/launch

name: launch
description: Shipyard's governed delivery pipeline — converge the mission, synthesize a durable spec, decompose vertical-slice tickets with blocking edges, run the frontier in parallel via team, close with verification, and report with a full decision log. Two entry gates — the yard gate (drydock audit) and the fog gate (an effort whose destination is unclear is routed to /ask-navigator before this pipeline starts). Humans own the checkpoints where there is no unique answer or the error cost is severe; agents continuously run everything repeatable and acceptable-by-evidence.
argument-hint: "<mission brief | path to existing spec> [--serial]"
level: 3
disable-model-invocation: true
pipeline: [deep-interview, launch]

Launch

Launch is the shipyard's delivery run: from mission brief to shipped, verified change. It stands on the verifiability boundary — **agents continuously run everything repeatable and acceptable-by-evidence; humans decide what cannot be judged by the system or what fails expensively.** The goal is not maximum automation — it is maximum delegation of verifiable work, so the human's time is spent only on the decisions only a human can make.

The verifiability test, applied to every step: *if this is done wrong, can the system detect it? Can it redo or roll back automatically?* Both yes → agent. No unique answer, system cannot judge, or expensive to get wrong → human.

Launch assumes the shipyard exists — and refuses to run if it does not. The yard gate is the first action of every invocation, before document-language resolution and before reading any supplied spec:

The audit report includes `contractVersion: 2`; missing required day-one faces use `shipyard.yard.unlaid`, and consumers must not interpret retired `shipyard.surface.missing.*` IDs as optional-surface failures.

• **Run the full drydock `--check` audit** — require the day-one base faces `CLAUDE.md` and `GLOSSARY.md` (a recognizable legacy glossary `CONTEXT.md` is accepted until drydock migrates it); beyond those, audit only adopted optional surfaces, so an absent optional surface is not a finding. The audit also checks a missing or invalid glossary `documentLanguage`, dead paths, glossary terms unused in code, and standards never referenced. This is the single criterion: Launch performs no separate facility inventory of its own.
• **Actionable / high-confidence findings hard-block the run:** list every such finding verbatim, point at `/oh-my-claudecode:drydock`, state that the run never started and no artifacts were produced, and stop. Without an explicit override, treat any finding as blocking.
• **Narrow override (explicit intent only):** low-confidence findings, findings explicitly classified as false positives in the drydock report, or a scratch/throwaway repository explicitly declared by the user may be overridden only with deliberate, per-invocation user intent — the override must name the finding(s) or the throwaway scope and must never silently swallow a high-confidence actionable finding. No general bypass flag.
• **Current audit contract (version 2):** the mechanical subset of `--check` is executable — `node scripts/shipyard-audit.mjs [repoRoot]` emits a versioned JSON report and checks the required yard base faces, duplicate glossary authority, a missing/invalid `documentLanguage` tag, dead paths in `CLAUDE.md`, project-skill triggers, and intent statuses. Absence of an optional surface is not a finding; `shipyard.surface.missing.*` IDs are retired in contract version 2. Exit 0 = clean, 1 = high-confidence actionable findings present. The gate consumes that exit: 0 admits the run, 1 lists the findings verbatim and blocks. The heuristic classes (glossary terms unused in code, standards never referenced) stay in the drydock prose audit — low-confidence by construction, override rules unchanged.
• **A clean audit (or an explicitly overridden low-confidence/false-positive/scratch scope) admits the run.** The day-one faces are present; `docs/adr/` and `docs/business/` appear on first use — the slot is there when a decision settles, and if it is not, Launch triggers its first use (per drydock's deferred-surface table) and sediments into it immediately. Launch fills the paper trail as decisions settle and never creates a slot speculatively.
• The rules entry is `CLAUDE.md` — the shipyard map recognizes no substitute.

The boundary

| Human checkpoints (the critical 20%) | Agent continuous run (the mechanical 80%) | |---|---| | C1 author the mission brief (objective + scope) | fact-finding and repo exploration, self-served | | C2 approve acceptance criteria + test seam list | interview preparation: frontier questions batched with recommended answers | | C3 approve ticket decomposition (granularity, blocking edges) | spec and ticket drafting, mechanical validation (independence, demonstrability, fits-one-context) | | C4 answer irreversible decisions that emerge mid-run (batched, async) | tdd implementation at agreed seams, builds, tests, regressions | | C5 accept the completion report; veto via Open Assumptions and the per-line sediment list | code-review, verify across the change, team frontier scheduling, the whole paper trail |

Between checkpoints the pipeline never idles: agents keep working every frontier ticket that does not depend on a pending human answer.

Lifecycle posture

Launch is a **stateless composition over OMC's existing lifecycle** — it owns no runtime state machine:

• Team owns task statuses, transitions, cancellation, and runtime cleanup; Launch never mutates them outside Team's contract.
• The canonical `plan` → `execute` → `review` → `verify` surfaces own their existing lifecycle behavior. Launch-authored artifacts are limited to `GLOSSARY.md`, `docs/adr/`, and `docs/business/` — plus, only after C5 approval, the sediment slots named in the Phase 5 table. The spec and its tickets live only in the tracker — **the spec is the parent issue, the tickets are it