Introduce Automated Engineering Validation

Overview

User capability

Establish tests, linting, type checking, and production builds

User

The AeroSim delivery team

What the user can do

Establish tests, linting, type checking, and production builds

Why the user benefits

The capability becomes an explicit, testable project boundary.

User need

The delivery team needs the AeroSim solution to establish tests, linting, type checking, and production builds.

In scope

Establish tests, linting, type checking, and production builds

• StatusProposed
• OwnerAeroSim Scope (proposed; not accepted)
• Parent EpicAEROSIM-EP-1
• Depends onAEROSIM-FT-41, AEROSIM-FT-42, AEROSIM-FT-43, AEROSIM-FT-45, AEROSIM-FT-46

Tasks

AEROSIM-TS-43Planning status: Done

Standardize local lint, type, test, and build commands

The application monorepo exposes deterministic root commands for linting, type checking, testing, and production builds across Nebula, Singularity, persistence, rendering, and physics packages.

• ComponentWeb Application and API Service build boundaries — Application monorepo — validation toolchain
• Depends onAEROSIM-TS-13, AEROSIM-TS-16, AEROSIM-TS-20, AEROSIM-TS-27, AEROSIM-TS-30
• RequirementsFR-0058, NFR-0007

AEROSIM-TS-44Planning status: Done

Run the local validation contract in Gitea Actions

Gitea Actions invokes the same lint, type, test, and production-build entry points used locally and fails when any required gate fails.

• ComponentGitea Actions — application validation workflow
• Depends onAEROSIM-TS-43
• RequirementsFR-0058, NFR-0007

AEROSIM-TS-45Planning status: Done

Bind CI success to the immutable candidate head

The workflow records and reports the exact candidate commit and cannot publish a successful aggregate result until every required gate for that commit passes.

• ComponentGitea Actions — exact-head result gate
• Depends onAEROSIM-TS-44
• RequirementsFR-0058, NFR-0007

AEROSIM-TS-46Planning status: Done

Test validation parity and fail-closed aggregation

Automated workflow-contract tests prove local and CI gate parity, immutable-SHA binding, and failure of the aggregate result when any required gate is removed, skipped, or failed.

• ComponentWeb Application and API Service build boundaries — Application monorepo — CI contract tests
• Depends onAEROSIM-TS-45
• RequirementsFR-0058, NFR-0007

AEROSIM-TS-157Planning status: Done

Fail closed on unusable rendered flight acceptance

Rendered-flight automation cannot pass an unusable release: production asset, camera, world, control, state, warning, route, and recovery failures are observable and fail closed.

• ComponentEngineering validation — rendered-flight observability and acceptance
• Depends onAEROSIM-TS-13, AEROSIM-TS-16, AEROSIM-TS-20, AEROSIM-TS-27, AEROSIM-TS-30, AEROSIM-TS-150, AEROSIM-TS-151, AEROSIM-TS-152, AEROSIM-TS-153, AEROSIM-TS-154, AEROSIM-TS-155, AEROSIM-TS-156
• RequirementsFR-0058

AEROSIM-TS-162Planning status: Done

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.

• ComponentEngineering validation — production long-flight UAT release gate
• Depends onAEROSIM-TS-157
• RequirementsFR-0058

Acceptance outcomes

1. 01

   The declared local validation and Gitea Actions run the same lint, type, test, and production-build gates.

2. 02

   CI reports success only for the exact immutable candidate head after every required gate passes.

Functional requirements and measurable criteria

FR-0058

Introduce Automated Engineering Validation

The system shall establish tests, linting, type checking, and production builds.

Acceptance 01

GivenAEROSIM-FT-51 is exercised within its governed scope under supported conditions

Whenthe primary capability path is completed

ThenThe declared local validation and Gitea Actions run the same lint, type, test, and production-build gates

EvidenceFuture reviewed automated and browser evidence must verify this exact outcome against the current requirement.

Acceptance 02

GivenAEROSIM-FT-51 is exercised within its governed scope under supported conditions

Whenthe continuation or repeat path is completed

ThenCI reports success only for the exact immutable candidate head after every required gate passes

EvidenceFuture reviewed automated and browser evidence must verify this exact outcome against the current requirement.

Non-functional requirements

• NFR-0007 — Engineering reproducibility and supply-chain integrity

  Repeated validation from the same immutable inputs produces equivalent artifacts and rejects unlicensed, untraceable, invalid, or over-budget inputs.

Risks

• Risk

  Partial introduction could leave an ungoverned or duplicated technical boundary.

Original source and prototype evidence

• discord: Engineering Features grounded in the selected AeroSim technology stack.
• discord: Engineering Feature decomposition continuation.
• discord: RootAtSkic directed publication of the agreed Scope update.

Prototype and discovery boundary

Existing implementation is discovery evidence only; it establishes no current approval, acceptance, or release state.