opencode-ship 0.10.0-rc.19 → 0.10.0-rc.28

package/CHANGELOG.md

@@ -4,22 +4,68 @@ All notable changes to `opencode-ship` are recorded here.
 
 ## Unreleased
 
-- The `release/1.0-completion` branch contains the complete
-  production runtime for the planned `0.10.0` release. No
-  `0.10.0` or `1.0.0` has been published; consumers should keep
-  using `opencode-ship@0.9.0`. The local `v0.10.0` and `v1.0.0`
-  tags are placeholders only and must not be pushed.
-- See `RELEASING.md` for the operational runbook and
-  `.git/opencode-ship/plans/opencode-ship-1.0-completion/execution-state.json`
-  for the authoritative task state.
-
-### Shipped source on `release/1.0-completion` (not yet released)
-
-These changes are present in source on the
-`release/1.0-completion` branch but are not production-ready
-until the formal registry dogfood on the npm-published `0.10.0`
-succeeds. Items will move to a dated release header only after
-that step completes.
+- The `release/0.10.0` branch is the live release branch carrying
+  the complete production runtime for the planned `0.10.0` and
+  `1.0.0` releases. Release candidates are published under the
+  `next` npm dist-tag. No `0.10.0` or `1.0.0` has been published;
+  consumers should keep using `opencode-ship@0.9.0`. The local
+  `v0.10.0` and `v1.0.0` tags are placeholders only and must not
+  be pushed.
+- See `docs/release/1.0.0-execution-plan.md` for the authoritative
+  execution plan and issue #37 for the bounded evidence ledger.
+
+### Release-qualification gaps closed (S1)
+
+These changes close the S1 release-qualification gaps on the
+`release/0.10.0` branch:
+
+- **Real Node compatibility lanes.** The `node-compat` job's
+  `setup-node` step now drives from `${{ matrix.node }}` for each
+  matrix row (`22.6.0`, current `22`, `24`); the trusted-publishing
+  `publish` job remains the only place that pins `22.14.0`. The
+  per-row observed `node --version` output is uploaded and
+  aggregated into the qualification report by
+  `scripts/compose-node-versions.mjs`.
+- **Real OpenCode startup and discovery smoke.** A new
+  `tests/release/opencode-discovery.test.mjs` boots a real
+  `opencode serve` instance against a packed-tarball fixture
+  with both `core` and `engineering` profiles, polls
+  `/global/health`, reads `/experimental/tool/ids`, and asserts
+  the canonical 24-tool set exported from
+  `tests/plugin/expected-tools.mjs`. The canonical set is the
+  single source of truth shared by the in-process plugin-load
+  test and the live-server smoke.
+- **Correct prerelease metadata.** The publish job now resolves a
+  `prerelease` flag from a dedicated step that delegates to
+  `scripts/is-prerelease.mjs`. SemVer prereleases (`-rc.N`,
+  `-alpha.N`, `-beta.N`) become `prerelease: true`; stable
+  versions become `prerelease: false`.
+- **Version-independent runtimeSourceSha256.** A new
+  `scripts/runtime-source-sha.mjs` computes a deterministic
+  digest over `src/**`, `assets/**`, `schema/**`, `vendor/**`,
+  `scripts/build.mjs`, `scripts/prepack.mjs`, and a normalised
+  `package.json` with the top-level `version` field removed.
+  The qualification report carries `runtimeSourceSha256`, and the
+  release-policy job refuses any `1.0.x` tag whose digest does
+  not match the accepted `0.10.0` qualification artifact
+  (via `scripts/promote-1.0-policy.mjs`).
+- **Truthful documentation.** README, CHANGELOG, and this file
+  no longer claim `release/1.0-completion` is the live branch,
+  no longer assert a stale test-count baseline, and no longer
+  promise a promotion rule that depends on equal source SHAs
+  between `0.10.0` and `1.0.0`.
+- **Stronger neutral-consumer assertions.**
+  `tests/package/neutral-consumer.test.mjs` now requires explicit
+  model IDs before any engineering install writes, asserts the
+  engineering install's exit code is `0` before doctor runs, and
+  covers the engineering-init-without-models failure path.
+
+### Shipped source on `release/0.10.0` (not yet released)
+
+These changes are present in source on the `release/0.10.0`
+branch but are not production-ready until the formal registry
+dogfood on the npm-published `0.10.0` succeeds. Items will move
+to a dated release header only after that step completes.
 
 - Crash-safe Git-common storage: link()-based atomic publication
   with rename() fallback, SHA-256 hashed resource locks, explicit
@@ -76,7 +122,7 @@ that step completes.
 
 ### Planned (not yet shipped)
 
-These changes are present in source on the `release/1.0-completion` branch but are not production-ready and have not been published. Items will move to a dated release header only after the relevant plan task is verified end-to-end and the formal registry dogfood passes.
+These changes are present in source on the `release/0.10.0` branch but are not production-ready and have not been published. Items will move to a dated release header only after the relevant plan task is verified end-to-end and the formal registry dogfood passes.
 
 - Lock schema v3 with a `scope` field per root pointer record (core | engineering) and byte-stable hash identity.
 - `src/state/git-common-dir.js` and `src/state/durable-store.js` for the shared crash-safe storage under the resolved Git common directory.

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:** v0.9.0 published. The `release/1.0-completion` branch holds the complete production runtime for `0.10.0` and `1.0.0`: 24 typed tools (9 existing delivery tools + 7 control-plane tools + 8 workflow tools), the deterministic controller, the contract-version-2 envelope, the GitHub operation store, the immutable plan + run + commit ledgers, the same-HEAD gate, the bounded compaction block, the per-run resume lock, the fail-closed engineering profile, and the ten-job release qualification pipeline. The local `v0.10.0` and `v1.0.0` tags are placeholders only; they MUST NOT be pushed until the formal fourteen-step dogfood on the npm-published `0.10.0` succeeds. See `RELEASING.md` for the full operational runbook and `.git/opencode-ship/plans/opencode-ship-1.0-completion/execution-state.json` for the authoritative task state.
+> **Status:** v0.9.0 is the current `npm latest`. The `release/0.10.0` branch is the live release branch carrying the complete production runtime for the upcoming `0.10.0` and `1.0.0` releases: 24 typed tools (9 existing delivery tools + 7 control-plane tools + 8 workflow tools), the deterministic controller, the contract-version-2 envelope, the GitHub operation store, the immutable plan + run + commit ledgers, the same-HEAD gate, the bounded compaction block, the per-run resume lock, the fail-closed engineering profile, the version-independent `runtimeSourceSha256` digest, the ten-job release qualification pipeline with a real OpenCode discovery smoke, and the prerelease-aware GitHub release metadata. Release candidates are published under `npm dist-tag next`; stable `0.10.0` and `1.0.0` remain unpublished until their gates pass. The previously-mentioned `release/1.0-completion` branch is not the live release branch and is not referenced by this README or `RELEASING.md`. See `docs/release/1.0.0-execution-plan.md` for the authoritative execution plan and issue #37 for the bounded evidence ledger.
 >
-> No `0.10.0` or `1.0.0` has been published yet. Consumers should keep using `opencode-ship@0.9.0`.
+> Consumers should keep using `opencode-ship@0.9.0` until `1.0.0` is promoted to `npm dist-tag latest`.
 
 ---
 
@@ -113,7 +113,7 @@ Existing consumers of `opencode-delivery@0.1.x` (commit-pinned shim) can run `pn
 
 ## Development
 
-`npm run verify` runs `format:check`, `lint`, `typecheck`, `build`, and the auto-discovered test suite. The tests cover the installer CLI, the lock and root-config planners, the catalog validator, the schema validator, agents, the packed-artifact smoke check, the transaction-recovery contract, the profile-resolution precedence chain, the catalog profile filter, the order-preserving root-config merge, the engineering↔core transition, the durable plan artifact, the Plan Mode permission integration, the M3 task loop contract (run store + task brief + Spec/Quality verdicts + 3-round breaker + commit binding + compaction context), the Ready gate (parallel GPT Standards/Spec + verifier + CI on one HEAD; Build cannot self-record), and the transition matrix smoke (core omits engineering, engineering adds engineering, lock tracks the active profile). v0.9 ships with 320 tests across 34 suites on the approved plan hash `f85bae931d9eed7763e2f6f4dc68e5fad71bdd38c8a667fc9ffe78b5290200be`.
+`npm run verify` runs `format:check`, `lint`, `typecheck`, `build`, and the auto-discovered test suite. The tests cover the installer CLI, the lock and root-config planners, the catalog validator, the schema validator, agents, the packed-artifact smoke check, the transaction-recovery contract, the profile-resolution precedence chain, the catalog profile filter, the order-preserving root-config merge, the engineering↔core transition, the durable plan artifact, the Plan Mode permission integration, the M3 task loop contract (run store + task brief + Spec/Quality verdicts + 3-round breaker + commit binding + compaction context), the Ready gate (parallel GPT Standards/Spec + verifier + CI on one HEAD; Build cannot self-record), the transition matrix smoke (core omits engineering, engineering adds engineering, lock tracks the active profile), the static release-policy tests (Node matrix wiring, prerelease metadata, runtime-source digest wiring, 1.0 promotion policy), the runtime-source digest algorithm tests (deterministic across clean checkouts; ignores version and release-metadata changes; tracks every runtime-source modification), and the OpenCode live-server discovery smoke (24-tool canonical set exposed via `/experimental/tool/ids` on a real `opencode serve` instance for both `core` and `engineering` profiles). The suite count and per-test count are derived from the test runner at qualification time; this README intentionally does not lock in a specific test-count baseline.
 
 ```
 npm ci

package/THIRD_PARTY_NOTICES.md

@@ -1,6 +1,6 @@
 # Third-Party Notices
 
-`opencode-ship@0.10.0-rc.19` ships the complete Matt Pocock and Superpowers
+`opencode-ship@0.10.0-rc.28` 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/dist/cli.js

@@ -1,5 +1,5 @@
 #!/usr/bin/env node
-// opencode-ship CLI v0.10.0-rc.19
+// opencode-ship CLI v0.10.0-rc.28
 var __defProp = Object.defineProperty;
 var __getOwnPropNames = Object.getOwnPropertyNames;
 var __esm = (fn, res) => function __init() {
@@ -689,7 +689,7 @@ function resolvePackageRoot(startUrl) {
 import { readFileSync as readFileSync2, existsSync as existsSync2 } from "node:fs";
 import { dirname as dirname2, resolve as resolve2 } from "node:path";
 import { fileURLToPath as fileURLToPath2 } from "node:url";
-var PACKAGE_VERSION = "0.10.0-rc.19";
+var PACKAGE_VERSION = "0.10.0-rc.28";
 var TEMPLATE_SET = `v${PACKAGE_VERSION}`;
 
 // src/installer/catalog.js
@@ -2960,7 +2960,7 @@ async function assembleLock({ repoRoot, plan, lock, configPlan, rootPlan, profil
     manager: {
       schemaVersion: CURRENT_LOCK_SCHEMA,
       name: "opencode-ship",
-      version: "0.10.0-rc.19",
+      version: "0.10.0-rc.28",
       templateSet: TEMPLATE_SET_ID,
       // Newly written locks always carry the resolved profile so
       // future CLI invocations without --profile still resolve to
@@ -3535,7 +3535,8 @@ async function runDiff(options) {
     profile: options.profile ?? null,
     replaceManaged: false,
     forceConfig: false,
-    forceRootConfig: false
+    forceRootConfig: false,
+    models: options.models ?? null
   });
   if (!preview.ok) {
     const exitCode = preview.error?.kind === "unsupported-lock-schema" ? 5 : preview.error?.kind === "lock-invalid" ? 3 : 2;
@@ -3610,7 +3611,8 @@ async function runUpdate(options) {
     profile: options.profile ?? null,
     replaceManaged: options.replaceManaged,
     forceConfig: options.forceConfig,
-    forceRootConfig: options.forceRootConfig
+    forceRootConfig: options.forceRootConfig,
+    models: options.models ?? null
   });
   if (!preview.ok) {
     if (preview.error?.kind === "unsupported-lock-schema") {
@@ -3791,7 +3793,7 @@ ${helpText()}`);
       });
       return;
     case "diff":
-      await runDiff({ json: !!opts.json, rootPath: opts.rootPath, profile });
+      await runDiff({ json: !!opts.json, rootPath: opts.rootPath, profile, models: hasModels ? models : null });
       return;
     case "update":
       await runUpdate({

package/dist/core.js

@@ -1,4 +1,4 @@
-// opencode-ship/core v0.10.0-rc.19
+// opencode-ship/core v0.10.0-rc.28
 
 // src/adapter.js
 import { readFile, writeFile, mkdir, rename } from "node:fs/promises";

package/dist/plugin.js

@@ -1,4 +1,4 @@
-// opencode-ship v0.10.0-rc.19
+// opencode-ship v0.10.0-rc.28
 var __defProp = Object.defineProperty;
 var __getOwnPropNames = Object.getOwnPropertyNames;
 var __esm = (fn, res) => function __init() {
@@ -16793,7 +16793,7 @@ function flattenShipConfig(ship) {
 import { readFileSync as readFileSync2, existsSync as existsSync12 } from "node:fs";
 import { dirname as dirname7, resolve as resolve13 } from "node:path";
 import { fileURLToPath } from "node:url";
-var PACKAGE_VERSION = "0.10.0-rc.19";
+var PACKAGE_VERSION = "0.10.0-rc.28";
 var TEMPLATE_SET = `v${PACKAGE_VERSION}`;
 
 // src/plugin.js

package/docs/release/1.0.0-execution-plan.md

@@ -0,0 +1,972 @@
+# opencode-ship 1.0.0 execution plan
+
+> Status: Approved for execution
+> Owner: Maintainer
+> Last reviewed: 2026-08-07
+> Tracker: https://github.com/Viktorxyz/opencode-ship/issues/37
+> Related: [RELEASING.md](../../RELEASING.md),
+> [README.md](../../README.md), [CHANGELOG.md](../../CHANGELOG.md)
+
+## Purpose
+
+Finish `opencode-ship` as a registry-installed OpenCode engineering workflow,
+prove it in a neutral repository with real OpenCode, GitHub, and model
+dispatch, publish a byte-equivalent `1.0.0`, move npm `latest` to `1.0.0`, and
+then install it in a real consumer project.
+
+This plan is deliberately explicit so a low-cost Build model can execute
+reversible steps without making architecture or release-policy decisions.
+
+## Fixed decisions
+
+| Decision | Value |
+|---|---|
+| Final npm target | `opencode-ship@1.0.0` on `latest` |
+| Consumer profile | `engineering` |
+| Planner model | `openai/gpt-5.6-sol` |
+| Builder model | `minimax/MiniMax-M3` |
+| Final reviewer model | `openai/gpt-5.6-sol` |
+| First real qualification consumer | `Viktorxyz/opencode-ship-dogfood` |
+| Package source | npm registry only for external dogfood |
+| Merge policy | Explicit user request only |
+| Release policy | Immutable versions; a failed published RC is replaced by a new RC |
+
+Do not revisit these decisions during execution unless the user explicitly
+changes them.
+
+## Current factual baseline
+
+Re-check every value before starting because registry and branch state can
+change between sessions.
+
+| Item | Value at plan approval |
+|---|---|
+| Upstream repository | `/home/viktorcordas/repos/opencode-ship` |
+| Active release branch | `release/0.10.0` |
+| Active release HEAD | `9bc178c692cd197982c64c109440ece9205c460b` |
+| Published candidate | `0.10.0-rc.19` |
+| npm `next` | `0.10.0-rc.19` |
+| npm `latest` | `0.9.0` |
+| RC19 npm integrity | `sha512-rpD5sgCokj2GNBnXmnbRhnQh5FpHel2GtzspApLTMcQaZCuLEkt1iJcRqhwtzqY8ikC+nFHLWPkuvksNQFeXlw==` |
+| RC19 tarball SHA-256 | `410ef29ed3189fb041c44c51006b685b46b6d1d2b8da45128d1bc4ea7b3ca8d7` |
+| Neutral dogfood repository | Does not exist yet |
+| Obsolete Leo migration | `Viktorxyz/leo#221` |
+
+`Viktorxyz/leo#221` is not a migration base. It targets the abandoned
+`practices`/v0.4 proposal, is conflicting, and was produced by copying an
+unpublished artifact. It must eventually be closed as superseded by a fresh
+registry-generated migration.
+
+## Scope
+
+The critical path includes:
+
+1. Persisting the release tracker and evidence ledger.
+2. Closing known release-qualification gaps.
+3. Publishing and qualifying one final RC.
+4. Running registry-sourced neutral install acceptance.
+5. Publishing stable `0.10.0`.
+6. Running the real 14-step engineering dogfood.
+7. Promoting equivalent runtime source to `1.0.0` and npm `latest`.
+8. Installing `1.0.0` into a real project.
+9. Replacing Leo PR #221 with a clean migration.
+
+## Non-goals
+
+- Do not change Leo product, design-lab, API, dashboard, web, or database code.
+- Do not touch, clean, reset, stash, stage, or commit the dirty Leo main
+  worktree.
+- Do not add new workflow features after the final RC is selected.
+- Do not manually copy plugin, agent, command, or skill files into a consumer.
+- Do not treat `scripts/dogfood-local.mjs` or a fake harness as formal
+  external dogfood.
+- Do not publish `1.0.0` merely because unit and package tests pass.
+
+## Definition of done
+
+The release is complete only when all rows are proven with linked evidence.
+
+- [ ] `npm view opencode-ship dist-tags --json` returns `latest: 1.0.0`.
+- [ ] `pnpm dlx opencode-ship@latest --version` prints `1.0.0`.
+- [ ] The accepted final RC has a green qualification workflow and public
+      qualification artifact.
+- [ ] npm and pnpm install both `core` and `engineering` from the registry.
+- [ ] A real OpenCode CLI starts in the neutral consumer and discovers the
+      exact expected tool IDs.
+- [ ] `diff` is read-only and same-version init/update are idempotent.
+- [ ] A changed managed file causes a conflict without being overwritten.
+- [ ] `0.9.0` upgrades to the final candidate or stable package.
+- [ ] `engineering -> core -> engineering` transitions converge safely.
+- [ ] Uninstall restores pre-install root config bytes.
+- [ ] The real 14-step dogfood completes with real GitHub and real models.
+- [ ] Final Standards review, Spec review, verifier, CI, PR, and Ready records
+      bind to one HEAD.
+- [ ] Merge happens only after a separate explicit user request.
+- [ ] Cleanup succeeds and leaves no unpublished worktree commits.
+- [ ] `1.0.0` has the same version-independent runtime-source digest as the
+      accepted `0.10.0`.
+- [ ] A user-selected real project installs the `engineering` profile and
+      `doctor --json` exits 0.
+- [ ] Leo PR #221 is superseded by a fresh registry-generated migration.
+- [ ] README, CHANGELOG, RELEASING, GitHub release metadata, and npm dist-tags
+      all describe the same shipped state.
+
+## Safety and authorization gates
+
+The executing agent may autonomously inspect, edit, test, commit, push a normal
+feature branch, and open a draft PR when the user starts a Build session with
+this plan.
+
+The agent must stop and request explicit user authorization before each of the
+following operations:
+
+| Gate | Irreversible or externally visible operation |
+|---|---|
+| A | Create `Viktorxyz/opencode-ship-dogfood`; the user chooses visibility, default private |
+| B | Merge a qualification or release PR |
+| C | Push any release tag |
+| D | Trigger an npm stable/candidate publication if tag push is not itself the trigger |
+| E | Merge the real dogfood PR |
+| F | Run `npm dist-tag add ... latest` |
+| G | Merge the Leo migration PR |
+
+Never use force-push, hard reset, stash, tag mutation, version overwrite,
+manual npm publish, raw Git ref plumbing, or a bypass around a failed gate.
+
+## Evidence ledger
+
+The parent issue is the authoritative progress tracker. Add one bounded comment
+after every slice using this schema:
+
+```text
+Status: pass | fail | blocked | partial
+Phase: S0 | S1 | S2 | S3 | S4 | S5 | S6 | S7 | S8
+Source SHA: <40 hex>
+Package version: <semver or n/a>
+Summary:
+- <at most three bullets>
+Evidence:
+- issue/PR/workflow/release URLs
+- npm integrity and tarball SHA-256 when applicable
+- artifact URL when applicable
+Verification:
+- <command> -> exit <code>
+Risks:
+- <unresolved concern or none>
+Next authorization: <exact gate or none>
+```
+
+Never place tokens, credentials, raw model prompts containing secrets, or
+unsanitized environment dumps in the issue or repository.
+
+## Work breakdown
+
+| Slice | Deliverable | Type | Blocked by |
+|---|---|---|---|
+| S0 | Durable plan and parent tracker | AFK | None |
+| S1 | Release qualification gaps closed | AFK | S0 |
+| S2 | Final RC published and qualified | HITL release | S1 |
+| S3 | Neutral registry acceptance green | HITL repo creation | S2 |
+| S4 | Stable `0.10.0` published | HITL release | S3 |
+| S5 | Real 14-step dogfood green | HITL merge | S4 |
+| S6 | Equivalent `1.0.0` promoted to `latest` | HITL release | S5 |
+| S7 | Real-project and Leo consumer migrations | HITL merge | S6 |
+| S8 | Evidence closure and truthful docs | AFK | S7 |
+
+## S0: Persist the plan and tracker
+
+### Goal
+
+Create durable coordination surfaces before changing release code.
+
+### Steps
+
+1. Re-read this plan, `README.md`, `CHANGELOG.md`, `RELEASING.md`,
+   `schema/ship-config.schema.json`, `.github/workflows/release.yml`, and
+   `tests/package/neutral-consumer.test.mjs`.
+2. Confirm the upstream worktree is clean and record branch, HEAD, remote main,
+   npm dist-tags, and the highest published RC.
+3. Create or reuse the parent GitHub issue named at the top of this file.
+4. Add the issue URL to this document's `Tracker` header.
+5. Add the S0 evidence comment to the issue.
+6. Commit this plan before any release or runtime changes.
+
+### Verification
+
+```bash
+git diff --check
+git status --short
+npm view opencode-ship dist-tags --json
+```
+
+### Acceptance
+
+- [ ] The parent issue exists.
+- [ ] The issue and this file contain identical fixed decisions.
+- [ ] Current branch, SHA, and npm tags are recorded.
+- [ ] No runtime or release workflow code changed in the plan commit.
+
+## S1: Close release-qualification gaps
+
+### Goal
+
+Make the release pipeline prove the claims it records before publishing another
+immutable candidate.
+
+### Branching
+
+Create a normal feature branch from the current `release/0.10.0` head. Open a
+PR back to `release/0.10.0`. Do not work directly on the release branch.
+
+### Required changes
+
+#### 1. Real Node compatibility lanes
+
+The release workflow currently declares Node `22.6.0`, current 22, and 24 but
+sets up Node `22.14.0` in every lane. Change the compatibility job so each
+matrix row runs the declared runtime. Keep Node 22.14/npm 11.5.2 only in the
+trusted-publishing job where npm OIDC requires it.
+
+Acceptance:
+
+- [ ] Workflow source proves `matrix.node` drives setup-node.
+- [ ] Tests or static policy checks fail if the matrix is ignored.
+- [ ] Qualification reports the actual Node versions observed.
+
+#### 2. Real OpenCode startup and discovery smoke
+
+Package-level plugin import tests are insufficient. Add a deterministic test or
+release job that:
+
+1. Creates a neutral temporary Git repository.
+2. Installs the packed package into that repository.
+3. Initializes `core` and `engineering` in separate fixtures.
+4. Installs a pinned real OpenCode CLI.
+5. Starts `opencode serve` with an isolated HOME and the fixture as cwd.
+6. Polls `/global/health` until healthy or a bounded timeout expires.
+7. Reads `/experimental/tool/ids`.
+8. Compares the exact set with the canonical expected set from
+   `tests/plugin/plugin-load.test.mjs`.
+9. Terminates the server and proves cleanup.
+
+Exercise OpenCode `1.15.5` and `1.18.10`. Do not make a model call.
+
+Acceptance:
+
+- [ ] Both supported OpenCode versions boot successfully.
+- [ ] The engineering fixture exposes exactly the expected 24 custom tools.
+- [ ] Missing or extra tools fail the release.
+- [ ] Timeout and process cleanup are deterministic.
+
+#### 3. Correct prerelease metadata
+
+GitHub release `0.10.0-rc.19` was marked as a normal release. Configure the
+release step so SemVer prereleases are marked prerelease and stable versions
+are not.
+
+Acceptance:
+
+- [ ] RC metadata test expects `prerelease=true`.
+- [ ] Stable metadata test expects `prerelease=false`.
+
+#### 4. Version-independent runtime-source digest
+
+The existing runbook asks `1.0.0` to match the `0.10.0` source SHA, which is
+impossible after a version/docs commit. Replace that rule with a reproducible
+`runtimeSourceSha256`.
+
+The canonical digest must include the version-independent inputs that can
+change behavior:
+
+```text
+src/**
+assets/**
+schema/**
+vendor/**
+scripts/build.mjs
+scripts/prepack.mjs
+package.json with the top-level `version` field removed before canonicalization
+```
+
+Sort normalized relative paths, include path separators and bytes in the hash,
+and exclude generated output, lockfile version, README, CHANGELOG, and release
+metadata. The normalized package manifest remains in scope because `bin`,
+`exports`, `files`, `engines`, and peer ranges affect consumer behavior even
+when runtime source bytes do not change. Document the exact algorithm and test
+it with an independent implementation or golden fixture.
+
+Add `runtimeSourceSha256` to the qualification report. For `1.0.x`, the release
+policy must fetch the accepted `0.10.0` qualification artifact and refuse the
+release unless the digest matches.
+
+Acceptance:
+
+- [ ] Digest is deterministic across clean checkouts.
+- [ ] Runtime source modification changes the digest.
+- [ ] Version/docs-only changes do not change the digest.
+- [ ] `1.0.0` promotion fails when the accepted `0.10.0` digest is absent or
+      different.
+
+#### 5. Truthful documentation and branch names
+
+Update README, CHANGELOG, and RELEASING to state the actual current status:
+
+- RCs are published under npm `next`.
+- `release/0.10.0` is the live release branch.
+- `release/1.0-completion` does not exist and must not be referenced as live.
+- Stable `0.10.0` and `1.0.0` remain unpublished until their gates pass.
+- Promotion compares `runtimeSourceSha256`, not impossible source-SHA equality.
+- The release job count and matrix must match the actual workflow.
+
+#### 6. Stronger neutral-consumer assertions
+
+`tests/package/neutral-consumer.test.mjs` must not run `doctor` after an
+unchecked engineering init. Require explicit model IDs, assert init exit 0,
+then assert doctor exit 0 and profile footprint.
+
+Add explicit coverage that engineering init without model IDs fails before any
+write.
+
+### Required verification
+
+```bash
+npm ci
+npm run verify
+npm pack --json
+git diff --check
+git status --short
+```
+
+Run an independent code review on the final PR HEAD. Resolve every Critical or
+Important finding before merge.
+
+### Acceptance
+
+- [ ] Every required change above has an automated regression test.
+- [ ] `npm run verify` exits 0.
+- [ ] Packed artifact smoke exits 0.
+- [ ] Independent review passes on the final HEAD.
+- [ ] The PR is merged into `release/0.10.0` only after Gate B authorization.
+
+## S2: Publish and qualify the final RC
+
+### Goal
+
+Publish one immutable candidate containing the corrected qualification policy.
+
+### Version selection
+
+Resolve the next unused RC at execution time. The expected version is
+`0.10.0-rc.20`, but if that version exists, choose the next unused integer.
+
+```bash
+npm view opencode-ship versions --json
+```
+
+Set and record:
+
+```bash
+export RC=<next-unused-0.10.0-rc.N>
+```
+
+### Steps
+
+1. Start from the reviewed and merged `release/0.10.0` head.
+2. Bump `package.json` and `package-lock.json` to `$RC` without creating a tag.
+3. Update release-status docs only where the candidate number must appear.
+4. Run the full local verification.
+5. Commit and push the release version commit.
+6. Confirm the release branch HEAD, package version, lock version, and proposed
+   tag all match.
+7. Stop at Gate C and request permission to push the signed release tag.
+8. After authorization, create and push the canonical no-leading-v signed tag.
+9. Monitor all release qualification jobs.
+10. If any job fails, do not reuse the version. Fix source, choose the next RC,
+    and repeat S1/S2 verification.
+11. On success, verify npm registry metadata, provenance, integrity,
+    post-publish install smoke, GitHub prerelease metadata, SBOM, tarball hash,
+    and qualification artifact.
+12. Record all evidence in the parent issue.
+
+### Acceptance
+
+- [ ] Every qualification job is green on one source tag.
+- [ ] npm `next` points to `$RC`.
+- [ ] Registry integrity equals the qualification report.
+- [ ] GitHub asset digest equals the tarball SHA-256.
+- [ ] GitHub marks the release prerelease.
+- [ ] `runtimeSourceSha256` exists in the qualification artifact.
+- [ ] Registry-sourced `--version` prints `$RC`.
+
+## S3: Neutral registry acceptance
+
+### Goal
+
+Prove that a non-Leo project can safely install and operate the published RC.
+
+### Repository fixture
+
+The neutral repository is `Viktorxyz/opencode-ship-dogfood`. Re-check whether
+it exists. If absent, stop at Gate A before creating it. Ask the user to choose
+visibility; use private unless the user explicitly requests public evidence.
+
+The repository must contain only:
+
+- a Git repository on `main` with a GitHub origin;
+- a private, single-dependency Node package;
+- `node --test` as its verification command;
+- a required GitHub status check named `verify`;
+- two ordered implementation tasks used later in S5;
+- an `opencode.json` with `$schema`, `share: "disabled"`, and unrelated sentinel
+  fields that must survive install/uninstall;
+- no Leo code, no local opencode-ship link, and no manually copied assets.
+
+Use these deterministic dogfood tasks:
+
+| Task | User-visible behavior | Test seam |
+|---|---|---|
+| A | Add `formatReleaseLabel(version)` that returns a canonical `v<semver>` label and rejects malformed input | `node:test` unit cases |
+| B | Add a small CLI that prints the canonical label and exits nonzero for malformed input | spawned CLI integration cases |
+
+For Task B round 1, the dogfood fixture deliberately omits the nonzero invalid
+input path so the reviewer has one real blocking finding. Round 2 fixes it.
+
+### Preflight
+
+Record, without secrets:
+
+```bash
+node --version
+git --version
+gh --version
+gh auth status
+opencode --version
+pnpm --version
+npm --version
+```
+
+Requirements:
+
+- Node `>=22.6.0`;
+- OpenCode `>=1.15.5`;
+- authenticated GitHub CLI with repository access;
+- npm and pnpm able to reach the public registry.
+
+### Command wrapper
+
+Use the exact accepted RC version, never `latest` or an unpinned local path:
+
+```bash
+ship() {
+  pnpm dlx --package="opencode-ship@$RC" opencode-ship "$@"
+}
+```
+
+### Acceptance matrix
+
+#### A1: Root conflict refusal
+
+Create a disposable conflicting Build permission in a fixture clone. Run init.
+
+Expected: exit 3, conflict reported, existing bytes unchanged, no partial lock
+or managed files.
+
+#### A2: Read-only preview
+
+Digest the fixture tree, run:
+
+```bash
+ship diff \
+  --profile engineering \
+  --planner-model openai/gpt-5.6-sol \
+  --builder-model minimax/MiniMax-M3 \
+  --final-reviewer-model openai/gpt-5.6-sol \
+  --json
+```
+
+Expected: exit 1 with `status: changed`; tree digest is unchanged.
+
+#### A3: Clean engineering initialization
+
+```bash
+ship init \
+  --profile engineering \
+  --planner-model openai/gpt-5.6-sol \
+  --builder-model minimax/MiniMax-M3 \
+  --final-reviewer-model openai/gpt-5.6-sol \
+  --force-config \
+  --strict-doctor \
+  --json
+```
+
+Use `--force-root-config` only in a fixture that has no root OpenCode config.
+
+Expected: exit 0; engineering lock/profile, model configuration, managed files,
+root pointers, hashes, and sentinel fields are correct.
+
+#### A4: Doctor
+
+```bash
+ship doctor --profile engineering --json
+```
+
+Expected: exit 0 and every required row `noop`.
+
+#### A5: Real OpenCode discovery
+
+Quit any existing OpenCode session because project config is not hot-reloaded.
+Start a fresh real OpenCode server with the neutral repo as cwd and an isolated
+HOME. Poll `/global/health`; read `/experimental/tool/ids`; assert the exact
+expected custom tool set from the accepted package.
+
+Expected: health 200, no config error, exact tool IDs, clean server shutdown.
+
+#### A6: Idempotency
+
+Run `diff`, `init`, and `update` again at the same version.
+
+Expected: diff exit 0/noop; init/update exit 0; no creates, updates, deletes, or
+conflicts; managed bytes and sentinel root config are unchanged.
+
+#### A7: Managed-file conflict
+
+Modify one managed agent in a disposable fixture and run update.
+
+Expected: exit 3; edited bytes and prior lock remain unchanged. Restore the
+file; update then exits 0.
+
+#### A8: Upgrade from stable 0.9.0
+
+Initialize a fresh fixture using exactly `0.9.0`, then run accepted RC diff,
+update, doctor, and OpenCode discovery.
+
+Expected: update exit 0, lock manager version changes to `$RC`, final diff is
+noop, doctor and discovery pass.
+
+#### A9: Profile transitions
+
+Run `core -> engineering -> core -> engineering`, checking managed files,
+Plan Mode root pointers, lock scope, and root sentinel bytes after every step.
+
+Expected: profile-specific files/pointers are added and removed exactly once,
+with no residue or user-field loss.
+
+#### A10: Uninstall and restoration
+
+```bash
+ship uninstall --purge-config --json
+```
+
+Expected: exit 0; managed files, lock, and generated ship config are absent;
+user files remain; original root OpenCode config bytes are restored.
+
+#### A11: npm invoker
+
+Repeat clean core and engineering installs with:
+
+```bash
+npm exec --yes --package="opencode-ship@$RC" -- opencode-ship <command>
+```
+
+Expected: results match pnpm invocation.
+
+### Acceptance
+
+- [ ] A1-A11 pass from registry bytes.
+- [ ] No test uses source checkout, local link, or local tarball.
+- [ ] Sanitized evidence is linked in the parent issue.
+- [ ] No consumer-owned root field changed unexpectedly.
+
+## S4: Publish stable 0.10.0
+
+### Goal
+
+Publish the accepted candidate runtime as stable `0.10.0` under npm `next`.
+
+### Invariants
+
+- No runtime-source file may change after S3 acceptance.
+- The candidate and stable `runtimeSourceSha256` must match.
+- Only package/lock version, release docs, and release metadata may differ.
+
+### Steps
+
+1. Start from the accepted RC source.
+2. Bump `package.json` and `package-lock.json` to `0.10.0` without tagging.
+3. Update README, CHANGELOG, and RELEASING status truthfully.
+4. Run full local verification and compute the runtime-source digest.
+5. Open the stable release PR into `main` so the eventual tag is reachable
+   from `origin/main`.
+6. Require independent review and all branch CI.
+7. Stop at Gate B before merging.
+8. After explicit authorization, merge and fetch the final main SHA.
+9. Verify final main has version `0.10.0`, expected digest, and a clean tree.
+10. Stop at Gate C before creating/pushing signed tag `0.10.0`.
+11. After authorization, push the tag and monitor the full release workflow.
+12. Verify npm `next`, registry integrity, provenance, GitHub assets, SBOM,
+    qualification report, and post-publish registry smoke.
+13. Record the accepted `0.10.0` runtime-source digest and artifact URLs.
+
+### Acceptance
+
+- [ ] `opencode-ship@0.10.0` is publicly installable.
+- [ ] npm `next` points to `0.10.0`.
+- [ ] Stable release metadata is not marked prerelease.
+- [ ] Stable digest equals accepted RC digest.
+- [ ] Full qualification report is public and green.
+
+## S5: Formal real 14-step dogfood
+
+### Goal
+
+Prove the complete engineering lifecycle using the npm-published stable
+`0.10.0`, real OpenCode, real GitHub, and the approved real model roles.
+
+### Hard rule
+
+Do not substitute `scripts/dogfood-local.mjs`, fake GitHub, fake models, direct
+source imports, or a packed local tarball. Those remain useful pre-release
+tests but do not satisfy S5.
+
+### Environment
+
+```bash
+export DOGFOOD_REPO=/path/to/opencode-ship-dogfood
+export DOGFOOD_PLANNER=openai/gpt-5.6-sol
+export DOGFOOD_BUILDER=minimax/MiniMax-M3
+export DOGFOOD_REVIEWER=openai/gpt-5.6-sol
+```
+
+### Required sequence
+
+1. Install `opencode-ship@0.10.0` core from npm.
+2. Upgrade the same repo to engineering with explicit model IDs.
+3. Restart OpenCode and have the real strong planner generate PlanV2 for dogfood
+   Tasks A and B.
+4. Obtain explicit user approval and persist the immutable plan seal.
+5. Use typed tools to create the issue, worktree, branch, and draft PR linked
+   with `Closes #N`.
+6. Dispatch Task A to the MiniMax builder; run Spec and Quality task reviews;
+   require pass; commit only the reviewed range.
+7. Trigger native OpenCode compaction after Task A and capture the bounded
+   opencode-ship resume context.
+8. Dispatch Task B round 1 with the controlled missing invalid-input path;
+   require the reviewer to return one blocking finding.
+9. Trigger native compaction during Task B fix work.
+10. Invoke `ship_resume`; verify the durable ledger resumes the same task,
+    revision, review round, and immutable plan hash.
+11. Test issue-mirror restoration. Before removing local plan storage, stop for
+    explicit user confirmation and record the exact disposable path. Remove
+    only the dogfood plan copy, then invoke `ship_resume` and prove restoration
+    from the verified issue mirror.
+12. Finish Task B round 2. On one final HEAD, run parallel strong Standards and
+    Spec reviews, independent verification, and required `verify` CI. Every
+    record must reference the same HEAD and package integrity.
+13. Invoke `delivery_ready`. Capture evidence that the PR is Ready and unmerged.
+14. Stop at Gate E. Only after the user says `merge it`, invoke the typed merge,
+    re-check fresh same-HEAD gates, squash merge, clean the worktree, downgrade
+    to core, then uninstall and prove root-config restoration.
+
+### Required evidence
+
+- Issue and PR URLs.
+- npm package version and integrity.
+- Plan revision, plan hash, approval record, and mirror URL.
+- Sanitized model-routing records for planner, builder, and final reviewers.
+- Task A and Task B review records.
+- Compaction snapshots and resume counters.
+- Mirror restoration evidence.
+- Final Standards, Spec, verifier, CI, PR, and Ready common HEAD.
+- Ready-before-merge snapshot.
+- Explicit merge authorization and merge SHA.
+- Cleanup result.
+- Core downgrade and uninstall byte-restoration hashes.
+
+### Acceptance
+
+- [ ] All 14 steps complete in order.
+- [ ] No step is simulated.
+- [ ] No context loss changes task identity, plan hash, or review round.
+- [ ] Ready does not merge.
+- [ ] Merge requires a separate explicit user request.
+- [ ] Cleanup and uninstall restoration pass.
+
+If any runtime defect appears, stop. Publish a new immutable 0.10 patch/RC as
+appropriate and repeat the complete dogfood. Never promote known-defective
+runtime bytes.
+
+## S6: Promote equivalent 1.0.0 to npm latest
+
+### Goal
+
+Publish `1.0.0` with the exact dogfooded runtime-source inputs and make it the
+default npm install.
+
+### Allowed changes from accepted 0.10.0
+
+- `package.json` version;
+- `package-lock.json` version;
+- README release status;
+- CHANGELOG release status;
+- RELEASING release status;
+- release metadata that does not affect runtime behavior.
+
+No other change is allowed. Any runtime-source change invalidates S5 and
+requires another 0.10 dogfood.
+
+### Steps
+
+1. Create a release branch from the accepted `0.10.0` tag/main state.
+2. Bump package and lock to `1.0.0` without tagging.
+3. Update release documentation.
+4. Run full verification and compute `runtimeSourceSha256`.
+5. Compare it to the accepted `0.10.0` qualification artifact.
+6. Open the 1.0 promotion PR into `main`.
+7. Require independent review and CI.
+8. Stop at Gate B before merge.
+9. After authorization, merge and verify final main state.
+10. Stop at Gate C before creating/pushing signed tag `1.0.0`.
+11. After authorization, push the tag and monitor all qualification jobs.
+12. Verify publication under npm `candidate`, provenance, integrity, assets,
+    qualification artifact, and registry smoke.
+13. Re-run clean neutral `init`, `doctor`, real OpenCode discovery, and
+    uninstall using exactly `opencode-ship@1.0.0`.
+14. Stop at Gate F before changing npm `latest`.
+15. After authorization, run:
+
+```bash
+npm dist-tag add opencode-ship@1.0.0 latest
+```
+
+16. Verify registry propagation from a clean npm cache and fresh directory.
+
+### Acceptance
+
+- [ ] `1.0.0` qualification is green.
+- [ ] `1.0.0` runtime-source digest equals accepted `0.10.0`.
+- [ ] npm provenance and GitHub asset digest match.
+- [ ] Clean registry install and real OpenCode discovery pass.
+- [ ] `npm view opencode-ship dist-tags --json` reports `latest: 1.0.0`.
+- [ ] `pnpm dlx opencode-ship@latest --version` prints `1.0.0`.
+
+## S7: Install real consumers
+
+### Part A: User-selected project
+
+Ask the user for the target repository path. Inspect its package manager,
+OpenCode config, Git remote, default branch, verification command, required CI,
+and existing agents/skills before writing.
+
+Run read-only preview first:
+
+```bash
+pnpm dlx opencode-ship@latest diff \
+  --profile engineering \
+  --planner-model openai/gpt-5.6-sol \
+  --builder-model minimax/MiniMax-M3 \
+  --final-reviewer-model openai/gpt-5.6-sol \
+  --json
+```
+
+Resolve every ownership conflict explicitly. Then initialize:
+
+```bash
+pnpm dlx opencode-ship@latest init \
+  --profile engineering \
+  --planner-model openai/gpt-5.6-sol \
+  --builder-model minimax/MiniMax-M3 \
+  --final-reviewer-model openai/gpt-5.6-sol \
+  --force-config \
+  --strict-doctor \
+  --json
+```
+
+Use `--force-root-config` only when the target has no root OpenCode config and
+the user approves creating one.
+
+Quit and restart OpenCode after installation. Verify doctor, startup, exact
+tool/agent/skill discovery, unchanged user-owned root fields, and one small
+real issue through worktree, PR, review, verification, CI, and Ready. Stop
+before merge unless the user explicitly authorizes it.
+
+### Part B: Leo replacement migration
+
+The Leo main worktree contains unrelated design-lab changes. Never touch it.
+
+1. Use a fresh isolated worktree from current remote `main`.
+2. Create a new Leo GitHub issue for the `opencode-ship@1.0.0` registry
+   migration.
+3. Run registry `diff` and `init --profile engineering` with the approved model
+   IDs.
+4. Never copy managed artifacts manually.
+5. Reconcile `opencode.json`, `.opencode/ship.config.json`, generated lock,
+   package lock, agent task permissions, AGENTS skill names, workflow docs,
+   plugin contract tests, and `docs/delivery/STATUS.md`.
+6. Ensure every installed companion file is present and every managed hash is
+   final, not `pending`.
+7. Remove legacy `opencode-delivery` paths only through supported migration
+   behavior or explicit reviewed cleanup.
+8. Run frozen install from a clean checkout/worktree.
+9. Run `pnpm verify:workspace`.
+10. Run canonical delivery reviewer, verifier, and required CI on one final
+    HEAD.
+11. Open the replacement PR and mark Ready only when gates are fresh.
+12. Close Leo PR #221 as superseded only after the replacement URL exists.
+13. Stop at Gate G before merging the replacement.
+
+### Acceptance
+
+- [ ] User-selected project works with `opencode-ship@latest` engineering.
+- [ ] Leo replacement uses registry-generated `1.0.0` artifacts.
+- [ ] Leo frozen install and workspace verification pass.
+- [ ] PR #221 links to the replacement before closure.
+- [ ] Unrelated design-lab files remain untouched.
+
+## S8: Close release evidence
+
+### Steps
+
+1. Update README install commands to use `opencode-ship@latest` and document
+   the engineering model flags/config requirement.
+2. Move final CHANGELOG items from Unreleased to `1.0.0` with the release date.
+3. Update RELEASING current-state tables and preserve the historical process.
+4. Verify GitHub releases, npm tags, registry metadata, and docs agree.
+5. Add a final bounded evidence comment to the parent issue.
+6. Close the parent issue only after every Definition of Done checkbox is
+   linked to evidence.
+7. Record any non-blocking follow-up as a new issue, not an unchecked note in
+   this plan.
+
+## Failure and recovery rules
+
+| Failure | Required response |
+|---|---|
+| Local verification fails | Diagnose and fix before any tag |
+| Release qualification fails before publish | Fix and rerun same unconsumed tag only if no immutable publication occurred; otherwise choose a new RC |
+| npm version exists with different integrity | Stop immediately; never overwrite |
+| Registry propagation times out | Preserve workflow evidence, retry read-only checks, do not republish |
+| Neutral install conflict | Preserve consumer bytes and resolve ownership explicitly |
+| Managed hash conflict | Do not use `--replace-managed` without user review and approval |
+| Real dogfood runtime defect | Publish a corrected 0.10 patch/candidate and repeat S3-S5 |
+| Plan/mirror restoration fails | Stop promotion; preserve issue and local evidence |
+| Same-HEAD gate mismatch | Re-run every invalidated final gate on the new HEAD |
+| Cleanup refuses | Preserve worktree and manifest; diagnose without deleting it manually |
+| 1.0 digest mismatch | Refuse promotion and identify the unauthorized runtime-source change |
+
+## Per-session operating contract
+
+At the start of every continuation session:
+
+1. Read this file and the parent issue.
+2. Inspect current git branch, HEAD, worktree status, npm dist-tags, open PRs,
+   release workflows, and the last evidence comment.
+3. Identify exactly one active slice and mark it in progress in the issue.
+4. Do not repeat completed irreversible operations.
+5. Use current registry/remote facts over stale values in this document.
+6. Execute until the next approval gate, a real blocker after one retry, or the
+   slice acceptance criteria are complete.
+7. Post the evidence envelope before ending the session.
+
+## Suggested skills
+
+Load strong matches before acting:
+
+- `customize-opencode` for config, plugin, agent, permission, and skill work;
+- `verification-before-completion` before every success claim;
+- `requesting-code-review` before release/release-policy merges;
+- `systematic-debugging` for qualification or registry failures;
+- `test-driven-development` for release-policy and installer regressions;
+- `delivery-workflow` where the consumer has the typed delivery lifecycle;
+- `git-commit` only when the user asks the session to commit;
+- `handoff` when stopping at an approval gate.
+
+## Final report format
+
+The executor's final response must include:
+
+```text
+Status: pass | fail | blocked | partial
+Completed through: S<N>
+Source SHA: <40 hex>
+Published versions: <list>
+npm dist-tags: <json>
+Evidence URLs: <issue, PRs, workflows, releases, qualification artifacts>
+Verification: <commands and exit codes>
+Definition of Done: <passed>/<total>
+Remaining risks: <list or none>
+Next authorization: <exact gate or none>
+```
+
+Do not report `complete` until every Definition of Done checkbox is proven.
+
+## Copyable handoff prompt
+
+Use this prompt to start or resume execution with a lower-cost Build model:
+
+```text
+Work in /home/viktorcordas/repos/opencode-ship.
+
+Goal: Execute the approved opencode-ship 1.0 release plan through the next
+authorization gate, preserving evidence so another session can resume without
+reconstructing context.
+
+Mandatory source of truth:
+docs/release/1.0.0-execution-plan.md
+
+Before acting:
+1. Load every strong matching skill, especially customize-opencode,
+   verification-before-completion, requesting-code-review, and systematic
+   debugging or test-driven-development when applicable.
+2. Read the entire plan, README.md, CHANGELOG.md, RELEASING.md,
+   schema/ship-config.schema.json, .github/workflows/release.yml,
+   src/installer/cli-args.js, and tests/package/neutral-consumer.test.mjs.
+3. Inspect git status/branch/HEAD, npm dist-tags, published versions, open
+   issues/PRs, release workflows, and the parent issue's latest evidence.
+4. If the parent issue does not exist, create or reuse the exact issue required
+   by S0 and add its URL to the plan header before release-code changes.
+5. Identify exactly one active slice. Do not skip ahead or repeat an already
+   completed irreversible operation.
+
+Fixed decisions:
+- Final target: opencode-ship@1.0.0 on npm latest.
+- Profile: engineering.
+- Planner: openai/gpt-5.6-sol.
+- Builder: minimax/MiniMax-M3.
+- Final reviewer: openai/gpt-5.6-sol.
+- Registry-sourced real dogfood is mandatory.
+
+Constraints:
+- Never edit, reset, stash, clean, stage, or commit the dirty Leo main
+  worktree. Leo is out of scope until S7 and must use a fresh worktree.
+- Never copy managed plugin/agent/skill files manually into a consumer.
+- Never overwrite, retag, unpublish, or mutate a published npm version.
+- Never use force-push, hard reset, raw Git ref plumbing, or bypass a failed
+  review/verification/CI gate.
+- Never expose tokens or credentials in logs, issues, commits, or artifacts.
+- Stop for every authorization gate in the plan. In particular, do not create
+  the dogfood repository, merge a PR, push a release tag, publish/move an npm
+  dist-tag, or merge dogfood/Leo without explicit user authorization.
+- Restart OpenCode after project config, plugin, agent, command, or skill files
+  change.
+- Do not claim completion from unit tests alone.
+
+Execution behavior:
+- Work autonomously through reversible steps in the active slice.
+- Verify every change using the commands required by that slice.
+- Run independent review before release-policy or release merges.
+- Update the parent issue with the bounded evidence envelope before stopping.
+- Stop only at an authorization gate, a real blocker after one retry, or when
+  the active slice acceptance criteria are complete.
+
+Return exactly:
+Status: pass | fail | blocked | partial
+Completed through: S<N>
+Source SHA: <40 hex>
+Published versions: <list>
+npm dist-tags: <json>
+Evidence URLs: <issue, PRs, workflows, releases, qualification artifacts>
+Verification: <commands and exit codes>
+Definition of Done: <passed>/<total>
+Remaining risks: <list or none>
+Next authorization: <exact gate or none>
+```

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "opencode-ship",
-  "version": "0.10.0-rc.19",
+  "version": "0.10.0-rc.28",
   "private": false,
   "description": "npm-distributed OpenCode installer that materializes the delivery plugin, reviewer/verifier agents, skills, ship config and lock into any consumer repository.",
   "license": "MIT",
@@ -49,6 +49,7 @@
     "docs",
     "vendor",
     "tests/plugin/plugin-load.test.mjs",
+    "tests/plugin/expected-tools.mjs",
     "THIRD_PARTY_NOTICES.md",
     "README.md",
     "CHANGELOG.md",

package/tests/plugin/expected-tools.mjs

@@ -0,0 +1,56 @@
+/*
+ * Canonical opencode-ship tool set.
+ *
+ * The bundled plugin registers exactly 24 typed tools (9
+ * existing delivery + 7 control-plane + 8 workflow). This module
+ * is the single source of truth for the expected set so:
+ *
+ *   - the in-process plugin-load test asserts the contract at the
+ *     plugin boundary;
+ *   - the opencode-discovery smoke test asserts the contract at
+ *     the runtime boundary by polling a real opencode server;
+ *   - the release workflow can fail fast if a future change adds
+ *     or removes a tool without updating both consumers.
+ *
+ * Changing this set is a contract change. Both the in-process
+ * test and the live-server test must continue to agree.
+ */
+
+export const EXPECTED_OPENCODE_SHIP_TOOLS = Object.freeze([
+  // 9 existing delivery tools
+  "delivery_cleanup",
+  "delivery_github_read",
+  "delivery_inspect",
+  "delivery_issue",
+  "delivery_issue_close",
+  "delivery_issue_comment",
+  "delivery_issue_labels",
+  "delivery_issue_link",
+  "delivery_merge",
+  "delivery_pr",
+  "delivery_publish",
+  "delivery_ready",
+  "delivery_review",
+  "delivery_sync",
+  "delivery_verify",
+  "delivery_worktree",
+  // 7 control-plane + 8 workflow tools
+  "ship_plan_approve",
+  "ship_plan_start",
+  "ship_plan_submit",
+  "ship_resume",
+  "ship_run_start",
+  "ship_status",
+  "ship_task_report",
+  "ship_task_review",
+]);
+
+/**
+ * Frozen set, sorted lexicographically. The plugin-load and
+ * opencode-discovery tests both compare against this exact set.
+ */
+export const EXPECTED_OPENCODE_SHIP_TOOL_IDS = Object.freeze(
+  [...EXPECTED_OPENCODE_SHIP_TOOLS].sort(),
+);
+
+export const OPENCODE_SHIP_TOOL_COUNT = EXPECTED_OPENCODE_SHIP_TOOLS.length;

package/tests/plugin/plugin-load.test.mjs

@@ -7,41 +7,21 @@
  *   - calling it returns an object with a `tool` key
  *   - the `tool` object exposes exactly the 24 named tool
  *     definitions (9 delivery + 7 control-plane + 8 workflow)
+ *
+ * The canonical 24-tool set is imported from
+ * `tests/plugin/expected-tools.mjs`, the single source of truth
+ * shared with the opencode-discovery smoke test.
  */
 
 import test from "node:test";
 import assert from "node:assert/strict";
 import { pathToFileURL } from "node:url";
 import { resolve } from "node:path";
+import { EXPECTED_OPENCODE_SHIP_TOOL_IDS, OPENCODE_SHIP_TOOL_COUNT } from "./expected-tools.mjs";
 
 const pluginPath = pathToFileURL(resolve("dist/plugin.js")).href;
 
-const EXPECTED_TOOLS = [
-  "delivery_cleanup",
-  "delivery_github_read",
-  "delivery_inspect",
-  "delivery_issue",
-  "delivery_issue_close",
-  "delivery_issue_comment",
-  "delivery_issue_labels",
-  "delivery_issue_link",
-  "delivery_merge",
-  "delivery_pr",
-  "delivery_publish",
-  "delivery_ready",
-  "delivery_review",
-  "delivery_sync",
-  "delivery_verify",
-  "delivery_worktree",
-  "ship_plan_approve",
-  "ship_plan_start",
-  "ship_plan_submit",
-  "ship_resume",
-  "ship_run_start",
-  "ship_status",
-  "ship_task_report",
-  "ship_task_review",
-];
+const EXPECTED_TOOLS = EXPECTED_OPENCODE_SHIP_TOOL_IDS;
 
 test("plugin: default export is a function", async () => {
   const mod = await import(pluginPath);
@@ -60,7 +40,7 @@ test("plugin: registers exactly 24 tools", async () => {
   const result = await mod.default(fakeCtx);
   assert.ok(result.tool, "result.tool should exist");
   const ids = Object.keys(result.tool).sort();
-  assert.deepEqual(ids, EXPECTED_TOOLS, `expected 24 tools, got ${ids.length}: ${ids.join(", ")}`);
+  assert.deepEqual(ids, EXPECTED_TOOLS, `expected ${OPENCODE_SHIP_TOOL_COUNT} tools, got ${ids.length}: ${ids.join(", ")}`);
   for (const id of ids) {
     assert.equal(typeof result.tool[id].execute, "function", `${id} should expose an execute function`);
     assert.equal(typeof result.tool[id].description, "string", `${id} should expose a description`);