Verify the engineering delivery baseline
Use this reference before preparing an AeroSim implementation or release change. It records the engineering surface verified on 2026-09-03 at application test commit 5b2624e9b36e191b275b796a754109df30cb0e4c; it does not approve implementation, publication, deployment, or release. Documentation build evidence is deliberately labeled as the preceding verified baseline rather than the current page head, because embedding this page's own mutable head would make the evidence stale as soon as the page changed.
Repository and workspace
| Area | Current repository path or source |
|---|---|
| Browser application | corp-v1-aerosim/applications/web |
| API application | corp-v1-aerosim/applications/api |
| Shared flight logic | corp-v1-aerosim/packages/flight-core |
| Deployment charts | corp-v1-aerosim/helm-charts/aerosim-web and helm-charts/aerosim-api |
| Developer automation | corp-v1-aerosim/Taskfile.yml and .scripts/ |
| Validation workflow | corp-v1-aerosim/.gitea/workflows/validation.yml |
| Image-publication workflow | corp-v1-aerosim/.gitea/workflows/publication.yml |
| Documentation portal | corp-v1-aerosim-documentation |
Both repositories use pnpm workspaces and TypeScript. Application-specific environment names are listed in .env.example and retain the CORP_V1_AEROSIM_* namespace.
Development and testing
Install from the committed lockfile and run the complete validation surface:
corepack pnpm install --frozen-lockfile
corepack pnpm validate
In the application repository, pnpm validate now runs format:check before linting, type checks, Vitest tests, and production builds through Turborepo. Current automated tests cover the shared flight core and trainer, browser scene and telemetry behavior, trainer guidance, the browser application, and the API health route. The Taskfile exposes the adopted .scripts/application and .scripts/devbox modules; use task --list to discover their commands.
In the documentation repository, validate runs canonical-data validation and drift checks, the Node test suite, Scope/Architecture/Kanban validators, TypeScript checking, a strict Docusaurus production build, and built-relationship validation. Broken documentation links fail the build, and local search is generated during the build.
Build and CI
Gitea Actions validates pushes and pull requests targeting test.
| Repository | Exact-SHA workflow evidence |
|---|---|
| Application validation | Actions task 1701 (run 30) succeeded at 5b2624e9b36e191b275b796a754109df30cb0e4c |
| Application publication | Actions task 1700 (run 29) succeeded at 5b2624e9b36e191b275b796a754109df30cb0e4c |
| Documentation predecessor build | Actions task 1696 (run 427) succeeded at b4514c19320dde6a6969474e938f70ae4084a768 |
For every proposed change, match Actions tasks to the exact pull-request head_sha. A successful task at an older commit is health context, not acceptance evidence for a newer commit. Local validation and remote Actions are separate gates and must be reported separately.
The application validation workflow also checks that both Dockerfiles exist and runs helm lint for both charts. This validation result does not prove that an image or chart was published; publication has a separate exact-SHA Actions task.
Packaging and deployment preparation
The application repository contains Dockerfiles for applications/web and applications/api, plus Helm charts named aerosim-web and aerosim-api. Chart and package metadata currently declare 0.1.0, but no approved target version, Git tag, or Gitea release exists; metadata alone is not a version allocation.
The active publication workflow builds the web and API Dockerfiles, tags both images with the full source commit SHA, and pushes them to Harbor. It runs on pushes to test and release/gondor-v1-publication and uses Gitea secret references without exposing their values. Successful publication task 1700 proves that the workflow published images for source 5b2624e9b36e191b275b796a754109df30cb0e4c; it does not select those images for an environment, deploy them, accept a Feature, or create a release.
Deployment remains GitOps-managed. CI must not run kubectl or mutate a runtime environment directly. Any Gondor or Argo CD source change requires its own reviewed branch, evidence, and deployment approval.
Operations and troubleshooting
Issue #7 is closed by application PR #9. The repair made formatting part of the aggregate validation gate and documented two repository-specific exclusions: the self-hosted runner's checkout-local .pnpm-store/, and Helm Go-template YAML that Prettier cannot preserve safely. Failed PR-head task 1698 captured the runner-cache failure; replacement exact-head task 1699 passed after the exclusion. Both Helm charts passed helm lint before merge.
Use this sequence when delivery validation fails:
- Record the repository, branch, exact head SHA, and affected Actions task.
- Reproduce the failing command locally from the committed lockfile.
- Identify whether the failure is in source behavior, TypeScript, tests, Docusaurus, Docker definitions, Helm rendering, runner tooling, or credentials.
- Compare the intended fix with approved Feature requirements and architecture. Escalate contradictions rather than changing scope.
- Apply the smallest authorized fix and rerun the complete local validation surface.
- Push a focused branch, then require successful Actions tasks matched to the exact pushed SHA.
- Read back the remote branch and pull request before reporting completion.
Do not print credentials, suppress validation, or force-push shared work. Merge, publication, deployment, and release actions require the active project's explicit authority and every applicable implementation, review, security, Kanban, and release gate; successful CI alone is not authorization.
Historical implementation-gate snapshot
The following statement is bounded to 2026-08-13 and Discord evidence 1537468705724960798: the canonical Epic and four Features were Proposed and had no implementation evidence, dependency-aware tasks, or approved target version. Consult the generated canonical roadmap for current lifecycle state; the engineering baseline does not itself authorize Feature implementation.