ship

Use the tech-lead skill to run the full harness on $ARGUMENTS.

Default to interactive (auto_level = interactive): pause at every ⏸ gate and require PO sign-off — especially the Ship gate (L4). The harness's safety depends on the human being in the loop; do not skip gates by default.

Before anything else, dispatch tech-lead and let it open the run — its first action is harness init run, which writes the run receipt. Do not summarise what the harness will do; a session that dispatches the orchestrator and leaves no receipt is blocked at Stop by hooks/gate-zerowork.mjs.

How the run actually executes

On a spec with committed scopes/*.md — the common case — tech-lead holds the L0 intake conversation, writes project-profile.md, then hands the whole pipeline to a single background launch and does not drive it turn by turn:

Workflow({
  scriptPath: "${CLAUDE_PLUGIN_ROOT}/skills/tech-lead/workflows/shapeup-run.js",
  args: <the RunArgs object>
})

ORIENT → L1a → ANALYZE → WIRE → L1a.5 → MAP SCOPES → L1b → rounds of BUILD/L2/EVAL → QA → GATE H all run inside it. Three things follow, and they are the point of the cutover rather than trivia:

• A gate pause is a return value, not a stop. The launch returns {status: "paused", paused_at, block}; emit block verbatim, get the PO's decision, write it to .shapeup/<slug>/gate-answers.json, and relaunch the same call with the same args. The fast-forward re-derives position from disk and re-dispatches nothing already finished.
• A killed session loses nothing. Resume state comes off disk, never from context, so a fresh session picks the run up where it died — the property the whole launch shape exists to buy.
• The launch is the Workflow tool, which is what gives the run resume-from-journal, worktree isolation, and sub-agents that share the session's prompt cache instead of paying a cold start each. npx shapeup-sdlc init writes the "Workflow" grant it needs. That grant is unscoped — it authorises every dynamic workflow script in the project — so an install may decline it with --no-native-workflow, in which case the launch asks for approval once per session and the unattended lane is unavailable.

--tiny, and any spec with no committed scopes/*.md yet, take the unchanged prose lane in skills/tech-lead/references/protocol.md instead — non-regression, by design.

Only run headless/auto if the user explicitly asks for it in their message:

• --auto → advance low-risk gates automatically, still pause at L4 (Ship sign-off). Implies --gate-answers guarded unless a set is named.

• --unattended → fully headless, max_rounds 3. Intended for CI, not day-to-day local runs. Implies --gate-answers ci unless a set is named. In a claude -p invocation, set CLAUDE_CODE_PRINT_BG_WAIT_CEILING_MS=0 first. Print mode terminates a session's background tasks after 600 s, and the entire pipeline is one background launch, so without it the run is killed roughly ten minutes in — mid-phase, with no error beyond the CLI's own "background tasks still running; terminating". Resume state is on disk, so a relaunch fast-forwards past whatever finished; the cost is a relaunch, not the run. Typing the flag IS the confirmation — do not stop to ask for another one. Emit the warning that no human will review the verdict before ship as the run's first line, then proceed straight into GATE L0 in the same turn.

  Why this is spelled out: asking for confirmation here made --unattended unusable for the only job it has. In a non-interactive invocation (claude -p …, a CI step) there is no second turn in which to answer, so the run spent its turn requesting permission and exited having written nothing. A headless flag that cannot complete a headless run is a defect, not a safety feature — and the warning, which is the part that carries the safety value, is still printed. --auto remains the middle setting that pauses at L4.