Registry: vogt-stack release (lean) and branch (full) builds are indistinguishable; `latest` points at the lean variant

[thedancingdeveloper]

Problem

The ghcr.io/thedancingdeveloper-org/vogt-stack repository interleaves two deliberately different artifacts under one name, with nothing in the registry distinguishing them:

• Release builds (X.Y.Z, X.Y, sha-<short>, latest) — built by release.yml on the lean pod base: CLI-free by policy (docs/DEPLOYMENT.md §7 states the signed release digests are CLI-free).
• Branch builds (dev, dev-<longsha>, prod-<longsha>) — built by build.yml on the full pod base: carry the agent CLIs and toolchain, because the estate's own pods run coding sessions (build.yml selects full for dev/prod pushes).

A consumer inspecting the registry — or pinning by the natural-looking vogt-stack:<version>/latest — cannot tell they are getting the lean variant. A deployment that runs agent sessions and pins a release/latest stack digest comes up without claude/codex, and its session templates register but cannot start. This exact mispin has happened in practice more than once (v0.3.0 shipped agent-less this way; the "bake the AI clients into the release image" fix was written and deliberately reverted in favour of the CLI-free-release policy).

Proposals (any subset)

1. Document the tag taxonomy in docs/DEPLOYMENT.md so the two families and their variants are stated where a deployer reads (PR incoming).
2. Stop tagging the lean release stack latest — release.yml notes vogt-stack "is not the supported install of Vogt"; advertising latest on it invites exactly the wrong pin. (Semver tags could arguably go too, leaving the release stack addressable by digest + sha-<short> only.)
3. Make the variant discoverable in the artifact itself — distinct image names per variant (e.g. vogt-stack vs vogt-stack-lean), or at minimum an OCI label/annotation (org.opencontainers.image.variant=full|lean) so tooling and humans can check before running.

Non-goals

The lean/CLI-free release policy itself is settled and correct (public artifacts stay free of bundled third-party agent CLIs); this issue is only about the two variants being indistinguishable at the point of consumption.

[thedancingdeveloper]

Closing as resolved by design rather than implemented.

The concrete harm this issue exists to prevent — pin latest, get a pod with no claude/codex, session templates registered but unable to start — disappears once the release stack carries the CLIs. feat/generic-aio does exactly that: release.yml now builds with INSTALL_AI_CLIENTS=true and INSTALL_CADASTRE_MCP=false, so the release digests are the generic public AIO.

Against the three proposals:

1. Document the tag taxonomy — done, on the corrected axis. Both families carry the CLIs; what separates them is whether they also carry the estate (lean vs full pod base, Cadastre/theclawbay). It lands in docs/DEPLOYMENT.md §7, with a three-shape comparison in the new §1.1. PR docs(deploy): document the vogt-stack tag taxonomy (lean releases vs full branch builds) #503 is closed because it documented the pre-change premise.
2. Stop tagging the lean release stack latest — this one inverts. vogt-stack becomes the published, supported public AIO, so latest on it is now correct rather than a trap. Withdrawing the semver tags would be actively wrong.
3. Make the variant discoverable via an OCI label — drops from defect fix to nice-to-have hygiene, since the two families are no longer distinguished by a missing capability. Worth opening separately if it is still wanted.

One residue is worth keeping in mind: the release family is the lean pod base, so it carries no Flutter/Android SDK. That was never this issue's stated harm and the mobile shell is built by release.yml's own Android job, not from inside a pod — but it is the one remaining difference a consumer could be surprised by, and §7 now says so.

Reopen if the variant label is still wanted on its own merits.