ratchet-ship

Ratchet Ship — land it green

Shipping is the only ratchet click users feel. Your contract: nothing leaves the machine unverified, nothing merges while CI is red, and if it goes wrong there is a written way back.

Invocation

/ratchet-ship ["summary of what's going out"]

Phase 1 — Know the pipeline before touching it

1. Read the repo's release reality: CI workflows (.github/workflows/, GitLab CI, etc.), deploy docs (README/DEPLOYMENT/CLAUDE.md), branch model (git log --graph --oneline -20, default branch, PR-based or push-to-deploy?).
2. If pushing the default branch triggers a production deploy, say so out loud before anything else and get explicit confirmation. Push-to-deploy repos get no casual pushes.
3. Detect the local verify commands (test/typecheck/lint/build) from the manifest — and confirm each actually runs. A lint script that shells to a removed subcommand, or a typecheck that only passes with a warm cache, is a broken gate wearing a green coat; verify cold.
4. Confirm the CI gate is enforceable, not just present. A green pipeline that cannot block a merge is advisory theater. Check branch protection / required-status-checks actually exist (gh api repos/{owner}/{repo}/branches/{branch}/protection); if it returns 403/empty (e.g. a private free-plan repo), say so — red commits can and do reach the default branch, so your local gate is the real gate.

Phase 2 — Preflight (local, all of it)

1. Run the full local gate: typecheck, tests, lint, build — whatever exists. Any red → STOP and report; shipping red is not your call to make.
2. Review the outgoing diff (git diff <base>...HEAD --stat + read the risky hunks):
   • Secret scan the diff: keys, tokens, passwords, connection strings, .env content. Hit → STOP immediately, tell the user (rotation may be needed if it was ever committed).
   • Large/binary files, lockfile churn without dependency intent, debug leftovers (console.log, commented-out blocks, skipped tests).
   • Reproducibility of the CI build. If CI deletes or regenerates the lockfile and runs npm install (not npm ci) — or otherwise floats dependency versions — the thing CI tested is not pinned to what you reviewed. Flag it; a green run on unpinned deps is a weaker signal than it looks.
3. Docs sync: if the repo maintains a CHANGELOG / task ledger / ratchet BACKLOG.md, confirm it reflects what's shipping; update if the convention demands it. A v2 ratchet backlog (<!-- ratchet:v2 -->) keeps its state in ratchet/lanes/*.md, not in BACKLOG.md — read the lane files for the sync check, and never write ledger state into the (human-owned) BACKLOG.md. Gate: no pending sha, no in-progress row, and no open run started marker (a run started journal line with no later run ended) in any lane file being shipped — an open lane is an unfinished run; STOP and name it. If lane branches are being merged as part of this ship: merge commit or fast-forward only — never squash or rebase-merge, both rewrite shas and orphan every Commit: cell in the merged ledgers — and re-run the local gate after the merge (lanes green in isolation can be red together).
4. Migrations going out? Confirm they're additive or explicitly approved, and that a pre-deploy backup exists in the pipeline (or tell the user it doesn't — that's a finding, not a blocker you silently absorb).