Ship Lane

---
name: ship-lane
description: Productionization loop for any product repo — classify the lane (rail / surface / activation), fix the proof column, ONE review pass, scripted path to production, done = live with a receipt. Use whenever a feature is being built for a real customer; use instead of ad-hoc review rounds.
---

# Ship a lane (loop v3)

James, Sep 3 2026: "stop spending so much time on unnecessary review and ceremony … repeatable stuff … clear paths to productionizing." and "on other projects I've been stuck in endless loops instead of using repeatable smart workflows." This skill is the repeatable workflow. Apply it on every project.

## 0. Done means live
A feature is done when it is live for the real customer with a receipt (a row, a log line, a screenshot of the real account). Never when a review certifies it.

## 1. Classify before dispatch (never mix classes in one lane)
| Class | Contents | Proof column (all of it, every time) | Review |
|---|---|---|---|
| A rail | migration, RPC, worker/runner, provider read/write, receipts | acceptance at real cardinality · disposable-DB drill · runtime probe · red-first unit pins · apply + deploy same minute · post-apply script · one live receipt | one adversarial pass (money/provider-write/credentials/customer-messages: highest effort) |
| B surface | member-visible copy/cards/gestures | film on the final tree · record derived by script · digest pin · SSR pin per sentence · deploy · live film green | one design pass on frames (PASS/BLOCK) |
| C activation | flags, secrets, schedulers on, first run on the customer | runbook step · post-apply script · `/ready` · one live receipt | none — the driver executes under standing authorization |

## 2. One pass, one fix
Builder (codex terra, flat-rate) → proofs → ONE review pass with a CHECKLIST (the proof column + the WO deliverables; verdict per item with the pin that holds it) → ONE fix → merge. Residue goes to a weekly punch batch (one lane, one design pass). A second round exists only for a truth/custody BLOCK, and then only that item is re-checked. Certification by inspection is worth nothing; a pin that goes red is the certification.

## 3. Activation is supervised-first
If the rail has produced real, owner-approved output, it runs on its scheduler under a database spend ceiling + kill switch + the existing quality decision + receipts. Any "accepted packet" is generated from that real evidence by the finalizer, never a separate dogfood ceremony.

## 4. The path is scripts, not hands
`train.sh` (merge main → positive-marker prove → PR → merge-on-green with the required checks present and green → apply migration + deploy same minute → live film) → `verify-<migration>-live.sh` → `activate-flag.sh` (secrets → `/ready`) → read the live receipt. Prove guards assert the PRESENCE of every success marker. Records (film critiques, run sentences, digests, line counts) move by a derivation script, never by hand.

## 5. The WO template (every order)
Why · truth read (dated, read-only) · deliverables (substrate → runner+flag OFF → one-shot → surfaces → film → docs/runbook) · activation · non-goals · proof column · dispatch (class, seat, after which merge).

## 6. Anti-patterns that caused the endless loops
Three seats per round on residue · rounds on record formatting · hand-derived records · mixed A+B lanes needing merge-and-refilm dances · packet ceremonies gating rails that already proved themselves · guards that pass on an empty log · Opus building when codex is up · board stamps per notification. When one appears, stop and name it.