Skip to main content

AEROSIM-TS-93

Project task

Define the governed secondary-camera registry

Every supported secondary view resolves through one typed identifier to a camera rig with explicit lifecycle behavior.

AEROSIM-TS-93Canonical ID TASK-0093
Verified flow state
Done
Owner
AeroSim Architecture and Delivery
Component
Web Application / R3F flight scene — secondary-camera registry
Repository
corp-v1-aerosim/corp-v1-aerosim

Delivery scope

Implement applications/web/src/flight/cameras/secondary-camera-registry.ts, applications/web/test/flight/secondary-camera-registry.spec.ts. Consume only the inputs listed in this contract, publish only its listed outputs, enforce every failure boundary before commit, and prove the listed exclusions remain unchanged through the verification steps.

Implementation contract

Implementation artifacts

  • applications/web/src/flight/cameras/secondary-camera-registry.ts
  • applications/web/test/flight/secondary-camera-registry.spec.ts

Inputs

  • A build-time list of SecondaryCameraDefinition { id, createRig, initialisationPolicy, disposalPolicy } entries.
  • AircraftFrame for the active attempt supplied to a created rig as read-only pose input.

Outputs

  • An immutable SecondaryCameraRegistry keyed by SecondaryCameraId with deterministic sorted identifiers and create/dispose functions for each supported view.
  • A created secondary rig that writes only its own camera resources and returns CameraFrame for the supplied aircraft sourceStep.

Failure boundaries

  • Fail registry construction on an empty, duplicate, or blank identifier, missing factory, or missing lifecycle policy; publish no partial registry.
  • Return UnsupportedSecondaryCamera for an identifier absent from the registry; do not substitute the primary camera or another secondary view.
  • If a rig emits a non-finite camera transform, reject that frame and dispose the faulty rig without changing aircraft or control state.

Excluded scope

  • Primary chase-camera implementation and initial active-flight camera selection.
  • Aircraft physics, control ownership, and persistence of user camera preferences.

Verification steps

  • Run applications/web/test/flight/secondary-camera-registry.spec.ts and assert every configured identifier resolves to exactly one rig and the identifier order is stable.
  • Instantiate, update, and dispose every rig against a fixed AircraftFrame trace; assert one disposal and writes only to rig-owned resources.
  • Mutate the fixture with duplicate/blank IDs, missing policies/factories, unknown selections, and non-finite rig output; assert construction or frame publication is rejected without fallback or flight-state writes.

Traceability

Requirements

Dependencies

Acceptance evidence

Verified delivery: application PR #149 reviewed head 4e0618d86d4887d650c7a07d81881aff214d9963 merged as 8e245f7eae5a9e9ba59414d9f6f50c06668fdb2e. The immutable secondary-camera registry validates the complete definition set before publication, snapshots definitions, sorts unique identifiers deterministically, returns UnsupportedSecondaryCamera without fallback, enforces explicit create/dispose lifecycle, supplies immutable AircraftFrame snapshots, rejects mismatched or non-finite CameraFrame output, disposes faulty rigs exactly once, and exposes no aircraft/control-state write surface. Focused registry tests pass 16/16; formatting, lint, typecheck, full repository tests, build, production audit, workflow/container/Helm contracts, candidate CI run 4503, integration validation run 4505, and immutable image publication run 4504 passed. Harbor readback resolved Nebula digest sha256:526fefaa71b7f4c3253a3b5f0b08f8af98a33bd2ff32ad4055c10217db3e7e93 and Singularity digest sha256:fc317cf1d70de307c4c7b5d5f88874d24b7303f4ffb8c10cabe8bdf2302eecc8 for the exact integration revision. Release completion verified on product 1.0.0.0 at GitOps revision 5d3712d89dfbf7dacd993348e55f497d126c7bf9 with Argo Synced/Healthy, exact image digests, authenticated API/database access, and three-world configured-flight acceptance.

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.