Skip to main content

AEROSIM-TS-96

Project task

Apply control commands through the responsive flight loop

Each valid authoritative control command affects subsequent aircraft motion continuously within the declared timing and resource budgets.

AEROSIM-TS-96Canonical ID TASK-0096
Verified flow state
Done
Owner
AeroSim Architecture and Delivery
Component
Web Application / Deterministic flight runtime — Shared flight-core — control-command application and simulation update loop
Repository
corp-v1-aerosim/corp-v1-aerosim

Delivery scope

Implement packages/flight-core/src/control/apply-flight-control-command.ts, packages/flight-core/test/control/apply-flight-control-command.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

  • packages/flight-core/src/control/apply-flight-control-command.ts
  • packages/flight-core/test/control/apply-flight-control-command.spec.ts

Inputs

  • The next FlightControlCommand from TASK-0003 matching the active attempt and ownership epoch.
  • Previous authoritative AircraftState and FixedStepContext { stepIndex, dtSeconds, simulationTimeMs }.
  • FlightControlLimits with finite rate, force, clamp, and configured latency/resource limits.

Outputs

  • The next authoritative AircraftState and ControlApplication { commandSequence, appliedAtStep, resultingControlSurfaces } committed atomically for that fixed step.
  • InputToStateLatencySample from command sampledAt to the commit of the first state affected by that command.

Failure boundaries

  • Reject a command with stale attempt/epoch, duplicate or regressing sequence, non-finite channel, or channel outside normalized bounds; advance no state from that command.
  • Clamp the commanded rate/force using FlightControlLimits; never publish non-finite pose, velocity, force, or control-surface state.
  • If a step cannot commit, retain the previous AircraftState, mark the step failed, and do not consume the command sequence.

Excluded scope

  • Browser-device sampling and ownership assignment.
  • Changing aerodynamic equations, rendering instruments/cameras, or session lifecycle transitions.

Verification steps

  • Run packages/flight-core/test/control/apply-flight-control-command.spec.ts with fixed initial state and sustained, changed, and neutral command traces; assert each accepted command affects the next committed motion state in sequence.
  • Repeat identical traces and compare committed states and command application records; capture input-to-state samples and compare them with the configured limits.
  • Inject stale epochs, duplicate/regressing sequences, out-of-range and non-finite channels, and commit failure; assert no invalid state, command loss, or partial commit and enforce configured resource limits for the sustained fixture.

Traceability

Dependencies

Acceptance evidence

Verified delivery: application PR #137 reviewed head 6615e9397842f6b1a78140b47ed9dc1e43c00a72 merged as 02d7db9e740bc3761613b3e5c29b126622ef8322. Applied authoritative commands atomically through fixed steps with bounded rates, accelerations and latency, deterministic 600-step traces, rejection without state advance, and commit-failure retry. Flight-core: 286 tests including 11 focused cases. Exact-head and post-merge CI runs 4348, 4349, 4350, 4351 passed. 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.