opencode-ship 1.1.2-rc.2 → 1.1.2

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "opencode-ship",
-  "version": "1.1.2-rc.2",
+  "version": "1.1.2",
   "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",
@@ -44,10 +44,14 @@
   },
   "files": [
     "dist",
-    "assets",
+    "assets/agents",
+    "assets/commands",
+    "assets/skills",
     "schema",
-    "docs",
-    "vendor",
+    "vendor/sources.json",
+    "vendor/mattpocock/LICENSE",
+    "vendor/superpowers/LICENSE",
+    "vendor/obra/LICENSE",
     "tests/plugin/plugin-load.test.mjs",
     "tests/plugin/expected-tools.mjs",
     "THIRD_PARTY_NOTICES.md",
@@ -72,6 +76,7 @@
     "@opencode-ai/plugin": "1.18.10",
     "@types/node": "^22.10.2",
     "esbuild": "^0.25.0",
+    "jsonc-parser": "3.3.1",
     "tsx": "^4.23.1",
     "typescript": "^5.9.3"
   }

package/tests/plugin/expected-tools.mjs

@@ -2,7 +2,7 @@
  * Canonical opencode-ship tool set.
  *
  * The bundled plugin registers exactly 32 typed tools (16
- * delivery + 4 control-plane + 12 ship). This module is the
+ * delivery + 16 ship). This module is the
  * single source of truth for the expected set so:
  *
  *   - the in-process plugin-load test asserts the contract at the
@@ -34,7 +34,7 @@ export const EXPECTED_OPENCODE_SHIP_TOOLS = Object.freeze([
   "delivery_sync",
   "delivery_verify",
   "delivery_worktree",
-  // 12 ship tools
+  // 16 ship tools
   "ship_final_review",
   "ship_plan_approve",
   "ship_plan_start",

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

@@ -5,10 +5,10 @@
  * runtime types without booting OpenCode. It verifies:
  *   - the bundled plugin is the default-exported function
  *   - 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 `tool` object exposes exactly the 32 named tool
+ *     definitions (16 delivery + 16 workflow)
  *
- * The canonical 24-tool set is imported from
+ * The canonical 32-tool set is imported from
  * `tests/plugin/expected-tools.mjs`, the single source of truth
  * shared with the opencode-discovery smoke test.
  */
@@ -29,6 +29,11 @@ test("plugin: default export is a function", async () => {
   assert.equal(typeof mod.ShipPlugin, "function");
 });
 
+test("plugin: bundle exports only plugin entry functions", async () => {
+  const mod = await import(pluginPath);
+  assert.deepEqual(Object.keys(mod).sort(), ["ShipPlugin", "default"]);
+});
+
 test("plugin: registers exactly 32 tools", async () => {
   const mod = await import(pluginPath);
   const fakeCtx = {

package/assets/_archive/issue-tracker-gitlab.md

@@ -1,46 +0,0 @@
-# Issue tracker: GitLab
-
-Issues and PRDs for this repo live as GitLab issues. Use the [`glab`](https://gitlab.com/gitlab-org/cli) CLI for all operations.
-
-## Conventions
-
-- **Create an issue**: `glab issue create --title "..." --description "..."`. Use a heredoc for multi-line descriptions. Pass `--description -` to open an editor.
-- **Read an issue**: `glab issue view <number> --comments`. Use `-F json` for machine-readable output.
-- **List issues**: `glab issue list -F json` with appropriate `--label` filters.
-- **Comment on an issue**: `glab issue note <number> --message "..."`. GitLab calls comments "notes".
-- **Apply / remove labels**: `glab issue update <number> --label "..."` / `--unlabel "..."`. Multiple labels can be comma-separated or by repeating the flag.
-- **Close**: `glab issue close <number>`. `glab issue close` does not accept a closing comment, so post the explanation first with `glab issue note <number> --message "..."`, then close.
-- **Merge requests**: GitLab calls PRs "merge requests". Use `glab mr create`, `glab mr view`, `glab mr note`, etc. — the same shape as `gh pr ...` with `mr` in place of `pr` and `note`/`--message` in place of `comment`/`--body`.
-
-Infer the repo from `git remote -v` — `glab` does this automatically when run inside a clone.
-
-## Merge requests as a triage surface
-
-**MRs as a request surface: no.** _(Set to `yes` if this repo treats external merge requests as feature requests; `/triage` reads this flag.)_
-
-When set to `yes`, MRs run through the same labels and states as issues, using the `glab mr` equivalents:
-
-- **Read an MR**: `glab mr view <number> --comments` and `glab mr diff <number>` for the diff.
-- **List external MRs for triage**: `glab mr list -F json`, then keep only MRs whose author is not a project member/owner (a contributor's MR, not a maintainer's in-flight work).
-- **Comment / label / close**: `glab mr note`, `glab mr update --label`/`--unlabel`, `glab mr close`.
-
-Unlike GitHub, GitLab numbers issues and MRs separately, so `#42` is unambiguous once you know which surface the maintainer means.
-
-## When a skill says "publish to the issue tracker"
-
-Create a GitLab issue.
-
-## When a skill says "fetch the relevant ticket"
-
-Run `glab issue view <number> --comments`.
-
-## Wayfinding operations
-
-Used by `/wayfinder`. The **map** is a single issue with **child** issues as tickets.
-
-- **Map**: a single issue labelled `wayfinder:map`, holding the Notes / Decisions-so-far / Fog body. `glab issue create --label wayfinder:map`. (On GitLab tiers with native epics, an epic may hold the map instead; a labelled issue works everywhere.)
-- **Child ticket**: an issue carrying `Part of #<map>` at the top of its description and labels `wayfinder:<type>` (`research`/`prototype`/`grilling`/`task`). Once claimed, the ticket is assigned to the driving dev.
-- **Blocking**: GitLab's **native blocking link** — the canonical, UI-visible representation. Add it with the `/blocked_by #<n>` quick action, posted as a note (`glab issue note <child> --message "/blocked_by #<blocker>"`). Native blocking links are a Premium/Ultimate feature; on the free tier (or where unavailable) fall back to a `Blocked by: #<n>, #<n>` line at the top of the description. A ticket is unblocked when every blocker is closed.
-- **Frontier query**: `glab issue list -F json` scoped to the map's children, drop any with an open blocker — a native `blocked_by` link to an open issue (`glab api projects/:id/issues/:iid/links`), or an open issue in the `Blocked by` line — or an assignee; first in map order wins.
-- **Claim**: `glab issue update <n> --assignee @me` — the session's first write.
-- **Resolve**: `glab issue note <n> --message "<answer>"`, then `glab issue close <n>`, then append a context pointer (gist + link) to the map's Decisions-so-far.

package/assets/_archive/issue-tracker-local.md

@@ -1,30 +0,0 @@
-# Issue tracker: Local Markdown
-
-Issues and specs (you may know a spec as a PRD) for this repo live as markdown files in `.scratch/`.
-
-## Conventions
-
-- One feature per directory: `.scratch/<feature-slug>/`
-- The spec is `.scratch/<feature-slug>/spec.md`
-- Implementation issues are one file per ticket at `.scratch/<feature-slug>/issues/<NN>-<slug>.md`, numbered from `01` — never a single combined tickets file
-- Triage state is recorded as a `Status:` line near the top of each issue file (see `triage-labels.md` for the role strings)
-- Comments and conversation history append to the bottom of the file under a `## Comments` heading
-
-## When a skill says "publish to the issue tracker"
-
-Create a new file under `.scratch/<feature-slug>/` (creating the directory if needed).
-
-## When a skill says "fetch the relevant ticket"
-
-Read the file at the referenced path. The user will normally pass the path or the issue number directly.
-
-## Wayfinding operations
-
-Used by `/wayfinder`. The **map** is a file with one **child** file per ticket.
-
-- **Map**: `.scratch/<effort>/map.md` — the Notes / Decisions-so-far / Fog body.
-- **Child ticket**: `.scratch/<effort>/issues/NN-<slug>.md`, numbered from `01`, with the question in the body. A `Type:` line records the ticket type (`research`/`prototype`/`grilling`/`task`); a `Status:` line records `claimed`/`resolved`.
-- **Blocking**: a `Blocked by: NN, NN` line near the top. A ticket is unblocked when every file it lists is `resolved`.
-- **Frontier**: scan `.scratch/<effort>/issues/` for files that are open, unblocked, and unclaimed; first by number wins.
-- **Claim**: set `Status: claimed` and save before any work.
-- **Resolve**: append the answer under an `## Answer` heading, set `Status: resolved`, then append a context pointer (gist + link) to the map's Decisions-so-far in `map.md`.

package/docs/adr/0001-opencode-ship-redesign.md

@@ -1,168 +0,0 @@
-# ADR 0001 — `opencode-ship`: npm-distributed, single-command installer
-
-Status: Accepted
-
-## Context
-
-The current package, `opencode-delivery`, is a private source-level ESM
-core library. Consumer projects adopt it by copying a project plugin
-shim into `opencode.json` and pinning a Git commit hash. Each new
-release is a manual PR into every consumer repo. There is no CLI, no
-generated plugin bundle, no managed-file policy, and no upgrade path
-short of consumer-side edits.
-
-Consumer pain observed in the wild:
-
-- Every onboarding requires editing `opencode.json`, copying the shim,
-  copying the two agents, copying the two skills, copying the
-  `delivery.json` adapter, copying the workflow lock, and remembering to
-  rename the plugin when the package moves.
-- Updates require a Git ref ping and a manual diff; tooling cannot
-  reason about who owns which file.
-- Cleanup is only triggered manually and silently fails when the local
-  branch head SHA drifts from the manifest.
-
-## Decision
-
-Re-establish the package as `opencode-ship`, a publishable npm module
-with three surfaces:
-
-1. A self-contained compiled ESM OpenCode plugin at the package root
-   (`opencode-ship`) that registers the canonical nine `delivery_*`
-   tools and removes the need for any consumer-side plugin wrapper.
-2. A first-class CLI (`opencode-ship` binary) materialising every
-   required asset in the consumer repo through five idempotent commands.
-3. A `opencode-ship/core` subpath that preserves the existing library
-   surface so consumer scripts that already import from the package can
-   migrate at their own pace.
-
-### Managed-file policy
-
-Five output classes are installer-managed and recorded in the lock:
-
-- `.opencode/plugins/opencode-ship.js` — the bundled plugin.
-- `.opencode/agents/delivery-reviewer.md`,
-  `.opencode/agents/delivery-verifier.md`.
-- `.opencode/skills/delivery-workflow/SKILL.md`,
-  `.opencode/skills/planning-research-checkpoint/SKILL.md`.
-- `.opencode/ship.config.json` — user-owned, written only on the
-  first `init` if missing.
-- `.opencode/ship.lock.json` — installer-managed.
-
-Root `opencode.json` / `opencode.jsonc` is a shared document. The
-installer owns only the Build-agent delivery permissions and the
-delivery subagent delegation allow-list; everything else stays.
-
-`update` only replaces managed files whose hashes still match the
-previous manifest. Modified managed files are refused with a precise
-conflict report; the user either restores the upstream bytes (the
-preferred repair) or opts into `--replace-managed`. We never silently
-overwrite.
-
-### Reconciliation algorithm
-
-For each managed target, three hashes are computed:
-
-- `B` = the SHA-256 stored in the previous lock for that path.
-- `C` = the SHA-256 of the bytes currently on disk.
-- `D` = the SHA-256 of the bytes we want to install.
-
-The combination determines the action:
-
-| Condition | Plan |
-| --- | --- |
-| No lock, target absent | `create` |
-| No lock, target present | `report` (unowned collision) |
-| `C == B == D` | `noop` |
-| `C == B`, `D != B` | `update` |
-| `C == D`, `C != B` | `converge` (refresh lock only) |
-| `C != B`, `C != D` | `conflict` (refuse) |
-| Target removed, `C == B` | `delete` |
-| Target removed, `C != B` | `conflict` |
-
-Conflict semantics are uniform across `init`, `update`, and `uninstall`.
-
-### Transactions
-
-Multi-file updates are recoverable but not truly atomic. The transaction
-layer:
-
-1. Acquires an exclusive repository lock file under `.git/opencode-ship/`.
-2. Re-reads and re-hashes every target before staging.
-3. Stages each target as a sibling temporary file and `fsync`s it.
-4. Writes a journal recording original paths, backup paths, hashes,
-   and operation order.
-5. Renames each managed target to a backup, then promotes the staged
-   copy into place, then `fsync`s the parent directory.
-6. Promotes the new lock last as the commit marker.
-7. Removes backups and journal after commit.
-
-Pre-commit failures roll back in reverse order. Post-commit failure
-treats the plan as committed and surfaces a degraded-cleanup warning;
-the journal is cleaned on the next mutating command.
-
-### CLI surface
-
-```
-opencode-ship init    [--root <path>] [--config <path>] [--force-config]
-opencode-ship diff    [--root <path>] [--json] [--config <path>]
-opencode-ship update  [--root <path>] [--json] [--replace-managed]
-opencode-ship doctor  [--root <path>] [--json]
-opencode-ship uninstall [--root <path>] [--json] [--purge-config]
-opencode-ship --version
-```
-
-Exit codes:
-
-- `0` success / no-op
-- `1` expected negative result (`diff` saw changes; `doctor` unhealthy)
-- `2` invalid input, unsupported project, ambiguous detection
-- `3` ownership/hash/structural conflict
-- `4` filesystem, staging, rollback, or transaction failure
-- `5` unsupported lock/config schema
-
-### Plugin + cleanup hardening
-
-The bundled plugin no longer assumes `minimax/MiniMax-M3`; model
-inheritance is the default. The verifier agent gains explicit denials
-for the other eight tools so isolation is symmetric to the reviewer.
-The Build agent gains explicit denials for `delivery_review` and
-`delivery_verify`, plus an `ask` rule for `delivery_merge`. The
-GitHub driver replaces the unsupported `gh pr view --json merged` field
-with a typed `gh pr view ... --json state,mergedAt`.
-
-Post-merge cleanup moves to immediate, atomic-enough execution after
-an explicit user-authorised merge: validate the preconditions, persist
-`cleanup-pending`, perform the worktree removal and CAS-style branch
-deletion, seal the manifest, retry on the next delivery task if any
-step failed. No force removal and no OpenCode restart.
-
-### Compatibility strategy
-
-Legacy `.opencode/delivery.json`, `.opencode/delivery.lock.json`, the
-two agents, the two skills, and the generic `delivery.ts` wrapper
-shape are recognised. Migration is opt-in by running `init` from a
-checkout that already has those files. The consumer keeps the
-existing manifest directory (`opencode-delivery/` under the Git common
-dir) untouched to avoid stranding in-flight deliveries.
-
-## Consequences
-
-- Consumer repo touches only `.opencode/` and root
-  `opencode.json`/`.jsonc`. Initial onboarding becomes
-  `pnpm dlx opencode-ship init`.
-- Upgrades become `opencode-ship update`, with conflicts surfaced
-  instead of overwritten.
-- The library surface stays public through `opencode-ship/core`.
-- v0.1.x becomes a legacy package; v0.2.0 is the first npm-distributed
-  release.
-- The lock introduces a migration concern that the installer's
-  `doctor` must surface if the lock format is too old.
-- A `cleanupPending` schedule runs only on consumer demand (the next
-  delivery start), never on package installation.
-
-## Non-goals
-
-- Publishing to a registry is deferred until this PR is approved.
-- Migrating Leo into `opencode-ship` consumers is a separate follow-up.
-- Changing the lifecycle state machine semantics.