@webpresso/plugin-claude 0.0.14 → 0.0.16

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -5,14 +5,14 @@
5
5
  "url": "https://github.com/webpresso"
6
6
  },
7
7
  "metadata": {
8
- "description": "Webpresso agent-kit Claude Code plugin: blueprints, skills, hooks, MCP server",
9
- "version": "0.0.14"
8
+ "description": "Webpresso app Claude Code plugin: blueprints, skills, hooks, MCP server",
9
+ "version": "0.0.16"
10
10
  },
11
11
  "plugins": [
12
12
  {
13
- "name": "agent-kit",
13
+ "name": "wp",
14
14
  "source": "./",
15
- "description": "Webpresso agent-kit: blueprints, skills, lore commit protocol, tech-debt lifecycle",
15
+ "description": "Webpresso app: blueprints, skills, lore commit protocol, tech-debt lifecycle",
16
16
  "category": "development",
17
17
  "keywords": ["agent", "blueprint", "claude-code", "skills", "mcp"]
18
18
  },
@@ -24,5 +24,8 @@
24
24
  "keywords": ["typescript", "lsp", "claude-code", "language-server"]
25
25
  }
26
26
  ],
27
- "version": "0.0.14"
27
+ "renames": {
28
+ "agent-kit": "wp"
29
+ },
30
+ "version": "0.0.16"
28
31
  }
@@ -1,7 +1,7 @@
1
1
  {
2
- "name": "agent-kit",
3
- "version": "0.0.14",
4
- "description": "Webpresso agent-kit: blueprints, skills, lore commit protocol, tech-debt lifecycle",
2
+ "name": "wp",
3
+ "version": "0.0.16",
4
+ "description": "Webpresso app: blueprints, skills, lore commit protocol, tech-debt lifecycle",
5
5
  "author": {
6
6
  "name": "Webpresso",
7
7
  "url": "https://github.com/webpresso"
@@ -9,7 +9,7 @@
9
9
  "skills": "./skills",
10
10
  "commands": "./commands",
11
11
  "mcpServers": {
12
- "webpresso": {
12
+ "wp": {
13
13
  "command": "${CLAUDE_PLUGIN_ROOT}/bin/wp",
14
14
  "args": ["mcp"],
15
15
  "env": {
package/commands/audit.md CHANGED
@@ -2,7 +2,7 @@
2
2
  description: Run a webpresso audit
3
3
  ---
4
4
 
5
- Use the `wp_audit` tool when the requested audit is available through MCP.
5
+ Use the `audit` tool when the requested audit is available through MCP.
6
6
  For humans or MCP-unavailable hosts, use the global `wp audit <kind>` CLI
7
7
  compatibility path. Never use a repo-local `./bin/wp` launcher as the normal
8
8
  agent path. Common `kind` values include `guardrails`, `quality`,
@@ -4,24 +4,24 @@ description: Manage blueprints via focused MCP tools
4
4
 
5
5
  Use the focused blueprint MCP tools.
6
6
 
7
- - `wp_blueprint_projects` — discover visible projects and worktrees
8
- - `wp_blueprint_list` — list blueprints
9
- - `wp_blueprint_get` — fetch one blueprint with freshness metadata
10
- - `wp_blueprint_context` — assemble bounded task context
11
- - `wp_blueprint_create` — create a draft blueprint; requires `project_id` and accepts optional `request_id` and `head_at_ingest` for retry-safe, stale-write-safe creation
12
- - `wp_blueprint_put` — whole-document structured authoring; writes the canonical blueprint markdown from typed input and returns revision metadata
13
- - `wp_blueprint_transition` — optimistic-concurrency lifecycle transition; requires `expected_version` and returns updated revision metadata
14
- - `wp_blueprint_task_next` — return the next ready task; accepts optional `project_id` when the current cwd is a multi-repo workspace container
15
- - `wp_blueprint_task_advance` — change task status (non-`done`); requires `project_id` and `slug` (task ids are not unique across blueprints, so `slug` scopes the mutation to the right one), and accepts optional `request_id` and `head_at_ingest` for retry-safe mutation
16
- - `wp_blueprint_task_verify` — mark a task `done` with evidence; accepts optional `request_id` and `head_at_ingest` for retry-safe verification
17
- - `wp_blueprint_promote` / `wp_blueprint_finalize` — accept optional `project_id` for nested-workspace disambiguation
7
+ - `blueprint_projects` — discover visible projects and worktrees
8
+ - `blueprint_list` — list blueprints
9
+ - `blueprint_get` — fetch one blueprint with freshness metadata
10
+ - `blueprint_context` — assemble bounded task context
11
+ - `blueprint_create` — create a draft blueprint; requires `project_id` and accepts optional `request_id` and `head_at_ingest` for retry-safe, stale-write-safe creation
12
+ - `blueprint_put` — whole-document structured authoring; writes the canonical blueprint markdown from typed input and returns revision metadata
13
+ - `blueprint_transition` — optimistic-concurrency lifecycle transition; requires `expected_version` and returns updated revision metadata
14
+ - `blueprint_task_next` — return the next ready task; accepts optional `project_id` when the current cwd is a multi-repo workspace container
15
+ - `blueprint_task_advance` — change task status (non-`done`); requires `project_id` and `slug` (task ids are not unique across blueprints, so `slug` scopes the mutation to the right one), and accepts optional `request_id` and `head_at_ingest` for retry-safe mutation
16
+ - `blueprint_task_verify` — mark a task `done` with evidence; accepts optional `request_id` and `head_at_ingest` for retry-safe verification
17
+ - `blueprint_promote` / `blueprint_finalize` — accept optional `project_id` for nested-workspace disambiguation
18
18
 
19
19
  Guidance:
20
20
 
21
- - Prefer `project_id` from `wp_blueprint_projects` when multiple repos are visible.
21
+ - Prefer `project_id` from `blueprint_projects` when multiple repos are visible.
22
22
  - Use `request_id` for retry-safe mutations and reuse it only with the same payload.
23
23
  - Carry `head_at_ingest` from read/context tools into stale-write-sensitive mutations.
24
- - Author documents through `wp_blueprint_put`, then lifecycle with `wp_blueprint_transition`.
25
- - Deferred `wp_blueprint_patch` semantic ops (`add_task`, `update_task`, `set_summary`, `replace_decision`) are future layers; patch is **not** part of the v1 canonical surface.
26
- - MCP Apps editor support is a follow-on enhancement over `wp_blueprint_put` / `wp_blueprint_transition`.
24
+ - Author documents through `blueprint_put`, then lifecycle with `blueprint_transition`.
25
+ - Deferred `blueprint_patch` semantic ops (`add_task`, `update_task`, `set_summary`, `replace_decision`) are future layers; patch is **not** part of the v1 canonical surface.
26
+ - MCP Apps editor support is a follow-on enhancement over `blueprint_put` / `blueprint_transition`.
27
27
  - Hosts without MCP Apps support keep using the structured tools above.
package/commands/qa.md CHANGED
@@ -2,4 +2,4 @@
2
2
  description: Run lint + typecheck + tests in parallel via webpresso MCP
3
3
  ---
4
4
 
5
- Use the `wp_qa` tool to run lint, typecheck, and tests in parallel. No arguments required; the tool aggregates structured results from each sub-tool.
5
+ Use the `qa` tool to run lint, typecheck, and tests in parallel. No arguments required; the tool aggregates structured results from each sub-tool.
package/commands/test.md CHANGED
@@ -2,4 +2,4 @@
2
2
  description: Run tests via the webpresso MCP server
3
3
  ---
4
4
 
5
- Use the `wp_test` tool to run tests. Pass `packages` or `files` as arguments based on what the user asks for.
5
+ Use the `test` tool to run tests. Pass `packages` or `files` as arguments based on what the user asks for.
package/hooks/hooks.json CHANGED
@@ -13,7 +13,7 @@
13
13
  ],
14
14
  "PreToolUse": [
15
15
  {
16
- "matcher": "Grep|Read|Write|Edit|MultiEdit|Workflow|mcp__.*wp_session_(?:batch_)?execute$|mcp__.*(?:wp_blueprint_errata)$",
16
+ "matcher": "Grep|Read|Write|Edit|MultiEdit|Workflow|mcp__(?:plugin_[a-z0-9-]+_)?wp__session_(?:batch_)?execute$|mcp__(?:plugin_[a-z0-9-]+_)?wp__(?:blueprint_errata)$",
17
17
  "hooks": [
18
18
  {
19
19
  "type": "command",
package/package.json CHANGED
@@ -1,8 +1,8 @@
1
1
  {
2
2
  "name": "@webpresso/plugin-claude",
3
- "version": "0.0.14",
3
+ "version": "0.0.16",
4
4
  "private": false,
5
- "description": "Claude Code plugin adapter for Webpresso agent-kit skills, commands, and MCP runtime.",
5
+ "description": "Claude Code plugin adapter for the Webpresso app (wp CLI) skills, commands, and MCP runtime.",
6
6
  "homepage": "https://github.com/webpresso/app#readme",
7
7
  "bugs": {
8
8
  "url": "https://github.com/webpresso/app/issues"
@@ -2,14 +2,14 @@
2
2
  "schemaVersion": 1,
3
3
  "host": "claude",
4
4
  "packageName": "@webpresso/plugin-claude",
5
- "packageVersion": "0.0.14",
5
+ "packageVersion": "0.0.16",
6
6
  "runtimeDirs": [".claude/skills"],
7
7
  "skills": {
8
8
  "ai-deslop": {
9
9
  "digest": "sha256:cf07df5835037f10401400e220c1c923f5325a6149d59c231ce316e10595fdfc"
10
10
  },
11
11
  "autopilot": {
12
- "digest": "sha256:6a72b2db563a48742c501f20d509050f193a5d31f2d413f6bef838f277d470c1"
12
+ "digest": "sha256:8355f6ddc6e53e68ada49248bdd8d8beb0069ed09d3f2d346debc2401270445c"
13
13
  },
14
14
  "autoresearch": {
15
15
  "digest": "sha256:b4d51cd53beb4a3271827172dfbd0b1d27bd58761ca07a35d49a5d6324b87fdf"
@@ -21,19 +21,19 @@
21
21
  "digest": "sha256:21fd24862e7f7c8a1feadea6bc376492b136b99fc381cf1b8927c9db80615431"
22
22
  },
23
23
  "claude": {
24
- "digest": "sha256:0205d693121b740b76041f1e25925a70d665774f7493070cdd6df40d0058ffe6"
24
+ "digest": "sha256:63b7afb2b65f65fb142e5ef142f80516be00c54d449c5fa7d7897bcaa6cae657"
25
25
  },
26
26
  "codex": {
27
- "digest": "sha256:88837502404449b641b71dbc4f018c75dab6294ad98af29d41de50e98649ff0e"
27
+ "digest": "sha256:574669e040141e9986e362e9f46e3176aa47eccfda0f4589205d9d6d65e57b8d"
28
28
  },
29
29
  "deep-interview": {
30
- "digest": "sha256:79fbf86a86024a311583a1500bb6960c82ad1383cc9f8ed3f04bbace41848ff7"
30
+ "digest": "sha256:1d5bbb564dde9037722d2029f771afb52c2fe000a2b38822db430224cbe3407d"
31
31
  },
32
32
  "deep-research": {
33
33
  "digest": "sha256:ece766cb18869317d7c8992fc562920b03250ff8c44bdcb9eccdc3b21922a83f"
34
34
  },
35
35
  "delivery-program": {
36
- "digest": "sha256:ebd6b35036c12fa26ff98649ac57ede607b7b3526c401784670a5ce68369a691"
36
+ "digest": "sha256:a2222cc04fb5366026b951273e4e5d5d8c296d426d51706da8a6b56761a4567f"
37
37
  },
38
38
  "design-review": {
39
39
  "digest": "sha256:5b213735e2842568774572f36b198bccf03c03a54b2732484aadd023f04acb23"
@@ -42,22 +42,22 @@
42
42
  "digest": "sha256:306355888da0827e3523022077f731845726bbaaf595ca12515cc91d8605b5e6"
43
43
  },
44
44
  "fix": {
45
- "digest": "sha256:4804c546291316439aad3ea05fb7d3f043bc191abd8b9c180eb1d349f19f64cf"
45
+ "digest": "sha256:cf5d74995a690307ebbc3f6b017b03a0c2b395acecccb16dcfedbb9674d0f155"
46
46
  },
47
47
  "handoff": {
48
- "digest": "sha256:eda4410dc75019b40b1ffae5f301bfc1e57d9313241d170e4743d379a1b6d846"
48
+ "digest": "sha256:5d40899f54fabe3f6ec8f99b417345a433850585086570872a137a1d0d837002"
49
49
  },
50
50
  "hooks-doctor": {
51
- "digest": "sha256:9d9147e842246955f284854c35cf57237d4d056dca23f4c66019e1b44bb09eb6"
51
+ "digest": "sha256:0a32515ba42755847552991fe5dafe5bd9572a9540e7b376f56d8549320a4cf2"
52
52
  },
53
53
  "investigate": {
54
- "digest": "sha256:778b3a1f38323e8dd6101c6ace26ff8aada1246b20952b3641d5d1049bc50055"
54
+ "digest": "sha256:44578904d967161b9128830c7c66f9684bb8c8257e8da7884dd6dbda88743b39"
55
55
  },
56
56
  "lore-protocol": {
57
57
  "digest": "sha256:a80fbacc765e8b886437b9fdf7dd71e1ceb1b98b939078ec90fc88d06a8b4c69"
58
58
  },
59
59
  "opencode-go": {
60
- "digest": "sha256:a304b282fa078f97c2aa6a7d040d30eaae4c735de0aa5edf3af7368f62491804"
60
+ "digest": "sha256:9498e4f9d9c1b8ee2355d9ca57c65eaf2a3a9dbc2ba11ef0c4b0428769949f05"
61
61
  },
62
62
  "plan-ceo-review": {
63
63
  "digest": "sha256:4d426158518dd71f8998770e8d4037bcbfa3c65d7265a93a4a78a9b015ba881e"
@@ -72,31 +72,31 @@
72
72
  "digest": "sha256:b728dad90254d4c9f81b3818321d34ab53519b79ce20ff3bfe08bfacb2aa3e86"
73
73
  },
74
74
  "plan-refine": {
75
- "digest": "sha256:cf2c0743a81b0d8954417482e7812212a6a90e5046926c44cd82a6a309dfdc26"
75
+ "digest": "sha256:3dccc4e85ff7f355b1d7297b636d7acf3c31658b749fc1778ffdd1a255b27300"
76
76
  },
77
77
  "ralplan": {
78
- "digest": "sha256:d3e8ab6285f9882d18ee9feabf51bb6dd9d81f8aaa243c050e9eeaa3436927af"
78
+ "digest": "sha256:aa8879addccc19c0cdb69fce945fe54cf356380203f774080f8655211a5841c3"
79
79
  },
80
80
  "team": {
81
- "digest": "sha256:c27107b46e0cd7b9c264a6f51f74f505920d63e7ee2a2d26d2f288592fd10bd2"
81
+ "digest": "sha256:e403a5a92d145e777d7a344fe8fc6fe5df44640691aa2319b6dfd50b909166f5"
82
82
  },
83
83
  "tech-debt": {
84
- "digest": "sha256:2018bf8dc5f338baee3d982a5bf28c48773befea08e44f33b70561c18d897c56"
84
+ "digest": "sha256:fd2f8e26e006c9c5ed5ef6f1678c3f7472a35dfd2f743e58f7ec348606399353"
85
85
  },
86
86
  "testing-philosophy": {
87
87
  "digest": "sha256:23fdad944b089de3cfcd13957a5ac10c37bd3d136b192029af69368bca1470db"
88
88
  },
89
89
  "tooling-friction": {
90
- "digest": "sha256:64992c6a789d0283b7379a914d7686af5db97fe48cb5929f800a11d8f8e8f126"
90
+ "digest": "sha256:7f6e60a2c886e0c735135ab66926fbbd1b54d9291036fb0ddea020c7754f1534"
91
91
  },
92
92
  "tph": {
93
93
  "digest": "sha256:bed3684a850651534f315d355cdeae50d951c429817df0f105cccdb7f4e1561b"
94
94
  },
95
95
  "ultragoal": {
96
- "digest": "sha256:344177e32690fe6355577abe50659cea1af682933a78eb13a11765d1a1ad66d7"
96
+ "digest": "sha256:8826e955c3a68f962d73a4b476d952574fa32e802c0d2616d569e58e7cfc29c3"
97
97
  },
98
98
  "verify": {
99
- "digest": "sha256:bb9144c18983cea1b2be6f193dadadbf9f0f638021385a4aad7de390e520e281"
99
+ "digest": "sha256:e1aa3baed96ef005b144e17fac8a2153b90a075b142acee2fdfba7c89e613765"
100
100
  }
101
101
  }
102
102
  }
@@ -21,11 +21,11 @@ argument-hint: "<brief|force: brief>"
21
21
  - parallel ready-set execution under ultragoal controller
22
22
 
23
23
  Drive an approved brief through `plan -> execute -> qa -> validate -> land -> complete`
24
- using `wp_ultragoal_run` / `wp ultragoal run` and the current handoff.
24
+ using `ultragoal_run` / `wp ultragoal run` and the current handoff.
25
25
 
26
26
  ## Outside-voice (required)
27
27
 
28
- After each ultragoal **phase or plan-gate milestone**, run an **OpenCode Go** outside-voice review and pick the model by purpose. The purpose→family ordering lives in one place — the committed reviewer policy rendered into the `opencode-go` skill — so follow that skill and do not restate the ordering here. Resolve IDs from live `opencode models opencode-go`. `wp_review_gate` has one mode: purpose plan for exact-version draft plan approval/auto-promotion, purpose delivery for implementation/phase review; each new provider verdict is a formal round and an approval is authority immediately. Never self-approve. Full protocol: the `ultragoal` skill. Respect `review_budget` (default owned by `workflow-skills-routing.md`): one sequential path, no multi-host stampede.
28
+ After each ultragoal **phase or plan-gate milestone**, run an outside-voice review. Pass `caller_model` with your own model id and omit `provider`/`model`/`effort`: the gate selects the cross-family reviewer route itself (capability, limits, measured daily cost) and reports it in `policy_selection`. Never resolve model ids from a live catalog at invocation time. `review_gate` has one mode: purpose plan for exact-version draft plan approval/auto-promotion, purpose delivery for implementation/phase review; each new provider verdict is a formal round and an approval is authority immediately. Never self-approve. Full protocol: the `ultragoal` skill. Respect `review_budget` (default owned by `workflow-skills-routing.md`): one sequential path, no multi-host stampede.
29
29
 
30
30
  ## Vague gate
31
31
 
@@ -45,23 +45,23 @@ skill.
45
45
 
46
46
  ## Tooling map
47
47
 
48
- | Pipeline step | Tools |
49
- | -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- |
50
- | Plan | `plan-refine`, `wp_blueprint_*`, `wp_session_capture` for decisions |
51
- | Create controller | `wp_ultragoal_new`, `wp_worktree` |
52
- | Execute | ready-set via blueprint tools; `/goal` or parallel subagents; `wp_session_context` for delegates; `wp_blueprint_task_verify` only to complete tasks |
53
- | Opportunistic repair | `/fix` up to `fix_budget`; else handoff backlog |
54
- | QA | `wp_qa` / `wp_lint` / `wp_typecheck` / `wp_test`; PR checks via `wp_pr_status` / `wp_pr_wait` |
55
- | Validate | one outside voice if merge-bound (OpenCode Go by purpose, or claude/codex); `wp review gate` for authority |
56
- | Land | `wp_pr_upsert`, green required checks, merge + owner cleanup |
57
- | Blocked / stop | `wp_ultragoal_handoff` ≤40 lines; `wp_ultragoal_cancel` if abandoned |
48
+ | Pipeline step | Tools |
49
+ | -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
50
+ | Plan | `plan-refine`, `blueprint_*`, `session_capture` for decisions |
51
+ | Create controller | `ultragoal_new`, `worktree` |
52
+ | Execute | ready-set via blueprint tools; `/goal` or parallel subagents; `session_context` for delegates; `blueprint_task_verify` only to complete tasks |
53
+ | Opportunistic repair | `/fix` up to `fix_budget`; else handoff backlog |
54
+ | QA | `qa` / `lint` / `typecheck` / `test`; PR checks via `pr_status` / `pr_wait` |
55
+ | Validate | one outside voice if merge-bound (the gate picks the cross-family reviewer from `caller_model`); `wp review gate` for authority |
56
+ | Land | `pr_upsert`, green required checks, merge + owner cleanup |
57
+ | Blocked / stop | `ultragoal_handoff` ≤40 lines; if the send channel is capped, the handoff records send-budget state (attempt count, last canary result); judgment requests ride the typed envelope or are named in the manifest; preserve the outbox, never route around a pause; `ultragoal_cancel` if abandoned |
58
58
 
59
59
  ## Pipeline
60
60
 
61
61
  1. **Plan:** refine blueprints and satisfy provenance-backed promotion approvals.
62
62
  2. **Execute:** implement current **ready** tasks in parallel up to `concurrency`; use only
63
- `wp_blueprint_task_verify` to mark them done.
64
- 3. **QA:** run affected checks and `wp_qa`; preserve normalized failure evidence. Prefer
63
+ `blueprint_task_verify` to mark them done.
64
+ 3. **QA:** run affected checks and `qa`; preserve normalized failure evidence. Prefer
65
65
  PR-bound CI when a PR exists.
66
66
  4. **Validate:** obtain verification + code-review evidence within `review_budget`. Each
67
67
  lane appends a tracked `reviews.md` record in one of these exact forms:
@@ -73,10 +73,10 @@ skill.
73
73
 
74
74
  5. **Land:** require green PR checks, complete the blueprint in the same PR, merge, and
75
75
  run owner cleanup.
76
- 6. **Complete:** stop only when `wp_ultragoal_run` records terminal evidence.
76
+ 6. **Complete:** stop only when `ultragoal_run` records terminal evidence.
77
77
 
78
78
  Resume from durable state after interruption. Obey `WP_ULTRAGOAL_DISABLE=1`,
79
79
  iteration/error/validation caps, and repository ownership. Never self-approve, directly
80
80
  mark tasks done, bypass evidence, push to main, or increase timeouts (keep every loop bounded and never increase timeouts). After every phase
81
- transition recorded by `wp ultragoal run`, obtain a fresh OpenCode Go outside review
81
+ transition recorded by `wp ultragoal run`, obtain a fresh outside-voice review
82
82
  before treating the milestone as closed (see Outside-voice above and the `ultragoal` skill).
@@ -11,8 +11,8 @@ until independently verified.
11
11
 
12
12
  ## MCP-only contract
13
13
 
14
- - Call `wp_review_gate` exactly once for the real plan version or delivery diff.
15
- - Observe the same durable operation with `wp_review_gate_wait` when needed.
14
+ - Call `review_gate` exactly once for the real plan version or delivery diff.
15
+ - Observe the same durable operation with `review_gate_wait` when needed.
16
16
  - Never invoke a provider command, the legacy review CLI, or a removed review-run surface.
17
17
  - If the review MCP is unavailable, stop and report it unavailable. There is no CLI fallback.
18
18
 
@@ -25,7 +25,7 @@ until independently verified.
25
25
  "purpose": "delivery",
26
26
  "base_ref": "<full-base-sha>",
27
27
  "authority_ref": "<full-head-sha>",
28
- "provider": "claude",
28
+ "caller_model": "<your own model id, exactly as your host reports it>",
29
29
  "repository_access": "none",
30
30
  }
31
31
  ```
@@ -36,10 +36,15 @@ verdict with no new review and no new round. A partial approval, withheld becaus
36
36
  is incomplete (not every prior finding was briefed, or a briefed prior claim was marked
37
37
  still-open without a matching finding), grants no authority and spends no round.
38
38
 
39
- ## Model policy
39
+ ## Reviewer selection
40
40
 
41
- When the user names an exact model, pass it in the MCP `model` field. Otherwise omit
42
- that field and let the MCP owner select the configured provider default.
41
+ Pass `caller_model` with your OWN model id, exactly as your host reports it, and omit
42
+ `provider`, `model`, and `effort`: the gate selects the reviewer route itself — a cross-family
43
+ reviewer chosen for capability, current provider limits, and measured daily cost — and reports
44
+ the choice in `policy_selection`. Never name a reviewer model, probe a provider CLI for its
45
+ catalog, or read a credential store to discover models at invocation time; provider catalog
46
+ discovery belongs to the snapshot drift workflow. An operator may still pass an explicit
47
+ `provider`/`model` as a human override; agents must not.
43
48
 
44
49
  ## Review quality
45
50
 
@@ -11,8 +11,8 @@ until independently verified.
11
11
 
12
12
  ## MCP-only contract
13
13
 
14
- - Call `wp_review_gate` exactly once for the real plan version or delivery diff.
15
- - Observe the same durable operation with `wp_review_gate_wait` when needed.
14
+ - Call `review_gate` exactly once for the real plan version or delivery diff.
15
+ - Observe the same durable operation with `review_gate_wait` when needed.
16
16
  - Never invoke a provider command, the legacy review CLI, or a removed review-run surface.
17
17
  - If the review MCP is unavailable, stop and report it unavailable. There is no CLI fallback.
18
18
 
@@ -25,7 +25,7 @@ until independently verified.
25
25
  "purpose": "delivery",
26
26
  "base_ref": "<full-base-sha>",
27
27
  "authority_ref": "<full-head-sha>",
28
- "provider": "codex",
28
+ "caller_model": "<your own model id, exactly as your host reports it>",
29
29
  "repository_access": "none",
30
30
  }
31
31
  ```
@@ -36,10 +36,15 @@ verdict with no new review and no new round. A partial approval, withheld becaus
36
36
  is incomplete (not every prior finding was briefed, or a briefed prior claim was marked
37
37
  still-open without a matching finding), grants no authority and spends no round.
38
38
 
39
- ## Model policy
39
+ ## Reviewer selection
40
40
 
41
- When the user names an exact model, pass it in the MCP `model` field. Otherwise omit
42
- that field and let the MCP owner select the configured provider default.
41
+ Pass `caller_model` with your OWN model id, exactly as your host reports it, and omit
42
+ `provider`, `model`, and `effort`: the gate selects the reviewer route itself — a cross-family
43
+ reviewer chosen for capability, current provider limits, and measured daily cost — and reports
44
+ the choice in `policy_selection`. Never name a reviewer model, probe a provider CLI for its
45
+ catalog, or read a credential store to discover models at invocation time; provider catalog
46
+ discovery belongs to the snapshot drift workflow. An operator may still pass an explicit
47
+ `provider`/`model` as a human override; agents must not.
43
48
 
44
49
  ## Review quality
45
50
 
@@ -59,7 +59,7 @@ Max rounds is a hard cap, not a target. Do not continue only to reach a round co
59
59
  - 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.
60
60
  - 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.
61
61
  - Before crystallizing, complete at least one explicit pressure pass that revisits an earlier answer with a deeper, assumption- or tradeoff-focused follow-up.
62
- - Gather codebase facts via local search tools, `wp_session_*` retrieval, and read-only repo inspection before asking the user about internals.
62
+ - Gather codebase facts via local search tools, `session_*` retrieval, and read-only repo inspection before asking the user about internals.
63
63
  - Always run a preflight context intake before the first question.
64
64
  - 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.
65
65
  - 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
82
82
  ## Phase 0: Preflight Context Intake
83
83
 
84
84
  1. Parse `{{ARGUMENTS}}` and derive a short kebab-case task slug.
85
- 2. Attempt to load the latest relevant context for the slug from session memory via the `wp_session_search`/`wp_session_retrieve` MCP tools.
85
+ 2. Attempt to load the latest relevant context for the slug from session memory via the `session_search`/`session_retrieve` MCP tools.
86
86
  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.
87
87
  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.
88
88
  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.
89
- 6. Capture the snapshot into session memory via `wp_session_capture` (tagged with the slug) and reference it in the interview state.
89
+ 6. Capture the snapshot into session memory via `session_capture` (tagged with the slug) and reference it in the interview state.
90
90
 
91
91
  ## Phase 1: Initialize
92
92
 
93
93
  1. Parse `{{ARGUMENTS}}` and the depth profile (`--quick|--standard|--deep`).
94
94
  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.
95
- 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`.
95
+ 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`.
96
96
  4. Announce kickoff with the profile, threshold, and current ambiguity.
97
97
 
98
98
  ## Phase 2: Socratic Interview Loop
@@ -178,7 +178,7 @@ Show the weighted breakdown table, readiness-gate status (`Non-goals`, `Decision
178
178
 
179
179
  ### 2e) Persist state
180
180
 
181
- Append the round result and updated scores to the slug-tagged interview state in session memory (`wp_session_capture`).
181
+ Append the round result and updated scores to the slug-tagged interview state in session memory (`session_capture`).
182
182
 
183
183
  ### 2f) Round controls
184
184
 
@@ -203,9 +203,9 @@ Track used modes in state to prevent repetition.
203
203
 
204
204
  When the threshold is met (or the user exits with warning / hard cap):
205
205
 
206
- 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.
206
+ 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.
207
207
  2. Write the interview transcript summary to `blueprints/draft/{slug}/interview.md`.
208
- 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`.
208
+ 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`.
209
209
 
210
210
  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.
211
211
 
@@ -219,7 +219,7 @@ Present execution options after artifact generation using explicit handoff contr
219
219
  - **`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.
220
220
  - **`ultragoal`** — when the clarified work should become durable, sequentially tracked goal-mode work.
221
221
  - **`team`** — when the task is large, multi-lane, or blocker-sensitive enough to justify coordinated parallel execution.
222
- - **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.
222
+ - **Blueprint lifecycle** — refine with `blueprint_put`, review the exact version with `review_gate`, and inspect the auto-promoted result with `blueprint_get` when work should enter planned execution directly.
223
223
  - **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.
224
224
 
225
225
  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
232
232
 
233
233
  <Tool_Usage>
234
234
 
235
- - Use local search tools, `wp_session_*` retrieval, and read-only repo inspection for codebase fact gathering.
235
+ - Use local search tools, `session_*` retrieval, and read-only repo inspection for codebase fact gathering.
236
236
  - 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.
237
- - Keep context snapshots and resumable interview state in session memory via the `wp_session_*` MCP tools, tagged with the task slug.
237
+ - Keep context snapshots and resumable interview state in session memory via the `session_*` MCP tools, tagged with the task slug.
238
238
  - 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.
239
- - Land transcript artifacts in the active task's blueprint folder; create/update `_overview.md` only through `wp_blueprint_put`.
239
+ - Land transcript artifacts in the active task's blueprint folder; create/update `_overview.md` only through `blueprint_put`.
240
240
  - Use `best-practice-research` when unresolved ambiguity depends on current external/upstream guidance.
241
241
  </Tool_Usage>
242
242
 
@@ -250,7 +250,7 @@ For research-shaped requests (a research question, evaluator-backed analysis, or
250
250
 
251
251
  <Final_Checklist>
252
252
 
253
- - [ ] Preflight context snapshot captured to session memory (`wp_session_capture`, slug-tagged)
253
+ - [ ] Preflight context snapshot captured to session memory (`session_capture`, slug-tagged)
254
254
  - [ ] Oversized initial context, if present, has a prompt-safe summary before scoring or handoff
255
255
  - [ ] Ambiguity score shown each round
256
256
  - [ ] Intent-first stage priority used before implementation detail
@@ -260,7 +260,7 @@ For research-shaped requests (a research question, evaluator-backed analysis, or
260
260
  - [ ] Challenge modes triggered at thresholds (when applicable)
261
261
  - [ ] `Non-goals` and `Decision Boundaries` explicit before handoff
262
262
  - [ ] Transcript written to `blueprints/draft/{slug}/interview.md`
263
- - [ ] Spec folded into `blueprints/draft/{slug}/_overview.md` through `wp_blueprint_put`
263
+ - [ ] Spec folded into `blueprints/draft/{slug}/_overview.md` through `blueprint_put`
264
264
  - [ ] Brownfield questions use evidence-backed confirmation and doc grounding when applicable
265
265
  - [ ] Fuzzy/conflicting terminology challenged against repo language when applicable
266
266
  - [ ] Handoff options provided (`ralplan`, `autopilot`, `ultragoal`, `team`, blueprint lifecycle)
@@ -28,14 +28,14 @@ Child membership comes only from `parent_roadmap`; do not maintain a second list
28
28
 
29
29
  ## Loop
30
30
 
31
- 1. Call `wp_delivery_status({ slug })`.
31
+ 1. Call `delivery_status({ slug })`.
32
32
  2. Treat its `version`, blockers, and exact returned action as the current derived
33
33
  truth. Do not reconstruct state from transcripts.
34
- 3. Dispatch only returned `wp_worktree` actions. Child work starts from the
34
+ 3. Dispatch only returned `worktree` actions. Child work starts from the
35
35
  delivery branch and child PRs target that branch.
36
36
  4. Integrate at most one child at a time. Recheck status immediately before
37
- calling `wp_pr_merge` with the exact returned head SHA.
38
- 5. An `enqueued` merge is not integrated. Call `wp_delivery_status` again and
37
+ calling `pr_merge` with the exact returned head SHA.
38
+ 5. An `enqueued` merge is not integrated. Call `delivery_status` again and
39
39
  wait for the merged postcondition.
40
40
  6. After every child PR is merged, verify the delivery branch and land its final
41
41
  PR to `delivery_base` through the same exact-SHA merge tool.
@@ -31,26 +31,26 @@ the blast radius is broader than a local fix.
31
31
 
32
32
  ## Tooling map
33
33
 
34
- | Need | Prefer |
35
- | ---------------------- | --------------------------------------------------------------------------- |
36
- | Reproduce / large logs | `wp_session_execute`, `wp_session_batch_execute`, `wp_session_execute_file` |
37
- | Recall prior evidence | `wp_session_search`, `wp_session_restore`, `wp_session_retrieve` |
38
- | Capture decisions | `wp_session_capture` (do not paste full reports back as user text) |
39
- | Scoped proof | `wp_test`, `wp_lint`, `wp_typecheck`, or `wp_qa` |
40
- | Audits | `wp_audit` / `wp_audits` |
41
- | Worktree isolation | `wp_blueprint_put` / `wp_worktree` — never thrash primary checkout |
42
- | PR follow-up | `wp_pr_status`, `wp_pr_upsert` when landing the fix |
34
+ | Need | Prefer |
35
+ | ---------------------- | ------------------------------------------------------------------ |
36
+ | Reproduce / large logs | `session_execute`, `session_batch_execute`, `session_execute_file` |
37
+ | Recall prior evidence | `session_search`, `session_restore`, `session_retrieve` |
38
+ | Capture decisions | `session_capture` (do not paste full reports back as user text) |
39
+ | Scoped proof | `test`, `lint`, `typecheck`, or `qa` |
40
+ | Audits | `audit` / `audits` |
41
+ | Worktree isolation | `blueprint_put` / `worktree` — never thrash primary checkout |
42
+ | PR follow-up | `pr_status`, `pr_upsert` when landing the fix |
43
43
 
44
44
  ## Non-negotiable invariants
45
45
 
46
46
  1. **Root cause, not symptom.** Trace the failure to the invariant that actually broke. Do not patch callers when the owner is fixable.
47
47
  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.
48
- 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.
48
+ 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.
49
49
  4. **Regression proof is mandatory.** Add or strengthen a test or other reliable proof that would fail against the old behavior.
50
50
  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.
51
51
  6. **Zero suppressions, zero papering over.** No lint disables, ts-ignore, compat aliases, or "temporary" branches to sneak the fix through.
52
52
  7. **Minimal correct diff.** Update every consumer of a changed contract in the same change, but do not bundle unrelated cleanup.
53
- 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.
53
+ 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.
54
54
 
55
55
  ## Opportunistic fix budget (when called from ultragoal / autopilot)
56
56
 
@@ -61,7 +61,7 @@ the blast radius is broader than a local fix.
61
61
  - **Tooling / harness findings** ("fix inefficiency you come across", MCP vs shell,
62
62
  hook thrash) honor the same budget. Excess → record via the `tech-debt` skill
63
63
  (or backlog handoff); do not expand the current epic unbounded.
64
- - Prefer MCP `wp_*` and session-memory tools over the `wp` CLI / raw shell for
64
+ - Prefer wp MCP tools and session-memory tools over the `wp` CLI / raw shell for
65
65
  quality and discovery paths (see tooling map).
66
66
 
67
67
  ## Protocol
@@ -130,10 +130,10 @@ Do not keep production code written before the test as "reference". If you wrote
130
130
 
131
131
  Run the narrowest checks that prove the repaired behavior on the real repo surface:
132
132
 
133
- - `wp_test` / targeted tests for the repaired path
134
- - `wp_lint` / `wp_typecheck` for changed surfaces
135
- - `wp_qa` only when the blast radius needs the bookend
136
- - Before push: start `wp_ci_preflight`, then poll `wp_ci_preflight_wait` with
133
+ - `test` / targeted tests for the repaired path
134
+ - `lint` / `typecheck` for changed surfaces
135
+ - `qa` only when the blast radius needs the bookend
136
+ - Before push: start `ci_preflight`, then poll `ci_preflight_wait` with
137
137
  its run ID until terminal success (use global `wp ci-preflight` only when MCP
138
138
  is unavailable). Run it after the final commit and do not edit or commit again
139
139
  before pushing: terminal success records the exact-state receipt checked by pre-push.
@@ -141,7 +141,7 @@ Run the narrowest checks that prove the repaired behavior on the real repo surfa
141
141
 
142
142
  Rules:
143
143
 
144
- - Prefer MCP `wp_*` over raw host Bash.
144
+ - Prefer wp MCP tools over raw host Bash.
145
145
  - Reuse fresh logs / session-memory indexed output; do not re-run long commands just to re-read.
146
146
  - Read the exit code and summary before making a claim.
147
147
  - Never `git push --no-verify` to land an unproven fix.
@@ -158,7 +158,7 @@ cleanup pass, use `ai-deslop` before the final verify handoff.
158
158
 
159
159
  ### Tool recovery and delivery intent
160
160
 
161
- - Discover the managed owner's current identity with `wp_blueprint_projects`
161
+ - Discover the managed owner's current identity with `blueprint_projects`
162
162
  using its absolute `cwd`; pass the returned project ID and matching checkout
163
163
  to session tools. A blueprint ID is not a project ID.
164
164
  - If quality tooling refuses stale or cross-checkout execution, follow its