Skip to main content

AEROSIM-TS-162

Project task

Gate releases on long-flight control and visual UAT

Release automation rejects a build that accepts key events but cannot sustain pilot-directed flight or produces unusable production screenshots.

AEROSIM-TS-162Canonical ID TASK-0162
Verified flow state
Done
Owner
AeroSim Architecture and Delivery
Component
Engineering validation — production long-flight UAT release gate
Repository
corp-v1-aerosim/corp-v1-aerosim

Delivery scope

Add a production-path UAT gate covering three worlds, all aircraft classes and models, all four cameras, all condition presets, neutral-flight stability, opposite-command control authority, attempt continuity, world identity, camera usability, warnings, and final screenshot evidence. Keep displayed control-value changes separate from proven aircraft response.

Implementation contract

Implementation artifacts

  • applications/web/e2e/production-long-flight-uat.browser.spec.ts
  • applications/web/e2e/pilot-control-authority.browser.spec.ts
  • .gitea/workflows/validation.yml
  • scripts/validate-production-uat-evidence.mjs

Inputs

  • Release 1.0.0.2 passed prior pixel/diversity and control-transition automation but failed all 36 production UAT journeys.
  • Existing checks proved visible slider transitions without proving stable pilot-authoritative aircraft motion.
  • RootAtSkic requested per-journey UAT screenshots and reported unusable keyboard flight control in Discord message 1550551559899848705.
  • RootAtSkic rejected the screenshot quality and required video-based analysis plus explicit Tasks for the uncontrollable aircraft and all other observed defects in Discord messages 1550580266580447333 and 1550583772309889217.

Outputs

  • One immutable evidence bundle with a result, screenshot, and continuous flight recording for every governed production journey.
  • Fail-closed neutral stability, signed control-response, attempt-continuity, camera, world, and visual-quality assertions.
  • A release gate that distinguishes technical deployment health, automated UAT, and explicit human acceptance.

Failure boundaries

  • Fail when control widgets change but aircraft trajectory does not respond directionally.
  • Fail on implicit reset, black/empty frame, wrong world, unusable camera, visible terrain defect, detached or duplicated aircraft geometry, or missing journey screenshot/video.
  • Fail when clean console/network signals or pixel diversity substitute for flight usability.

Excluded scope

  • Automation never declares human acceptance.
  • No forced click, hidden input, direct DOM/state mutation, fixture renderer, storage seeding, or direct API setup may count as journey evidence.

Verification steps

  • Reproduce the Release 1.0.0.2 failure corpus as negative fixtures before implementing the stronger gate.
  • Run 36 ordinary production journeys for at least 60 seconds and retain labeled per-journey screenshots, videos, sampled frames, and structured HUD/control/attempt timelines.
  • Require independent visual review and exact-head CI before release admission.

Traceability

Requirements

Dependencies

Acceptance evidence

Verified release completion: merged revision dbba4a186a02cb4567c64f1c3400d38556aa1a25 activated the production-path long-flight control and visual UAT gate on the default branch. Publication run 5546 passed required validation, all three complete long-flight shards, evidence aggregation, image build, and image publication. RootAtSkic accepted TASK-0162 as complete and assigned the remaining duplicated/inconsistent CI execution problem to separate Release 2.0 CI-efficiency scope; integration run 5547 is not represented as successful evidence. Release completion was verified on deployed revision dbba4a186a02cb4567c64f1c3400d38556aa1a25; human post-release acceptance remains PENDING.

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.