F4: canary-rollout engine operates on v<major>-<tier> channels (fallback-safe) [#657] #696

Activity

1. don-petry

   added

   dev-leadFor dev-lead agent pickupFor dev-lead agent pickup

   on Jul 13, 2026
2. don-petry commented on Jul 13, 2026

   

   don-petry

   on Jul 13, 2026

   ContributorAuthor

   More actions

   Dev-Lead Implementation Plan

   Issue: #696 — F4: canary-rollout engine operates on v- channels (fallback-safe) [#657]

   Scope

   Make the canary-rollout engine resolve/promote/autocut major-scoped <agent>/v<M>-<tier> channel tags, preferring the v-form when it exists and falling back to the legacy bare <agent>/<tier> — so on today's (bare-tier) fleet the engine is byte-identical to pre-F4.

   Implementation Checklist

   • scripts/lib/canary-rollout.sh (pure): add major_component <version> and channel_tag <agent> <tier> [major] name-builders (matching F3 ring_canonical_ref convention)
   • scripts/canary-rollout.sh: add _agent_current_major (derive major from highest <agent>/vX.Y.Z release), _channel_tag_commit, _looks_like_oid, _resolved_channel/_resolved_channel_tag
   • scripts/canary-rollout.sh: rewrite channel_commit to prefer v<M>-<tier> then fall back to bare <tier>
   • scripts/canary-rollout.sh: cmd_promote moves the resolved frontier tag (v-form within a major line, else bare)
   • scripts/canary-rollout.sh: _autocut_agent — major bump seeds a fresh <agent>/v<newmajor>-next; minor/patch move the resolved current-major next tag (bare on today's fleet)
   • scripts/canary-rollout.sh: cmd_evaluate reports the major line under evaluation (e.g. candidate (v2-next) = …)

   Tests to Write (tests/canary_rollout.bats, gated by #685)

   • pure: major_component extracts MAJOR; channel_tag builds v-form + bare form
   • transition-safety: on the bare-tier fixture, evaluate verdict + labels are byte-identical to pre-F4 (fall-back to bare)
   • resolution prefers v<M>-<tier> when that tag is present
   • autocut of a major bump seeds v<newmajor>-next (fresh line), does not move the old next
   • autocut of minor/patch moves the current major's v<M>-next when the v-line exists
   • promote advances within a major line; a v2 promotion never touches v1-* tags
   • evaluate prints the major line

   Test Command

   GH_TOKEN=dummy bats tests/canary_rollout.bats (CI: Canary-rollout Tests — shellcheck + bats)
3. don-petry commented on Jul 13, 2026

   

   don-petry

   on Jul 13, 2026

   ContributorAuthor

   More actions

   ✅ F4 complete — canary-rollout engine now operates on v<major>-<tier> channels (fallback-safe)

   Implemented per the Phase-1 plan. The engine is now capable of resolving, promoting, and autocutting major-scoped <agent>/v<M>-<tier> channel tags while remaining fall-back-safe: it prefers the v-form tag when it exists, otherwise the legacy bare <agent>/<tier>. On today's bare-tier fleet (no v-tags) the engine is byte-identical to pre-F4 — the transition-safety guarantee.

   What changed

   scripts/lib/canary-rollout.sh (pure core — kept side-effect-free):

   • major_component <version> — MAJOR of a strict MAJOR.MINOR.PATCH, empty otherwise.
   • channel_tag <agent> <tier> [major] — builds <agent>/v<M>-<tier> with a major (mirrors F3's ring_canonical_ref), else bare <agent>/<tier>.

   scripts/canary-rollout.sh (orchestrator / I/O glue):

   • _looks_like_oid — hex guard so only a real commit id (never an absent-tag/{} sentinel) is preferred over the bare form.
   • _agent_current_major — derives the current major from the agent's highest vX.Y.Z release (no new required registry field — derivation only).
   • _channel_tag_commit / _resolved_channel / _resolved_channel_tag — unified prefer-v-then-fallback resolution shared by commit lookup, promote, autocut, and display.
   • channel_commit — now delegates to _resolved_channel (fall-back-safe).
   • cmd_promote — advances the resolved v<M>-<tier> within a major line (a v2 promotion never touches a v1 tag). Logical tier still drives the gate and is reported as promoted_ring.
   • _autocut_agent — a MAJOR bump seeds a fresh <agent>/v<newmajor>-next line; minor/patch advance the current major's v<M>-next, falling back to bare next where no v-line exists yet.
   • cmd_evaluate — reports the resolved major line (e.g. candidate (v2-next) = …, ring listing shows v2-stable).

   Test-first (TDD)

   Added 10 tests to tests/canary_rollout.bats (written red-first, confirmed failing before implementation): pure channel_tag/major_component; v-line resolution + evaluate label; promote-within-major; autocut MAJOR-seeds-v3-next, patch-advances-v2-next, patch-falls-back-to-bare; and a byte-identical-on-bare-fixture transition-safety guard. The shared _autocut_stub was made faithful to the bare fleet (a v<M>-next channel probe resolves absent), so its release-tag existence probe is unaffected.

   Verification

   • bats tests/canary_rollout.bats — 180/180 passing (170 pre-existing unchanged + 10 new).
   • shellcheck --severity=warning -x scripts/canary-rollout.sh scripts/lib/canary-rollout.sh — clean.
   • .dev-lead/scripts/dev-lead-lint.sh — all checks passed.

   Out of scope (as specified)

   F5 — live tag migration and consumer re-pins. F4 only makes the engine capable + safe; today's fleet behavior is unchanged.
4. don-petry

   added a commit that references this issue on Jul 13, 2026

   feat: implement issue #696 — F4: canary-rollout engine operates on v<…

   ...

   0ba3be0
5. don-petry

   closed this as completedin #697on Jul 13, 2026