Skip to main content

AEROSIM-TS-154

Project task

Unify rendered flight state, telemetry, warnings, and recovery

Rendered motion, telemetry, warnings, initial state, boundary/collision recovery, and explicit restart have one authoritative state relationship with no unsynchronized dual-state behavior or ambiguous uncommanded reset.

AEROSIM-TS-154Canonical ID TASK-0154
Verified flow state
Done
Owner
AeroSim Architecture and Delivery
Component
Web Application — authoritative flight-state relationship
Repository
corp-v1-aerosim/corp-v1-aerosim

Delivery scope

Establish a single authoritative flight snapshot or an explicit one-way projection from one simulation authority. Render aircraft/cameras/world, DOM telemetry, warnings, controls, collision/boundary recovery, and restart from the same attempt ID, source step, and initial-state contract. Distinguish automatic bounded recovery from an explicit full restart and record each transition with reason and sequence.

Implementation contract

Implementation artifacts

  • corp-v1-aerosim/corp-v1-aerosim:packages/flight-core/src/index.ts
  • corp-v1-aerosim/corp-v1-aerosim:applications/web/src/App.tsx
  • corp-v1-aerosim/corp-v1-aerosim:applications/web/src/flight/SceneRoot.tsx
  • corp-v1-aerosim/corp-v1-aerosim:applications/web/src/flight/physics/representative-flight-runtime.ts
  • corp-v1-aerosim/corp-v1-aerosim:applications/web/src/flight/recovery-boundary-runtime.ts
  • corp-v1-aerosim/corp-v1-aerosim:applications/web/test/flight/authoritative-state.browser.spec.ts

Inputs

  • RootAtSkic authorized Wave 33 correction work in Discord message 1549867630800666695 and then asked the exact completeness question in message 1549881095363760179; this admission supplies the missing repair Tasks without modifying the separately claimed TASK-0149.
  • Deployed application source ab085692e2ed70bdb6525044b4ca91cc48a27478 for product 1.0.0.1; release 1.0.0.1 remains deployed, human acceptance FAILED, production REJECTED, and a replacement release is required.
  • Ordinary-user UAT evidence: /opt/data/corp-v1-aerosim-releases/workspace/uat-1.0.0.1-training-airfield-rerun/report.md and report.json (12/12 failed), /opt/data/corp-v1-aerosim-releases/workspace/uat-1.0.0.1-coastal-range/uat-report.md and uat-report.json (12/12 failed), and /opt/data/corp-v1-aerosim-releases/workspace/uat-1.0.0.1-mountain-valley/report.md and report.json (12/12 failed). All three runs prohibit forced clicks, hidden-input interaction, DOM/state mutation, direct API setup, or other bypass.
  • Diagnosed root-cause records: /opt/data/cache/delegation/subagent-summary-0-20260916_203916_911368.txt, /opt/data/cache/delegation/subagent-summary-1-20260916_203916_911707.txt, /opt/data/cache/delegation/subagent-summary-2-20260916_203916_911857.txt.
  • Root-cause summary 1 lines 66-82: App advances a simplified DOM telemetry runtime while SceneRoot independently advances Rapier render state from different initial conditions, allowing 850 kt/1,600 ft telemetry while the visible aircraft starts at 12 m and zero velocity.
  • Training Airfield rerun reported position resets in 12/12 journeys; diagnosis lines 118-141 found explicit UI restart and separate Rapier automatic recovery with no timer/Arrow full restart and insufficient sequence/navigation evidence to attribute coincident drops.
  • STALL SPEED 140 KT is static specification text, not an active warning; active stall warning thresholds are separate and must remain so.

Outputs

  • One authoritative attempt/source-step identity shared by rendered aircraft, telemetry, warnings, camera targets, controls, and recovery decisions.
  • Explicit transition records distinguish launch, automatic bounded recovery, collision/boundary outcome, and user-requested restart.
  • Initial and restarted state are defined once and projected consistently to render and DOM surfaces.

Failure boundaries

  • Fail when rendered and presented state can advance independently, disagree on attempt/source step, or recover/reset one surface without the others.
  • Fail when a position drop is classified as restart without an explicit transition, or when static STALL SPEED 140 KT specification text is treated as an active warning.

Excluded scope

  • No application implementation is performed by this admission change.
  • Do not rewrite TASK-0149, infer a router-retention defect, report working Menu Restart as failed, classify static STALL SPEED 140 KT specification text as an active warning, or broaden governed interaction scope beyond the exact interaction semantics stated here.

Verification steps

  • Tests first: reproduce divergent render/DOM state, one-sided recovery, stale camera target, and ambiguous reset before introducing the authoritative relationship.
  • Run deterministic timed input traces from launch, collision, boundary recovery, and explicit restart; assert render, telemetry, warnings, controls, and sequence/navigation evidence agree at every sampled step.
  • Exercise ordinary browser controls and visible recovery paths without direct runtime mutation. No force-click, synthetic state injection, DOM mutation, API setup, or browser bypass is acceptance evidence.

Traceability

Requirements

Dependencies

Acceptance evidence

Verified delivery: PR #209 reviewed head f6245731984d7bf75d347d51e2b1b2502032c852 merged as 2e52a3fc896a8fd94c4aef86d9bc09d746ed4f52; exact-head run 5306, integration run 5310 attempt 2, publication run 5309 attempt 2, ordinary visible-interaction browser acceptance, and immutable Harbor readback passed.

Current evidence boundary

No current implementation, acceptance, release, or deployment evidence is claimed for this planned Task. Any prior implementation may be used only as prototype and discovery evidence.