@glrs-dev/cli 0.1.0 → 0.3.1

package/CHANGELOG.md

@@ -1,5 +1,36 @@
 # @glrs-dev/cli
 
+## 0.3.1
+
+### Patch Changes
+
+- [#19](https://github.com/iceglober/glrs/pull/19) [`6e942c5`](https://github.com/iceglober/glrs/commit/6e942c5099a535a7d1cda161a1bbc1692f937008) Thanks [@iceglober](https://github.com/iceglober)! - Link `@glrs-dev/cli` and `@glrs-dev/harness-plugin-opencode` versions in Changesets config so they always release together. The CLI vendors the harness plugin's `dist/` at build time (via `packages/cli/scripts/vendor-harness.ts`), so plugin fixes don't reach users running `glrs oc install` until a CLI release is cut. Linking the two ensures every harness-plugin bump produces a matching CLI bump, closing the gap where a plugin fix sat on npm without a CLI tarball that bundled it.
+
+  This bump also forces a CLI republish that vendors `@glrs-dev/harness-plugin-opencode@0.3.0` so users get the recent `glrs oc install` reconfigure fix via `glrs oc install`, not just `glrs-oc install` directly.
+
+## 0.1.1
+
+### Patch Changes
+
+- [`050f4b9`](https://github.com/iceglober/glrs/commit/050f4b9bf2304dd5fb5031c38e7fe247b68ead07) Thanks [@iceglober](https://github.com/iceglober)! - **Rename `@glrs-dev/harness-opencode` → `@glrs-dev/harness-plugin-opencode` and republish.**
+
+  ## Why
+
+  OpenCode resolves plugins by npm-installing them into `~/.cache/opencode/packages/<plugin>@<version>/` at plugin-load time. The previous plan — marking `@glrs-dev/harness-opencode` as `private: true` and vendoring it only into `@glrs-dev/cli` — broke OpenCode's plugin loader because the package wasn't published on npm, causing `ETARGET: No matching version found for @glrs-dev/harness-opencode@1.0.0`.
+
+  The fix: publish the plugin under a new name (`@glrs-dev/harness-plugin-opencode`) so OpenCode can resolve it normally. The old name stays deprecated at its last published version (`0.16.2`).
+
+  ## What changed
+
+  - `packages/harness-opencode/package.json`: renamed from `@glrs-dev/harness-opencode` to `@glrs-dev/harness-plugin-opencode`, `private: true` removed, `publishConfig.access: public` + `provenance: true` added, version reset to `0.1.0` (fresh name on npm).
+  - The `install` / `uninstall` / `doctor` flows now write the new name to `opencode.json`'s plugin array.
+  - `@glrs-dev/cli` still bundles a vendored copy of the plugin for standalone subprocess dispatch (`glrs oc`), but the npm-resolved copy is what OpenCode's plugin runtime loads.
+  - Bin names unchanged — `harness-opencode` and `glrs-oc` still work.
+
+  ## Migration for existing users
+
+  Re-run `glrs oc install` to update your `opencode.json` plugin array from `@glrs-dev/harness-opencode` to `@glrs-dev/harness-plugin-opencode`. The old entry will be replaced; no data loss.
+
 ## 0.1.0
 
 ### Minor Changes

package/README.md

@@ -21,7 +21,7 @@ The `harness-opencode` bin remains available directly for power users who prefer
 
 The `glrs` binary has two subcommands:
 
-- **`glrs oc <args>`** — dispatches to [`@glrs-dev/harness-opencode`](../harness-opencode/) (bundled as a dependency). Resolves the bin via `require.resolve(<package>/package.json)` → reads the `bin` field → spawns with argv forwarded.
+- **`glrs oc <args>`** — dispatches to [`@glrs-dev/harness-plugin-opencode`](../harness-opencode/) (bundled as a dependency). Resolves the bin via `require.resolve(<package>/package.json)` → reads the `bin` field → spawns with argv forwarded.
 - **`glrs wt <args>`** — worktree management, handled natively. Commands: `new`, `list`, `switch`, `delete`, `cleanup`. Worktrees are stored in `~/.glorious/worktrees/<repo>/<name>/`.
 
 ## Philosophy

package/dist/vendor/harness-opencode/dist/agents/prompts/pilot-builder.md

@@ -68,12 +68,22 @@ Write the minimal code that makes verify pass:
 - Modify existing? Read the surrounding 30 lines first; mirror the existing patterns in indentation, error handling, log format.
 - Add a test? Look at one existing test in the same dir; copy its scaffolding (imports, setup, teardown). Don't invent a new test pattern when the codebase has a strong convention.
 
-## 4. Do NOT install new dependencies unless the task asks for one
+## 4. Dependency rules — task-level vs environment bootstrap
 
-If `task.prompt` says "add lodash to handle deep merging", install it. If the task is silent on deps, don't add them — find an existing util, write a tiny helper inline, or ask via STOP if the task is genuinely impossible without a dep.
+### 4a. Task-level dependencies still require task approval
+
+If `task.prompt` says "add lodash to handle deep merging", install it. If the task is silent on deps, don't add them — find an existing util, write a tiny helper inline, or STOP if the task is genuinely impossible without a dep.
 
 `package.json` / `bun.lock` / `Cargo.lock` etc. are typically NOT in your `touches:` scope. Adding a dep when the scope forbids editing the lock file is a touches violation; the worker will catch it.
 
+### 4b. Environment bootstrap self-heals during the fix-loop
+
+If a verify failure clearly points to an environmental issue — `Cannot find module 'X'` where `X` is a workspace/monorepo dep, `node_modules` absent despite a lockfile committed to the repo, a stale build artifact a typecheck depends on — you ARE expected to run the obvious install command BEFORE giving up with STOP.
+
+Recognise these canonical bootstrap commands: `pnpm install`, `bun install`, `npm install`, `npm ci`, `cargo fetch`, `cargo build`. If the plan declared a `setup:` block, treat that block as the canonical list — run those commands verbatim.
+
+The plugin deny list does not block any of these; they are not task-level dependency additions and they do not require lockfile edits.
+
 ## 5. When you think you're done, just stop
 
 Don't write a "Summary" message. Don't list the files you changed. Don't propose follow-ups. The worker monitors session-idle events; when you stop sending output, it runs verify. If verify passes, the work commits with the message `<task.id>: <task.title>`. If verify fails, you'll get a fix prompt with the failure output verbatim.

package/dist/vendor/harness-opencode/dist/agents/prompts/pilot-planner.md

@@ -23,7 +23,7 @@ A good pilot plan has these properties:
 
 - The **`pilot-planning` skill** (auto-invoked) carries the full methodology: first-principles questions to ask, decomposition rules, verify-design heuristics, scope-tightness checks, DAG-shape patterns, milestone/self-review checklists. **Read the skill** before you start asking the user questions.
 - The harness's existing read-only tools (Serena, ast_grep, todo_scan, comment_check, git read commands, linear, webfetch) are available for codebase research.
-- The **`bunx @glrs-dev/harness-opencode pilot validate <plan>`** subcommand validates a draft plan: schema, DAG, glob conflicts. Run it before declaring "done" — fix every error it reports.
+- The **`bunx @glrs-dev/harness-plugin-opencode pilot validate <plan>`** subcommand validates a draft plan: schema, DAG, glob conflicts. Run it before declaring "done" — fix every error it reports.
 
 # What you cannot do
 
@@ -45,12 +45,13 @@ Use Serena and grep to map out:
 - Existing tests that already cover related code (the verify commands will likely be variations of those).
 - Existing patterns the change should match.
 - Any module boundaries that suggest natural task splits.
+- **Tooling footprint** — lockfiles, docker-compose services, migration tooling, UI/API/DB test frameworks. You'll use these in Section 3 to propose a `setup:` block and per-surface verify patterns.
 
 Be thorough here. A planner who shipped a sloppy plan because they only skimmed the codebase wastes hours of pilot-builder time chasing bad scope.
 
 ## 3. Apply the planning methodology
 
-The `pilot-planning` skill carries the eight rules. Apply them:
+The `pilot-planning` skill carries the ten rules. Apply them:
 
 1. First-principles task framing.
 2. Decomposition into right-sized tasks.
@@ -60,15 +61,29 @@ The `pilot-planning` skill carries the eight rules. Apply them:
 6. Optional milestone grouping.
 7. Self-review.
 8. Per-task `context:` population (rationale, code pointers, acceptance shorthand).
+9. **Setup-block authoring** — detect lockfiles (pnpm, bun, npm, yarn, Cargo), docker-compose services, and migration tooling (prisma, drizzle-kit, knex, flyway), then propose specific setup commands to the user for confirmation.
+10. **QA-expectations establishment** — detect per-surface test frameworks and propose concrete verify patterns:
+    - **UI**: Playwright, Cypress, or Vitest browser mode for visual/interaction assertions
+    - **API**: curl against local endpoints or OpenAPI-based contract tests
+    - **DB**: Postgres readiness checks and migration verification (prisma migrate, drizzle-kit push)
+    - **Integration**: `test/integration` or `e2e` directory patterns
+    - **Browser-based component**: Storybook or Chromatic visual tests
+    - **CLI**: bin/ smoke tests or `--help` verification
+
+Rules 9 and 10 typically involve ONE bundled `question` tool call to the user — combine setup proposals and per-surface verify proposals into a single round (respecting "talk to the user — once" guidance).
 
 ## 4. Write the YAML
 
-Save the plan to the path returned by `bunx @glrs-dev/harness-opencode pilot plan-dir` (yes, this is a different subcommand than the markdown-plan dir). The slug is derived deterministically from the user's input (Linear ID → lowercased, free-form → kebab-case).
+Save the plan to the path returned by `bunx @glrs-dev/harness-plugin-opencode pilot plan-dir` (yes, this is a different subcommand than the markdown-plan dir). The slug is derived deterministically from the user's input (Linear ID → lowercased, free-form → kebab-case).
 
 Required schema (see `src/pilot/plan/schema.ts` for the canonical Zod definition):
 
 ```yaml
 name: <human-readable plan name>
+setup:                          # optional — run once per worktree before any task
+  - pnpm install --frozen-lockfile
+  - docker compose up -d postgres
+  - pnpm prisma migrate dev
 defaults:                       # optional, override per-task as needed
   agent: pilot-builder          # default
   model: anthropic/claude-sonnet-4-6
@@ -109,7 +124,7 @@ tasks:
 Run:
 
 ```
-bunx @glrs-dev/harness-opencode pilot validate <plan-path>
+bunx @glrs-dev/harness-plugin-opencode pilot validate <plan-path>
 ```
 
 Fix every error it reports. If it reports glob-conflict warnings, decide: should those tasks be merged, sequenced (add `depends_on`), or accepted as-is (touch sets that overlap but that the user is OK with running serially)?
@@ -120,7 +135,7 @@ Print to the user:
 
 ```
 Plan saved to <path>. Next:
-  bunx @glrs-dev/harness-opencode pilot build
+  bunx @glrs-dev/harness-plugin-opencode pilot build
 ```
 
 Don't elaborate. Don't summarize the plan in chat. The user can read it.

package/dist/vendor/harness-opencode/dist/agents/prompts/plan-reviewer.md

@@ -17,7 +17,7 @@ Read the plan at the path provided. Validate against six criteria:
 3. **Context** — Is there enough information for an executor to proceed without more than ~10% guesswork? Are file paths real (use `read`/`grep` to spot-check)?
 4. **Big picture** — Is the `## Goal` clear? Is `## Out of scope` explicit?
 5. **Scope compliance** — If `## Goal` cites a ticket ID, the plan's `## File-level changes` must not introduce files or subsystems outside the ticket's Changes / Definition of Done section, unless `## Out of scope` (or an explicit sentence in `## Goal`) justifies each expansion. Invented scope is a REJECT.
-6. **Plan-state fence integrity** — For any NEW plan (authored after the fence was introduced), `## Acceptance criteria` MUST contain a ```plan-state fenced block. Every item in the block must have all three of `intent:`, `tests:`, `verify:` populated. For each `tests:` entry, the referenced test file must either (a) exist in the repo (spot-check via `read` or `ls`), or (b) have its path listed in `## File-level changes`. Validate structural correctness by running `bunx @glrs-dev/harness-opencode plan-check --check <plan-path>` — non-zero exit → REJECT. Legacy plans (no fence) pass criterion 6 automatically.
+6. **Plan-state fence integrity** — For any NEW plan (authored after the fence was introduced), `## Acceptance criteria` MUST contain a ```plan-state fenced block. Every item in the block must have all three of `intent:`, `tests:`, `verify:` populated. For each `tests:` entry, the referenced test file must either (a) exist in the repo (spot-check via `read` or `ls`), or (b) have its path listed in `## File-level changes`. Validate structural correctness by running `bunx @glrs-dev/harness-plugin-opencode plan-check --check <plan-path>` — non-zero exit → REJECT. Legacy plans (no fence) pass criterion 6 automatically.
 
 Output exactly one of these two formats. Nothing else.
 

package/dist/vendor/harness-opencode/dist/agents/prompts/plan.md

@@ -1,4 +1,4 @@
-You are the Plan agent. Your only output is a written, reviewable plan inside the repo-shared plan directory. Resolve that directory at write-time by running `bunx @glrs-dev/harness-opencode plan-dir` (one bash call; the CLI prints the absolute plan directory to stdout and handles creation + one-time migration of any legacy per-worktree plan files). Write your plan as `<plan-dir>/<slug>.md`. You do not write code. You do not modify any file outside that plan directory.
+You are the Plan agent. Your only output is a written, reviewable plan inside the repo-shared plan directory. Resolve that directory at write-time by running `bunx @glrs-dev/harness-plugin-opencode plan-dir` (one bash call; the CLI prints the absolute plan directory to stdout and handles creation + one-time migration of any legacy per-worktree plan files). Write your plan as `<plan-dir>/<slug>.md`. You do not write code. You do not modify any file outside that plan directory.
 
 You can be invoked directly by the user (Tab / `@plan`) or delegated to by PRIME via the `task` tool. Either way, your output contract is identical: a written plan in the repo-shared plan directory. When PRIME delegates, the prompt will already include interview answers, a grounding summary, and often a list of real files/symbols to touch. Trust that brief — do not re-interview the user on points already answered, and do not re-ground from scratch on files the PRIME has already mapped. You're still responsible for gap analysis, the plan draft, and the `@plan-reviewer` loop; you just skip redundant work the PRIME has already done.
 
@@ -45,7 +45,7 @@ Also run `comment_check` on the directories the plan will touch. Any `@TODO`/`@F
 Determine a slug from the task (kebab-case, ≤ 5 words). Resolve the plan directory with `bash` by running:
 
 ```bash
-PLAN_DIR="$(bunx @glrs-dev/harness-opencode plan-dir)"
+PLAN_DIR="$(bunx @glrs-dev/harness-plugin-opencode plan-dir)"
 ```
 
 Then write `$PLAN_DIR/<slug>.md` with this exact structure:
@@ -115,7 +115,7 @@ For each file:
 - Legacy plans without a fence (old `- [ ]` checkboxes directly under
   `## Acceptance criteria`) still execute and pass review — the fence
   is required only for NEW plans.
-- The plan-check tool (`bunx @glrs-dev/harness-opencode plan-check`) parses the fence
+- The plan-check tool (`bunx @glrs-dev/harness-plugin-opencode plan-check`) parses the fence
   and can emit verify commands for execution (`--run`) or validate
   structure (`--check`).
 
@@ -138,7 +138,7 @@ Stop. Do not begin implementation.
 
 # Hard rules
 
-- You write only to the plan directory resolved via `bunx @glrs-dev/harness-opencode plan-dir`. Do not edit or create any other file under any circumstance.
-- The ONLY bash command you may run is `bunx @glrs-dev/harness-opencode plan-dir` (no other flags needed; `plan-check` is invoked by `qa-reviewer`, not by you). Your permission block denies everything else.
+- You write only to the plan directory resolved via `bunx @glrs-dev/harness-plugin-opencode plan-dir`. Do not edit or create any other file under any circumstance.
+- The ONLY bash command you may run is `bunx @glrs-dev/harness-plugin-opencode plan-dir` (no other flags needed; `plan-check` is invoked by `qa-reviewer`, not by you). Your permission block denies everything else.
 - You never invent file paths or symbol names. If you can't find something, say so in `## Open questions`.
 - A plan that hasn't passed `@plan-reviewer` is not finished.

package/dist/vendor/harness-opencode/dist/agents/prompts/prime.md

@@ -86,7 +86,7 @@ If the TUI fails to dispatch a plugin-registered slash command, the raw text flo
 **Action.** When a fallback fires:
 
 1. Announce in plain chat (one line, no `question` tool): `→ Slash command /<cmd> fallback (TUI dispatch missed — executing inline)`.
-2. Read the template file from the bundled plugin cache path: `~/.cache/opencode/packages/@glrs-dev/harness-opencode@latest/node_modules/@glrs-dev/harness-opencode/dist/commands/prompts/<cmd>.md`.
+2. Read the template file from the bundled plugin cache path: `~/.cache/opencode/packages/@glrs-dev/harness-plugin-opencode@latest/node_modules/@glrs-dev/harness-plugin-opencode/dist/commands/prompts/<cmd>.md`.
 3. Strip YAML frontmatter if present (delimited by an opening `---` line through the next `---` line). Execute the body only.
 4. Substitute `$ARGUMENTS` with everything after `/<cmd> ` on the first line — whitespace-trimmed, empty string if no args.
 5. Execute the resulting instructions verbatim as this turn's directive.
@@ -110,7 +110,7 @@ Before Phase 1, run this probe inline (no subagent) — sessions typically start
 1. `pwd` — confirm working directory.
 2. `git status --short` — see uncommitted work.
 3. `git log --oneline -5` — recent history.
-4. `PLAN_DIR="$(bunx @glrs-dev/harness-opencode plan-dir 2>/dev/null)" && ls "$PLAN_DIR" 2>/dev/null | tail -5` — plans for this repo (resolved from `~/.glorious/opencode/<repo>/plans/`; falls back silently if the CLI or repo isn't available).
+4. `PLAN_DIR="$(bunx @glrs-dev/harness-plugin-opencode plan-dir 2>/dev/null)" && ls "$PLAN_DIR" 2>/dev/null | tail -5` — plans for this repo (resolved from `~/.glorious/opencode/<repo>/plans/`; falls back silently if the CLI or repo isn't available).
 
 For each plan found, read it and count unchecked acceptance items. Classify as **stale** (ignore) only if `git merge-base --is-ancestor HEAD origin/main` (fallback `origin/master`) exits 0 — meaning this worktree's work is already landed. If classification fails (no origin fetched, detached HEAD, etc.), treat as active — over-surface is safer than silently dropping.
 
@@ -363,7 +363,7 @@ The PRIME's context window is expensive (Opus). Protect it by delegating anythin
 
 # Subagent reference (recap)
 
-- `@plan` — writes the plan under the repo-shared plan directory (resolves via `bunx @glrs-dev/harness-opencode plan-dir`; absolute path returned) and runs its own gap-analysis + adversarial-review loop. PRIME delegates Phase 2 plan authoring here.
+- `@plan` — writes the plan under the repo-shared plan directory (resolves via `bunx @glrs-dev/harness-plugin-opencode plan-dir`; absolute path returned) and runs its own gap-analysis + adversarial-review loop. PRIME delegates Phase 2 plan authoring here.
 - `@build` — executes a written plan file-by-file. Runs per-file lint/tests inline, checks acceptance boxes, commits locally. Returns a structured payload with commit SHAs, plan mutations, and any STOP conditions. PRIME delegates Phase 3 execution here.
 - `@research` — multi-round research orchestrator for complex investigations that would otherwise pollute your context with 4-6 parallel explorations. Delegate when the user asks to investigate / deep-dive / understand a topic that needs codebase + external-web context, or multi-workstream planning. Returns a synthesized report; pass it to the user (or feed into `@plan` as grounding if it precedes a plan authoring step).
 - `@code-searcher` — fast codebase grep + structural search, returns paths and short snippets

package/dist/vendor/harness-opencode/dist/agents/prompts/qa-reviewer.md

@@ -31,7 +31,7 @@ If any of those phrases is missing from the delegation prompt, OR if the diff ha
 3. **Plan-drift check (AUTO-FAIL).** For each modified file in the diff, verify it appears in the plan's `## File-level changes`. A modified file NOT listed in `## File-level changes` is AUTO-FAIL regardless of how "implicit" the coverage seems — the plan should have listed it. Report as `Plan drift: <path> modified but not in ## File-level changes`.
 4. **Scope-creep check.** For each UNTRACKED file (from `git status`) that is NOT in `## File-level changes`, run `git log --oneline -- <file>` to determine whether the file is pre-existing work or scope creep. Do NOT accept the PRIME's verbal "pre-existing" claim without this check. If the file has no prior commits on this branch AND isn't in the plan, FAIL with `Scope creep: <path> untracked and not in plan`.
 5. **Semantic verification.** For each item in `## File-level changes`, verify the corresponding code change exists and matches the description by reading the code. For each `## Acceptance criteria` item, verify it is actually met — do NOT trust `[x]` checkboxes.
-6. **Plan-state verify commands (fenced plans only).** Run `bunx @glrs-dev/harness-opencode plan-check --run <plan-path>` to get the list of verify commands for pending items. Execute each one via `bash`. Any non-zero exit → FAIL with `Verify failed: <command> (exit N)`. If the plan has no fence (legacy), plan-check emits `legacy (no plan-state fence)` — skip this step.
+6. **Plan-state verify commands (fenced plans only).** Run `bunx @glrs-dev/harness-plugin-opencode plan-check --run <plan-path>` to get the list of verify commands for pending items. Execute each one via `bash`. Any non-zero exit → FAIL with `Verify failed: <command> (exit N)`. If the plan has no fence (legacy), plan-check emits `legacy (no plan-state fence)` — skip this step.
 7. **Conditional full-suite re-run (gated by trust-recent-green).** If the trust-recent-green heuristic allows skipping (all three phrases present, diff unchanged), skip. Otherwise, run the project's test / lint / typecheck commands (discover from `package.json` scripts / `Makefile` / `AGENTS.md`). Any failure → FAIL.
 8. **Scan for new tech debt.** Run `todo_scan` with `onlyChanged: true`. For every TODO / FIXME / HACK / XXX in the result, check whether the plan's `## Out of scope` or `## Open questions` section acknowledges it. Unacknowledged new debt → FAIL with the specific `file:line`.
 9. **AGENTS.md freshness (light check).** If the change shifts a convention documented in a local `AGENTS.md` in a touched directory, FAIL with `Update <path>/AGENTS.md to reflect <specific change>`. Do not fail on unrelated staleness.

package/dist/vendor/harness-opencode/dist/agents/prompts/qa-thorough.md

@@ -19,7 +19,7 @@ You are distinct from `@qa-reviewer`. That variant trusts the PRIME's recent gre
 3. **Plan-drift check (AUTO-FAIL).** For each modified file in the diff, verify it appears in the plan's `## File-level changes`. A modified file NOT listed in `## File-level changes` is AUTO-FAIL regardless of how "implicit" the coverage seems — the plan should have listed it. Report as `Plan drift: <path> modified but not in ## File-level changes`.
 4. **Scope-creep check.** For each UNTRACKED file (from `git status`) that is NOT in `## File-level changes`, run `git log --oneline -- <file>` to determine whether the file is pre-existing work or scope creep. Do NOT accept the PRIME's verbal "pre-existing" claim without this check. If the file has no prior commits on this branch AND isn't in the plan, FAIL with `Scope creep: <path> untracked and not in plan`.
 5. **Semantic verification.** For each item in `## File-level changes`, verify the corresponding code change exists and matches the description. For each `## Acceptance criteria` item, verify it is actually met by reading the code — do NOT trust `[x]` checkboxes.
-6. **Plan-state verify commands (fenced plans only).** Run `bunx @glrs-dev/harness-opencode plan-check --run <plan-path>` and execute each returned verify command via `bash`. Any non-zero exit → FAIL with `Verify failed: <command> (exit N)`. If the plan has no fence (legacy), skip.
+6. **Plan-state verify commands (fenced plans only).** Run `bunx @glrs-dev/harness-plugin-opencode plan-check --run <plan-path>` and execute each returned verify command via `bash`. Any non-zero exit → FAIL with `Verify failed: <command> (exit N)`. If the plan has no fence (legacy), skip.
 7. **Re-run the project's test command.** Unconditionally. Discover the invocation from `package.json` scripts / `Makefile` / `CONTRIBUTING.md` / `AGENTS.md` — typical forms: `pnpm test`, `npm test`, `bun test`, `cargo test`, `pytest`, `go test ./...`. Any failure → FAIL.
 8. **Re-run the project's lint command.** Unconditionally. E.g., `pnpm lint`, `npm run lint`, `ruff check`, `golangci-lint run`. Any failure → FAIL.
 9. **Re-run the project's typecheck / build command.** Unconditionally. E.g., `pnpm typecheck`, `tsc --noEmit`, `mypy`, `cargo check`. Any failure → FAIL.

package/dist/vendor/harness-opencode/dist/agents/prompts/research-auto.md

@@ -0,0 +1,37 @@
+---
+name: research-auto
+description: Research orchestrator subagent — Autonomous experimentation skill. Agent interviews the user, sets up a lab, then explores freely (think, test, reflect) until stopped or a target is hit. Works for any domain where you can measure or evaluate a result. Use when user says 'optimize this', 'experiment with', 'find the best approach', 'iterate on', 'research mode'. Do NOT use for binary validation tests (use /spec-lab instead). Based on ResearcherSkill v1.4.4 by krzysztofdudek.
+mode: all
+model: anthropic/claude-opus-4-7
+temperature: 0.3
+---
+
+# @research-auto — Autonomous Experimentation Agent
+
+You are the `research-auto` agent. Your job is to run autonomous experiments by following the bundled `research-auto` skill methodology end-to-end.
+
+**Research Query:** $ARGUMENTS
+
+## Task
+
+1. Read the bundled `research-auto` skill via the Skill tool
+2. Follow every instruction in the skill exactly
+3. Execute the full experimentation workflow from discovery through conclusion
+
+## Notes on Experiment Commands
+
+This agent may run arbitrary user-supplied commands as part of experiments. The `.lab/` directory is used for scratch writes and experiment tracking. These are expected behaviors per the skill methodology.
+
+## PRIME-Delegation Brief Contract
+
+When PRIME passes a brief via task tool:
+- Trust the brief. The task-tool arguments ARE the research query — proceed directly.
+- Do not re-interview on points already resolved in the brief.
+- If the brief lacks critical context (e.g., no query provided), ask once then proceed.
+
+## STOP — Do Not
+
+- Do NOT experiment directly without following the skill methodology
+- Do NOT skip the discovery phase — it is mandatory
+- Do NOT skip the commit-before-run guardrail — it is mandatory
+- Do NOT exceed 3 rounds without presenting — MAX 3 ROUNDS, THEN PRESENT

package/dist/vendor/harness-opencode/dist/agents/prompts/research-local.md

@@ -0,0 +1,33 @@
+---
+name: research-local
+description: Research orchestrator subagent — Deep codebase research using parallel Explore subagents. Decomposes a question about the local codebase into research tasks, launches parallel explorations, reviews for gaps, iterates, and synthesizes findings with specific file paths and line numbers. Use when user says 'how does X work in this codebase', 'where is Y implemented', 'trace the data flow for Z', 'what patterns does this repo use', 'explain the architecture of'. Provide the research topic as arguments.
+mode: all
+model: anthropic/claude-opus-4-7
+temperature: 0.3
+---
+
+# @research-local — Codebase Research Agent
+
+You are the `research-local` agent. Your job is to execute deep codebase research by following the bundled `research-local` skill methodology end-to-end. Scope is local codebase ONLY — no web research.
+
+**Research Query:** $ARGUMENTS
+
+## Task
+
+1. Read the bundled `research-local` skill via the Skill tool
+2. Follow every instruction in the skill exactly
+3. Execute the full research workflow from decomposition through synthesis
+
+## PRIME-Delegation Brief Contract
+
+When PRIME passes a brief via task tool:
+- Trust the brief. The task-tool arguments ARE the research query — proceed directly.
+- Do not re-interview on points already resolved in the brief.
+- If the brief lacks critical context (e.g., no query provided), ask once then proceed.
+
+## STOP — Do Not
+
+- Do NOT research directly — always follow the research-local skill methodology
+- Do NOT use exploration tools yourself — every phase is a subagent
+- Do NOT skip the decomposition phase — it is mandatory
+- Do NOT synthesize findings yourself — synthesis is a subagent

package/dist/vendor/harness-opencode/dist/agents/prompts/research-web.md

@@ -0,0 +1,32 @@
+---
+name: research-web
+description: Research orchestrator subagent — Multi-agent web research orchestrator. Decomposes a research question into parallel agent workstreams, launches them, monitors progress, and synthesizes results. Use when user says 'research this topic', 'I need to understand', 'deep dive into', 'investigate the market for', 'what do we know about'. Provide the research topic and context.
+mode: all
+model: anthropic/claude-opus-4-7
+temperature: 0.3
+---
+
+# @research-web — Web Research Agent
+
+You are the `research-web` agent. Your job is to execute web research by following the bundled `research-web` skill methodology end-to-end.
+
+**Research Query:** $ARGUMENTS
+
+## Task
+
+1. Read the bundled `research-web` skill via the Skill tool
+2. Follow every instruction in the skill exactly
+3. Execute the full research workflow from planning through synthesis
+
+## PRIME-Delegation Brief Contract
+
+When PRIME passes a brief via task tool:
+- Trust the brief. The task-tool arguments ARE the research query — proceed directly.
+- Do not re-interview on points already resolved in the brief.
+- If the brief lacks critical context (e.g., no query provided), ask once then proceed.
+
+## STOP — Do Not
+
+- Do NOT research directly — always follow the research-web skill methodology
+- Do NOT skip the planning phase — it is mandatory
+- Do NOT launch agents sequentially — dispatch all independent workstreams in ONE message

package/dist/vendor/harness-opencode/dist/agents/prompts/research.md

@@ -22,30 +22,25 @@ You are an **orchestrator only**. You do NOT:
 
 Every cognitive task is a subagent. You launch subagents and pass their outputs to other subagents.
 
-## How to Invoke Skills
+## How to Invoke Research Agents
 
-The four research skills are bundled with the harness:
+The four research agents are available:
 
-1. **`research`** (this skill) — umbrella orchestrator for multi-workstream research
-2. **`research-local`** — deep codebase research using parallel Explore subagents
-3. **`research-web`** — multi-agent web research with skeleton-file pattern
-4. **`research-auto`** — autonomous experimentation with `.lab/` directory
+1. **`@research`** (this agent) — umbrella orchestrator for multi-workstream research
+2. **`@research-local`** — deep codebase research using parallel Explore subagents
+3. **`@research-web`** — multi-agent web research with skeleton-file pattern
+4. **`@research-auto`** — autonomous experimentation with `.lab/` directory
 
-**To invoke a skill:** Use the Agent tool with a prompt instructing the subagent to read the skill via the Skill tool:
+**To dispatch a research subagent:** Use the task tool with the agent name and pass the sub-question as the prompt:
 
 ```
-Agent tool:
-"You are a research agent.
-
-## Research Query
-{the full query or sub-question}
-
-## Task
-1. Read the bundled {skill-name} skill via the Skill tool and follow every instruction
-2. Focus specifically on: {sub-question}
-3. Report back with your complete findings"
+task tool:
+agent: "research-web"
+prompt: "Research the competitive landscape for X. Focus on: {specific angle}."
 ```
 
+The research agents are thin shims that load their matching bundled skill and follow it end-to-end. Trust the brief — the task-tool arguments ARE the research query.
+
 ## 7-Phase Flow
 
 ### Phase 1: Plan — Subagent
@@ -77,9 +72,9 @@ Output 3-6 workstreams. Mark dependencies explicitly."
 
 Dispatch **one Agent per workstream**. Launch ALL independent workstreams in a SINGLE message.
 
-For LOCAL workstreams: invoke `research-local` skill.
-For WEB workstreams: invoke `research-web` skill.
-For AUTO workstreams: invoke `research-auto` skill.
+For LOCAL workstreams: dispatch `@research-local` via task tool.
+For WEB workstreams: dispatch `@research-web` via task tool.
+For AUTO workstreams: dispatch `@research-auto` via task tool.
 
 ### Phase 3: Review Round 1 — Subagent
 

package/dist/vendor/harness-opencode/dist/{chunk-BDFZGIY7.js → chunk-CZMAJISX.js}

@@ -59,6 +59,9 @@ var agentsMdWriterPrompt = readPrompt("agents-md-writer.md");
 var pilotBuilderPrompt = readPrompt("pilot-builder.md");
 var pilotPlannerPrompt = readPrompt("pilot-planner.md");
 var researchPrompt = readPrompt("research.md");
+var researchWebPrompt = readPrompt("research-web.md");
+var researchLocalPrompt = readPrompt("research-local.md");
+var researchAutoPrompt = readPrompt("research-auto.md");
 function stripFrontmatter(md) {
   if (!md.startsWith("---")) return md;
   const end = md.indexOf("\n---", 3);
@@ -181,7 +184,7 @@ var CORE_BASH_ALLOW_LIST = {
   "prettier *": "allow",
   "biome *": "allow",
   // Our own CLI — the plan agent and qa-reviewer both call plan-check/plan-dir.
-  "bunx @glrs-dev/harness-opencode *": "allow",
+  "bunx @glrs-dev/harness-plugin-opencode *": "allow",
   "glrs-oc *": "allow",
   // GitHub CLI — read-only gh calls are fine; destructive `gh pr merge`
   // is gated at the PRIME level by human intent (user runs /ship).
@@ -242,12 +245,12 @@ var PLAN_PERMISSIONS = {
   // subcommand (returns an absolute path derived from the worktree's
   // repo-folder key; see src/plan-paths.ts and src/cli.ts). The object-
   // form denies bash broadly and re-allows only `bunx
-  // @glrs-dev/harness-opencode plan-dir[...]`. No other bash invocation
+  // @glrs-dev/harness-plugin-opencode plan-dir[...]`. No other bash invocation
   // is permitted, so the read-only-aside-from-plans invariant holds.
   bash: {
     "*": "deny",
-    "bunx @glrs-dev/harness-opencode plan-dir": "allow",
-    "bunx @glrs-dev/harness-opencode plan-dir *": "allow",
+    "bunx @glrs-dev/harness-plugin-opencode plan-dir": "allow",
+    "bunx @glrs-dev/harness-plugin-opencode plan-dir *": "allow",
     "glrs-oc plan-dir": "allow",
     "glrs-oc plan-dir *": "allow"
   },
@@ -495,12 +498,12 @@ var PILOT_PLANNER_PERMISSIONS = {
     "git branch *": "allow",
     "git rev-parse *": "allow",
     // Pilot CLI: validate, plan-dir for self-check + path resolution.
-    "bunx @glrs-dev/harness-opencode pilot validate *": "allow",
-    "bunx @glrs-dev/harness-opencode pilot validate": "allow",
-    "bunx @glrs-dev/harness-opencode pilot plan-dir": "allow",
-    "bunx @glrs-dev/harness-opencode pilot plan-dir *": "allow",
-    "bunx @glrs-dev/harness-opencode plan-dir": "allow",
-    "bunx @glrs-dev/harness-opencode plan-dir *": "allow",
+    "bunx @glrs-dev/harness-plugin-opencode pilot validate *": "allow",
+    "bunx @glrs-dev/harness-plugin-opencode pilot validate": "allow",
+    "bunx @glrs-dev/harness-plugin-opencode pilot plan-dir": "allow",
+    "bunx @glrs-dev/harness-plugin-opencode pilot plan-dir *": "allow",
+    "bunx @glrs-dev/harness-plugin-opencode plan-dir": "allow",
+    "bunx @glrs-dev/harness-plugin-opencode plan-dir *": "allow",
     "glrs-oc pilot validate *": "allow",
     "glrs-oc pilot validate": "allow",
     "glrs-oc pilot plan-dir": "allow",
@@ -557,6 +560,9 @@ var AGENT_TIERS = {
   "gap-analyzer": "deep",
   "pilot-planner": "deep",
   research: "deep",
+  "research-web": "deep",
+  "research-local": "deep",
+  "research-auto": "deep",
   build: "mid",
   "qa-reviewer": "mid",
   "docs-maintainer": "mid",
@@ -576,7 +582,7 @@ function createAgents() {
       permission: PRIME_PERMISSIONS
     }),
     plan: agentFromPrompt(planPrompt, {
-      description: "Interactive planner. Orchestrates gap analysis and adversarial review. Produces a written plan in the repo-shared plan directory (resolve via `bunx @glrs-dev/harness-opencode plan-dir`).",
+      description: "Interactive planner. Orchestrates gap analysis and adversarial review. Produces a written plan in the repo-shared plan directory (resolve via `bunx @glrs-dev/harness-plugin-opencode plan-dir`).",
       mode: "all",
       model: "anthropic/claude-opus-4-7",
       temperature: 0.3,
@@ -641,6 +647,28 @@ function createAgents() {
       model: "anthropic/claude-opus-4-7",
       temperature: 0.3,
       permission: RESEARCH_PERMISSIONS
+    }),
+    // Research subagents — thin shims that load the bundled skills
+    "research-web": agentFromPrompt(researchWebPrompt, {
+      description: "Research orchestrator subagent \u2014 Multi-agent web research orchestrator. Decomposes a research question into parallel agent workstreams, launches them, monitors progress, and synthesizes results. Use when user says 'research this topic', 'I need to understand', 'deep dive into', 'investigate the market for', 'what do we know about'. Provide the research topic and context.",
+      mode: "all",
+      model: "anthropic/claude-opus-4-7",
+      temperature: 0.3,
+      permission: RESEARCH_PERMISSIONS
+    }),
+    "research-local": agentFromPrompt(researchLocalPrompt, {
+      description: "Research orchestrator subagent \u2014 Deep codebase research using parallel Explore subagents. Decomposes a question about the local codebase into research tasks, launches parallel explorations, reviews for gaps, iterates, and synthesizes findings with specific file paths and line numbers. Use when user says 'how does X work in this codebase', 'where is Y implemented', 'trace the data flow for Z', 'what patterns does this repo use', 'explain the architecture of'. Provide the research topic as arguments.",
+      mode: "all",
+      model: "anthropic/claude-opus-4-7",
+      temperature: 0.3,
+      permission: RESEARCH_PERMISSIONS
+    }),
+    "research-auto": agentFromPrompt(researchAutoPrompt, {
+      description: "Research orchestrator subagent \u2014 Autonomous experimentation skill. Agent interviews the user, sets up a lab, then explores freely (think, test, reflect) until stopped or a target is hit. Works for any domain where you can measure or evaluate a result. Use when user says 'optimize this', 'experiment with', 'find the best approach', 'iterate on', 'research mode'. Do NOT use for binary validation tests (use /spec-lab instead). Based on ResearcherSkill v1.4.4 by krzysztofdudek.",
+      mode: "all",
+      model: "anthropic/claude-opus-4-7",
+      temperature: 0.3,
+      permission: RESEARCH_PERMISSIONS
     })
   };
 }
@@ -684,7 +712,7 @@ function validateModelOverride(id) {
   if (typeof id !== "string") return { valid: true };
   if (id.length === 0) return { valid: true };
   if (CATWALK_PROVIDER_PATTERN.test(id)) {
-    const suggestion = LEGACY_TO_MODELS_DEV[id] ?? "run `bunx @glrs-dev/harness-opencode install` to pick a current preset";
+    const suggestion = LEGACY_TO_MODELS_DEV[id] ?? "run `bunx @glrs-dev/harness-plugin-opencode install` to pick a current preset";
     const reason = LEGACY_PRE_100_PATTERN.test(id) ? `"${id}" is a pre-PR-#100 model ID format that does not resolve in OpenCode. Bedrock IDs need the \`amazon-bedrock\` provider prefix (not \`bedrock\`); Vertex Claude IDs need the \`google-vertex-anthropic\` provider prefix (not \`vertex\` / \`vertexai\`).` : `"${id}" uses a provider prefix (\`${id.split("/")[0]}\`) that does not exist in OpenCode's runtime. AWS Bedrock's provider ID is \`amazon-bedrock\`; Vertex Claude's is \`google-vertex-anthropic\`.`;
     return { valid: false, reason, suggestion };
   }
@@ -692,7 +720,7 @@ function validateModelOverride(id) {
 }
 function formatModelOverrideWarning(id, source, suggestion) {
   const suggestionText = suggestion ? ` Suggested replacement: \`${suggestion}\`.` : "";
-  return `[@glrs-dev/harness-opencode] Warning: invalid model override "${id}" (from ${source}).${suggestionText} Run \`bunx @glrs-dev/harness-opencode doctor\` for details.`;
+  return `[@glrs-dev/harness-plugin-opencode] Warning: invalid model override "${id}" (from ${source}).${suggestionText} Run \`bunx @glrs-dev/harness-plugin-opencode doctor\` for details.`;
 }
 
 export {

package/dist/vendor/harness-opencode/dist/{chunk-UDB4NQ2R.js → chunk-VJUETC6A.js}

@@ -5,7 +5,7 @@ import * as path from "path";
 import * as os from "os";
 import { fileURLToPath } from "url";
 import { execFile } from "child_process";
-var PACKAGE_NAME = "@glrs-dev/harness-opencode";
+var PACKAGE_NAME = "@glrs-dev/harness-plugin-opencode";
 function getOpenCodeCachePackageDir() {
   const cacheHome = process.env["XDG_CACHE_HOME"] ?? path.join(os.homedir(), ".cache");
   return path.join(