[vsilent]

Stage 4 of config/docs/BAKE_PIPELINE_PLAN.md.

Problem. Clone picks the newest healthy snapshot. A fresh bake reaches buyers immediately, whether or not its smoke clone passed.

Change

• Migration 20261026100000_baked_snapshot_channels:
  • baked_snapshot_channels: one pointer per stack/provider/channel (unstable / latest / stable);
  • baked_snapshots.gated;
  • Casbin rule for the new route (group_admin, admin_service).
• POST /api/admin/bake records the snapshot as gated and points unstable at it, in one transaction.
• New POST /api/admin/bake/{id}/promote (bake job id). After a green smoke clone it moves latest ← unstable and stable ← old latest, using helpers::bake_registry::promote_ladder.
  • The stack's pointers are locked during the move.
  • Only the current unstable can be promoted: 409 otherwise, and 409 while the bake is not done.
  • A repeated promote is a 200 no-op.
• baked_snapshot::resolve / resolve_latest (clone and validate) pick latest, then stable, then the newest ungated healthy snapshot.
  • Snapshots recorded before this migration, and by the bake binary, are ungated, so existing Quick Deploy links behave as before.
• Why gated exists (not in the plan): without it, a bake whose smoke failed would lose its unstable pointer at the next bake and become "newest healthy". There is a test for this.

Tests. tests/bake_channels.rs, 4 tests, written failing first:

• an unpromoted bake is never served, not even by its version;
• promotion order and stable;
• a failed bake stays hidden after the next bake;
• legacy and unknown snapshots cannot be promoted;
• the HTTP route returns 409 / 403 / 200 / no-op / 404.

Unchanged and green: admin_bake, migration_boot_contract, quick_deploy_server_type, and --lib (2302). clippy reports nothing in the changed files.

Follow-up, not in this PR. awesome-selfhosted-stacker scripts/bake_pipeline.py must call /promote after a green smoke clone. Until then, new API bakes stay on unstable and are not served.

🤖 Generated with Claude Code

[vsilent]

Re-verification: the test run I re-did just before committing this PR was silently skipped, because the local test Postgres had gone down when the disk filled up. Re-run today against real Postgres, with no skips: bake_channels 4/4, admin_bake 2/2, quick_deploy_server_type 2/2, migration_boot_contract 11/11, --lib 2302 — all green.