@webpresso/plugin-claude 0.0.15 → 0.0.17

package/skills/claude/SKILL.md

@@ -11,8 +11,8 @@ until independently verified.
 
 ## MCP-only contract
 
-- Call `wp_review_gate` exactly once for the real plan version or delivery diff.
-- Observe the same durable operation with `wp_review_gate_wait` when needed.
+- Call `review_gate` exactly once for the real plan version or delivery diff.
+- Observe the same durable operation with `review_gate_wait` when needed.
 - Never invoke a provider command, the legacy review CLI, or a removed review-run surface.
 - If the review MCP is unavailable, stop and report it unavailable. There is no CLI fallback.
 
@@ -25,7 +25,7 @@ until independently verified.
   "purpose": "delivery",
   "base_ref": "<full-base-sha>",
   "authority_ref": "<full-head-sha>",
-  "provider": "claude",
+  "caller_model": "<your own model id, exactly as your host reports it>",
   "repository_access": "none",
 }
 ```
@@ -36,10 +36,15 @@ verdict with no new review and no new round. A partial approval, withheld becaus
 is incomplete (not every prior finding was briefed, or a briefed prior claim was marked
 still-open without a matching finding), grants no authority and spends no round.
 
-## Model policy
+## Reviewer selection
 
-When the user names an exact model, pass it in the MCP `model` field. Otherwise omit
-that field and let the MCP owner select the configured provider default.
+Pass `caller_model` with your OWN model id, exactly as your host reports it, and omit
+`provider`, `model`, and `effort`: the gate selects the reviewer route itself — a cross-family
+reviewer chosen for capability, current provider limits, and measured daily cost — and reports
+the choice in `policy_selection`. Never name a reviewer model, probe a provider CLI for its
+catalog, or read a credential store to discover models at invocation time; provider catalog
+discovery belongs to the snapshot drift workflow. An operator may still pass an explicit
+`provider`/`model` as a human override; agents must not.
 
 ## Review quality
 

package/skills/codex/SKILL.md

@@ -11,8 +11,8 @@ until independently verified.
 
 ## MCP-only contract
 
-- Call `wp_review_gate` exactly once for the real plan version or delivery diff.
-- Observe the same durable operation with `wp_review_gate_wait` when needed.
+- Call `review_gate` exactly once for the real plan version or delivery diff.
+- Observe the same durable operation with `review_gate_wait` when needed.
 - Never invoke a provider command, the legacy review CLI, or a removed review-run surface.
 - If the review MCP is unavailable, stop and report it unavailable. There is no CLI fallback.
 
@@ -25,7 +25,7 @@ until independently verified.
   "purpose": "delivery",
   "base_ref": "<full-base-sha>",
   "authority_ref": "<full-head-sha>",
-  "provider": "codex",
+  "caller_model": "<your own model id, exactly as your host reports it>",
   "repository_access": "none",
 }
 ```
@@ -36,10 +36,15 @@ verdict with no new review and no new round. A partial approval, withheld becaus
 is incomplete (not every prior finding was briefed, or a briefed prior claim was marked
 still-open without a matching finding), grants no authority and spends no round.
 
-## Model policy
+## Reviewer selection
 
-When the user names an exact model, pass it in the MCP `model` field. Otherwise omit
-that field and let the MCP owner select the configured provider default.
+Pass `caller_model` with your OWN model id, exactly as your host reports it, and omit
+`provider`, `model`, and `effort`: the gate selects the reviewer route itself — a cross-family
+reviewer chosen for capability, current provider limits, and measured daily cost — and reports
+the choice in `policy_selection`. Never name a reviewer model, probe a provider CLI for its
+catalog, or read a credential store to discover models at invocation time; provider catalog
+discovery belongs to the snapshot drift workflow. An operator may still pass an explicit
+`provider`/`model` as a human override; agents must not.
 
 ## Review quality
 

package/skills/deep-interview/SKILL.md

@@ -59,7 +59,7 @@ Max rounds is a hard cap, not a target. Do not continue only to reach a round co
 - Treat every answer as a claim to pressure-test: the next question should usually demand evidence or an example, expose a hidden assumption, force a tradeoff or boundary, or reframe root cause vs symptom.
 - Do not rotate to a new dimension just for coverage when the current answer is still vague. Stay on the thread until it is one layer deeper, one assumption clearer, or one boundary tighter.
 - Before crystallizing, complete at least one explicit pressure pass that revisits an earlier answer with a deeper, assumption- or tradeoff-focused follow-up.
-- Gather codebase facts via local search tools, `wp_session_*` retrieval, and read-only repo inspection before asking the user about internals.
+- Gather codebase facts via local search tools, `session_*` retrieval, and read-only repo inspection before asking the user about internals.
 - Always run a preflight context intake before the first question.
 - For brownfield work, preflight must ground in docs before user-facing questions: inspect applicable `AGENTS.md`/`CLAUDE.md`, README/getting-started docs, relevant `docs/` contracts/plans/ADRs, existing blueprints under `blueprints/`, and any project glossary such as `UBIQUITOUS_LANGUAGE.md` when present.
 - Treat repo language as evidence, not authority: if the user uses a fuzzy, overloaded, or conflicting term, surface the specific doc/code wording and ask which meaning should govern.
@@ -82,17 +82,17 @@ Max rounds is a hard cap, not a target. Do not continue only to reach a round co
 ## Phase 0: Preflight Context Intake
 
 1. Parse `{{ARGUMENTS}}` and derive a short kebab-case task slug.
-2. Attempt to load the latest relevant context for the slug from session memory via the `wp_session_search`/`wp_session_retrieve` MCP tools.
+2. Attempt to load the latest relevant context for the slug from session memory via the `session_search`/`session_retrieve` MCP tools.
 3. If the provided initial context (or loaded snapshot) is too large for safe prompt use, the first round must ask for a concise prompt-safe summary before scoring ambiguity or any downstream handoff. This gate is blocking: preserve goals, constraints, success criteria, non-goals, decision boundaries, and references to the full source documents.
 4. If no snapshot exists, create a minimum snapshot with: task statement, desired outcome, stated solution, probable intent hypothesis, known facts/evidence, constraints, unknowns/open questions, decision-boundary unknowns, likely codebase touchpoints, repo docs/rules inspected, terminology/doc-code conflicts found.
 5. For brownfield tasks, inspect the applicable documentation/rule surface before the first user-facing round. Prefer exact, nearby sources: governing `AGENTS.md`/`CLAUDE.md`, README/getting-started docs, relevant `docs/` contracts/plans/ADRs, existing blueprints, and project glossary/context files when present.
-6. Capture the snapshot into session memory via `wp_session_capture` (tagged with the slug) and reference it in the interview state.
+6. Capture the snapshot into session memory via `session_capture` (tagged with the slug) and reference it in the interview state.
 
 ## Phase 1: Initialize
 
 1. Parse `{{ARGUMENTS}}` and the depth profile (`--quick|--standard|--deep`).
 2. Detect project context: use local search tools and read-only repo inspection to classify **brownfield** (existing codebase target) vs **greenfield**; for brownfield, collect relevant context before questioning.
-3. Persist a lightweight resumable interview state to session memory via `wp_session_capture` (interview id, profile, type, initial idea, rounds, current ambiguity, threshold, max rounds, challenge modes used, current stage/focus, context snapshot reference), so a later session can resume via `wp_session_search`/`wp_session_restore`.
+3. Persist a lightweight resumable interview state to session memory via `session_capture` (interview id, profile, type, initial idea, rounds, current ambiguity, threshold, max rounds, challenge modes used, current stage/focus, context snapshot reference), so a later session can resume via `session_search`/`session_restore`.
 4. Announce kickoff with the profile, threshold, and current ambiguity.
 
 ## Phase 2: Socratic Interview Loop
@@ -178,7 +178,7 @@ Show the weighted breakdown table, readiness-gate status (`Non-goals`, `Decision
 
 ### 2e) Persist state
 
-Append the round result and updated scores to the slug-tagged interview state in session memory (`wp_session_capture`).
+Append the round result and updated scores to the slug-tagged interview state in session memory (`session_capture`).
 
 ### 2f) Round controls
 
@@ -203,9 +203,9 @@ Track used modes in state to prevent repetition.
 
 When the threshold is met (or the user exits with warning / hard cap):
 
-1. Create or update the versioned draft that owns this task with `wp_blueprint_put`, yielding `blueprints/draft/{slug}/`. In this repo, deep interviews exist to produce better blueprints before implementation; carry the returned `bpv1:` version through every replacement.
+1. Create or update the versioned draft that owns this task with `blueprint_put`, yielding `blueprints/draft/{slug}/`. In this repo, deep interviews exist to produce better blueprints before implementation; carry the returned `bpv1:` version through every replacement.
 2. Write the interview transcript summary to `blueprints/draft/{slug}/interview.md`.
-3. Fold the execution-ready spec into `blueprints/draft/{slug}/_overview.md` (intent, scope, non-goals, decision boundaries, constraints, acceptance criteria), and capture a copy of the final spec + scores into session memory via `wp_session_capture`.
+3. Fold the execution-ready spec into `blueprints/draft/{slug}/_overview.md` (intent, scope, non-goals, decision boundaries, constraints, acceptance criteria), and capture a copy of the final spec + scores into session memory via `session_capture`.
 
 The spec should include: metadata (profile, rounds, final ambiguity, threshold, context type); context snapshot reference; prompt-safe initial-context summary when oversized context was provided, plus references to the full sources; the clarity breakdown table; Intent (why); Desired Outcome; In-Scope; Out-of-Scope / Non-goals; Decision Boundaries (what the agent may decide without confirmation); Constraints; testable acceptance criteria (prefer repo verification surfaces — `wp test`, `wp typecheck`, `wp audit` — over manual checks); assumptions exposed and their resolutions; pressure-pass findings (which answer was revisited and what changed); brownfield evidence-vs-inference notes; the Docs/Terminology Ledger; scenario/edge-case findings that shaped scope or acceptance; and the full or condensed transcript.
 
@@ -219,7 +219,7 @@ Present execution options after artifact generation using explicit handoff contr
 - **`autopilot`** — when the spec is already strong enough for direct planning plus execution. Consumer uses the spec as the clarified execution brief with the non-goals and acceptance criteria as binding context.
 - **`ultragoal`** — when the clarified work should become durable, sequentially tracked goal-mode work.
 - **`team`** — when the task is large, multi-lane, or blocker-sensitive enough to justify coordinated parallel execution.
-- **Blueprint lifecycle** — refine with `wp_blueprint_put`, review the exact version with `wp_review_gate`, and inspect the auto-promoted result with `wp_blueprint_get` when work should enter planned execution directly.
+- **Blueprint lifecycle** — refine with `blueprint_put`, review the exact version with `review_gate`, then promote the approved version explicitly with `blueprint_promote` when work should enter planned execution directly (MCP `review_gate` never auto-promotes).
 - **Refine further** — re-enter the loop to resolve the highest-leverage remaining uncertainty when residual ambiguity is still too high or an early-exit/above-threshold warning indicates too much risk to proceed cleanly.
 
 For research-shaped requests (a research question, evaluator-backed analysis, or reference gathering), hand off to `autoresearch` after the interview converges on a validator-ready mission; keep the explicit `refine further` vs `launch` boundary and do not launch until the user confirms.
@@ -232,11 +232,11 @@ For research-shaped requests (a research question, evaluator-backed analysis, or
 
 <Tool_Usage>
 
-- Use local search tools, `wp_session_*` retrieval, and read-only repo inspection for codebase fact gathering.
+- Use local search tools, `session_*` retrieval, and read-only repo inspection for codebase fact gathering.
 - Use the host's native structured-question tool (e.g. `AskUserQuestion`) for each round when available; otherwise ask one concise plain-text question and wait.
-- Keep context snapshots and resumable interview state in session memory via the `wp_session_*` MCP tools, tagged with the task slug.
+- Keep context snapshots and resumable interview state in session memory via the `session_*` MCP tools, tagged with the task slug.
 - Read applicable repo docs/rules/context during preflight; write durable docs/glossary/ADR updates only when the user explicitly opts in and the content is public-safe.
-- Land transcript artifacts in the active task's blueprint folder; create/update `_overview.md` only through `wp_blueprint_put`.
+- Land transcript artifacts in the active task's blueprint folder; create/update `_overview.md` only through `blueprint_put`.
 - Use `best-practice-research` when unresolved ambiguity depends on current external/upstream guidance.
   </Tool_Usage>
 
@@ -250,7 +250,7 @@ For research-shaped requests (a research question, evaluator-backed analysis, or
 
 <Final_Checklist>
 
-- [ ] Preflight context snapshot captured to session memory (`wp_session_capture`, slug-tagged)
+- [ ] Preflight context snapshot captured to session memory (`session_capture`, slug-tagged)
 - [ ] Oversized initial context, if present, has a prompt-safe summary before scoring or handoff
 - [ ] Ambiguity score shown each round
 - [ ] Intent-first stage priority used before implementation detail
@@ -260,7 +260,7 @@ For research-shaped requests (a research question, evaluator-backed analysis, or
 - [ ] Challenge modes triggered at thresholds (when applicable)
 - [ ] `Non-goals` and `Decision Boundaries` explicit before handoff
 - [ ] Transcript written to `blueprints/draft/{slug}/interview.md`
-- [ ] Spec folded into `blueprints/draft/{slug}/_overview.md` through `wp_blueprint_put`
+- [ ] Spec folded into `blueprints/draft/{slug}/_overview.md` through `blueprint_put`
 - [ ] Brownfield questions use evidence-backed confirmation and doc grounding when applicable
 - [ ] Fuzzy/conflicting terminology challenged against repo language when applicable
 - [ ] Handoff options provided (`ralplan`, `autopilot`, `ultragoal`, `team`, blueprint lifecycle)

package/skills/delivery-program/SKILL.md

@@ -28,14 +28,14 @@ Child membership comes only from `parent_roadmap`; do not maintain a second list
 
 ## Loop
 
-1. Call `wp_delivery_status({ slug })`.
+1. Call `delivery_status({ slug })`.
 2. Treat its `version`, blockers, and exact returned action as the current derived
    truth. Do not reconstruct state from transcripts.
-3. Dispatch only returned `wp_worktree` actions. Child work starts from the
+3. Dispatch only returned `worktree` actions. Child work starts from the
    delivery branch and child PRs target that branch.
 4. Integrate at most one child at a time. Recheck status immediately before
-   calling `wp_pr_merge` with the exact returned head SHA.
-5. An `enqueued` merge is not integrated. Call `wp_delivery_status` again and
+   calling `pr_merge` with the exact returned head SHA.
+5. An `enqueued` merge is not integrated. Call `delivery_status` again and
    wait for the merged postcondition.
 6. After every child PR is merged, verify the delivery branch and land its final
    PR to `delivery_base` through the same exact-SHA merge tool.

package/skills/fix/SKILL.md

@@ -31,26 +31,26 @@ the blast radius is broader than a local fix.
 
 ## Tooling map
 
-| Need                   | Prefer                                                                      |
-| ---------------------- | --------------------------------------------------------------------------- |
-| Reproduce / large logs | `wp_session_execute`, `wp_session_batch_execute`, `wp_session_execute_file` |
-| Recall prior evidence  | `wp_session_search`, `wp_session_restore`, `wp_session_retrieve`            |
-| Capture decisions      | `wp_session_capture` (do not paste full reports back as user text)          |
-| Scoped proof           | `wp_test`, `wp_lint`, `wp_typecheck`, or `wp_qa`                            |
-| Audits                 | `wp_audit` / `wp_audits`                                                    |
-| Worktree isolation     | `wp_blueprint_put` / `wp_worktree` — never thrash primary checkout          |
-| PR follow-up           | `wp_pr_status`, `wp_pr_upsert` when landing the fix                         |
+| Need                   | Prefer                                                             |
+| ---------------------- | ------------------------------------------------------------------ |
+| Reproduce / large logs | `session_execute`, `session_batch_execute`, `session_execute_file` |
+| Recall prior evidence  | `session_search`, `session_restore`, `session_retrieve`            |
+| Capture decisions      | `session_capture` (do not paste full reports back as user text)    |
+| Scoped proof           | `test`, `lint`, `typecheck`, or `qa`                               |
+| Audits                 | `audit` / `audits`                                                 |
+| Worktree isolation     | `blueprint_put` / `worktree` — never thrash primary checkout       |
+| PR follow-up           | `pr_status`, `pr_upsert` when landing the fix                      |
 
 ## Non-negotiable invariants
 
 1. **Root cause, not symptom.** Trace the failure to the invariant that actually broke. Do not patch callers when the owner is fixable.
 2. **Loud failures, no silent fallbacks.** No default shims, sentinel returns, or catch-and-continue behavior that hides missing config, bad state, or broken boundaries.
-3. **Use the repo's real execution surface.** Prefer MCP `wp_*` tools and repo wrappers over host Bash for search/test/lint. Use bounded session-memory paths for large output.
+3. **Use the repo's real execution surface.** Prefer wp MCP tools and repo wrappers over host Bash for search/test/lint. Use bounded session-memory paths for large output.
 4. **Regression proof is mandatory.** Add or strengthen a test or other reliable proof that would fail against the old behavior.
 5. **Raising timeouts is not a fix.** If a timeout fires, investigate the bottleneck. Only raise a bound when the repo already documents that workload and you can cite measurement.
 6. **Zero suppressions, zero papering over.** No lint disables, ts-ignore, compat aliases, or "temporary" branches to sneak the fix through.
 7. **Minimal correct diff.** Update every consumer of a changed contract in the same change, but do not bundle unrelated cleanup.
-8. **Primary checkout is sacred.** If HEAD is detached, primary is dirty with unrelated work, or you are not on a managed worktree for non-trivial edits → **stop** and move to `wp_worktree` / blueprint owner. Never leave the primary checkout broken.
+8. **Primary checkout is sacred.** If HEAD is detached, primary is dirty with unrelated work, or you are not on a managed worktree for non-trivial edits → **stop** and move to `worktree` / blueprint owner. Never leave the primary checkout broken.
 
 ## Opportunistic fix budget (when called from ultragoal / autopilot)
 
@@ -61,7 +61,7 @@ the blast radius is broader than a local fix.
 - **Tooling / harness findings** ("fix inefficiency you come across", MCP vs shell,
   hook thrash) honor the same budget. Excess → record via the `tech-debt` skill
   (or backlog handoff); do not expand the current epic unbounded.
-- Prefer MCP `wp_*` and session-memory tools over the `wp` CLI / raw shell for
+- Prefer wp MCP tools and session-memory tools over the `wp` CLI / raw shell for
   quality and discovery paths (see tooling map).
 
 ## Protocol
@@ -98,6 +98,19 @@ there, the investigation work is part of `fix`.
 - Read enough surrounding code to say the broken invariant in one sentence.
 - If the issue is nondeterministic, gather evidence until you can describe the slow/flaky/failing case without guessing.
 
+**Prove the mechanism before naming it.** A cause that merely explains the
+symptom is a hypothesis, not a finding. Run the failing thing with the candidate
+values and read what it actually did; trace the claim to the code that executes,
+not the code whose name matches the theory. If you cannot reproduce it, label it
+unverified and keep investigating — do not write it into a plan, commit, or
+report as the cause.
+
+**When a cause is disproved, go back to the command, not to the next story.**
+Substituting another plausible explanation without new observation is how one
+dead route gets three confident, wrong diagnoses. If your second and third
+explanations are still unobserved, you have not reproduced the failure yet.
+Related: `catalog/agent/rules/evidence-discipline.md` § 6.
+
 If the "issue" is actually several unrelated failures, stop and ask which one to fix first.
 
 ### Step 2 — Decide where the fix belongs
@@ -130,10 +143,10 @@ Do not keep production code written before the test as "reference". If you wrote
 
 Run the narrowest checks that prove the repaired behavior on the real repo surface:
 
-- `wp_test` / targeted tests for the repaired path
-- `wp_lint` / `wp_typecheck` for changed surfaces
-- `wp_qa` only when the blast radius needs the bookend
-- Before push: start `wp_ci_preflight`, then poll `wp_ci_preflight_wait` with
+- `test` / targeted tests for the repaired path
+- `lint` / `typecheck` for changed surfaces
+- `qa` only when the blast radius needs the bookend
+- Before push: start `ci_preflight`, then poll `ci_preflight_wait` with
   its run ID until terminal success (use global `wp ci-preflight` only when MCP
   is unavailable). Run it after the final commit and do not edit or commit again
   before pushing: terminal success records the exact-state receipt checked by pre-push.
@@ -141,7 +154,7 @@ Run the narrowest checks that prove the repaired behavior on the real repo surfa
 
 Rules:
 
-- Prefer MCP `wp_*` over raw host Bash.
+- Prefer wp MCP tools over raw host Bash.
 - Reuse fresh logs / session-memory indexed output; do not re-run long commands just to re-read.
 - Read the exit code and summary before making a claim.
 - Never `git push --no-verify` to land an unproven fix.
@@ -158,7 +171,7 @@ cleanup pass, use `ai-deslop` before the final verify handoff.
 
 ### Tool recovery and delivery intent
 
-- Discover the managed owner's current identity with `wp_blueprint_projects`
+- Discover the managed owner's current identity with `blueprint_projects`
   using its absolute `cwd`; pass the returned project ID and matching checkout
   to session tools. A blueprint ID is not a project ID.
 - If quality tooling refuses stale or cross-checkout execution, follow its

package/skills/handoff/SKILL.md

@@ -26,24 +26,24 @@ session. Do **not** paste full transcripts.
 
 ## Tooling map
 
-| Need                   | Prefer                                                                              |
-| ---------------------- | ----------------------------------------------------------------------------------- |
-| Capture decisions      | `wp_session_capture`                                                                |
-| Context-light manifest | `wp_session_context` (required for subagents)                                       |
-| Prior evidence         | `wp_session_search` / `wp_session_retrieve` / `wp_session_restore`                  |
-| Other-host chat        | `wp_conversation_search` / `wp_conversation_get` / `wp_conversation_read` (bounded) |
-| Ultragoal block        | `wp_ultragoal_handoff` (≤40 lines) when a controller is active                      |
+| Need                   | Prefer                                                                     |
+| ---------------------- | -------------------------------------------------------------------------- |
+| Capture decisions      | `session_capture`                                                          |
+| Context-light manifest | `session_context` (required for subagents)                                 |
+| Prior evidence         | `session_search` / `session_retrieve` / `session_restore`                  |
+| Other-host chat        | `conversation_search` / `conversation_get` / `conversation_read` (bounded) |
+| Ultragoal block        | `ultragoal_handoff` (≤40 lines) when a controller is active                |
 
 ## Protocol
 
 1. **State the objective** in one sentence (what the next agent must finish).
-2. **Capture** short pointers via `wp_session_capture`: done, blockers, decisions,
+2. **Capture** short pointers via `session_capture`: done, blockers, decisions,
    evidence refs (log paths, test commands, PR numbers) — not full reports.
-3. **Build** a bounded manifest with `wp_session_context` (objective, constraints,
+3. **Build** a bounded manifest with `session_context` (objective, constraints,
    evidenceRefs, remainingSteps, validation, exclusions). Never copy parent history.
 4. **Optional cross-host:** resolve the conversation with conversation MCP tools;
    read only a **bounded tail** (`maxMessages` / `maxBytes`). Prefer resume
-   commands from `wp_conversation_get` over paste.
+   commands from `conversation_get` over paste.
 5. **Emit ≤40 lines** covering:
    - goal / non-goals
    - done + evidence refs
@@ -63,6 +63,37 @@ session. Do **not** paste full transcripts.
 ## Done looks like
 
 - [ ] ≤40-line handoff with evidence refs
-- [ ] `wp_session_context` (or capture ids) for the next agent
+- [ ] `session_context` (or capture ids) for the next agent
 - [ ] Next skill named
 - [ ] No transcript wall
+
+## Capped or paused host messaging
+
+When the host messaging channel is capped or paused, the ≤40-line manifest IS
+the delivery: the handoff built above carries objective, done, blockers, and
+next steps even if no send lands — emit it once and treat it as sent. Include
+the send-budget state (attempt count, last canary result) in the manifest
+whenever the cap has been in play this session — the count's durable homes
+are the outbox header and the `session_capture` record; re-read both on
+resume. The leader's outbox anchor is durable in two homes: the
+outbox file's own header and a `session_capture` record (`session_capture`
+is registered in `src/mcp/tools/_names.ts`, implemented in
+`src/mcp/tools/session-capture.ts`). When the coordinator incarnation changes,
+re-anchor: write both homes plus the next handoff manifest — a recorded anchor
+goes stale when the identity passes to a new session (observed 2026-10-31: a
+memory-recorded live outbox path no longer existed). On the reader side, a
+stale or dead anchor is not a wall: fall back to the next durable arbitration
+source (`fleet_status` / blueprint task lists) and queues the staleness as
+a blocker in the outbox or manifest; a control send is spent only when the
+channel is open and a reserve slot remains, to surface the staleness. Before executing a resumed
+or queued order, check durable state (the outbox, `fleet_status`,
+blueprint task lists) for a newer arbitration — queued sends deliver late
+and out of order. The manifest carries this check as a required line.
+Queued orders in the manifest are one line each; if the queue would break
+the ≤40-line cap, the manifest carries the count and the outbox path and
+the orders stay in the outbox. Never route around a cap or
+pause: no relays, no peer delegation, no new sessions, no schedulers, no
+filesystem push-delivery to peers, no configuration changes, and no alternate
+transport, tool, or uncapped/legacy send interface. The durable outbox is pull-read
+state, not a route-around. Keep manifests context-light — do not paste full
+transcripts.

package/skills/hooks-doctor/SKILL.md

@@ -7,7 +7,7 @@ scope: repo
 applies_to: [agents]
 related: []
 created: "2026-05-07"
-last_reviewed: "2026-05-07"
+last_reviewed: "2026-11-01"
 name: hooks-doctor
 description: "Hook/plugin doctor for install health. Use for hook blocked, pretooluse, plugin broken."
 argument-hint: "[--skip-mcp]"
@@ -55,13 +55,13 @@ Each check prints `[x]` (pass) or `[ ]` (fail) with a detail line:
 
 ## Failure Remediation
 
-| Check                                            | Likely Cause                                                   | Fix                                                               |
-| ------------------------------------------------ | -------------------------------------------------------------- | ----------------------------------------------------------------- |
-| `pretool-guard` / `post-tool` / etc. — not found | `wp run build` not run after install                           | `wp run build`                                                    |
-| `pretool-guard` / etc. — not executable          | `chmod +x` not persisted                                       | Re-run `wp run prepare` or `wp run build` which runs `chmod-bins` |
-| `plugin.json integrity` — missing                | Claude adapter manifest absent from `@webpresso/plugin-claude` | Re-run `wp setup --host claude` or reinstall the Claude plugin    |
-| `MCP server liveness` — timeout                  | MCP server cold-start too slow                                 | Wait and retry, or run `wp hooks doctor --skip-mcp`               |
-| Any check — not found at `dist/esm/...`          | Build artifacts missing                                        | Run `wp run build` in the webpresso repo                          |
+| Check                                            | Likely Cause                                                      | Fix                                                               |
+| ------------------------------------------------ | ----------------------------------------------------------------- | ----------------------------------------------------------------- |
+| `pretool-guard` / `post-tool` / etc. — not found | `wp run build` not run after install                              | `wp run build`                                                    |
+| `pretool-guard` / etc. — not executable          | `chmod +x` not persisted                                          | Re-run `wp run prepare` or `wp run build` which runs `chmod-bins` |
+| `plugin.json integrity` — missing                | Claude or Antigravity adapter manifest absent from plugin package | Re-run `wp setup --host <host>` or reinstall the host plugin      |
+| `MCP server liveness` — timeout                  | MCP server cold-start too slow                                    | Wait and retry, or run `wp hooks doctor --skip-mcp`               |
+| Any check — not found at `dist/esm/...`          | Build artifacts missing                                           | Run `wp run build` in the webpresso repo                          |
 
 ### Updating the webpresso MCP server (monorepo authors)
 
@@ -95,10 +95,12 @@ started. Check the installed host version before using version-scoped controls.
   commands](https://dev.opencode.ai/v2/docs/cli/commands/); host documentation
   verified 2026-10-17). These `dev.opencode.ai` paths sit on a preview domain
   and can move; confirm the v2 path still resolves before following it.
+- **Antigravity:** Preferences / Settings → Plugins → reload or toggle `wp` plugin,
+  or restart the Antigravity session. Verify with `wp hooks doctor` or `wp hooks status`.
 
 After reconnecting, prove the loaded source rather than the connection:
 
-1. Call `wp_tool_surface` with `detail: "diagnostic"`.
+1. Call `tool_surface` with `detail: "diagnostic"`.
 2. Compare `details.diagnostic.live.sourceCommit` against the commit you expect
    the checkout to be serving.
 3. Read `details.diagnostic.identity.status`, which is exactly one of `current`,

package/skills/investigate/SKILL.md

@@ -19,19 +19,19 @@ flaky behavior, or confusing symptom before editing code.
 
 ## Tooling map
 
-| Need                   | Prefer                                                           |
-| ---------------------- | ---------------------------------------------------------------- |
-| Reproduce / large logs | `wp_session_execute`, `wp_session_batch_execute`                 |
-| Large files            | `wp_session_execute_file`                                        |
-| Prior continuity       | `wp_session_search`, `wp_session_restore`, `wp_session_retrieve` |
-| Capture findings       | `wp_session_capture` (short pointer, not full paste-back)        |
-| Proof runs             | `wp_test`, `wp_qa`, `wp_lint`, `wp_typecheck`                    |
-| Code search/read       | host Grep/Read first; avoid shell-as-IDE                         |
+| Need                   | Prefer                                                  |
+| ---------------------- | ------------------------------------------------------- |
+| Reproduce / large logs | `session_execute`, `session_batch_execute`              |
+| Large files            | `session_execute_file`                                  |
+| Prior continuity       | `session_search`, `session_restore`, `session_retrieve` |
+| Capture findings       | `session_capture` (short pointer, not full paste-back)  |
+| Proof runs             | `test`, `qa`, `lint`, `typecheck`                       |
+| Code search/read       | host Grep/Read first; avoid shell-as-IDE                |
 
 ## Workflow
 
 1. Reproduce or capture the failure.
-   - Run the exact failing command or trace the exact user path (prefer `wp_session_execute`).
+   - Run the exact failing command or trace the exact user path (prefer `session_execute`).
    - Keep the evidence that matters: error text, failing assertion, exit code,
      log path, or boundary mismatch.
 2. Read the whole boundary.
@@ -42,9 +42,20 @@ flaky behavior, or confusing symptom before editing code.
    - Name the broken invariant in one sentence.
    - Name the owner that should enforce it.
    - Separate facts from guesses.
+   - **Every cause must carry the observation that proved it**: the command you
+     ran, its output, and the code path that produced it. A cause you have not
+     executed against the failing case is a guess and must be labelled as one.
 4. Disconfirm cheap alternatives.
    - Test the obvious competing explanations before settling on one cause.
    - Add temporary diagnostics only when needed, and remove them after one pass.
+   - **When a cause is disproved, return to the reproduction rather than
+     replacing it with the next plausible story.** Two or three confident
+     explanations in a row, none observed, means the failure has not been
+     reproduced yet — go back to step 1.
+   - A test fixture, capability object, or recorded tool output that asserts
+     behaviour is the weakest link: confirm at least one path against the real
+     binary, module, or service it stands in for.
+   - Related: `catalog/agent/rules/evidence-discipline.md` § 6.
 5. Produce failing proof.
    - Prefer a targeted failing test.
    - If test-first is impossible at this boundary, use the nearest deterministic

package/skills/opencode-go/SKILL.md

@@ -11,8 +11,8 @@ until independently verified.
 
 ## MCP-only contract
 
-- Call `wp_review_gate` exactly once for the real plan version or delivery diff.
-- Observe the same durable operation with `wp_review_gate_wait` when needed.
+- Call `review_gate` exactly once for the real plan version or delivery diff.
+- Observe the same durable operation with `review_gate_wait` when needed.
 - Never invoke a provider command, the legacy review CLI, or a removed review-run surface.
 - If the review MCP is unavailable, stop and report it unavailable. There is no CLI fallback.
 
@@ -25,8 +25,7 @@ until independently verified.
   "purpose": "delivery",
   "base_ref": "<full-base-sha>",
   "authority_ref": "<full-head-sha>",
-  "provider": "opencode",
-  "model": "opencode-go/deepseek-v4.1-flash",
+  "caller_model": "<your own model id, exactly as your host reports it>",
   "repository_access": "none",
 }
 ```
@@ -37,13 +36,15 @@ verdict with no new review and no new round. A partial approval, withheld becaus
 is incomplete (not every prior finding was briefed, or a briefed prior claim was marked
 still-open without a matching finding), grants no authority and spends no round.
 
-## Model policy
+## Reviewer selection
 
-Default exact model: `opencode-go/deepseek-v4.1-flash`.
-Committed exact options: `opencode-go/deepseek-v4.1-flash`, `opencode-go/glm-5.3-flash`, `opencode-go/deepseek-v4-pro`, `opencode-go/kimi-k2.7-code`, `opencode-go/muse-spark-1.3-contributor`, `opencode-go/mimo-v2.6-pro`, `opencode-go/step-5-preview`, `opencode-go/qwen3.8-max`, `opencode-go/mimo-v2.6-flash`, `opencode-go/qwen3.8-flash`, `opencode-go/minimax-m3.1-flash-free`, `opencode-go/qwen3.7-plus`, `opencode-go/muse-spark-1.2-contributor`, `opencode-go/mimo-v2.5`, `opencode-go/minimax-m3`, `opencode-go/mimo-v2.5-pro`, `opencode-go/longcat-2.5-preview-free`, `opencode-go/longcat-2.0`, `opencode-go/gpt-6-luna`, `opencode-go/kimi-k3`, `opencode-go/hy4-preview`, `opencode-go/hy3`, `opencode-go/grok-4.7`, `opencode-go/gpt-5.6-luna`, `opencode-go/claude-haiku-5-5`, `opencode-go/glm-5.3`, `opencode-go/glm-5.2`, `opencode-go/gemini-4-argon-contributor`, `opencode-go/beam-free`.
-Use a named exact option when requested; otherwise use the default. Provider catalog discovery
-belongs to the snapshot drift workflow, never to a skill invocation; reading the box-local
-credential store at gate time is a local file read, not catalog discovery.
+Pass `caller_model` with your OWN model id, exactly as your host reports it, and omit
+`provider`, `model`, and `effort`: the gate selects the reviewer route itself — a cross-family
+reviewer chosen for capability, current provider limits, and measured daily cost — and reports
+the choice in `policy_selection`. Never name a reviewer model, probe a provider CLI for its
+catalog, or read a credential store to discover models at invocation time; provider catalog
+discovery belongs to the snapshot drift workflow. An operator may still pass an explicit
+`provider`/`model` as a human override; agents must not.
 
 ## Review quality
 

package/skills/plan-refine/SKILL.md

@@ -75,9 +75,10 @@ Run **1–3 (and relevant review lenses) in parallel** whenever tools allow. Do
    - Score alternatives on elegance, durability, and efficiency; keep only the winner and write the rejection rationale for heavier options.
 
 4. **Plan-review lenses (skip when the caller already ran them).** Folded `/autoplan`: run relevant CEO/founder, design, engineering, and DevEx lenses **in parallel when independent**; consolidate keep/change/drop, unresolved taste calls, tests, go/no-go.
+   - **Review cost — know it before you dispatch.** An `approve`, `approve-with-nits`, or `reject` verdict from a `review_gate` run spends ONE formal review round (per slug and purpose). A no-verdict attempt spends none; editing the plan spends and resets nothing already spent. `src/review/budgets.ts` owns the numeric allowance — never restate it in prose — and `wp review budget <slug>` reports remaining capacity live.
    - **Skip condition.** If the caller states `plan-* reviews complete for this pass`, do **not** re-run the lenses. `ralplan` runs them before handing off, so re-running them here is duplicated spend, not a second opinion.
    - **Re-entry.** If refinement itself **materially changes scope**, re-run only the affected lens — never the full set — then continue applying.
-   - **Re-review rounds.** `catalog/agent/rules/review-methodology-sota.md` Principle 5 sets the delta-anchored adjudication contract subsequent `wp_review_gate` rounds follow.
+   - **Re-review rounds.** `catalog/agent/rules/review-methodology-sota.md` Principle 5 sets the delta-anchored adjudication contract subsequent `review_gate` rounds follow.
 
 5. **Blueprint enforcement (max parallel).**
    - Split for independent execution; declare `Depends`; file-conflict CP = 0 per wave; TDD/proof steps; preserve acceptance criteria.

package/skills/ralplan/SKILL.md

@@ -42,6 +42,10 @@ Use when the user invokes `$ralplan`, asks for RALPLAN, or wants consensus plann
 1. **Blueprint is the plan.** Freeform notes are not durable consensus. Create or bind a blueprint before reviews.
 2. **Align with other lanes before planning.** This repo is worked by many concurrent agent sessions. Before the code dive, establish which surfaces another live lane already owns and record them as explicit non-goals. See [Lane alignment](#lane-alignment-not-optional). The user should not have to re-assert this.
 3. **Ground before drafting.** Code dive (+ bounded external research when needed) happens **before** the blueprint draft is treated as serious.
+   - **A stated cause is a claim that must be observed.** When a plan explains
+     why something fails, it carries the command that produced that answer.
+     An unobserved cause is a guess laundered into consensus, and review will
+     spend rounds disproving it instead of improving the plan.
 4. **Reviews before refine.** Run risk-matched `plan-*` skills on the blueprint, apply findings, **then** `/plan-refine`.
 5. **No implementation.** Do not edit product source, commit implementation, or start `ultragoal`/`team`/`autopilot` unless the user explicitly switches out of planning.
 6. **No review stampede.** Do not fan out multi-host outside-voice swarms. Prefer in-host skill loads; at most one outside voice only if the user asks or the change is auth / data-loss / public-API sensitive.
@@ -126,7 +130,7 @@ Rules:
 - Apply findings **into the blueprint** after each review (or once after the set if independent).
 - Independent reviews may run in parallel **only when** they do not depend on each other's edits; if eng findings reshape scope, re-run only the affected optional reviews.
 - Optional high-risk challenge: one sequential outside-voice pass (`codex` / `claude` / `opencode-go`) **after** eng review if the user asks or the change is auth / data-loss / public-API sensitive. Never parallel multi-host review.
-- Any formal `wp_review_gate` re-review round follows `catalog/agent/rules/review-methodology-sota.md` Principle 5's delta-anchored adjudication contract, not a fresh rediscovery pass.
+- Any formal `review_gate` re-review round follows `catalog/agent/rules/review-methodology-sota.md` Principle 5's delta-anchored adjudication contract, not a fresh rediscovery pass.
 
 ### 5. `/plan-refine` last (always)