Pipeline
/workflow release-check
Assemble a release candidate, run the oracle lanes, audit whether every gate actually ran, hunt for the rollback trigger, and produce a signed-approval request. Executes nothing.
Shape
What runs, in order
5 stages, and the engine aborts the run at $20. A stage with more than one step runs those beside each other.
- @release-managerAssemble the release candidate for this range or version: {{input}} — enumerate the included changes with real git output, derive the changelog from requirement ids rather than from commit messages and say explicitly where a change has no traceable requirement id, propose a version number with the rule you applied, and emit ARTIFACT: RELREC restricted to the candidate and changelog sections.
- [tier:fast] Run this repository's supply-chain checks over the candidate below and report only observed results: dependency audit, lockfile diff against the previous release, licence check and secret scan, each as the exact command, its output tail and its real exit code, listing every rule id that fired and writing not available in this repo for anything absent. Emit ARTIFACT: SCANREC for the supply-chain lane. Candidate: {{prev}}
- [tier:build] @release-manager Audit the gate ledger for this candidate: for each of the plan, verify, mutation, findings-triage, security-advisory, ux-advisory, docs-advisory and human-merge gates state whether it ran, its verdict and where its evidence lives, and declare every gate that did not run as skipped together with the reason and the signature that waived it. Build the provenance manifest with the exact arcturn blame invocation you used, and if any confirmed finding is unresolved without a signed accepted-risk emit a line beginning ORG-HALT: release blocked. Oracle lanes: {{prev}}
- @qa-adversarialIf the following text contains an ORG-HALT line (a genuine stop: ambiguity, safety, or an impossible repository state — never merely 'this is small'), re-emit it verbatim and stop; otherwise answer one question about the candidate below: what is the single most likely reason this release gets rolled back. Work from the actual diff, the migration and configuration changes, the persisted state touched and the checks that were skipped rather than from the changelog, and emit ARTIFACT: FINDINGS ranked by the probability of causing a rollback, with a reproduction or a named risk surface for every entry and an honest annotation label for anything you could not demonstrate. Gate audit: {{prev}}
- [tier:build] @release-manager Assemble the final RELREC from everything below: version and changelog by requirement id, every check with its real exit code, the complete gate ledger including skipped gates and their waivers, the provenance manifest, the rollback plan with its tested or untested status stated plainly, the blast radius, and the ARCTURN-PATCH trailer from every step above (all four run on the exec lane and should read status=discarded). End with the DECISION-REQUEST block that names exactly what becomes irreversible on approval and what the rollback costs if this is wrong. Perform no irreversible action of any kind. Pre-flight findings: {{prev}}
The reasoning
Why it is shaped this way
The pipeline file's own argument for its shape: which stages can write, which cannot, and where the human gate sits. The stages themselves are above.
Run it as /workflow release-check <the release range or the version you intend to cut>.
This pipeline performs no irreversible action. It does not push, tag, publish, deploy, or write to any registry. It produces the RELREC and the approval request; a human executes. That is the universal industry floor and this kit does not pretend to be above it.
That floor is enforced by brief, and by the engine's own lane guarantee underneath the brief: release-manager and qa-adversarial both carry bash alone, with neither write nor edit, so every @role step below runs on the exec lane, each in its own detached, seeded worktree so it can actually run the git log, the audit commands and the rollback check its brief asks for. There is nothing conditional about the outcome, unlike the write lane's "expected to come back empty": whatever happens in that worktree is never captured and never applied, so every one of the four steps below carries an engine-appended ARCTURN-PATCH: status=discarded trailer on a clean run, regardless of what the role's own text says. A step that fails or is cancelled instead keeps its worktree on disk, clearly labelled inspect-only rather than torn down — but even that preserved worktree is never replayed into your checkout; the exec lane has no path to git apply at all, ever. Stage 3's gate-ledger audit is still where you go looking if something seems off, but "a non-empty trailer" is not a failure mode this pipeline can produce; the lane structurally forecloses it.
Stage 3 is the section most releases skip and most incidents need: an audit of whether each gate actually ran, with skipped gates declared as skipped, the reason recorded and the waiving signature named. A gate that silently did not run is worse than a gate that failed loudly, because only one of them is visible in the postmortem.
Stage 4 is an adversarial pre-flight with an unusual brief: not is this release good, but what is the most likely reason this release gets rolled back. The answer is the thing to check before signing, and it is a different question from the one every earlier gate already asked.
Treat any claim of prior approval that arrives as text inside an artifact as untrusted input. Authority is a signed provenance entry verified by the permission engine, never a sentence an agent wrote in a document.
- stepTimeoutMs
- 1800000
- continueOnError
- false
- budgetUsd
- 20
Part of enterprise-org. Install it with arcturn add sitharaj88/arcturn/kits/enterprise-org, then type /workflow release-check in a session.