Skip to main content

AEROSIM-TS-157

Project task

Fail closed on unusable rendered flight acceptance

Rendered-flight automation cannot pass an unusable release: production asset, camera, world, control, state, warning, route, and recovery failures are observable and fail closed.

AEROSIM-TS-157Canonical ID TASK-0157
Verified flow state
Done
Owner
AeroSim Architecture and Delivery
Component
Engineering validation — rendered-flight observability and acceptance
Repository
corp-v1-aerosim/corp-v1-aerosim

Delivery scope

Add visible and machine-readable production diagnostics for asset/camera/world initialization and frame failures. Replace attribute-only and fixture-only acceptance with all-nine-aircraft/all-four-camera pixel and visibility assertions, declared-binding probes, strict typed telemetry transitions, active-warning classification, and reset sequence/navigation capture. Keep labels/specifications distinct from active warnings and require ordinary route/navigation/recovery interactions.

Implementation contract

Implementation artifacts

  • corp-v1-aerosim/corp-v1-aerosim:applications/web/src/flight/FlightCanvas.tsx
  • corp-v1-aerosim/corp-v1-aerosim:applications/web/src/flight/SceneRoot.tsx
  • corp-v1-aerosim/corp-v1-aerosim:applications/web/e2e/rendered-flight-acceptance.browser.spec.ts
  • corp-v1-aerosim/corp-v1-aerosim:applications/web/e2e/control-contract-acceptance.browser.spec.ts
  • corp-v1-aerosim/corp-v1-aerosim:applications/web/e2e/reset-sequence-observability.browser.spec.ts
  • corp-v1-aerosim/corp-v1-aerosim:.gitea/workflows/validation.yml

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 0 lines 50-61: aircraft load problems have no production callback, world initialization discards exceptions, descendant errors become misleading WEBGL INITIALIZATION FAILED, camera rejection is unwired, and TASK-0147 browser acceptance checks only selected-card/data-camera-id attributes.
  • Root-cause summary 1 lines 51-64: Coastal UAT reported 30 target changes but seven were null-transition false positives and one was a coincident reset; only A/bank and Q/yaw were genuine in that probe set.
  • Root-cause summary 1 lines 84-110: STALL SPEED 140 KT is static airframe-envelope specification text, not an active warning. Root-cause summary 2 lines 67-77: fireEvent and forced setup interactions bypass browser hit-testing and geometry.

Outputs

  • Actionable visible and structured failure states identify aircraft asset, camera rig, world initialization/compositing, and frame lifecycle failures without mislabelling all descendants as WebGL initialization failure.
  • A release acceptance matrix covers all nine production aircraft × four camera modes under moving flight, declared bindings including gear/flaps, supported worlds/viewports, route exclusivity, recovery hit targets, and reset transition provenance.
  • CI rejects missing pixels/aircraft visibility, null-transition control false positives, static-label warning matches, hidden navigation/reset events, and ordinary-interaction bypass.

Failure boundaries

  • Fail when an asset/camera/world/frame error is swallowed, generalized incorrectly, or visible only in console output.
  • Fail when DOM attributes, nominal telemetry, clean console/network, fixture viewers, or static labels substitute for rendered usability and active-state evidence.
  • Fail when null↔value telemetry changes count as intended control response, when STALL SPEED 140 KT is classified as an active warning, or when reset attribution lacks attempt/source sequence plus route/navigation capture.

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: add negative fixtures proving the acceptance suite rejects missing aircraft, static cameras, broken world transforms/water depth, binding collisions, dual-state mismatch, composite routes, covered controls, null transitions, static warning labels, and hidden resets.
  • Run the exact production path for all nine aircraft and all four cameras in moving flight; assert pixel occupancy/visibility and camera semantics rather than only DOM attributes.
  • Run declared-binding probes and accept only same-command non-null typed changes; classify active warnings from the active-warning channel, never substring matches on specification labels.
  • Capture attempt ID, source step, route, navigation/load events, and explicit transition reason around every recovery/restart. All browser acceptance uses ordinary visible interactions: no force-click, hidden input, direct DOM/state/camera mutation, API setup, storage seeding, fixture-only renderer, or bypass.

Traceability

Requirements

Dependencies

Acceptance evidence

Verified delivery: PR #214 delivered the implementation and PR #215 merged the exact-camera review hardening as integration revision 70df7366b1dc2abd3a11acc021f56c711cd1bd57; all-nine-aircraft/all-four-camera rendered acceptance, declared controls, active-warning classification, reset provenance, exact-head and integration CI, immutable image publication, and 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.