Release 1 human review reference

This page is the human-review entry point for Release 1. It consolidates the cross-links a reviewer needs without converting implementation evidence into Scope, Architecture, UAT, release, or human acceptance.

Review verdict

The Release 1 design-to-architecture-to-Delivery input chain is cross-linked and reproducible. The canonical relationship validators, Docusaurus build, and exact human acknowledgements identify no unresolved cross-link contradiction in that chain.

This verdict is deliberately narrower than release readiness:

• UI/UX acknowledged the alignment ledger with no contradictions and no new approval;
• Delivery acknowledged the alignment evidence as reproducible;
• implementation admission, development deployment, UAT, candidate freeze, promotion, and final acceptance remain separate gates;
• rejected release 1.0.0.2 and chart 1.0.0+build.3 are not made valid by this page.

Immutable review baselines

Evidence set	Immutable identity	Human review link
Documentation and canonical relationships	217f1ecb427dce9c1e171988ef53222324f1f807	Documentation tree
Application source	1d651262dca9d82a765be39ea628b20f56d23812	Application tree
Approved UI/UX package	AEROSIM-UIUX-REL-1.0.0, Penpot revision 6608	Editable Penpot journey
Documentation exact-default validation	run 5791, job 11505	CI run
Current application artifact publication	source 1d651262dca9d82a765be39ea628b20f56d23812	Publication run 5801

The machine-readable link-verification report records authenticated API readback for every Gitea source/run link on this page. Penpot remains an authenticated human-review surface and is bound through the canonical design package and UI/UX acknowledgement.

A newer commit in any evidence set requires the affected links and claims to be revalidated. Artifact publication is not deployment or UAT.

Cross-link map

Follow this chain in both directions:

Penpot frame/state
  ↕ approved package AEROSIM-UIUX-REL-1.0.0
Feature ↔ FR/NFR ↔ Task
  ↕ implementation paths and retained evidence
C1 context ↔ C2 containers ↔ C3 Web components
  ↕ exact application source
rendering + physics + persistence boundaries
  ↕ CI/artifact/GitOps/UAT evidence owned by later gates

Review question	Authoritative reference	What it proves
Are all Release 1 Tasks classified and design links reciprocal?	UI/UX and NFR alignment ledger	162/162 Tasks classified; 66 design-bound Tasks; Task → design and design → Task ledgers; NFR status preserved
What is the approved design source?	Design package source	Immutable Penpot team, project, file, page, revision, frames, states, and Task backlinks
How do Features, requirements, Tasks, C4 elements, interfaces, and risks join?	Option A decision-ready draft and machine-readable report	Exact decision inputs for 33 Features without creating approval
What is the owned runtime boundary?	C1 context, C2 containers, Web C3	Browser flight authority, API persistence, PostgreSQL ownership, identity, protocols, and inactive Socket.IO boundary
Which decisions and risks remain open?	Architecture baseline and delivery-readiness architecture	Accepted/returned KDDs, security and operability risks, and fail-closed downstream gates
Did the owning channels acknowledge the package?	UI/UX acknowledgement and Delivery acknowledgement	No UI/UX contradiction; Delivery accepts the alignment supplement while retaining admission and lifecycle gates

Rendering architecture

Canonical chain: AEROSIM-FT-45 ↔ FR-0052 ↔ TASK-0025, TASK-0026, TASK-0027, and TASK-0139 ↔ Web C3.

Selected runtime stack

The shipped Web Application uses React 19.1.1, React DOM 19.1.1, React Three Fiber 9.3.0, Three.js 0.179.1, and Rapier compatibility package 0.19.2. The exact dependency and test command record is applications/web/package.json.

Rendering is browser-local:

1. FlightCanvas.tsx lines 290–427 own the React Three Fiber canvas boundary and readiness checks.
2. SceneRoot.tsx lines 257–353 and 388–497 bind the world, aircraft, environment, production cameras, and authoritative frame observer.
3. RepresentativeFlightScene.tsx lines 38–81 compose the rendered terrain and aircraft scene.
4. asset-manifest.ts and the asset schema govern asset identity and metadata.
5. The governed asset loader validates and loads browser assets; it is not an API catalogue.
6. Production camera rigs, world-space validation, environment presentation, HUD, warnings, and recovery consume the authoritative flight state through the implementation anchors listed in the Web C3 view.

Rendering authority rule: rendering consumes authoritative poses and frames. It does not integrate a second aircraft state or become physics authority.

Physics engine and flight authority

Canonical chain: AEROSIM-FT-46 ↔ FR-0053 ↔ TASK-0028, TASK-0029, and TASK-0030 ↔ Web C3.

Selected engine

Rapier (@dimforge/rapier3d-compat 0.19.2) is the rigid-body and collision engine. AeroSim wraps it in an application-owned deterministic contract rather than exposing Rapier directly as the product architecture.

• RapierFlightWorld.tsx, especially createRapierFlightWorld at lines 101–213 and restore/reset/dispose at lines 260–385, creates the Rapier world, binds the fixed timestep, evaluates governed forces and wind, records collisions, and exposes atomic restore/reset/dispose operations.
• simulation-clock.ts, FixedStepClock at lines 66–185, owns the 1/60-second step, five-step catch-up cap, input sampling, snapshots, and interpolation contract.
• production-physics.ts, lines 36–134, selects class-specific aircraft handling and environment profiles.
• representative-flight-runtime.ts, lines 105–220, joins Rapier, collision classification, boundary policy, recovery, and the rendered aircraft transform.
• authoritative-flight-state.ts, lines 23–36 and 145–257, projects one attempt ID, source step, immutable render state, snapshot, and transition record.
• deterministic-flight.test.ts and variable-frame-authority.test.ts verify repeatability and that render-frame partitioning does not replace fixed-step authority.

Explicit boundary

• Physics authority is browser-local and fixed-step at 60 Hz.
• The API persists authenticated pilot data and outcomes; it does not advance flight physics.
• Socket.IO libraries, contracts, route, and tests exist, but production flight composition does not instantiate the realtime flight client and the API has no production command forwarder. Valid commands fail closed with COMMAND_FORWARDER_UNAVAILABLE.
• No server-authoritative, multiplayer, anti-tamper, or competitive-flight claim is made.
• A deliberate restart may create a new provenance-linked attempt; ordinary flight, pause, recovery, completion, and abort must preserve the active attempt identity.

Exact physics conformance findings for human decision

The links above are now complete, but they deliberately expose these implementation-to-contract differences rather than hiding them:

1. Direct Rapier integration: Proposed AEROSIM-FT-46 / FR-0053 names Rapier and @react-three/rapier; the current Web package depends on @dimforge/rapier3d-compat and drives Rapier directly from React Three Fiber. @react-three/rapier is not the active adapter. Scope/Architecture must either narrow the Proposed wording to the implemented direct adapter or require the named adapter.
2. Integration authority split: flight-core supplies contracts, validation, fixed-step timing, wind, and force evaluation. Active state integration occurs in Rapier. The Rapier path applies evaluateFlightForces().netForceWorldN but uses pilotAuthoritativeMoment instead of the core result's netMomentBodyNm.
3. Aircraft configuration split: revision-bound launch metadata and a digest-checked JSON aircraft catalogue exist, but the active Rapier path selects hard-coded class profiles from production-physics.ts. For example, the JSON trainer configuration and active trainer profile do not currently share one mass value. This is an implementation-conformance decision, not a broken documentation link.
4. Terrain collision simplification: the visible governed GLB world is rendered through Three.js, while the active representative physics runtime registers one fixed terrain cuboid. A validated heightfield adapter exists but is not wired into the shipped representative runtime.
5. Identity fragmentation: the authoritative attempt ID is explicit, but pre-flight session ID, world-resource identity, recovery session key, and persisted completion identity are not one unified end-to-end identifier. Recovery currently uses a fixed representative-session key.
6. Landing semantics: independent landing-gear contact is not modeled; terrain contact fails closed as a non-landing rather than creating an unsupported successful landing claim.
7. Determinism boundary: tests establish fixed-step repeatability and render-frame partition independence for the governed suites. They do not establish bitwise determinism across every browser, CPU, Rapier/WASM engine, or unsupported device.

These findings do not invalidate the browser-local authority decision. They are the exact review points a human must accept, narrow, or return before claiming complete implementation conformance.

Tooling and delivery pipeline

Canonical chains: AEROSIM-FT-41 ↔ FR-0048 ↔ TASK-0011, TASK-0012, TASK-0013, and TASK-0117 for the React/Vite/TypeScript foundation. AEROSIM-FT-51 ↔ FR-0058 ↔ Documentation Site C3 ↔ TASK-0043, TASK-0044, TASK-0045, TASK-0046, TASK-0157, and TASK-0162 for governed engineering validation. Application CI and publication files are linked below because Delivery uses them, but the canonical FR-0058 C4 allocation remains the Documentation Site.

Concern	Exact source	Human interpretation
Workspace and orchestration	root package.json, pnpm-workspace.yaml, turbo.json	Node 22+, pnpm 10.15.1, Turbo, TypeScript 5.9.2
Application build	Web package, Vite config	Vite SPA with typed compile/build and runtime environment validation
Unit/component/physics tests	Web package scripts	Vitest, React Testing Library, React Three test renderer, deterministic physics and rendering suites
Browser and design conformance	Playwright config	Playwright journeys for routes, assets, cameras, recovery, design conformance, GPU/runtime budgets, and long-flight evidence
Branch and PR validation	feature-branch-push.yaml, application-validation.yaml	Exact source validation before merge
Immutable artifact publication	publish-images.yaml	Images and the immutable OCI Helm chart are published in coordinated jobs, separately from GitOps deployment
Container and Helm runtime	Web Dockerfile, AeroSim chart	Nginx-served SPA plus API and environment-specific runtime configuration

The root validate command still uses VITE_PRODUCT_RELEASE=1.0.0.2 as a validation input. That string is not a reusable candidate identity; the rejected Release 1.0.0.2 / chart 1.0.0+build.3 remains rejected.

Human cross-link review checklist

1. Open the approved Penpot page and confirm revision 6608.
2. Open the design package source; select a design reference and follow its owning Tasks in the reverse ledger.
3. From a Task, verify its Feature, FR/NFR, classification, implementation paths, and evidence; follow back to the same design reference.
4. Open the C1, C2, and Web C3 views and verify the browser-local rendering/physics boundary agrees across all three.
5. Inspect RapierFlightWorld.tsx, SceneRoot.tsx, and authoritative-flight-state.ts; verify physics produces the frame and rendering consumes it.
6. Confirm no production composition call site invokes connectSocket() for the flight path; tests and scaffold definitions do not establish runtime use.
7. Open the exact CI and publication runs; do not infer GitOps deployment or UAT from green publication.
8. Confirm the UI/UX and Delivery acknowledgements retain all downstream gates.

Remaining human decisions

There are no known unresolved cross-link contradictions in the Release 1 input chain at the baselines above. The following are not cross-link defects and remain intentionally open:

• exact Scope disposition for the Option A package and proposed FT-56 controls;
• Architecture implementation approval and exact-task Kanban admission;
• one immutable application/image/chart/GitOps/environment tuple;
• verified development Argo CD state and endpoint;
• complete authenticated UAT;
• candidate freeze, promotion authorization, production verification, remaining Task reconciliation, and human acceptance.