Deliver AeroSim changes

This how-to defines the initial delivery workflow for contributors.

What you will need

• An agreed user or engineering outcome
• Access to the application or documentation repository
• A branch from test

Workflow

1. Describe the observable outcome and acceptance evidence in an issue.
2. Keep the change within one coherent capability boundary.
3. Add automated checks at the lowest useful level.
4. Run formatting, type, unit, integration, and build gates that apply.
5. Open a pull request into test and link the issue.
6. Publish immutable application images after exact-head CI succeeds.
7. Delivery immediately renders the single-environment Copier template with development inputs into corp-v1-aerosim/gondor-v1-aerosim-dev; Argo CD, not CI or a contributor shell, deploys it to https://aerosim-dev.apps.lego-cloud.eu.
8. Verify the exact rendered GitOps revision is Synced and Healthy, then hand the frozen deployment tuple to UAT.
9. Run the versioned corp-v1-aerosim-e2e journeys against that endpoint and preserve evidence.
10. Route failed journeys back to Kanban/Delivery; route UAT_PASSED evidence to Releases, which alone may render and promote production through corp-v1-aerosim/gondor-v1-aerosim at https://aerosim.apps.lego-cloud.eu.

Definition of done

A change is done only when its canonical lifecycle gates are complete. Implementation completion requires reviewed behavior, green exact-head checks, immutable image publication, and a verified development GitOps deployment. UAT evidence remains a separate verdict, and Releases alone records final production promotion and Task DONE. Documentation must match the delivered contract, operational signals must exist where needed, and no credentials or generated local state may be committed.