Introduce the Delivery Runtime

Overview

User capability

Establish Docker, Helm, Harbor, Gitea Actions, and Argo CD GitOps

User

The AeroSim delivery team

What the user can do

Establish Docker, Helm, Harbor, Gitea Actions, and Argo CD GitOps

Why the user benefits

The capability becomes an explicit, testable project boundary.

User need

The delivery team needs the AeroSim solution to establish Docker, Helm, Harbor, Gitea Actions, and Argo CD GitOps.

In scope

Establish Docker, Helm, Harbor, Gitea Actions, and Argo CD GitOps

• StatusProposed
• OwnerAeroSim Scope (proposed; not accepted)
• Parent EpicAEROSIM-EP-1
• Depends onAEROSIM-FT-51

Tasks

AEROSIM-TS-47Planning status: Done

Build versioned Nebula and Singularity container images

Nebula and Singularity each produce reproducible runtime images labeled and tagged with the immutable application source revision.

• ComponentWeb Application and API Service — container images
• Depends onAEROSIM-TS-46
• RequirementsFR-0059, NFR-0007

AEROSIM-TS-48Planning status: Done

Package Nebula and Singularity Helm charts

Lintable Helm charts render Web and API workloads with explicit immutable image selection, probes, ingress paths, configuration, and secret references.

• ComponentDelivery packaging — Helm charts
• Depends onAEROSIM-TS-47
• RequirementsFR-0059, NFR-0007

AEROSIM-TS-49Planning status: Done

Publish immutable images to Harbor

Gitea Actions publishes both validated source-revision images to Harbor only after required engineering gates pass.

• ComponentGitea Actions — Harbor publication workflow
• Depends onAEROSIM-TS-48
• RequirementsFR-0059, NFR-0007

AEROSIM-TS-50Planning status: Done

Select immutable AeroSim artifacts through GitOps

The Gondor GitOps repository declaratively selects reviewed Nebula and Singularity image revisions and linted chart configuration for the AeroSim environment.

• ComponentGondor GitOps — AeroSim Argo CD application configuration
• Depends onAEROSIM-TS-49
• RequirementsFR-0059, NFR-0007

AEROSIM-TS-51Planning status: Done

Enforce the CI-to-GitOps deployment boundary

Automated checks prove CI can publish artifacts but cannot directly mutate Kubernetes or Argo CD runtime state.

• ComponentGitea Actions — GitOps boundary policy checks
• Depends onAEROSIM-TS-50
• RequirementsFR-0059, NFR-0007

AEROSIM-TS-52Planning status: Done

Verify Argo CD reconciliation of the selected release artifacts

A governed GitOps change reconciles through Argo CD to healthy Web and API workloads whose running image revisions match the reviewed selection.

• ComponentGondor runtime — Argo CD reconciliation verification
• Depends onAEROSIM-TS-51
• RequirementsFR-0059, NFR-0007

Acceptance outcomes

1. 01

   Nebula and Singularity produce versioned container images and lintable Helm charts.

2. 02

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

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

  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.