opencode-ship 1.1.1 → 1.1.2-rc.2

package/CHANGELOG.md

@@ -2,6 +2,62 @@
 
 All notable changes to `opencode-ship` are recorded here.
 
+## 1.1.2-rc.2 — Complete contract correction
+
+> Active stabilization branch: `fix/1.1.2-self-hosting`.
+> Parent tracker: https://github.com/Viktorxyz/opencode-ship/issues/56.
+> Authoritative plan: docs/release/1.1.2-correction-plan.md.
+
+`1.1.1` and `1.1.2-rc.1` shipped partial contracts: 24 of the 32
+promised tools, no real OpenCode dispatch, an executor that conflated
+"all three model fields populated" with "setup workflow completed",
+a setup skill that left consumers without `docs/agents/**` or an
+`AGENTS.md` Ship workflow block, and root permissions that still used
+a duplicated pointer list.
+
+This release corrects every one of those gaps:
+
+- 32 typed tools are registered. The previously missing
+  `ship_task_start`, `ship_task_commit`, `ship_task_complete`,
+  `ship_final_review`, `ship_skill_discover`, `ship_skill_install`,
+  `ship_skill_audit`, and `ship_skill_uninstall` are first-class.
+- The workflow agents are dispatched through real OpenCode
+  sessions via `client.session.create` and `client.session.promptAsync`.
+  The controller session id is persisted in dispatch records so
+  plan/task/final-review tools can authorize the caller from the
+  ToolContext, not from a caller-supplied `submittedBy` string.
+- `ship_task_review` authorizes against the configured builder
+  model (the task reviewer is rendered with the builder model).
+  `ship_final_review` requires the configured finalReviewer model.
+  Both gate on the controller session id.
+- The setup-complete command is the sole writer of
+  `lock.manager.setupComplete: true`. It validates models + docs +
+  AGENTS.md + lock BEFORE the lock write, then removes the
+  setup-pending marker in the same critical section. A failed
+  validation leaves the marker untouched.
+- The root permission matrix is the single source of truth. The
+  legacy `POINTER_ENTRIES` list is replaced by `rootPermissionMatrix()`.
+  `subagent_depth: 2` and the Build → ship-controller delegation
+  are wired so the deep plan / build / review chain works without
+  manual permission patching.
+- JSONC reads and writes use `jsonc-parser`. The apply step merges
+  sibling section insertions into a single JSONC edit insert so the
+  `applyEdits` call does not throw on overlapping ranges. Plain
+  JSON files are preserved key-by-key by the same matrix.
+- The `setup-ship-workflow` skill is GitHub-only. The 1.1.2
+  controller's delivery tool belt is GitHub-bound; the skill
+  refuses to drive GitLab, Jira, Linear, or local markdown.
+  The command is a thin wrapper that just invokes the skill.
+- Lock schema v4 explicitly accepts `manager.setupComplete` and
+  the `support` file kind, and drops `cleanupPending` (its state
+  lives under the Git common directory).
+
+## 1.1.2-rc.1 — (incomplete) placeholder
+
+The 1.1.2-rc.1 release shipped with a partial contract and is
+deprecated as soon as 1.1.2 stable is published. Upgrade to
+1.1.2-rc.2 or later.
+
 ## 1.1.1 — Stabilization + first self-hosting release (UNRELEASED)
 
 > Active stabilization branch: `fix/1.1.1-stabilization`.

package/THIRD_PARTY_NOTICES.md

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

package/assets/commands/setup-ship-workflow.md

@@ -1,173 +1,15 @@
 ---
-description: Configure the opencode-ship workflow for this repo: issue tracker, triage labels, domain docs, and AI model roles. Run once after `init` with /setup-ship-workflow.
+description: Configure the opencode-ship workflow for this repo: GitHub tracker, triage labels, domain docs, and AI model roles. Run once after `init` with /setup-ship-workflow.
 ---
 
 # Setup Ship Workflow
 
-First-run setup for `opencode-ship@1.1`. Run this exactly once after `init` and before any `ship-deliver`. It is prompt-driven, idempotent, and refuses to return until every step is committed or explicitly skipped.
+This command is a thin wrapper around the canonical
+`setup-ship-workflow` skill. OpenCode will load the skill
+and follow its procedure.
 
-## When you trigger
-
-- The user runs `/setup-ship-workflow` or types "set up ship" / "continue ship setup".
-- The installer creates `.opencode/ship.setup-pending.json` after `init`; the controller also routes `ship-deliver` here until this skill has cleared the marker.
-
-Do **not** trigger on a normal planning or delivery request.
-
-## Process
-
-Take the sections in order. Lead every question with a recommended default so the user can accept in one word. Skip a section only when exploration already settled it.
-
-### 1. Explore
-
-```bash
-git remote -v
-git status --short
-ls -la AGENTS.md CLAUDE.md docs/ .opencode/ 2>/dev/null || true
-cat .opencode/opencode.json 2>/dev/null || true
-cat .opencode/ship.config.json 2>/dev/null || true
-cat .opencode/ship.lock.json 2>/dev/null || true
-cat .opencode/ship.setup-pending.json 2>/dev/null || true
-opencode providers list 2>/dev/null || true
-```
-
-Also check:
-
-- is `.opencode/ship.setup-pending.json` present? (it makes this run mandatory)
-- is the `triage` skill installed? (decides whether Section B runs)
-- monorepo signals (`pnpm-workspace.yaml`, `packages/*`)
-
-### 2. Section A — Issue tracker
-
-Default: GitHub (the most common case). If `git remote` points at GitLab, propose GitLab. Otherwise offer:
-
-- GitHub (uses `gh`)
-- GitLab (uses `glab`)
-- Local markdown (writes under `.scratch/<feature>/`)
-- Other (Jira, Linear, etc.) — describe in one paragraph
-
-Write the choice to `docs/agents/issue-tracker.md`. Use the seed template in `assets/skills/setup-engineering-workflow/issue-tracker-<choice>.md` as the starting point.
-
-### 3. Section B — Triage labels
-
-Only if the `triage` skill is installed. Ask one question:
-
-> Keep the default triage labels? (recommended: yes)
-> Defaults: `needs-triage`, `needs-info`, `ready-for-agent`, `ready-for-human`, `wontfix`.
-
-On **no**, capture the user's overrides so `triage` reuses existing labels instead of creating duplicates.
-
-Write `docs/agents/triage-labels.md`.
-
-### 4. Section C — Domain docs
-
-Default: **single-context** — one `CONTEXT.md` + `docs/adr/` at the repo root. Skip the question unless monorepo signals were found.
-
-Write `docs/agents/domain.md`.
-
-### 5. Section D — AI model roles
-
-Three questions, one at a time. Default to `openai/gpt-5.6-sol` and `minimax/MiniMax-M3`; offer alternative families below.
-
-| Role | Default | Suggestion |
-|---|---|---|
-| planner | `openai/gpt-5.6-sol` | strong model for plan writing |
-| builder | `minimax/MiniMax-M3` | cheap/fast model for code |
-| finalReviewer | `openai/gpt-5.6-sol` | strong model for final Standards + Spec review |
-
-Alternatives to mention if the user has no OpenAI/MiniMax:
-
-- Anthropic: `anthropic/claude-opus-4.1`, `anthropic/claude-sonnet-4.5`
-- Google: `google/gemini-2.5-pro`, `google/gemini-2.5-flash`
-- Or any `<provider>/<model>` string the user has credentials for
-
-After the user answers, **update `.opencode/ship.config.json`** so it looks like:
-
-```json
-{
-  "schemaVersion": 2,
-  "profile": "engineering",
-  "project": { ... },
-  "delivery": { ... },
-  "workflow": {
-    "models": {
-      "planner": "<answer>",
-      "builder": "<answer>",
-      "finalReviewer": "<answer>"
-    },
-    "approval": { "mirrorToIssue": true, "maxFailedRounds": 3 }
-  }
-}
-```
-
-Then run `opencode-ship update` to write the change with full transactional coverage.
-
-### 6. Section E — Provider auth probe
-
-```bash
-opencode providers list
-```
-
-If the planner/builder/finalReviewer names are missing credentials, surface a warning and tell the user how to log in:
-
-```bash
-opencode providers login openai
-opencode providers login minimax
-```
-
-Do not invent credentials. Do not retry.
-
-### 7. Section F — Permissions sanity
-
-Run `opencode-ship doctor`. If any pointer is missing, prompt the user to run:
-
-```bash
-opencode-ship update --force-root-config
-```
-
-Do not auto-rewrite root configs without consent.
-
-### 8. Section G — AGENTS.md / CLAUDE.md
-
-Pick the file to edit:
-
-- If `CLAUDE.md` exists, edit it.
-- Else if `AGENTS.md` exists, edit it.
-- If neither, ask the user to pick one — never create both.
-
-If an `## Ship workflow` block exists, update in place. Otherwise append:
-
-```markdown
-## Ship workflow
-
-This repo uses opencode-ship. Read `.opencode/ship.config.json` for the active model roles and approval policy. Issues live in [tracker]. See `docs/agents/issue-tracker.md`. Triage labels are documented in `docs/agents/triage-labels.md`.
-
-For a single-issue delivery, the user invokes `/setup-ship-workflow` once, then `ship-deliver <issue-number>` (or types "Ship issue N"). The controller dispatches the planner, builder, and reviewers; no further user action is required until Ready.
-```
-
-Include the `### Triage labels` sub-block only when the `triage` skill is installed.
-
-### 9. Done
-
-- Delete `.opencode/ship.setup-pending.json`.
-- Print the next-step block below.
-- Tell the user they can edit `docs/agents/*.md` directly; re-running this skill is only necessary to switch trackers or re-configure models.
-
-## Next steps (always print)
-
-```text
-Setup complete.
-
-Next:
-1. Restart OpenCode in this repo (if you haven't already).
-2. Try: Ship issue 1    (or any issue number)
-3. The controller will: plan -> ask approve -> implement -> review -> ready -> wait for "merge it"
-```
-
-## Hard rules
-
-- One question per turn. Never batch.
-- Re-run safe: skip sections already settled by existing config or docs.
-- Never edit the same `docs/agents/*.md` twice in one run.
-- Never silently overwrite a user-owned value in `ship.config.json`; always show the diff first.
-- Never tell the user to "merge it" automatically. The merge step is the only autonomy break.
-- Never hide step failures. If a write fails, surface the error and stop.
+To run the skill from this command, the user types
+`/setup-ship-workflow` in OpenCode. The CLI's
+`setup-complete` command is the transactional gate that
+commits the lock flip and clears the marker once the skill
+has produced every artifact.

package/assets/skills/setup-ship-workflow/SKILL.md

@@ -1,52 +1,78 @@
 ---
 name: setup-ship-workflow
-description: First-run setup of opencode-ship. Walks the user through issue tracker, triage labels, domain docs, and AI model roles. Run once after `init` with /setup-ship-workflow.
+description: First-run setup of opencode-ship. Walks the user through GitHub configuration, triage labels, domain docs, and AI model roles. Run once after `init` with /setup-ship-workflow.
 disable-model-invocation: true
 ---
 
 # Setup Ship Workflow
 
-First-run setup for `opencode-ship@1.1`. Run this exactly once after `init` and before any `ship-deliver`. It is prompt-driven, idempotent, and refuses to return until every step is committed or explicitly skipped.
+First-run setup for `opencode-ship@1.1.2`. Run this exactly once after `init`
+and before any `ship-deliver`. It is prompt-driven, idempotent, and refuses
+to return until every step is committed or explicitly skipped.
+
+The setup contract is GitHub-only. The skill refuses to drive GitLab,
+Jira, Linear, or local markdown because the controller's own delivery
+tool belt is GitHub-bound. A team that needs a different tracker should
+hold off on `opencode-ship@1.1.2` until 1.2 ships the next tracker.
 
 ## When you trigger
 
-- The user runs `/setup-ship-workflow` or types "set up ship" / "continue ship setup".
-- The installer creates `.opencode/ship.setup-pending.json` after `init`; the controller also routes `ship-deliver` here until this skill has cleared the marker.
+- The user runs `/setup-ship-workflow` or types "set up ship" / "continue setup".
+- The installer creates `.opencode/ship.setup-pending.json` after `init`.
+- The controller also routes `ship-deliver` to this skill until the marker is cleared.
 
 Do **not** trigger on a normal planning or delivery request.
 
 ## Process
 
-Take the sections in order. Lead every question with a recommended default so the user can accept in one word. Skip a section only when exploration already settled it.
+Take the sections in order. Lead every question with a recommended default so
+the user can accept in one word. Skip a section only when exploration already
+settled it.
 
 ### 1. Explore
 
 ```bash
 git remote -v
+gh auth status
 git status --short
 ls -la AGENTS.md CLAUDE.md docs/ .opencode/ 2>/dev/null || true
 cat .opencode/opencode.json 2>/dev/null || true
 cat .opencode/ship.config.json 2>/dev/null || true
 cat .opencode/ship.lock.json 2>/dev/null || true
-opencode providers list 2>/dev/null || true
+opencode models 2>/dev/null || true
 ```
 
 Also check:
 
 - is `.opencode/ship.setup-pending.json` present? (it makes this run mandatory)
 - is the `triage` skill installed? (decides whether Section B runs)
-- monorepo signals (`pnpm-workspace.yaml`, `packages/*`)
+- is the issue tracker a GitHub repo? If not, refuse with the
+  GitHub-only contract and stop.
+
+### 2. Section A — GitHub repository
+
+The default is the GitHub repository that owns `git remote`. Confirm the
+detected `owner/repo` slug against the user's answer. If the user has
+multiple remotes, ask which one is the ship target.
 
-### 2. Section A — Issue tracker
+Write `docs/agents/issue-tracker.md` with the resolved `owner/repo`,
+`default branch`, and the canonical `gh` commands:
+
+```bash
+gh issue list --label needs-triage
+gh issue view <number>
+gh pr create --base <default-branch> --draft --title <title> --body <body>
+gh pr view <number>
+gh pr merge <number> --squash --delete-branch
+```
 
-Default: GitHub (the most common case). If `git remote` points at GitLab, propose GitLab. Otherwise offer:
+If the consumer is not on GitHub, refuse with:
 
-- GitHub (uses `gh`)
-- GitLab (uses `glab`)
-- Local markdown (writes under `.scratch/<feature>/`)
-- Other (Jira, Linear, etc.) — describe in one paragraph
+> opencode-ship@1.1.2 is GitHub-only. Re-run on a GitHub repo, or wait
+> for 1.2.
 
-Write the choice to `docs/agents/issue-tracker.md`. Use the seed template in `assets/skills/setup-engineering-workflow/issue-tracker-<choice>.md` as the starting point.
+Stop the skill. Do not write a `docs/agents/issue-tracker.md` for a
+non-GitHub consumer.
 
 ### 3. Section B — Triage labels
 
@@ -55,19 +81,23 @@ Only if the `triage` skill is installed. Ask one question:
 > Keep the default triage labels? (recommended: yes)
 > Defaults: `needs-triage`, `needs-info`, `ready-for-agent`, `ready-for-human`, `wontfix`.
 
-On **no**, capture the user's overrides so `triage` reuses existing labels instead of creating duplicates.
+On **no**, capture the user's overrides so `triage` reuses existing labels
+instead of creating duplicates.
 
 Write `docs/agents/triage-labels.md`.
 
 ### 4. Section C — Domain docs
 
-Default: **single-context** — one `CONTEXT.md` + `docs/adr/` at the repo root. Skip the question unless monorepo signals were found.
+Default: **single-context** — one `CONTEXT.md` + `docs/adr/` at the repo root.
+Skip the question unless monorepo signals were found.
 
 Write `docs/agents/domain.md`.
 
 ### 5. Section D — AI model roles
 
-Three questions, one at a time. Default to `openai/gpt-5.6-sol` and `minimax/MiniMax-M3`; offer alternative families below.
+Three questions, one at a time. Default to `openai/gpt-5.6-sol` and
+`minimax/MiniMax-M3`; offer alternative families only when the user
+explicitly states they have no credentials for the defaults.
 
 | Role | Default | Suggestion |
 |---|---|---|
@@ -81,7 +111,7 @@ Alternatives to mention if the user has no OpenAI/MiniMax:
 - Google: `google/gemini-2.5-pro`, `google/gemini-2.5-flash`
 - Or any `<provider>/<model>` string the user has credentials for
 
-After the user answers, **update `.opencode/ship.config.json`** so workflow looks like:
+After the user answers, update `.opencode/ship.config.json`:
 
 ```json
 {
@@ -100,26 +130,32 @@ After the user answers, **update `.opencode/ship.config.json`** so workflow look
 }
 ```
 
-Then run `opencode-ship update` to write the change with full transactional coverage.
+Then run `opencode-ship update --planner-model <a> --builder-model <b>
+--final-reviewer-model <c> --force-config` to write the change with full
+transactional coverage.
 
 ### 6. Section E — Provider auth probe
 
 ```bash
-opencode providers list
+opencode auth list
+opencode models openai
+opencode models minimax
 ```
 
-If the planner/builder/finalReviewer names are missing credentials, surface a warning and tell the user how to log in:
+If the planner/builder/finalReviewer names are missing credentials, surface
+a warning and tell the user how to log in:
 
 ```bash
-opencode providers login openai
-opencode providers login minimax
+opencode auth login openai
+opencode auth login minimax
 ```
 
 Do not invent credentials. Do not retry.
 
 ### 7. Section F — Permissions sanity
 
-Run `opencode-ship doctor`. If any pointer is missing, prompt the user to run:
+Run `opencode-ship doctor`. If any pointer is missing, prompt the user to
+run:
 
 ```bash
 opencode-ship update --force-root-config
@@ -140,18 +176,26 @@ If an `## Ship workflow` block exists, update in place. Otherwise append:
 ```markdown
 ## Ship workflow
 
-This repo uses opencode-ship. Read `.opencode/ship.config.json` for the active model roles and approval policy. Issues live in [tracker]. See `docs/agents/issue-tracker.md`. Triage labels are documented in `docs/agents/triage-labels.md`.
+This repo uses opencode-ship. Read `.opencode/ship.config.json` for the
+active model roles and approval policy. Issues live in GitHub.
+See `docs/agents/issue-tracker.md`. Triage labels are documented in
+`docs/agents/triage-labels.md`.
 
-For a single-issue delivery, the user invokes `/setup-ship-workflow` once, then `ship-deliver <issue-number>` (or types "Ship issue N"). The controller dispatches the planner, builder, and reviewers; no further user action is required until Ready.
+For a single-issue delivery, the user invokes `/setup-ship-workflow`
+once, then `ship-deliver <issue-number>` (or types "Ship issue N"). The
+controller dispatches the planner, builder, and reviewers; no further
+user action is required until Ready.
 ```
 
-Include the `### Triage labels` sub-block only when the `triage` skill is installed.
+Include the `### Triage labels` sub-block only when the `triage` skill is
+installed.
 
 ### 9. Done
 
-- Delete `.opencode/ship.setup-pending.json`.
+- Run `opencode-ship setup-complete` to commit the lock and clear the
+  marker in one transaction.
+- Tell the user that everything is ready.
 - Print the next-step block below.
-- Tell the user they can edit `docs/agents/*.md` directly; re-running this skill is only necessary to switch trackers or re-configure models.
 
 ## Next steps (always print)
 
@@ -169,6 +213,9 @@ Next:
 - One question per turn. Never batch.
 - Re-run safe: skip sections already settled by existing config or docs.
 - Never edit the same `docs/agents/*.md` twice in one run.
-- Never silently overwrite a user-owned value in `ship.config.json`; always show the diff first.
-- Never tell the user to "merge it" automatically. The merge step is the only autonomy break.
+- Never silently overwrite a user-owned value in `ship.config.json`; always
+  show the diff first.
+- Never tell the user to "merge it" automatically. The merge step is the
+  only autonomy break.
 - Never hide step failures. If a write fails, surface the error and stop.
+- Do not write any non-GitHub tracker docs. The contract is GitHub-only.