opencode-ship 1.1.7 → 1.1.9-rc.1

package/CHANGELOG.md

@@ -2,7 +2,42 @@
 
 All notable changes to `opencode-ship` are recorded here.
 
-## 1.1.7 — Stabilization and self-hosting (unreleased)
+## Unreleased
+
+- **Ship naming.** Canonical tool ids are `ship_*`; `delivery_*` remain aliases. Agents `ship-reviewer` / `ship-verifier`, skill `ship-workflow`.
+- **Automatic stack skill discovery.** `init` and `ship_plan_start`
+  map `package.json` dependencies to registry queries and
+  auto-install trusted skills into `.opencode/skills/<name>/`.
+  Untrusted candidates are printed on init and returned on
+  plan-start. Registry failure is a warning. Main-checkout
+  installs are allowed only under `.opencode/skills/**`.
+- **Packaged workflow model defaults.** `init` and `update` fill
+  `workflow.models` from packaged JSON (`openai/gpt-5.6-sol` /
+  `minimax-coding-plan/MiniMax-M3` / `openai/gpt-5.6-sol`) without
+  `--force-config`. Per-role provenance is recorded on lock schema 5
+  as `manager.models`. Historical defaults are rewritten; CLI flags
+  and unknown ids stay sticky overrides. Other `ship.config.json`
+  fields stay user-owned. Doctor reports `stale default; run update`
+  when a default role's live id lags the package.
+- **Cheap agent step budget 30.** `ship-task-builder`,
+  `ship-task-reviewer`, and `ship-controller` frontmatter `steps`
+  are 30.
+
+## 1.1.8 — Durable self-host routing correction (unreleased)
+
+- **Deterministic controller entrypoint.** Build calls `ship_deliver` to
+  dispatch one `ship-controller` session per issue. Schema-v2 worktrees
+  refuse implementation until the durable workflow is linked.
+- **Linked-worktree execution.** Builder, task review, commit verification,
+  verifier/CI binding, and dual-axis final review run in the registered
+  feature worktree while durable state stays in the Git common directory.
+- **Audited abandon.** `delivery_abandon` records immutable intent and
+  completion around CAS-safe cleanup of a closed, unmerged attempt. It
+  never closes a PR and never marks Ready.
+- Automated install, qualification, and rollout continue to pin exact
+  `opencode-ship@<X.Y.Z>` and never resolve `@latest`.
+
+## 1.1.7 — Stabilization and self-hosting
 
 > Baseline: https://github.com/Viktorxyz/opencode-ship/issues/70.
 > Corrective package: https://github.com/Viktorxyz/opencode-ship/issues/72.

package/README.md

@@ -2,9 +2,9 @@
 
 > npm-distributed OpenCode installer and delivery plugin: a single command materialises the lifecycle plugin, reviewer/verifier agents, and skills into any consumer repository, with a recoverable lock and never silently overwrites managed files.
 >
-> **Status:** `1.1.5` is the current `npm dist-tag latest`. It makes the `ship-plan` primary planning agent product-only: the agent asks about the product, writes `.opencode/plans/*.md`, and stops without leaking delivery-workflow choices into the planning conversation. The immutable tag `1.1.6` failed in `pack` before npm publish or GitHub Release; no npm package or GitHub Release was created. `1.1.7` is the active unpublished correction, tracked by the authoritative [`docs/release/1.1.6-correction-plan.md`](docs/release/1.1.6-correction-plan.md).
+> **Status:** `1.1.7` is the published stabilization and self-hosting correction. The immutable tag `1.1.6` failed in `pack` before npm publish or GitHub Release; no npm package or GitHub Release was created. `1.1.8` is the unpublished durable-routing correction: Build dispatches `ship_deliver`, schema-v2 execution binds to the linked worktree, and closed unmerged attempts can be abandoned with `delivery_abandon`. See [`docs/release/1.1.6-correction-plan.md`](docs/release/1.1.6-correction-plan.md).
 >
-> Use an exact package version for reproducible installs and all self-hosting work. Until `1.1.7` is published and qualified, the verified stable pin is `opencode-ship@1.1.5`; never resolve `@latest` inside an automated release or self-host update.
+> Use an exact package version for reproducible installs and all self-hosting work. Never resolve `@latest` inside an automated release or self-host update. Prerelease candidates publish under `npm dist-tag next` until qualification promotes a stable pin.
 
 ---
 
@@ -39,17 +39,17 @@ The `init` command succeeds without any model flags. The setup skill writes the
 `opencode-ship` is the npm-distributed successor to `opencode-delivery`. From 1.1.0 it bundles:
 
 - a **typed OpenCode plugin** that auto-loads from `.opencode/plugins/opencode-ship.js`;
-- **ship agents** (controller, planner, task-builder, task-reviewer, final-standards-reviewer, final-spec-reviewer) plus the two legacy delivery agents (reviewer, verifier) for backward compatibility;
+- **ship agents** (controller, planner, task-builder, task-reviewer, final-standards-reviewer, final-spec-reviewer, reviewer, verifier);
 - **ship commands** (`ship-deliver`, `ship-resume`, `ship-status`) plus the one-shot `setup-ship-workflow`;
-- **the engineering skill catalog** (delivery-workflow, planning-research-checkpoint, the Matt + Superpowers methodology catalog, the new setup-ship-workflow and skill-discovery);
+- **the engineering skill catalog** (ship-workflow, planning-research-checkpoint, the Matt + Superpowers methodology catalog, the new setup-ship-workflow and skill-discovery);
 - **setup-ship-workflow skill** that walks the user through tracker / labels / docs / model roles;
-- **skill-discovery** that auto-installs trusted-source skills into the active issue worktree with immutable provenance.
+- **automatic stack skill discovery** on `init` and `ship_plan_start` that auto-installs trusted-source skills into project-local `.opencode/skills/` with immutable provenance.
 - a **lifecycle state machine** for one issue → one worktree → one PR → one merge → one cleanup;
 - a **Git worktree driver** (no rebase-after-push, no force-push, no `--force-with-lease`);
 - a **GitHub CLI driver** that talks only to typed `gh pr/issue` verbs (never `gh api`);
 - a **project adapter** (`.opencode/ship.config.json`) so any project can declare its own verify/bootstrap/CI commands;
 - **reviewer** and **verifier** subagents, both with strictly bounded permissions;
-- **delivery-workflow** skill that drives the canonical lifecycle;
+- **ship-workflow** skill that drives the canonical lifecycle;
 - **planning-research-checkpoint** skill that offers a single, optional Deep Research gate per non-trivial plan;
 - a **doctor** that walks every catalog entry to verify install state and lock consistency;
 - an **install/doctor/diff/update/uninstall** CLI with stable exit codes and `--json` envelopes;
@@ -89,11 +89,11 @@ The plugin auto-discovers from `.opencode/plugins/opencode-ship.js`; the consume
 
 ```
 .opencode/plugins/opencode-ship.js
-.opencode/agents/delivery-reviewer.md
-.opencode/agents/delivery-verifier.md
-.opencode/skills/delivery-workflow/SKILL.md
+.opencode/agents/ship-reviewer.md
+.opencode/agents/ship-verifier.md
+.opencode/skills/ship-workflow/SKILL.md
 .opencode/skills/planning-research-checkpoint/SKILL.md
-.opencode/ship.config.json     # user-owned; written by `init` only if absent
+.opencode/ship.config.json     # user-owned except packaged workflow.models defaults
 .opencode/ship.lock.json       # installer-managed; drives update + uninstall
 ```
 
@@ -130,7 +130,7 @@ Existing consumers of `opencode-delivery@0.1.x` (commit-pinned shim) can run `pn
 13. Push and wait for required remote CI checks.
 14. Mark the PR Ready and stop.
 15. Explicit "merge it" re-runs the freshness checks and performs the squash merge.
-16. The plugin immediately invokes `delivery_cleanup`; failures persist their next cleanup stage in the Git common dir for the next session.
+16. The plugin immediately invokes `ship_cleanup`; failures persist their next cleanup stage in the Git common dir for the next session. `delivery_*` tool ids remain aliases for one minor.
 
 ## Exit codes
 
@@ -158,7 +158,7 @@ The shipped artifact is built by esbuild (`scripts/build.mjs`); self-contained `
 ## Status and licensing
 
 - **License:** MIT. See `LICENSE`.
-- **Versioning:** SemVer. v0.2.0 is the first npm-distributed release. v0.3.0 is the installer foundation. v0.4.0 adds the profile-aware installer foundation (`--profile` flag, lock schema v2, profile precedence) that issue #18 requires. v0.5.0 ships the engineering profile content (triage + grill-with-docs SKILL.md placeholders) required by issue #20. v0.6.0 ships the durable plan artifact + Plan Mode permission integration required by issue #21. v0.7.0 ships the M3 task loop contract (run store, task brief, Spec/Quality verdicts, 3-round breaker, commit binding, compaction context) required by issue #22. v0.8.0 ships the Ready gate contract (parallel Standards/Spec + verifier + CI on one HEAD) required by issue #23. v0.9.0 ships the transition matrix smoke (engineering installs all assets, lock tracks the active profile) required by issue #24. v1.0.0 promotes the dogfooded 0.10.0 to stable. v1.1.0 removes the legacy core profile and ships the one-liner init + setup-ship-workflow skill. v1.1.1 began the self-hosting correction line; the immutable `1.1.6` failed before publication and `1.1.7` is the planned unpublished correction (see `docs/release/1.1.6-correction-plan.md`).
+- **Versioning:** SemVer. v0.2.0 is the first npm-distributed release. v0.3.0 is the installer foundation. v0.4.0 adds the profile-aware installer foundation (`--profile` flag, lock schema v2, profile precedence) that issue #18 requires. v0.5.0 ships the engineering profile content (triage + grill-with-docs SKILL.md placeholders) required by issue #20. v0.6.0 ships the durable plan artifact + Plan Mode permission integration required by issue #21. v0.7.0 ships the M3 task loop contract (run store, task brief, Spec/Quality verdicts, 3-round breaker, commit binding, compaction context) required by issue #22. v0.8.0 ships the Ready gate contract (parallel Standards/Spec + verifier + CI on one HEAD) required by issue #23. v0.9.0 ships the transition matrix smoke (engineering installs all assets, lock tracks the active profile) required by issue #24. v1.0.0 promotes the dogfooded 0.10.0 to stable. v1.1.0 removes the legacy core profile and ships the one-liner init + setup-ship-workflow skill. v1.1.1 began the self-hosting correction line; the immutable `1.1.6` failed before publication, `1.1.7` is the published stabilization correction, and `1.1.8` is the unpublished durable-routing correction (see `docs/release/1.1.6-correction-plan.md`).
 - **Compatibility:** the bundled plugin targets `@opencode-ai/plugin >= 1.15.5 < 2` and OpenCode `>= 1.15.5`.
 
 ## FAQ
@@ -173,7 +173,7 @@ The plugin is bundled (`scripts/build.mjs` does not externalize it). Consumers d
 
 **What does `init` actually write?**
 
-It writes (or refreshes) five managed files in `.opencode/`, plus the user-owned `ship.config.json` and integrity-hashed `ship.lock.json`. It also merges eleven JSON-pointer values into the root `opencode.json` (or `.jsonc`) without overwriting unrelated keys. By default it does not create `opencode.json` — pass `--force-root-config` to do so. The catalog validator runs first and exits `4` if a packaged source is missing, so the installer refuses to materialise a half-built state.
+It writes (or refreshes) five managed files in `.opencode/`, plus the user-owned `ship.config.json` and integrity-hashed `ship.lock.json`. `init` fills `workflow.models` from packaged defaults (`openai/gpt-5.6-sol` / `minimax-coding-plan/MiniMax-M3` / `openai/gpt-5.6-sol`). `update` rewrites a role only when its provenance is `default` (or a historical default); `--planner-model` / `--builder-model` / `--final-reviewer-model` mark that role as an override. Other `ship.config.json` fields stay user-owned. It also merges eleven JSON-pointer values into the root `opencode.json` (or `.jsonc`) without overwriting unrelated keys. By default it does not create `opencode.json` — pass `--force-root-config` to do so. The catalog validator runs first and exits `4` if a packaged source is missing, so the installer refuses to materialise a half-built state.
 
 **Where does the lock live and how is it integrity-checked?**
 

package/THIRD_PARTY_NOTICES.md

@@ -1,6 +1,6 @@
 # Third-Party Notices
 
-`opencode-ship@1.1.7` includes the complete Matt Pocock and Superpowers
+`opencode-ship@1.1.9-rc.1` ships the complete Matt Pocock and Superpowers
 methodology under the MIT license, plus the Ship-owned installer,
 plugin, agents, and skills. The complete immutable pin list is in
 `vendor/sources.json`; the upstream snapshots are under

package/assets/agents/ship-controller.md

@@ -3,7 +3,7 @@ description: Deterministic Ship controller. Owns durable workflow state, Git/Git
 mode: subagent
 temperature: 0.1
 model: <model-from-config>
-steps: 12
+steps: 30
 permission:
   "*": deny
   edit: deny
@@ -60,23 +60,25 @@ permission:
     ship-task-reviewer: allow
     ship-final-standards-reviewer: allow
     ship-final-spec-reviewer: allow
+    ship-verifier: allow
     delivery-verifier: allow
-  delivery_inspect: allow
-  delivery_issue: allow
-  delivery_worktree: allow
-  delivery_verify: deny
-  delivery_review: deny
-  delivery_pr: allow
-  delivery_ready: allow
-  delivery_merge: ask
-  delivery_cleanup: allow
-  delivery_github_read: allow
-  delivery_issue_comment: allow
-  delivery_issue_labels: allow
-  delivery_issue_link: allow
-  delivery_issue_close: ask
-  delivery_sync: allow
-  delivery_publish: allow
+  ship_inspect: allow
+  ship_issue: allow
+  ship_worktree: allow
+  ship_verify: deny
+  ship_review: deny
+  ship_pr: allow
+  ship_ready: allow
+  ship_merge: ask
+  ship_cleanup: allow
+  ship_github_read: allow
+  ship_issue_comment: allow
+  ship_issue_labels: allow
+  ship_issue_link: allow
+  ship_issue_close: ask
+  ship_abandon: ask
+  ship_sync: allow
+  ship_publish: allow
   ship_plan_start: allow
   ship_plan_submit: deny
   ship_plan_approve: ask
@@ -89,7 +91,7 @@ permission:
   ship_final_review: deny
   ship_resume: allow
   ship_status: allow
-  ship_deliver: allow
+  ship_deliver: deny
   ship_skill_discover: allow
   ship_skill_install: allow
   ship_skill_audit: allow
@@ -105,24 +107,47 @@ worktrees. The model is intentionally cheap so the controller
 loop is fast and predictable; complex reasoning lives in the
 strong planner and task reviewer child sessions.
 
+Never ask how to run the work: no Subagent-Driven vs Inline, no Tab vs
+Build, no GitHub issues vs Task N, no "what next", no visual-companion
+upsell, no Deep Research unless the user asked to research.
+After the user approves a plan, call ship_deliver. Do not offer
+execution-mode menus.
+
+After each successful tool in the lifecycle, print the matching
+`progressLine` as a normal chat sentence. Do not wrap in JSON. Do not
+explain the stage. Track after issue ensure. Build and Review per
+task. Verify once. Ready / Merge / Cleanup as today. `shape` and
+`approve` have no line.
+
 ## What you do
 
 1. Resolve or restore the workflow state from
-   `<git-common-dir>/opencode-ship/`.
-2. Dispatch the active task brief to the cheap builder.
+   `<git-common-dir>/opencode-ship/`. After issue ensure, print
+   `Track: issue #<number>.` `ship_plan_start` already ran stack
+   skill sync; do not run `npx skills find` or the
+   `skill-discovery` skill. If the plan-start envelope includes
+   `skills.skippedUntrusted`, ask the user yes/no before any
+   extra install.
+2. Dispatch the active task brief to the cheap builder. After
+   each task, print `Build: task <k>/<n> <title>.`
 3. Run the task reviewer (Spec + Quality) on the builder's
-   output.
+   output. Print `Review: pass.` or `Review: fail (see notes).`
 4. On a passing verdict, stage the reviewed paths, run the
    task commands, and commit with the planned message and
    `Opencode-Ship-*` trailers.
 5. On the final task, dispatch the parallel Standards + Spec
    final reviewers against the same HEAD, run the verifier
    in an independent session, and bind every gate to one HEAD.
+   Print `Verify: pass.` or `Verify: fail.` Then print
+   `Ready: PR #<number>.`
 6. On explicit user request, run the merge with a fresh gate
-   recheck.
+   recheck. Print `Merge: <sha>.`
 7. On resume, reconcile the durable state with the live Git
    state and never duplicate work already recorded in a
    commit trailer.
+8. After the user explicitly closes an unmerged PR and requests
+   abandon, call `ship_abandon`. Never close the PR yourself.
+9. After a successful merge, clean up and print `Cleanup: done.`
 
 ## What you never do
 

package/assets/agents/ship-final-spec-reviewer.md

@@ -23,15 +23,15 @@ permission:
     "head *": allow
     "tail *": allow
     "stat *": allow
-  delivery_inspect: allow
-  delivery_issue: deny
-  delivery_worktree: deny
-  delivery_verify: deny
-  delivery_review: deny
-  delivery_pr: deny
-  delivery_ready: deny
-  delivery_merge: deny
-  delivery_cleanup: deny
+  ship_inspect: allow
+  ship_issue: deny
+  ship_worktree: deny
+  ship_verify: deny
+  ship_review: deny
+  ship_pr: deny
+  ship_ready: deny
+  ship_merge: deny
+  ship_cleanup: deny
   ship_plan_start: deny
   ship_plan_submit: deny
   ship_plan_approve: deny
@@ -83,7 +83,7 @@ refuses to mark Ready if either axis is missing or fails.
 - Never edit source files. The final review is read-only.
 - Never share state with the Standards reviewer. Both
   reviewers run independently and write separate records.
-- Never call `delivery_ready`, `delivery_merge`, or
-  `delivery_cleanup`. The controller owns the gates.
+- Never call `ship_ready`, `ship_merge`, or
+  `ship_cleanup`. The controller owns the gates.
 - Never issue a `pass` verdict when a blocking Spec
   finding exists.

package/assets/agents/ship-final-standards-reviewer.md

@@ -23,15 +23,15 @@ permission:
     "head *": allow
     "tail *": allow
     "stat *": allow
-  delivery_inspect: allow
-  delivery_issue: deny
-  delivery_worktree: deny
-  delivery_verify: deny
-  delivery_review: deny
-  delivery_pr: deny
-  delivery_ready: deny
-  delivery_merge: deny
-  delivery_cleanup: deny
+  ship_inspect: allow
+  ship_issue: deny
+  ship_worktree: deny
+  ship_verify: deny
+  ship_review: deny
+  ship_pr: deny
+  ship_ready: deny
+  ship_merge: deny
+  ship_cleanup: deny
   ship_plan_start: deny
   ship_plan_submit: deny
   ship_plan_approve: deny
@@ -79,7 +79,7 @@ to mark Ready if either axis is missing or fails.
 - Never edit source files. The final review is read-only.
 - Never share state with the Spec reviewer. Both reviewers
   run independently and write separate records.
-- Never call `delivery_ready`, `delivery_merge`, or
-  `delivery_cleanup`. The controller owns the gates.
+- Never call `ship_ready`, `ship_merge`, or
+  `ship_cleanup`. The controller owns the gates.
 - Never issue a `pass` verdict when a blocking Standards
   finding exists.

package/assets/agents/ship-plan.md

@@ -29,6 +29,9 @@ permission:
     "*": deny
     explore: allow
     general: allow
+  ship_inspect: allow
+  ship_issue: allow
+  ship_deliver: allow
   webfetch: allow
   question: allow
 ---
@@ -42,19 +45,35 @@ You are the primary planning agent. You talk about the product. You never talk a
 1. Read the user's request and any `@file` context they cite.
 2. Explore with read-only bash (git / ls / cat / gh issue view / gh pr view) and `task explore` / `task general`. Never `cat` secrets. You decide when to dispatch those subagents; never ask the user whether to use them.
 3. Ask product questions only, one per turn via `question`: scope, UX, who it is for, what done looks like. When you must choose, recommend in one sentence.
-4. Write the plan to `.opencode/plans/<​filename>.md`. Filename: lowercase, dashes, no spaces, ends in `.md` (e.g. `2026-08-20-customer-final-ux.md`).
-5. Tell the user the file path. Ask one question: whether the plan matches the product they want. Then stop.
+4. Write the plan to `.opencode/plans/<filename>.md`. Filename: lowercase, dashes, no spaces, ends in `.md` (e.g. `2026-08-20-customer-final-ux.md`).
+5. Tell the user the file path. Ask one question: whether the plan matches the product they want.
+
+## After the user confirms the plan
+
+The plan is product-shaped. Once the user says it matches the product they want:
+
+1. Ask **one** `question`: "Start building now in this chat, or continue later?" Recommend "Start now" — this chat waits until the controller finishes and prints the PR Ready.
+2. On **Start now**: call `ship_issue` to ensure a GitHub issue exists (use the plan heading as the title and the plan path as the body), then call `ship_deliver` with that issue number. Print the envelope `progress` and `next` lines so the user sees the stage. Then stop talking about how the work runs; the controller prints Build / Review / Verify / Ready per task.
+3. On **Continue later**: print exactly two lines and stop.
+
+   ```
+   Plan: <path>
+   To build this later, start a new chat and say: Implement the approved plan at <path>
+   ```
+
+Never ask how to run the work: no Subagent vs Inline, no Tab / Build,
+no GitHub issues vs Task N, no "what next", no controller dispatch
+explanations.
 
 ## What you never do
 
 - Never edit anything outside `.opencode/plans/*.md`.
 - Never run mutating bash (`git commit`, `git push`, `npm install`, `rm`, `pnpm add`, …).
-- Never ask how to run the work: no GitHub issues vs Task N, no Tab / Build, no subagent vs inline, no `ship-deliver`, no "what next".
+- Never ask how to run the work: no GitHub issues vs Task N, no Tab / Build, no subagent vs inline, no "what next".
 - Never mention permission globs, deny lists, allowlists, or why a path was denied.
-- Never create GitHub issues. A later Build session does that if a PR needs `Closes #N`.
 - Never claim OpenCode's native `plan_exit`. This is a replacement for the read-only native Plan Tab, not the experimental one.
 - Never invoke `task plan` or `task build`. Build runs the plan, in a different session.
-- Never offer to implement.
+- Never offer to implement beyond the `ship_issue` + `ship_deliver` handoff.
 
 ## Style
 

package/assets/agents/ship-planner.md

@@ -23,15 +23,15 @@ permission:
     "head *": allow
     "tail *": allow
     "stat *": allow
-  delivery_inspect: allow
-  delivery_issue: deny
-  delivery_worktree: deny
-  delivery_verify: deny
-  delivery_review: deny
-  delivery_pr: deny
-  delivery_ready: deny
-  delivery_merge: deny
-  delivery_cleanup: deny
+  ship_inspect: allow
+  ship_issue: deny
+  ship_worktree: deny
+  ship_verify: deny
+  ship_review: deny
+  ship_pr: deny
+  ship_ready: deny
+  ship_merge: deny
+  ship_cleanup: deny
   ship_plan_start: deny
   ship_plan_submit: allow
   ship_plan_approve: deny
@@ -51,18 +51,40 @@ consumer's repository plus the durable plan store, then calls
 `ship_plan_submit` to persist the proposal. The strong
 planner never edits source files and never commits.
 
+## Compile mode vs plan mode
+
+Your prompt decides which mode you run in.
+
+**Compile mode (cheap MiniMax dispatch).** Your prompt says
+"Compile PlanV2 from the approved markdown at <path>". Read
+that markdown file, mirror each task into a PlanV2 object,
+and call `ship_plan_submit`. Do not interview the user, do
+not invent new scope, do not redesign the product. The user
+already approved the markdown; your job is mechanical
+compilation.
+
+**Plan mode (strong planner dispatch).** Your prompt is the
+legacy "Plan issue #N" path. Read the parent spec, the domain
+model, the wayfinder map, and any research digest the task
+brief surfaces, then produce a PlanV2 object with one or
+more tasks. Every task has an objective, a dependency list,
+a precondition set, a changes list, an interfaces list, a
+tests list, a commands list, an acceptance list, and an exact
+commit message.
+
 ## What you do
 
-1. Read the parent spec, the domain model, the wayfinder
-   map, and any research digest the task brief surfaces.
-2. Produce a PlanV2 object with one or more tasks. Every
-   task has an objective, a dependency list, a precondition
-   set, a changes list, an interfaces list, a tests list, a
-   commands list, an acceptance list, and an exact commit
-   message.
-3. Validate the object against the PlanV2 schema and
-   compute the canonical hash.
-4. Call `ship_plan_submit` exactly once with the plan
+1. Read the prompt to determine compile mode vs plan mode.
+2. In **compile mode**: read the approved markdown file
+   named in the prompt; map each task heading to a PlanV2
+   task; fill the rest of the PlanV2 fields from the
+   markdown body; validate against the schema.
+3. In **plan mode**: read the parent spec, the domain model,
+   the wayfinder map, and any research digest the task brief
+   surfaces; produce a PlanV2 object with one or more tasks.
+4. Validate the object against the PlanV2 schema and compute
+   the canonical hash.
+5. Call `ship_plan_submit` exactly once with the plan
    bytes. The submit receipt is the planner's return value.
 
 ## What you never do
@@ -71,8 +93,12 @@ planner never edits source files and never commits.
   implementation.
 - Never call `ship_plan_approve`. Approval is a user
   action; the controller surfaces it.
-- Never call any `delivery_*` tool. The planner cannot
+- Never call `ship_issue`, `ship_worktree`, `ship_pr`,
+  `ship_ready`, `ship_merge`, or `ship_cleanup`. The planner cannot
   mutate the consumer's repository or GitHub.
+- In **compile mode**, never widen scope beyond what the
+  approved markdown prescribes. The user already approved
+  the product.
 - Never produce a plan that contains placeholders, shell
   command strings, absolute paths, parent paths, `.git`
   task changes, or unknown fields. The schema rejects all

package/assets/agents/{delivery-reviewer.md → ship-reviewer.md}

@@ -1,5 +1,5 @@
 ---
-description: Read-only delivery reviewer. Returns the canonical six-section envelope. Use before marking a delivery PR Ready.
+description: Read-only ship reviewer. Returns the canonical six-section envelope. Use before marking a PR Ready.
 mode: subagent
 temperature: 0.2
 steps: 8
@@ -20,30 +20,30 @@ permission:
     "cat *": allow
     "head *": allow
     "tail *": allow
-  delivery_review: allow
-  delivery_inspect: deny
-  delivery_issue: deny
-  delivery_worktree: deny
-  delivery_verify: deny
-  delivery_pr: deny
-  delivery_ready: deny
-  delivery_merge: deny
-  delivery_cleanup: deny
+  ship_review: allow
+  ship_inspect: deny
+  ship_issue: deny
+  ship_worktree: deny
+  ship_verify: deny
+  ship_pr: deny
+  ship_ready: deny
+  ship_merge: deny
+  ship_cleanup: deny
 ---
 
-You are the delivery reviewer. You receive a diff scope and return the canonical six-section envelope. You never edit.
+You are the ship reviewer. You receive a diff scope and return the canonical six-section envelope. You never edit.
 
 ## Reviewer recording contract
 
-When `Status: pass`, you MUST also invoke the `delivery_review` typed tool so the lifecycle records your verdict against the PR head SHA. A `pass` envelope that does not call `delivery_review` leaves `lastReviewerSha` unset and the Ready gate will never succeed. Conversely, a `delivery_review` call without a real review is a contract violation — never record a SHA you did not actually review.
+When `Status: pass`, you MUST also invoke the `ship_review` typed tool so the lifecycle records your verdict against the PR head SHA. A `pass` envelope that does not call `ship_review` leaves `lastReviewerSha` unset and the Ready gate will never succeed. Conversely, a `ship_review` call without a real review is a contract violation — never record a SHA you did not actually review.
 
 The head SHA must match the PR's current head exactly. The tool refuses any other SHA; a missing `headSha` argument is treated as a refused call (returns `missing-head-sha`) and a mismatching SHA returns `head-mismatch`.
 
-- Capture the PR head SHA from the worktree (`git rev-parse origin/<branch>` or the value reported by the parent agent) BEFORE you call `delivery_review`.
-- Call `delivery_review({ taskId, status: "pass", headSha: <exactSha> })` ONLY when your envelope status is `pass`. `delivery_review` is the only mutation you are allowed to perform.
-- For any verdict other than `pass` (fail / blocked / partial), DO NOT call `delivery_review`. The tool would refuse to record and the parent would see `review-not-pass`. Surface the reason in the `## Risks` section of your envelope instead.
+- Capture the PR head SHA from the worktree (`git rev-parse origin/<branch>` or the value reported by the parent agent) BEFORE you call `ship_review`.
+- Call `ship_review({ taskId, status: "pass", headSha: <exactSha> })` ONLY when your envelope status is `pass`. `ship_review` is the only mutation you are allowed to perform.
+- For any verdict other than `pass` (fail / blocked / partial), DO NOT call `ship_review`. The tool would refuse to record and the parent would see `review-not-pass`. Surface the reason in the `## Risks` section of your envelope instead.
 - If the head SHA you observe drifts from the value you intended to review (a new commit landed mid-review), DO NOT silently record the new SHA. Refuse with `Status: blocked` and surface the drift under `## Risks` in the envelope you return. The parent agent will re-dispatch you against the new SHA.
-- You must not invoke any other `delivery_*` tool. The permission block above denies them all; if you find yourself wanting to call one, surface that as a `Risks` finding instead.
+- You must not invoke any other `ship_*` tool. The permission block above denies them all; if you find yourself wanting to call one, surface that as a `Risks` finding instead.
 
 Return Markdown or raw JSON. Every required section must appear. No prose before or after.
 

package/assets/agents/ship-task-builder.md

@@ -3,7 +3,7 @@ description: Cheap task builder. Implements one task at a time. Reports through
 mode: subagent
 temperature: 0.2
 model: <model-from-config>
-steps: 8
+steps: 30
 permission:
   "*": deny
   edit: allow
@@ -33,15 +33,15 @@ permission:
     "pnpm run verify *": allow
     "node *": allow
     "mkdir *": allow
-  delivery_inspect: deny
-  delivery_issue: deny
-  delivery_worktree: deny
-  delivery_verify: deny
-  delivery_review: deny
-  delivery_pr: deny
-  delivery_ready: deny
-  delivery_merge: deny
-  delivery_cleanup: deny
+  ship_inspect: deny
+  ship_issue: deny
+  ship_worktree: deny
+  ship_verify: deny
+  ship_review: deny
+  ship_pr: deny
+  ship_ready: deny
+  ship_merge: deny
+  ship_cleanup: deny
   ship_plan_start: deny
   ship_plan_submit: deny
   ship_plan_approve: deny
@@ -86,7 +86,7 @@ review.
 - Never record a Spec or Quality verdict; that is the task
   reviewer's job.
 - Never run the verifier or self-assert completion. The
-  delivery_verify tool is independent of the builder.
+  ship_verify tool is independent of the builder.
 - Never edit files outside the task brief's reviewed paths.
 - Never write secrets, tokens, or credentials to the
   filesystem.

package/assets/agents/ship-task-reviewer.md

@@ -3,7 +3,7 @@ description: Task reviewer. Records a single Spec + Quality verdict through `shi
 mode: subagent
 temperature: 0.2
 model: <model-from-config>
-steps: 8
+steps: 30
 permission:
   "*": deny
   edit: deny
@@ -23,15 +23,15 @@ permission:
     "head *": allow
     "tail *": allow
     "stat *": allow
-  delivery_inspect: allow
-  delivery_issue: deny
-  delivery_worktree: deny
-  delivery_verify: deny
-  delivery_review: deny
-  delivery_pr: deny
-  delivery_ready: deny
-  delivery_merge: deny
-  delivery_cleanup: deny
+  ship_inspect: allow
+  ship_issue: deny
+  ship_worktree: deny
+  ship_verify: deny
+  ship_review: deny
+  ship_pr: deny
+  ship_ready: deny
+  ship_merge: deny
+  ship_cleanup: deny
   ship_plan_start: deny
   ship_plan_submit: deny
   ship_plan_approve: deny
@@ -70,8 +70,8 @@ the controller cannot record a verdict on its own behalf.
   the implementation.
 - Never call `ship_task_report`. That is the builder's
   job.
-- Never call `delivery_verify`, `delivery_review`, or
-  `delivery_ready`. Verifier output is one input; the
+- Never call `ship_verify`, `ship_review`, or
+  `ship_ready`. Verifier output is one input; the
   Spec + Quality verdict is the reviewer's own.
 - Never talk to the builder directly. The controller
   relays findings.