Launch Delivery Pipeline

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:

• Run the full drydock --check audit — missing surfaces, a missing or invalid CONTEXT.md frontmatter documentLanguage, dead paths, glossary terms unused in code, 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: the mechanical subset of --check is executable — node scripts/shipyard-audit.mjs [repoRoot] checks the high-confidence classes (missing surfaces, a missing/invalid documentLanguage tag, dead paths in CLAUDE.md, project-skill triggers present, and intent statuses within the documented vocabulary) and emits JSON findings in the shared severity/confidence/actionable vocabulary; 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. Every paper-trail slot (CONTEXT.md, docs/adr/, docs/business/) and facility surface already exists at that point; Launch fills the paper trail as decisions settle but never creates the slots.
• The rules entry is CLAUDE.md — the shipyard map recognizes no substitute.

The boundary

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 .omc/specs/<feature-slug>/, CONTEXT.md, docs/adr/, and docs/business/ — plus, only after C5 approval, the sediment slots named in the Phase 5 table.
• Launch has no automatic resume. After interruption, re-read the artifacts and current Team status, but continue only through a new explicit Launch invocation after the owning Team lifecycle has reached a supported terminal/cleanup boundary. Never infer a human approval or replay an in_progress task.
• Foggy efforts are the navigator's jurisdiction: when the fog gate routes to /oh-my-claudecode:ask-navigator, the run never started — no artifacts, no partial state. The navigator's map is the only carrier across sessions; launch resumes only from the mission brief it hands back.
• Launch adds no approval receipt, revision counter, replay log, cancellation path, rollback mechanism, or cleanup lifecycle of its own.

Any durability claim in this skill is a claim about the files on disk, not about a hidden runtime.

Phase 0 — Entry

A run reaches this phase only through a clean yard gate. Before reading a supplied spec or entering Phase 1, resolve the document language per the drydock document-language contract — the shipyard-document-language-contract block in /oh-my-claudecode:drydock is the single authority for the resolution order (explicit human choice wins; otherwise the CONTEXT.md frontmatter documentLanguage tag; otherwise unanimous high-confidence inference from CLAUDE.md then README.md), the Chinese script-qualification rule (zh-Hans / zh-Hant), and the ask-once conditions (missing, mixed, conflicting, low-confidence, invalid-explicit, or script-ambiguous evidence asks one batched question; never guess). Launch-specific requirements: persist the resolved normalized tag back to CONTEXT.md before any Launch-authored artifact so a fresh explicit invocation can read it without hidden conversation state. The human reads and maintains these artifacts; agents are language-agnostic.

Localize prose and human-facing labels/localizable scalar values only. Paths, slash commands, flags, code fences, placeholders, frontmatter keys and machine-semantic values, YAML/JSON keys, lifecycle tokens (plan, execute, review, verify), status enums (pending, in_progress, completed, failed, ready-for-agent), IDs, ticket blockedBy, public Team blocked_by, and all parser/control tokens remain byte-for-byte stable. Reference language companions are mutually exclusive: emit exactly one selected rendering, never bilingual duplicate headings or labels.

• Brief self-check before anything else: does the brief name an objective, a scope boundary, and non-goals? If two or more are missing, say so and ask for one sharpening pass — running the pipeline on a soft brief converts ambiguity into confident-looking output.
• Fog gate: after the sharpening pass, apply the navigator's fog test — Q1: can the destination be stated in one sentence (the spec, decision, or change this effort is finding its way to)? Q2: can the first three decisions be stated precisely right now, even though none can be answered yet? Either answer no → the run never starts: state that plainly, note that no artifacts were produced, recommend /oh-my-claudecode:ask-navigator (the shipyard's navigator charts fog as a map of decision tickets and hands back a mission brief), and stop. Hand over the residual questions and any vocabulary already settled, so the navigator's W1 does not re-ask them.
• Map check: before reading a supplied spec or entering Phase 1, look for an open navigator:map (tracker label, or under .omc/wayfinder/). One exists and this invocation supplies no new brief → recommend /oh-my-claudecode:ask-navigator to work the next decision on that map, and stop. One exists and a new brief is supplied → ask one question — continue the open map, or start a new effort — before proceeding.
• Spec path supplied → read it, jump to Phase 2.
• Mission brief → Phase 1. An accepted intent (docs/intents/<slug>/intent.md, status: accepted, latest round — see /oh-my-claudecode:intent) is a valid mission brief: its five sections carry the objective, scope, and open questions.
• Single-point fix → hand off to execute, exit.

Phase 1 — Converge (human decides, agent prepares)

Run the interview with the design-tree protocol: map decisions and their dependencies, then work in frontier rounds — batch every currently-askable question into one round, numbered, each with a recommended answer. The human answers; the tree reshapes; recompute the frontier. Facts are always self-served by sub-agents from repo evidence — the human is asked only what no amount of exploration can settle.

Comprehension reset. Before a settled decision is presented for signature, restate it back in one short paragraph of plain technical prose, using the yard's own vocabulary — the terms as CONTEXT.md defines them, no borrowed jargon. A restatement the captain cannot follow sends the decision back to the frontier, not forward on a guess: signing what was understood, not what was said, is how misreads become load-bearing. The same discipline repairs a message that did not land mid-flight: when the captain's reply shows a misunderstanding of what was sent, re-send it shorter and plainer in the CONTEXT.md vocabulary, one misunderstanding at a time, before the conversation continues — compounding a misread is how two different conversations end up sharing one thread.

Paper trail, written the moment each item settles:

• domain vocabulary → CONTEXT.md at repo root (one entry per term)
• decisions passing the ADR test (hard to reverse, surprising without context, real tradeoff) → docs/adr/NNNN-<slug>.md
• business rules and background discovered during convergence → docs/business/ (one article per business question, opening paragraph states why it matters)

Before surfacing a proposal, check the paper trail (ADRs, docs/business/) for a prior rejection of the same concept: a concept-similar re-proposal must state what changed, or it is declined — a new name for a rejected idea is not a new idea.

The glossary is policed during the interview, not after it: a term that collides with CONTEXT.md is challenged on the spot; a fuzzy term is pressed until it holds one exclusive name; business relationships are stress-tested against a concrete scenario; claims about system behavior are checked against the code, and a contradiction goes on the table instead of passing. A term the interview needs but the glossary lacks is itself a finding — either the word is being invented for this ship (withdraw it) or the glossary has a real gap (write the entry now).

Non-convergence here is normal work, not a failure: if the frontier will not empty, present the residual questions ranked — this is C2's input, not an error. If the residual questions themselves cannot be stated precisely (fog test Q2 fails), the destination itself is unsettled and that is beyond C2's authority: stop, note what already settled (vocabulary in CONTEXT.md, answered questions), recommend /oh-my-claudecode:ask-navigator, and exit — the pipeline never invents a destination.

Loft detour. A residual question that is precise but cannot settle in prose — it needs to be seen or clicked, not described (how the UI should look, whether a state model feels right) — is answered with an artifact, not more questions: call the Skill tool with "loft", let the captain react, and fold that reaction back into the interview. The lofted artifact is C2's input; the captain signs what they saw, not what they were told.

Harbor briefs. A mission brief handed over by /oh-my-claudecode:harbor carries signed decisions with links and applicable conditions: consume them as already-made — do not re-ask unchanged business goals. If the code has moved since the evidence was gathered (new head, changed base), re-verify the affected technical evidence; new implementation scope beyond the signed brief still gets its own approval.

Settled-consensus exit. When this invocation arrives from a conversation whose decision tree is already worked — every frontier question answered, vocabulary and decisions already settled (by a live interview, a decision questionnaire, or a handoff artifact) — Phase 1 collapses to a consensus audit: read what the session settled, verify each settled decision against the evidence it names, restate the whole set once (the comprehension reset above), and draft the spec directly. No questions are re-asked; the fog gate and C2 still gate the run — skipping the interview never skips a signature. Consensus quality is verified, never assumed: any settled decision that fails its restatement re-opens, and the interview resumes from there.

Phase 2 — Spec synthesis (agent drafts → C2 approves)

Synthesize .omc/specs/<feature-slug>/spec.md. When the mission is an accepted intent, follow the four-step contract from the intent skill: read the accepted intent (latest round), combine with the existing codebase, follow the Rules pillar (CLAUDE.md + docs/standards/ + docs/business/), and list every doubt and rule conflict — graded into the spec's pending-confirmation section; intent open questions carry into the spec verbatim, keeping their pending status:

# <Feature> Spec
## Problem
## Solution
## User Stories        (numbered, each with testable acceptance criteria)
## Implementation Decisions
## Testing Decisions   (external behavior only)
## Out of Scope

Draft all of it, then stop at C2: present the acceptance criteria and the test seam list for human approval. When the mission is an accepted intent, the C2 presentation also carries the intent-flavor checklist: does the spec still solve the intent's original problem, are the carried open questions accounted for, and do high-risk items get a tech-lead consult before approval. Seams are selected by repo evidence and the deep-module discipline (public interfaces, existing test seams, depth analysis; the vocabulary is seeded in docs/standards/architecture.md); the human confirms or corrects the list — a seam the human has not approved gets no tests. Each seam entry declares its boundary class — in-process, locally substitutable, owned-remote (a port with a production and a test adapter), or true-external (an injected substitute) — because the class decides how the seam is tested.

Tender rule. When the interface's shape is itself contested — two plausible designs, neither settleable by talk — C2 signs between alternatives, never on the only proposal on the table: draft the candidate shapes in parallel sub-agents, each under a different emphasis (smallest interface surface · widest future fit · smoothest default path for the most common caller · cleanest cross-boundary adapter), present them side by side compared on depth, locality, and seam placement, and let the captain pick one or fold a hybrid.

Durability gate (agent-enforced, no approval needed): spec and tickets carry contracts, never coordinates — no file paths, no line numbers. Fragments encoding a decision better than prose (state machines, reducers, schemas) are the exception and state their origin (usually a loft).

Testing decisions retire orphans: when a seam is deepened or replaced, the tests pinned to the old interface retire with it — new tests write to the new interface only. The testing rules themselves are seeded in docs/standards/process.md.

Phase 3 — Ticket decomposition (agent drafts → C3 approves)

Split into vertical slices under .omc/specs/<feature-slug>/tickets/:

• NN-slug.md, one file per ticket, dependency-ordered, each declaring blockedBy: [ids]
• each ticket crosses every layer, is independently demonstrable, and fits one fresh context
• blocking edges are load-bearing declarations: a ticket states what it waits on — which decisions, artifacts (specs, ADRs, loft results), or other tickets — not just which ticket numbers. The declaration is C3's input: granularity wrong here misroutes every dependency, and a ticket whose waits are undeclared cannot be scheduled honestly on the frontier.
• wide refactors go expand-contract: add the new form, migrate in batches, remove the old — each batch a ticket

Agent-side mechanical validation runs first (independence, demonstrability, context fit). Then C3: present granularity, blocking edges, and proposed merges/splits for human approval. Iterate until approved. Mark every ticket ready-for-agent. The C3 bar: a fresh worker can start any ticket without a question back — a ticket that must ask sends the flaw up to the spec, not to the worker.

Integration-wiring rule: every vertical slice includes its own wiring and a smoke assertion — a slice whose output nothing mounts, serves, or imports is not done. Cross-slice seams that no single slice owns (route mounting, static serving, entry-point wiring) get an explicit integration ticket as the last frontier item.