Promote and verify AeroSim Release 1.0.0

Overview

User capability

Freeze the exact Release 1.0.0 candidate, publish the operational plan, prepare the reviewed GitOps change, and execute approval-gated deployment and closure.

User

The AeroSim release team

What the user can do

Promote one immutable, reviewed Release 1.0.0 candidate and verify its production result.

Why the user benefits

Release execution is exact, approval-gated, observable, and reversible.

User need

Release operators need one governed package that joins immutable candidate identity, accurate release notes, review-only GitOps preparation, separate deployment approval, runtime acceptance, rollback evidence, and canonical closure.

In scope

Release-management work for AeroSim 1.0.0 from immutable-candidate freeze through approval-gated production verification and canonical Task closure; no deployment occurs from this documentation change.

• StatusApproved for Solution
• OwnerAeroSim Releases
• Parent EpicAEROSIM-EP-9
• Depends onNone

Tasks

AEROSIM-TS-129Planning status: Done

Freeze immutable Release 1.0.0 candidate

One immutable candidate binds the exact application source revision, Harbor web and API digests, chart revision, GitOps template revision, and rendered GitOps revision.

• ComponentRelease management — immutable candidate evidence
• Depends onNone
• RequirementsFR-0059, NFR-0007

AEROSIM-TS-130Planning status: Done

Publish accurate release notes and operational plan

Release notes and the operational plan reconcile all 144 cumulative Release 1.0.0 Tasks—the original 130 allocations plus 14 Wave 31 corrections—and define executable readiness, migration, compatibility, rollback, capacity, risk, ownership, and acceptance gates.

• ComponentRelease management — release notes and operational plan
• Depends onNone
• RequirementsFR-0059, NFR-0007

AEROSIM-TS-131Planning status: Done

Prepare and validate the reviewed GitOps deployment change

A reviewable GitOps change binds the exact Release 1.0.0 candidate through project template source, authoritative rendering, rendered repository output, pull-request identity, and exact-head checks while stopping before merge or deployment.

• ComponentRelease management — reviewed GitOps deployment change
• Depends onNone
• RequirementsFR-0059, NFR-0007

AEROSIM-TS-132Planning status: Done

Approve, deploy, verify, and close Release 1.0.0

After separate exact-head approval, AeroSim Release 1.0.0 is reconciled, verified through runtime health, route, login, and release acceptance, remains rollback-ready, and receives append-only Task Done and parent closure evidence calculated from verified children.

• ComponentRelease management — approval-gated deployment, verification, rollback, and closure
• Depends onNone
• RequirementsFR-0059, NFR-0007

AEROSIM-TS-145Planning status: Done

Display the deployed product release identity

The production flight experience visibly identifies product version 1.0.0.0 and cannot display stale BUILD 0.2.0 or PLAYABLE FLIGHT ALPHA branding.

• ComponentDisplay the deployed product release identity
• Depends onNone
• RequirementsFR-0059

Acceptance outcomes

1. 01

   One immutable candidate binds application source, Harbor digests, chart, template, rendered GitOps revision, and mismatch rejection.

2. 02

   Release notes and the operational plan reconcile all 162 Tasks in the governed Release 1.0.0 Feature inventory, readiness, migration, compatibility, rollback, capacity, risk, owners, and acceptance criteria.

3. 03

   A reviewed GitOps deployment change binds exact candidate references and passes authoritative render, repository, pull-request, and check gates without merge or deployment.

4. 04

   Separate exact-head approval precedes GitOps reconciliation, runtime acceptance, rollback evidence, and append-only Task and parent closure.

Functional requirements and measurable criteria

FR-0059

Introduce the Delivery Runtime

The system shall establish Docker, Helm, Harbor, Gitea Actions, and Argo CD GitOps.

Acceptance 01

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

Whenthe primary capability path is completed

ThenNebula and Singularity produce versioned container images and lintable Helm charts

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

Acceptance 02

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

Whenthe continuation or repeat path is completed

ThenHarbor publication and Argo CD GitOps deployment use governed automation without direct CI runtime mutation

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

  Mutable or mismatched source, image, chart, template, or rendered references could deploy a candidate that was not reviewed.

• Risk

  Treating documentation, CI, artifact publication, PR creation, or merge as deployment evidence could close the release prematurely.

Approval and source evidence

• discord: RootAtSkic approved the dedicated release hierarchy, implementation planning, and exact Wave 30 admission.

Prototype and discovery boundary

Existing implementation, CI, image, and GitOps evidence remains input to candidate freeze; it does not itself prove deployment or release completion.