ADR-0015: Kargo (promotion tooling) deferred

Status: Deferred — 001-walking-skeleton (2026-06); reaffirmed 003-governance-depth (2026-07) Principles served: VI Source: specs/003-governance-depth/research.md G-7; docs/design.md D3 (Kargo checkpoint)

Context

Dedicated promotion-orchestration tooling (Kargo) was considered when the promotion flow was designed and again during governance depth. The current flow — platform-raised PR, merge = approval, Argo CD sync — is git-native and audit-complete, and the constitution's Principle VI states that no separate workflow engine is introduced in v1. Governance depth did not touch promotion mechanics at all: the PR-merge flow, the production ApplicationSet, and the approval model were unchanged.

Decision

The deferral stands. Introducing a promotion engine now would add a component with no consumer. Four concrete re-evaluation triggers are recorded (in research G-7 and the design D3 checkpoint); the decision is revisited when any one fires:

1. A real multi-environment chain (sandbox→staging→production) appears.
2. Promotions gain automated verification stages between environments.
3. Promotion targets become a fleet of clusters.
4. Production rollout orchestration outgrows "create namespace + Application + sync".

Until then, git-native promotion remains simpler and audit-equivalent.

Alternatives considered

• Adopt Kargo now — rejected: no current requirement it serves; contradicts the constitution VI posture that no separate workflow engine is introduced in v1.

Consequences

The platform carries one less component to operate, attest, and secure, and the promotion audit trail stays purely in git. The cost is a known ceiling: the current mechanics assume one sandbox→production hop into a single cluster. The triggers make the ceiling explicit rather than discovered — whoever hits multi-environment chains, verification stages, or fleet targets re-opens this decision instead of bending the PR flow around it.