factory-release

factory-release

Post-merge release orchestrator that closes the factory loop: approved head → gated merge → staged rollout with threshold verdicts → SemVer-tagged, noted release with a monitor handoff, plus a change record on non-obvious rationale only.

Overview

factory-release takes a human-approved head and carries it to production without inventing new authority: merge happens only when both gates green on the same SHA at the exact-head under review, rollout advances on measured threshold verdicts (green advances, yellow holds, red rolls back), and the release is cut merge → tag → changelog with a dry-run preview and a handoff packet. There is no auto-approve tier — never auto-approve, never auto-merge past a human gate.

The 12-step program (workflow.yml) is the single source of truth; this prose never overrides it. Heavy detail lives in references/.

When to Use / When NOT Use

Use when:

• A reviewed PR has an approved head and needs merging at that exact head.
• A merged head needs staging, canary rollout, expansion, and a terminal verdict.
• A release must be cut: SemVer tag, impact-grouped notes, monitor handoff.
• A shipped release must close its tracker milestone and update the roadmap.

When NOT Use:

• Continuous monitoring or incident response — that is factory-monitor scope; this skill ships a release-scoped watch only, then hands off.
• Review depth or approval policy — that is the Merge Gate owner's review depth call, not this run.
• Infra provisioning, environment locks, or outcome-metric dashboards — out of scope.
• Per-merge history entries — change records mint on non-obvious rationale only, never per merge.

Core Process

The 12 steps run in order; gates halt, never warn.

1. verify — Halt-first entry checks. Confirm the approved head SHA, the rollback plan requirement (a rollback plan must exist before stage completes or halt), the short-path rule as recorded here, blackout windows for this repo, and the error-budget source binding. Anything missing halts.
2. gate-merge — Deploy Gate checkpoint 3 (human): both the review-owned Merge Gate and Deploy Gate checkpoint 3 must be green on the same SHA with the approver identity recorded (one approval per gate: verdict_merge authorizes only this gate). Re-read the head at execution time — on head-moved, discard all gate evidence and re-verify from step 1.
3. merge — Gated exact-head merge executor. Execute the merge when both gates are green on the exact reviewed head SHA. --no-merge path: when the head is already merged, skip the mutation but still verify exact-head identity.
4. stage — Staging rollout. Dry-run preview first, then roll to staging.
5. gate-canary-expand — Deploy Gate checkpoint 1 (human): staging green, rollback plan exists, baseline frozen (or a waiver granted with a recorded approver). Approving starts the 5% production canary (verdict_canary authorizes only this gate, never reused from another gate).
6. canary — 5% canary under the armed evaluator: green / yellow / red threshold verdicts against frozen baselines with unified budget reads. See references/threshold-verdicts.md.
7. gate-full-expand — Deploy Gate checkpoint 2 (human): canary verdicts green (or a hold resolved). Approving starts terminal expansion (verdict_full authorizes only this gate, never reused from another gate).
8. expand — Auto-advance on green, hold-and-investigate on yellow, mechanical rollback on signal red. Budget-burn red (error budget exhausted) freezes the deploy instead of rolling back — advance past a freeze only on an explicit human order recorded as an override annotation (invariant 8).
9. full — Terminal verdict on the expanded rollout.
10. publish — Release cut in merge → tag → changelog order with a dry-run preview. See references/release-cut.md.
11. close-milestone — Close the shipped milestone. Resolve the milestone from the shipped MR/issue linkage (factory MR/issue milestone inheritance). No milestone linked → recorded no-op (milestone: none). Open issues remain → halt listing them (close-anyways is not offered). Tracker write through the issues-provider milestone API only; provider lacks milestone write support → halt with a manual instruction, never silently skip.
12. update-roadmap — Flip the milestone row in docs/adlc/product/roadmap.md (active → closed, with release version and date), committed through the run's normal publish path — never an uncommitted local edit. Then the monitor handoff packet and the conditional change record (references/release-chdr.md).