@squadrules/mcp 5.11.0 → 5.12.1

package/dist/embed-docs/mem/challenge-type-guide.md

@@ -1,21 +1,18 @@
 ---
-version: "5.11.0"
+version: "5.12.1"
 slug: challenge-type-guide
 title: Challenge Type Selection Guide
 ---
 
-
-
 # Challenge Type Selection Guide
 
 Decision rules, JSON formats, interpreter selection, and anti-patterns for
-choosing SQUADRULES challenge types. Loaded by protocol-authoring agents during
+choosing SQUADRULES challenge types. Loaded by adapter-authoring agents during
 drafting and review.
 
 ## Activation Patterns
 
-**Typically invoked by:** `author-adapter` and
-`critic-loop`.
+**Typically invoked by:** `author-adapter` and `critic-loop`.
 
 **Can be invoked directly when agent needs:**
 - "challenge type reference" / "which challenge type to use"
@@ -25,31 +22,31 @@ drafting and review.
 **Trigger pattern:** **challenge** + (type | format | selection | guide).
 
 **Must Never:**
-- Be used as an execution protocol.
+- Be used as an execution adapter.
 - Select `comment` merely because it is easy.
 
 **Must Always:**
-- Be consulted before assigning challenge types to protocol steps.
+- Be consulted before assigning challenge types to adapter steps.
 - Choose the strongest observable contract available.
 - Match challenge choice to the mode of the step: ask, decide, act, verify, or review.
 
 **Good trigger examples:**
-- drafting a new protocol and need challenge types → load this
+- drafting a new adapter and need challenge types → load this
 - reviewing challenge type selection in a draft → load this
 
 **Bad trigger examples:**
-- "Create a new protocol" → use `author-adapter`
-- "Review my protocol draft" → use `critic-loop`
+- "Create a new adapter" → use `author-adapter`
+- "Review my adapter draft" → use `critic-loop`
 
 ## Core Rules
 
 `comment` is the challenge type of **last resort**. If a step produces any
 observable artifact — a file, a git state change, an API response, or an exit
-code — use `shell` or `mcp` instead.
+code — use `shell` or `subagent` instead.
 
 **Mode before challenge type:**
 - **clarify / approve** → `user_input`
-- **call a SQUADRULES / MCP tool** → `mcp`
+- **chain to another adapter** → `mcp` (forward-link only)
 - **execute or verify local state** → `shell`
 - **delegate to another agent** → `subagent`
 - **pure reasoning with no observable artifact** → `comment`
@@ -57,63 +54,59 @@ code — use `shell` or `mcp` instead.
 ### Decision Tree
 
 ```
-Does the step call an MCP tool?
- ├─ YES → Is the step a chain link to another adapter?
- │         ├─ YES → "mcp" with tool_name + arguments (forward + slug URI)
- │         └─ NO  → "mcp" with tool_name only
+Does the step chain to another adapter via forward?
+ ├─ YES → "mcp" forward-link (tool_name: "forward", arguments.uri: squadrules://adapter/<slug>)
  └─ NO → Does the step produce or verify a file, command result, or system state?
-          ├─ YES → "shell"
+          ├─ YES → "shell" (with interpreter)
           └─ NO → Does the step require human approval or choice?
                    ├─ YES → "user_input"
                    └─ NO → Does the step delegate work to another agent?
-                            ├─ YES → "subagent" with optional context
-                            └─ NO → "comment" only if there is no stronger observable contract
+                            ├─ YES → "subagent"
+                            └─ NO → "comment" (last resort — no stronger contract possible)
 ```
 
 ### Challenge JSON Formats
 
-**shell**
+**shell** (interpreter is REQUIRED)
 ```json
-{"contract":{"type":"shell","shell":{"cmd":"<command>","timeout_seconds":30},"required":true}}
+{"contract":{"type":"shell","shell":{"cmd":"<command>","interpreter":"bash","timeout_seconds":30},"required":true}}
 ```
 
-**mcp**
-```json
-{"contract":{"type":"mcp","mcp":{"tool_name":"<tool>"},"required":true}}
-```
+Allowed interpreters: `bash`, `sh`, `python3`, `python`, `node`. Build tools
+(`terraform`, `docker`, `npm`, etc.) are **not** interpreters — wrap them in a
+`bash` command instead.
 
-**mcp with arguments (chain link)**
+**mcp** (forward-link only — bare tool_name checks are not valid)
 ```json
 {"contract":{"type":"mcp","mcp":{"tool_name":"forward","arguments":{"uri":"squadrules://adapter/<slug>"}},"required":true}}
 ```
 
-Use the `arguments` form when the step's purpose is to invoke a specific
-adapter via `forward`. The server validates that `solution.mcp.arguments`
-is a superset of the contract's `mcp.arguments` (subset/deep matching),
-proving the agent called the correct target — not just any `forward` call.
+The server validates that `solution.mcp.arguments` is a superset of the
+contract's `mcp.arguments` (subset/deep matching), proving the agent called
+`forward` with the correct target slug.
 
 **user_input**
 ```json
 {"contract":{"type":"user_input","user_input":{"prompt":"<specific question>"},"required":true}}
 ```
 
-**comment**
-```json
-{"contract":{"type":"comment","comment":{"min_length":50},"required":true}}
-```
-
 **subagent**
 ```json
-{"contract":{"type":"subagent","subagent":{"context":"<task description>"},"required":true}}
+{"contract":{"type":"subagent","subagent":{"instruction":"<task description>"},"required":true}}
 ```
 
 Use `subagent` when a step delegates work to another agent (human or AI) rather
-than executing it directly. The optional `context` field provides task-specific
+than executing it directly. The `instruction` field provides task-specific
 guidance. Evidence of completion is collected via the anti-cheat evidence gate.
 
+**comment** (last resort — max 1 per adapter, closing ACK only)
+```json
+{"contract":{"type":"comment","comment":{"min_length":50},"required":true}}
+```
+
 ### Solution JSON Formats
 
-Every solution, regardless of type, follows the same envelope:
+Every solution follows the same envelope:
 
 ```json
 {
@@ -127,84 +120,43 @@ Every solution, regardless of type, follows the same envelope:
 
 **shell solution**
 ```json
-{
-  "type": "shell",
-  "outcome": "success",
-  "evidence": {
-    "exit_code": 0,
-    "stdout": "...",
-    "stderr": "",
-    "duration_seconds": 1.2
-  }
-}
+{"type":"shell","outcome":"success","evidence":{"exit_code":0,"stdout":"...","stderr":"","duration_seconds":1.2}}
 ```
 
 **mcp solution**
 ```json
-{
-  "type": "mcp",
-  "outcome": "success",
-  "evidence": {
-    "tool_name": "activate",
-    "arguments": { "query": "example search" },
-    "response": { "choices": [...] }
-  }
-}
+{"type":"mcp","outcome":"success","evidence":{"tool_name":"forward","arguments":{"uri":"squadrules://adapter/critic-loop"},"response":{}}}
 ```
 
-**user_input solution**
+**subagent solution**
 ```json
-{
-  "type": "user_input",
-  "outcome": "success",
-  "evidence": {
-    "confirmation": "agreed. proceed",
-    "timestamp": "2026-05-18T14:49:00Z"
-  }
-}
+{"type":"subagent","outcome":"success","evidence":{"agent_id":"agent-uuid","artifacts":["path/to/output"],"summary":"Task completed"}}
 ```
 
 **comment solution**
 ```json
-{
-  "type": "comment",
-  "outcome": "success",
-  "evidence": {
-    "text": "Verified all 78 issues now have repo: labels."
-  }
-}
+{"type":"comment","outcome":"success","evidence":{"text":"Verified all items are complete."}}
 ```
 
-**subagent solution**
+**user_input solution**
 ```json
-{
-  "type": "subagent",
-  "outcome": "success",
-  "evidence": {
-    "agent_id": "agent-uuid-or-name",
-    "artifacts": ["path/to/output"],
-    "summary": "Task completed successfully"
-  }
-}
+{"type":"user_input","outcome":"success","evidence":{"confirmation":"agreed. proceed","timestamp":"2026-05-18T14:49:00Z"}}
 ```
 
 ## Interpreter Selection
 
-| Task | Use bash | Use perl | Use python3 |
-|---|---|---|---|
-| File exists, tool installed, git state | yes | no | no |
-| Simple content grep | yes | no | no |
-| Multi-line regex | no | yes | no |
-| Paragraph processing | no | yes | no |
-| JSON validation | maybe | yes | yes |
-| YAML / complex data structure checks | no | no | yes |
+| Task | Interpreter |
+|---|---|
+| File exists, tool installed, git state | `bash` |
+| Simple content grep | `bash` |
+| Multi-line regex or paragraph processing | `python3` |
+| JSON validation | `bash` (jq) or `python3` |
+| YAML / complex data structure checks | `python3` |
+| Node.js ecosystem tools | `node` |
 
-**Rule of thumb:** if bash requires `while read`, `grep | awk`, or heavy quote
-escaping, rewrite in Perl. If you need imports for data formats, use Python.
-
-```json
-{"contract":{"type":"comment","comment":{"min_length":30},"required":true}}
-```
+**Rule of thumb:** default to `bash`. If you need multi-line regex, imports for
+data formats, or complex string processing, use `python3`. Use `node` only when
+the check requires the Node.js runtime.
 
 ## Security and Working Directory Rules
 
@@ -216,148 +168,79 @@ to avoid collisions between parallel sessions.
 - all file paths in shell challenges reference variables (e.g., `$DRAFT_FILE`,
   `$VERDICT_FILE`) set by the parent agent — never hardcode filenames
 - the parent agent constructs collision-free paths under
-  `$SQUADRULES_LOCAL_ARTIFACT_DIR` (e.g., with a session ID or random suffix)
-- when using SQUADRULES MCP, the latest `activate` / `forward` / `next` response field `squadrules_local_artifact_dir` is an ordered array of URI hints (`project://<rel>`, `user://<rel>`); pick one (`project://` when you have exactly one project context, otherwise `user://`), resolve on your machine, and `export SQUADRULES_LOCAL_ARTIFACT_DIR="<absolute>"` if your shell does not already define it
-- if the server-returned path is not usable on your local filesystem, resolve
-  locally to `$PROJECT_DIR/.local/squadrules/work` and keep it stable for the run
-- prerequisites create the directory
-- Reward Signal cleans it up
+  `$SQUADRULES_LOCAL_ARTIFACT_DIR`
+- when using SQUADRULES MCP, the latest `activate` / `forward` / `next` response
+  field `squadrules_local_artifact_dir` is an ordered array of URI hints
+  (`project://<rel>`, `user://<rel>`); pick one, resolve on your machine, and
+  `export SQUADRULES_LOCAL_ARTIFACT_DIR="<absolute>"`
+- prerequisites create the directory; Reward Signal cleans it up
 - never write credentials or secrets to files
 
 ### Resolving `project://` and `user://` URI hints
 
-The server returns relative URI hints — it never names an absolute path on its
-own filesystem. Resolve on your machine:
-
 | Scheme | Resolution | Example |
 |--------|-----------|--------|
-| `project://<rel>` | `<IDE project root>/<rel>` | `project://.local/squadrules/work` → `/home/user/repos/my-project/.local/squadrules/work` |
-| `user://<rel>` | `<$XDG_CONFIG_HOME or $HOME>/<rel>` | `user://.config/squadrules/work` → `/home/user/.config/squadrules/work` |
+| `project://<rel>` | `<IDE project root>/<rel>` | `project://.local/squadrules/work` |
+| `user://<rel>` | `<$XDG_CONFIG_HOME or $HOME>/<rel>` | `user://.config/squadrules/work` |
 
-When your session spans multiple projects, prefer `user://` to avoid ambiguity
-about which project root applies. When you have exactly one project context,
-`project://` is fine.
+When your session spans multiple projects, prefer `user://` to avoid ambiguity.
 
 ### Worktree placement (for task-isolation adapters)
 
 When an adapter requires a git worktree for isolation, the worktree path MUST
-be **outside** every existing checkout. A common mistake is placing the worktree
-inside `$REPO_ROOT` (e.g. `$REPO_ROOT/.mcp.worktrees/...`), which the setup
-script correctly rejects.
-
-**Correct placement — absolute path examples:**
+be **outside** every existing checkout:
 
 ```
 REPO_ROOT=/home/user/repos/my-project
-# RIGHT: sibling of the repo, not inside it
+# RIGHT: sibling of the repo
 WT=/home/user/repos/mcp.worktrees/<task-id>
-
-# WRONG: inside the checkout (rejected by setup script)
+# WRONG: inside the checkout
 # WT=/home/user/repos/my-project/.mcp.worktrees/<task-id>
 ```
 
-**Common mistakes:**
-- `$REPO_ROOT/.mcp.worktrees/...` — inside checkout, rejected
-- `./mcp.worktrees/...` — relative path resolves inside checkout
-- `$REPO_ROOT/../mcp.worktrees/...` — correct only if `..` actually exits the repo
-
 **Rule of thumb:** `$(dirname "$REPO_ROOT")/mcp.worktrees/<task-id>`
 
 ### IDE worktree access limitations
 
-Most IDE file tools (Write, Read, Edit) scope operations to the open project
-root. They **cannot** reach worktrees placed outside `$REPO_ROOT`. When working
-in an IDE:
+Most IDE file tools scope operations to the open project root. They **cannot**
+reach worktrees placed outside `$REPO_ROOT`. Use the terminal/shell tool for
+external worktrees, or open the worktree as a separate project window.
 
-1. Use the **terminal/shell tool** (not IDE file tools) to read/write files in
-   external worktrees.
-2. Shell commands: `cat`, `tee`, `cp`, or your editor's CLI mode work on any
-   absolute path.
-3. If you need to edit a worktree file with IDE assistance, open the worktree
-   as a separate project window or use `code <worktree-path>` to add it to the
-   workspace.
-4. The `squadrules export` MCP tool can retrieve adapter content without
-   filesystem access to the worktree.
+## Composition Patterns
 
-```json
-{"contract":{"type":"comment","comment":{"min_length":30},"required":true}}
+**Multi-check compound command** — chain with `&&`, let the first failure stop.
+
+**Agent-readable shell status** — preserve the original exit status:
+```bash
+( set -o pipefail; <command> ); rc=$?; printf '\nSQUADRULES_SHELL_EXIT=%s\n' "$rc" >&2; exit "$rc"
 ```
 
-## Composition Patterns
+**Freeze-then-verify** — step N writes checksum, step N+1 verifies before publish.
+
+**Write-then-grep** — subagent writes a verdict file, main agent checks line 1.
 
-**Multi-check compound command**
-- chain with `&&`
-- let the first failure stop execution
-
-**Agent-readable shell status**
-- use when failure can produce no output, especially `test`, quiet `grep`,
-  JSON probes, pipelines, or commands that redirect stderr
-- empty stdout or stderr is not success; success is the real process status
-  reported as `solution.shell.exit_code`
-- print the final status marker to stderr when stdout is machine-readable
-- preserve the original status exactly:
-  ```bash
-  ( set -o pipefail; <command> ); rc=$?; printf '\nSQUADRULES_SHELL_EXIT=%s\n' "$rc" >&2; exit "$rc"
-  ```
-- keep `&&` inside `<command>` for ordered checks; use the final
-  `; rc=$?; ...` trailer only to capture, print, and return the process status
-- do not use `<command> || echo ERROR && false`; shell operators group
-  left-to-right, so that form can fail after a successful command and it loses
-  the original status
-
-**Freeze-then-verify**
-- step N writes checksum
-- step N+1 verifies checksum before publish
-
-**Write-then-grep**
-- subagent writes a verdict file
-- main agent checks the first line for `PASS`
-
-**Phase-batch with critic**
-- batch related TODO items into one phase
-- verify hard artifacts with shell
-- then call `critic-loop` for adversarial review
-
-**Dry-run before execution**
-- dry-run command
-- human review
-- real command
-
-**Chain-link via forward + slug**
-- layer N's contract requires `forward` with a specific adapter slug
-- agent calls `forward` to start the next adapter (new `execution_id`)
-- next adapter runs its own layer chain through to `reward`
-- use when the protocol exceeds 350 lines or needs multi-path routing
-- NOT a replacement for layers — layers remain the primary unit of work
-- example contract:
-  ```json
-  {"contract":{"type":"mcp","mcp":{"tool_name":"forward","arguments":{"uri":"squadrules://adapter/implement-plan"}},"required":true}}
-  ```
+**Phase-batch with critic** — batch related items, verify hard artifacts with
+shell, then call `critic-loop` for adversarial review.
 
+**Chain-link via forward + slug** — layer N's contract requires `forward` with a
+specific adapter slug. Use when the adapter exceeds 350 lines or needs
+multi-path routing. Example:
 ```json
-{"contract":{"type":"comment","comment":{"min_length":30},"required":true}}
+{"contract":{"type":"mcp","mcp":{"tool_name":"forward","arguments":{"uri":"squadrules://adapter/implement-plan"}},"required":true}}
 ```
 
 ## Artifacts for Shell Contracts
 
-When a shell contract needs a reusable script (Python guard, validation logic,
-setup helper), **attach it as an artifact** rather than inlining it in the
-contract JSON:
+When a shell contract needs a reusable script, **attach it as an artifact**
+rather than inlining it in the contract JSON:
 
 1. Write the script file.
 2. `train` with `mime: "text/x-python"`, `artifact_name: "isolation-guard.py"`,
-   `adapter_uri: "squadrules://adapter/my-adapter"`, and the script content in
-   `content`.
+   `adapter_uri: "squadrules://adapter/my-adapter"`, and the script content.
 3. In the shell contract, reference it via `export` with
    `squadrules://artifact/{uuid}` at execution time.
 
-This keeps adapter markdown clean, makes scripts independently versionable,
-and avoids bloating contract JSON with large inline scripts.
-
-**Interpreter restriction:** The `interpreter` field in shell contracts accepts
-only: `bash`, `sh`, `python3`, `python`, `node`. Build tools (`terraform`,
-`docker`, `npm`, etc.) are **not** interpreters — wrap them in a `bash -c`
-command instead.
+This keeps adapter markdown clean and makes scripts independently versionable.
 
 ```json
 {"contract":{"type":"comment","comment":{"min_length":30},"required":true}}
@@ -368,9 +251,10 @@ command instead.
 Only reachable after all prior steps are solved.
 
 The agent can now:
-1. pick the correct challenge type for each protocol step
+1. pick the correct challenge type for each adapter step
 2. match challenge type to the step's mode
-3. choose the right interpreter
+3. choose the right interpreter (bash, python3, node)
 4. apply working-directory and security rules
-5. preserve real shell statuses for silent checks
-6. use stronger verification patterns instead of weak narrative checks
+5. use forward-link mcp contracts for chain links
+6. use subagent contracts for delegated work
+7. apply stronger verification patterns instead of weak comment checks

package/dist/embed-docs/mem/critic-loop-guide.md

@@ -1,5 +1,5 @@
 ---
-version: "5.11.0"
+version: "5.12.1"
 slug: critic-loop-guide
 title: Critic Loop Integration and Mutation Gate Guide
 ---
@@ -100,7 +100,7 @@ Split proofs by **reversibility cost**, not by step count:
   sub-condition (`A && B && C && echo OK`):
 
 ```json
-{"contract":{"type":"shell","shell":{"cmd":"test -f \"$OUT_A\" && test -f \"$OUT_B\" && grep -q \"$EXPECTED\" \"$OUT_A\" && echo OK","timeout_seconds":10},"required":true}}
+{"contract":{"type":"shell","shell":{"cmd":"test -f \"$OUT_A\" && test -f \"$OUT_B\" && grep -q \"$EXPECTED\" \"$OUT_A\" && echo OK","interpreter":"bash","timeout_seconds":10},"required":true}}
 ```
 
 - **Never let an aggregate proof degrade to `echo "done"`.** A proof that asserts
@@ -115,7 +115,7 @@ it happens — for example, confirm you are on a throwaway worktree and branch (
 `main`, not the human's active checkout) **before** making changes:
 
 ```json
-{"contract":{"type":"shell","shell":{"cmd":"test \"$(git rev-parse --abbrev-ref HEAD)\" != main && git rev-parse --git-common-dir | grep -q worktrees","timeout_seconds":5},"required":true}}
+{"contract":{"type":"shell","shell":{"cmd":"test \"$(git rev-parse --abbrev-ref HEAD)\" != main && git rev-parse --git-common-dir | grep -q worktrees","interpreter":"bash","timeout_seconds":5},"required":true}}
 ```
 
 ## How to Chain Critic-Loop into an Adapter
@@ -154,7 +154,7 @@ Record `work` in the handoff file pointed to by `$WORK_MANIFEST`, as flat keys
 stays a machine-checkable file test instead of prose:
 
 ```json
-{"contract":{"type":"shell","shell":{"cmd":"test -f \"${WORK_MANIFEST:-}\" || test -f \"${INPUT_FILE:-}\"","timeout_seconds":3},"required":true}}
+{"contract":{"type":"shell","shell":{"cmd":"test -f \"${WORK_MANIFEST:-}\" || test -f \"${INPUT_FILE:-}\"","interpreter":"bash","timeout_seconds":3},"required":true}}
 ```
 
 Anything that cannot be resolved is `verification_blocked` — an item the critic
@@ -194,7 +194,7 @@ fails when the verdict is not PASS. This is the mechanical guard that prevents
 weaker agents from proceeding after FAIL:
 
 ```json
-{"contract":{"type":"shell","shell":{"cmd":"head -1 \"$VERDICT_FILE\" | grep -qi '^PASS$'","timeout_seconds":5},"required":true}}
+{"contract":{"type":"shell","shell":{"cmd":"head -1 \"$VERDICT_FILE\" | grep -qi '^PASS$'","interpreter":"bash","timeout_seconds":5},"required":true}}
 ```
 
 If the critic wrote FAIL, this shell command exits non-zero. The server rejects
@@ -229,15 +229,17 @@ Assert the preconditions with a shell or mcp contract so the action only runs fr
 valid state — never with a `user_input` "are you sure?" prompt:
 
 ```json
-{"contract":{"type":"shell","shell":{"cmd":"test -n \"$TARGET_REPO\" && test -n \"$TARGET_BRANCH\"","timeout_seconds":5},"required":true}}
+{"contract":{"type":"shell","shell":{"cmd":"test -n \"$TARGET_REPO\" && test -n \"$TARGET_BRANCH\"","interpreter":"bash","timeout_seconds":5},"required":true}}
 ```
 
 ### Post-mutation verification (objective)
 
-Confirm the mutation actually took effect by reading the remote state back:
+Confirm the mutation actually took effect by reading the remote state back.
+Use a `subagent` contract when the verification requires multi-step reasoning
+or tool orchestration beyond a single shell command:
 
 ```json
-{"contract":{"type":"mcp","mcp":{"tool_name":"getMergeRequest","arguments":{"repo":"X"}},"required":true}}
+{"contract":{"type":"subagent","subagent":{"instruction":"Verify the remote mutation took effect: read back the created/updated resource and confirm its state matches the intended outcome."},"required":true}}
 ```
 
 The guarantee comes from critic-loop (truth of intent) plus these objective

package/dist/embed-docs/mem/critic-loop.md

@@ -1,5 +1,5 @@
 ---
-version: "5.11.0"
+version: "5.12.1"
 slug: critic-loop
 title: Critic Loop
 ---
@@ -96,7 +96,7 @@ This protocol produces:
 }
 ```
 
-## Precondition Check [SUBAGENT]
+## Precondition Check
 
 Verify foundational preconditions before deep investigation. Early-abort if any
 are broken.
@@ -122,10 +122,10 @@ are broken.
 **Output:** verified preconditions or early-abort diagnostics
 
 ```json
-{"contract":{"type":"shell","shell":{"cmd":"test -f \"${WORK_MANIFEST:-}\" || test -f \"${INPUT_FILE:-}\"","timeout_seconds":3},"required":true}}
+{"contract":{"type":"shell","shell":{"cmd":"test -f \"${WORK_MANIFEST:-}\" || test -f \"${INPUT_FILE:-}\"","interpreter":"bash","timeout_seconds":3},"required":true}}
 ```
 
-## Resolve Submission [SUBAGENT]
+## Resolve Submission
 
 Turn the submission into the material under review. What cannot be resolved is
 never guessed at.
@@ -150,8 +150,7 @@ never guessed at.
      stderr as the material.
    - `inline` — the text recorded in the manifest is the material.
 3. Record the resolved inventory before auditing: `kind`, item count, per-item
-   status (`resolved` or `blocked`), and where each item's evidence lives. The
-   audit investigates this inventory and nothing else.
+   status (`resolved` or `blocked`), and where each item's evidence lives.
 4. A `pr` or `git_diff` submission is reviewed as a diff: claims are checked
    against the changed lines and the tests they touch, never against the
    description written alongside them.
@@ -159,10 +158,10 @@ never guessed at.
 **Output:** resolved work inventory for the audit
 
 ```json
-{"contract":{"type":"comment","comment":{"min_length":80},"required":true}}
+{"contract":{"type":"subagent","subagent":{"instruction":"Resolve the work submission into reviewable material: read the manifest, resolve each item by kind from work.root, and record the resolved inventory with per-item status."},"required":true}}
 ```
 
-## Audit [SUBAGENT]
+## Audit
 
 Perform bounded adversarial review of the target against the resolved work
 submission and invariants.
@@ -187,14 +186,8 @@ Extract every verifiable claim that matters operationally:
 4. continue reviewing all in-scope claims even after a normal FAIL condition is met;
    only a precondition failure stops the audit early
 
-**High-risk areas**
-- setup steps and prerequisites
-- CLI commands and flags
-- configuration keys and environment variables
-- authentication, identity, and permissions
-- deployment and release behaviour
-- external publishing actions
-- destructive or irreversible operations
+**High-risk areas:** setup steps, CLI commands, configuration keys, authentication,
+deployment, external publishing, destructive operations.
 
 **Step 3 — Gather evidence using the hierarchy**
 
@@ -207,43 +200,29 @@ Extract every verifiable claim that matters operationally:
 | 5 | external docs, web pages, linked references |
 | 6 | conversational assumption or indirect inference |
 
-**Rules:**
-- higher-priority evidence overrides lower-priority evidence
-- priority 5–6 alone is not enough for `verified`
-- a submitted link or PR description is priority 5 evidence: verify the claim
-  against the fetched content or the actual diff, never against the summary
+**Rules:** higher-priority evidence overrides lower; priority 5–6 alone is not
+enough for `verified`; a submitted link or PR description is priority 5.
 
 **Step 4 — Produce claim verdicts**
-
-For each claim, record:
-- CLAIM
-- EVIDENCE
-- EVIDENCE PRIORITY
-- VERDICT: `verified` / `partially_verified` / `unverifiable` / `incorrect`
-
+For each claim: CLAIM, EVIDENCE, EVIDENCE PRIORITY, VERDICT
+(`verified` / `partially_verified` / `unverifiable` / `incorrect`).
 A claim must not be marked `verified` without positive supporting evidence.
 
 **Step 5 — Review the phase boundary**
-Check whether the calling protocol preserved the right mode boundary:
-- was execution reviewed independently?
-- were review and execution kept separate?
-- did the protocol switch to verification when it should have?
-- is escalation needed because certainty was overstated?
+Check whether the calling adapter preserved the right mode boundary.
 
 **Step 6 — Check requirement coverage**
-For every item in the supplied `requirements` list, confirm the target addresses
-it with positive evidence and record it as `covered` / `partial` / `missing`. An
-omitted requirement leaves no trace in the output, so coverage can only be judged
-against the list, never from the artifact alone. Any `missing` item — or any
-`partial` high-risk item — forces a FAIL with `failure_class: requirement_gap`.
+For every item in `requirements`, confirm coverage with positive evidence.
+Any `missing` item — or any `partial` high-risk item — forces FAIL with
+`failure_class: requirement_gap`.
 
 **Output:** structured audit findings for the verdict step
 
 ```json
-{"contract":{"type":"comment","comment":{"min_length":120},"required":true}}
+{"contract":{"type":"subagent","subagent":{"instruction":"Perform bounded adversarial audit: extract claims, investigate with scope discipline, gather evidence by priority hierarchy, produce claim verdicts, review phase boundary, and check requirement coverage."},"required":true}}
 ```
 
-## Verdict [SUBAGENT]
+## Verdict
 
 Turn the audit into a final PASS / FAIL result.
 
@@ -275,7 +254,7 @@ Turn the audit into a final PASS / FAIL result.
 **Output:** final verdict file
 
 ```json
-{"contract":{"type":"shell","shell":{"cmd":"test -f \"$VERDICT_FILE\" && head -1 \"$VERDICT_FILE\" | grep -qiE '^(PASS|FAIL)$' && sed -n '2p' \"$VERDICT_FILE\" | grep -qiE '^(High|Medium|Low)$'","timeout_seconds":5},"required":true}}
+{"contract":{"type":"shell","shell":{"cmd":"test -f \"$VERDICT_FILE\" && head -1 \"$VERDICT_FILE\" | grep -qiE '^(PASS|FAIL)$' && sed -n '2p' \"$VERDICT_FILE\" | grep -qiE '^(High|Medium|Low)$'","interpreter":"bash","timeout_seconds":5},"required":true}}
 ```
 
 ## Reward Signal