Skip to main content

Apply delivery practices

This page records the delivery practices currently exercised by AeroSim. It does not approve a Feature, version, merge, release, or deployment.

Delivery workflow​

  1. Select a Feature only after its registry entry is marked Approved for Implementation by RootAtSkic or Hermes acting under the recorded AeroSim project-lead delegation and includes linked requirements, architecture, dependency-aware tasks, acceptance evidence, and a target version.
  2. Start only an unblocked task and preserve the approved scope.
  3. Add or update tests with behavior, then run the applicable formatting, type, unit, integration, build, container, and Helm checks.
  4. Open a pull request into test; merge only after review and green Actions checks tied to the pull request head SHA.
  5. Publish immutable images, immediately render the single-environment Copier template with development inputs into corp-v1-aerosim/gondor-v1-aerosim-dev, and verify the exact Argo CD revision and runtime health at https://aerosim-dev.apps.lego-cloud.eu.
  6. Hand the immutable development deployment tuple to UAT and keep the Task at TO_BE_RELEASED while acceptance journeys run.
  7. Return a failed journey to Kanban/Delivery for remediation and a new deployment tuple; send UAT_PASSED evidence to Releases.
  8. Route production promotion through Releases. Releases separately renders the same single-environment template with production inputs into corp-v1-aerosim/gondor-v1-aerosim and verifies https://aerosim.apps.lego-cloud.eu.

The following is a historical statement bounded to 2026-08-13 and Discord evidence 1537468705724960798: canonical records were Proposed and their legacy aliases were provenance only. Consult the generated canonical registry for current state; implementation remains governed by the gates below.

Implementation-intake checklist​

Before moving any TASK-* record into active delivery, verify all of the following against the durable registries and the proposed pull-request head:

  • the exact Feature—not only its Epic or a sibling Feature—has explicit Approved for Implementation evidence from RootAtSkic or Hermes acting under the recorded AeroSim project-lead delegation;
  • approved FR/NFR and architecture links cover the task's behavior and component boundary;
  • task dependencies are explicit and every predecessor is complete or independently unblocked;
  • acceptance evidence names the tests, build outputs, or observable behavior required for completion;
  • an explicitly approved target version is recorded for the Feature by RootAtSkic or Hermes acting under the recorded AeroSim project-lead delegation;
  • the branch starts from the current origin/test head and uses only the CORP_V1_AEROSIM_* project namespace;
  • the expected local validation and exact-head Gitea Actions checks are identified before coding.

If any item is missing or contradictory, keep the task blocked and route the exact gap to its owner. An Epic approval, solution approval, answered product question, mergeable pull request, or green CI run does not substitute for implementation approval.

Branching and reviews​

  • Branch from the current test head after fetching and checking divergence.
  • Use a focused branch name such as feat/<topic>, fix/<topic>, or docs/<topic>.
  • Keep each change within one coherent capability or documentation concern.
  • Open a pull request into test and link the Feature/task plus acceptance evidence.
  • Do not force-push over shared work or merge without authorization from a trusted human or the delegated AeroSim project lead and the required exact-head evidence.
  • Match remote CI evidence to the exact head SHA; local validation is not remote CI evidence.

Planning and ownership​

  • Epic and Feature state is maintained in the product lifecycle registry.
  • Dependencies and target version must be explicit before implementation starts.
  • The Feature owner coordinates acceptance evidence; individual task ownership should be recorded where tasks are defined.
  • Blocked work records the exact missing approval, dependency, or evidence and its known owner rather than substituting guessed scope.

Quality practices​

  • Add automated checks at the lowest useful level and test observable behavior.
  • Run the repository's documented Task or pnpm validation surface before review.
  • Require successful Gitea Actions jobs tied to the exact reviewed commit.
  • Treat documentation, configuration, Docker, and Helm changes as reviewable delivery artifacts.
  • Do not weaken checks, suppress gates, or expose credentials to make a pipeline pass.

Current health evidence verified on 2026-09-04: application publication task 1786 and validation task 1787 succeeded for 98e377b71d37e5606af0e35d7bb08ccf83e63e0b; documentation build task 1763 succeeded for f686610a8b1b21825c66dc424f484fb2672933d7. Recheck every task against the exact head used by a future delivery or release change.

Collaboration and decisions​

  • Discord supports discussion and synchronization; durable lifecycle state and approval evidence belong in project documentation.
  • Delivery synchronization reads only AeroSim's eight governed channels: General, Scope, Architecture, UI/UX, Kanban, Delivery, UAT, and Releases. For frontend work, verify the approved UI/UX package and accessibility handoff before implementation; Delivery does not redesign the intended experience in code.
  • Architecture contradictions or unclear requirements are escalated rather than resolved by delivery assumptions.
  • A trusted human or the delegated AeroSim project lead may approve solution, implementation, version allocation, merge, release, or deployment gates through explicit exact-scope decisions and the owning evidence workflow.
  • Delivery reports summarize implications, completed work with exact evidence, and remaining action/owner when known.