Argo Refs code-dot-org Commit

Short name: Argo refs commit

Catchy description: Write one tiny release record to warehouses/codeai/,
then let Argo CD deploy Kustomize source pinned to a code-dot-org commit.

Detailed Technical Description of Plan

This plan is the simplest source-driven Kargo design in iteration 7. Kargo does
not snapshot a release package or render review output into Freight; instead it
promotes a tiny Git build-lock record from k8s-gitops that names one exact
code-dot-org commit and one exact image tag/digest. The build-lock is the
release record, and current.yaml is just a stable parse path to that same
record. The whole point is to keep Freight small, deterministic, and easy to
audit while still letting the real deploy source live in code-dot-org.

Argo points at k8s-gitops/apps/codeai/deployments/<deployment>/deploy/, where
the deploy tree is built from the checked-in code-dot-org/k8s/kustomize/
package plus the envType Components under apps/codeai/envTypes/<envType>/.
That is the main conceptual difference from the rendered-branch plans: here the
GitOps repo does not store rendered output, it stores the deploy entrypoint and
env policy that tell Argo how to materialize source at the right commit.

The tricky part is that the plan looks deceptively simple until you try to make
promotion and deploy truth line up. The build-lock file must be written
atomically as both git-<full-commit-sha>.yaml and current.yaml, and the GH
action must keep the image tag and the lock file in sync.

• Type: Source-driven plan
• Pattern: Source-driven
• Rendered manifests pattern: No

argo-refs-code-dot-org-commit

Other PR: code-dot-org/k8s-gitops#3