Files
portal/docs/projects/aerosim.md
T
jarvis-at-skic 966adeb1bd
Build and publish Corp v1 steering documentation / build (push) Successful in 33s
docs: align AeroSim channel lifecycle
2026-08-13 13:43:36 +00:00

113 lines
6.0 KiB
Markdown

---
title: AeroSim
sidebar_position: 1
---
# AeroSim
| Field | Value |
|---|---|
| Code | `aerosim` |
| Status | Active — lifecycle alignment reviewed |
| Started | 2026-08-12 |
| Sponsor and accountable lead | RootAtSkic |
| Initial technical member | `jarvis-at-skic` / Hermes code agent |
| Team | [AeroSim Team](/teams/aerosim/) |
## Purpose
Build a browser-based flight simulator supporting several aircraft classes with a shared, extensible flight model and scenario system.
## Initial deliverable
A playable MVP covering a light trainer, commercial airliner, and fighter-style aircraft, with shared flight controls, live telemetry, basic safety warnings, and foundational scenarios.
## Success measures
- A browser user can select and control all three aircraft classes.
- Shared flight behavior is implemented in a reusable typed package.
- Web and API applications build, test, and package independently.
- Architecture, user guidance, ways of working, and engineering standards are published.
- CI validates the monorepo and documentation on every change.
## Scope
- Browser simulator cockpit and controls.
- Trainer, airliner, and fighter-style aircraft profiles.
- Shared flight-core package and API endpoints.
- Docker and Helm packaging.
- Documentation and architecture sources.
## Exclusions for the first deliverable
- Certified training use.
- Real-world avionics fidelity claims.
- Multiplayer, global scenery streaming, and production deployment.
## Resources
- Project organization: [corp-v1-aerosim](https://gitea.lego-cloud.eu/corp-v1-aerosim)
- Skills organization: [corp-v1-aerosim-skills-code-agent](https://gitea.lego-cloud.eu/corp-v1-aerosim-skills-code-agent)
- [Application repository](https://gitea.lego-cloud.eu/corp-v1-aerosim/corp-v1-aerosim) — `test` at `14b5c0e8f25215d8bb4f41edcc0cdff4a87c342c`
- [Documentation repository](https://gitea.lego-cloud.eu/corp-v1-aerosim/corp-v1-aerosim-documentation) — `test` at `5f674525f6c8b5ce29fe2653350c6188fb97ea01`
- [Published documentation](https://pages.apps.lego-cloud.eu/corp-v1-aerosim/corp-v1-aerosim-documentation/) — protected by the existing Keycloak access layer
## Discord
Exactly four same-project channels exist under category `corp-v1` (`1537070242335821924`):
- `corp-v1-aerosim-general` — `1537227679374508132`
- `corp-v1-aerosim-architecture` — `1537227680590733383`
- `corp-v1-aerosim-delivery` — `1537227683191197807`
- `corp-v1-aerosim-releases` — `1537388451501056081`
Hermes bot `1526860732917088266` successfully read, posted, and pinned project guidance. The general introduction is pinned as message `1537227685657444484`. The releases purpose message is `1537388452658815077`. RootAtSkic was resolved as Discord member `1518725627845283888`.
Four staggered recurring synchronization jobs are active. Every job runs each hour, monitors only the other three AeroSim channels, loads its mapped adopted channel skill, proactively performs useful safe work within that channel's purpose, and records durable work in project documentation:
- General: `6fc9c6a1328e`, `0 * * * *`, skill `corp-v1-channel-general--aerosim`, target `1537227679374508132`
- Architecture: `c236b1e9642e`, `15 * * * *`, skill `corp-v1-channel-architecture--aerosim`, target `1537227680590733383`
- Delivery: `fdb061087f2f`, `30 * * * *`, skill `corp-v1-channel-delivery--aerosim`, target `1537227683191197807`
- Releases: `9deaa76e0077`, `45 * * * *`, skill `corp-v1-channel-releases--aerosim`, target `1537388451501056081`
All four jobs are enabled and restricted from cross-project inspection and approval-required, destructive, secret-bearing, or high-impact autonomous actions.
## Adopted project skills
All use default branch `test` and are primary for AeroSim work:
- `development-branching-strategy--aerosim`
- `development-gitops-argo-cd--aerosim`
- `development-monorepo-pnpm--aerosim`
- `development-scripts--aerosim`
- `devsecops-ci-cd-gitea--aerosim`
- `documentation-docusaurus--aerosim`
- `drawio-main--aerosim`
- `template-engine-copier--aerosim`
- `corp-v1-channel-general--aerosim`
- `corp-v1-channel-architecture--aerosim`
- `corp-v1-channel-delivery--aerosim`
- `corp-v1-channel-releases--aerosim`
Each repository records the central source branch and commit in `ADOPTION.md`.
Current steering policy defaults to seven adopted engineering skills plus four channel skills and references global `drawio-main`. AeroSim retains the historical `drawio-main--aerosim` repository pending an explicit team decision to retain it as an approved exception or retire it; no repository was deleted during alignment.
## Verification
- Application Actions run `2359`: successful.
- Documentation Actions runs `2354` and `2361`: successful, including Gondor Pages publication and the authoritative steering links.
- Documentation lifecycle alignment commit `5f674525f6c8b5ce29fe2653350c6188fb97ea01` and Actions run `609`: successful.
- Application tests: four passed across web, API, and shared flight core.
- Application and documentation production builds: passed.
- Project-team access to both project repositories: verified.
- Skills-team organization contains all twelve adopted skill repositories on default branch `test`: verified.
- Harbor organization variable names and secret name `HL_V1_HARBOR_ROBOT_GITEA_ACTIONS_V1_SECRET`: verified without reading secret values.
- Product lifecycle, solution traceability, and release-readiness registries now exist in project documentation. No Epic or Feature was assigned human approval retrospectively.
- Both application and documentation `test` branches currently have no branch-protection rule.
## Outstanding governance decisions
1. A human team member must decide whether to retain `drawio-main--aerosim` as an explicitly approved project copy or use only global `drawio-main` and retire the copy through the normal reviewed process.
2. A human team member must approve the desired branch-protection policy for both project `test` branches before protection is configured. No protection was added autonomously because required approvals and merge semantics are a governance decision.