Skip to main content

Release 1.0.0 Task Board

This Board is the execution sequence for release 1.0.0. It contains only active canonical Tasks allocated to that release; Epics, Features, later-release work, and terminal Tasks are excluded.

Loading interactive AeroSim board…
  • Release 1.0.0 Tasks grouped by dependency-ordered delivery wave
View accessible data table
Canonical itemTypeDelivery waveStatus basisLifecycleOwnerParentDependenciesTarget versionOpen questionsLatest evidenced decision
AEROSIM-TS-171 — Remove redundant camera confirmation stepTaskWave 37Exact item evidenceToBeReleasedAeroSim Architecture and DeliveryAEROSIM-FT-17AEROSIM-TS-136 (Done)1.0.0None2026-09-27
AEROSIM-TS-172 — Correct Training Airfield UAT imagery seams and atmospheric continuityTaskWave 37Exact item evidenceToBeReleasedAeroSim DeliveryAEROSIM-FT-47AEROSIM-TS-160 (Done)1.0.0None2026-09-29
AEROSIM-TS-173 — Correct hidden terminal flight state after automatic recoveryTaskWave 37Exact item evidenceToBeReleasedAeroSim DeliveryAEROSIM-FT-1AEROSIM-TS-158 (Done)1.0.0None2026-09-29
AEROSIM-TS-174 — Compact flight controls into the right-side HUD and match Camera to MenuTaskWave 37Exact item evidenceToBeReleasedAeroSim DeliveryAEROSIM-FT-4AEROSIM-TS-125 (Done)1.0.0None2026-09-29
AEROSIM-TS-175 — Replace Coastal Range with the approved documentation terrain modelTaskWave 37Exact item evidenceToBeReleasedAeroSim DeliveryAEROSIM-FT-45AEROSIM-TS-139 (Done)1.0.0None2026-10-01

How waves are calculated​

A wave is a dependency layer calculated from each Task's canonical dependencies and any approved non-retroactive scheduling floor:

  • Wave 01 contains Tasks with no Task dependencies.
  • A later wave contains a Task only after every dependency is assigned to an earlier wave.
  • delivery_wave_floor may place newly admitted correction work no earlier than an approved open wave. The effective wave is the greater of its dependency wave and its floor; it must never move a Task into an already completed wave.
  • Completed dependencies keep their wave position in the calculation but are omitted from the active Board.
  • READY_FOR_DELIVERY Tasks in the current wave must be claimed in parallel up to available Delivery capacity. Their exact status already records Focus admission; no additional approval follows wave selection.

Release 1.0.0 design-conformance placement​

The second production rejection and verified 36/36 failed ordinary-user UAT extend the release plan to 35 waves without rewriting completed Waves 1–34:

WaveAdded design-bound work
24AEROSIM-TS-117 freezes the Penpot Release 1.0.0 implementation baseline.
25AEROSIM-TS-118 through AEROSIM-TS-126 correct Entry, Profile, Settings, Home, Hangar, Flight Setup, HUD/warnings, and Chase without rewriting completed Waves 1–23.
29AEROSIM-TS-127 verifies the complete in-scope journey after feature-level work.
30Existing AEROSIM-TS-110 remains the final configuration-and-design integrity gate. Release-owned siblings AEROSIM-TS-129 through AEROSIM-TS-132 freeze the candidate, publish the operational plan, prepare the reviewed GitOps change, and perform separately approved deployment, verification, rollback evidence, and closure.
31AEROSIM-TS-133 through AEROSIM-TS-146 record and deliver the authenticated production-acceptance corrections against the exact deployed Release 1.0.0.0 application.
32AEROSIM-TS-147 corrects the unusable initial-camera selector under AEROSIM-FT-17; AEROSIM-TS-148 corrects metre-scale world-boundary policy under AEROSIM-FT-2. Both are exact READY_FOR_DELIVERY replacement-release work.
33AEROSIM-TS-149 through AEROSIM-TS-156 are DONE; their reviewed integrations are included in the cumulative deployed Release 1.0.0 revision.
34AEROSIM-TS-157 is DONE; its fail-closed rendered-flight observability integration is included in the cumulative deployed Release 1.0.0 revision.
35AEROSIM-TS-158 through AEROSIM-TS-163 are DONE: pilot-authoritative dynamics, attempt continuity, world composition, camera usability, the long-flight release gate, and removal of foreign or duplicated aircraft geometry.

RootAtSkic requested the Wave 35 improvements and per-journey UAT evidence in Discord message 1550551559899848705, then required flight videos and explicit Tasks for the uncontrollable plane and every additional observed defect in messages 1550580266580447333 and 1550583772309889217. RootAtSkic subsequently admitted the complete six-Task wave for immediate Delivery pickup in message 1550784733464498299. Each Task has tests-first verification, exact UAT evidence, objective acceptance, and an ordinary-browser no-bypass boundary. RootAtSkic later directed release-completion reconciliation for Waves 33–34 in Delivery message 1553334979155730457; their nine integration revisions were verified as ancestors of the same deployed revision that closed Wave 35.

The earlier Release 1.0.0.2 deployment with chart 1.0.0+build.3 was technically healthy but automated production UAT failed 36/36, and RootAtSkic reported that the aircraft circled automatically and could not be flown with the keyboard. Production acceptance for that immutable release identity remains REJECTED. Waves 33–35 preserve that failure evidence and the corrective-release lineage; their technical Task closure does not rewrite the rejected release or imply human post-release acceptance.

Wave placement is calculated presentation data. It does not by itself change Scope, Architecture, Delivery progress, or release approval. A bare or forged status cannot move a Task; governed flow changes still require the canonical hash-linked, append-only flow_history evidence.

Use the expand control above the diagram for the full-screen dependency view. The accessible table is generated by the same canonical selector and preserves Task links, owners, dependencies, target version, lifecycle status, and evidence.