@squadrules/mcp 5.13.7 → 5.14.0

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

@@ -1,5 +1,5 @@
 ---
-version: "5.13.7"
+version: "5.14.0"
 slug: critic-loop-guide
 title: Critic Loop Integration and Mutation Gate Guide
 ---
@@ -118,21 +118,34 @@ Example ```json
 {"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
+## How to Invoke Critic-Loop from an Adapter
 
-Use `forward` + slug to invoke `critic-loop` at phase boundaries. The standard
-pattern is a `forward` contract naming the `critic-loop` slug:
+Reach `critic-loop` at a phase boundary with a **`subagent` contract**, never a
+`forward` contract. A `forward` hop keeps the review on the thread that produced
+the work: the same agent reads the critic's instructions, performs them, and
+writes the verdict it is then gated on. The hop names the call the subagent must
+really make, so it cannot substitute an improvised review:
 
 ### After a planning phase
 
 Example ```json
-{"contract":{"type":"forward","forward":{"target":"squadrules://adapter/critic-loop"},"required":true}}
+{"contract":{"type":"subagent","subagent":{"context":"Run the critic on the plan and return its actual report. Call the forward tool with uri squadrules://adapter/critic-loop, submit the work from $WORK_MANIFEST with the requirement list, and let the critic write $VERDICT_FILE. Do not review it yourself.","mcp":[{"tool_name":"forward","arguments":{"uri":"squadrules://adapter/critic-loop"}}]},"required":true}}
 ```
 
 ### After an implementation phase
 
-Use the same contract. The critic-loop adapter receives the calling protocol's
-context and independently verifies the work.
+Use the same contract shape. The subagent receives the calling protocol's
+context, drives `critic-loop` to its end in its own context, and returns only its
+report — the tool transcript never re-enters the caller's reasoning.
+
+`forward` + slug stays correct for **chain continuation** — handing work to the
+next stage of the same effort, or to a reusable sub-adapter that is not auditing
+the caller. The test is not "does it link to an adapter" but "is the linked
+adapter the caller's auditor". Separation is the point: a review the audited agent
+runs on itself restates its work instead of checking it.
+
+A host with no subagent facility cannot satisfy this hop. Report that as a
+blocker; do not fall back to reviewing your own work.
 
 ### What to submit for review
 
@@ -174,7 +187,8 @@ surfaces the unresolved findings; it prevents a weak agent from thrashing foreve
 
 ### Verdict handoff pattern
 
-Critic-loop writes a verdict file. The calling adapter reads it:
+Critic-loop writes a verdict file in the delegated run. The calling adapter reads
+it:
 
 1. Critic-loop writes `$VERDICT_FILE` with `PASS`/`FAIL` on line 1.
 2. Calling adapter's next layer reads the verdict file.
@@ -188,7 +202,7 @@ review. The correct action is to fix the findings and re-invoke critic-loop.
 
 ### FAIL gate contract (required after every critic-loop invocation)
 
-Every adapter that chains critic-loop **must** include a shell contract that
+Every adapter that invokes critic-loop **must** include a shell contract that
 fails when the verdict is not PASS. This is the mechanical guard that prevents
 weaker agents from proceeding after FAIL:
 
@@ -250,24 +264,30 @@ confirmation gates for remote mutations.
 1. **Loop critic-loop until PASS at every major phase boundary** — after planning,
    after implementation, after validation — feeding it the requirement list and
    bounding it with an iteration ceiling.
-2. **Do NOT add critic-loop between every layer** — it is a phase-level review,
+2. **Invoke the critic from a separate context** — a `subagent` contract, never a
+   `forward` contract on the thread that produced the work.
+3. **Do NOT add critic-loop between every layer** — it is a phase-level review,
    not a step-level check.
-3. **Put one objective proof at each irreversibility boundary** — remote mutation
+4. **Put one objective proof at each irreversibility boundary** — remote mutation
    or the local precondition that guards it: pre-mutation readiness +
    post-mutation verification, never a human confirmation prompt.
-4. **Batch reversible, checkable steps into one aggregate strict-conjunction
+5. **Batch reversible, checkable steps into one aggregate strict-conjunction
    proof** instead of one proof per step; never let it degrade to `echo "done"`.
-5. **Never replace a boundary proof with critic-loop** — critic-loop reviews truth
+6. **Never replace a boundary proof with critic-loop** — critic-loop reviews truth
    after the fact; it does not block an irreversible step.
-6. **Never add a proof for purely local, reversible operations** — critic-loop
+7. **Never add a proof for purely local, reversible operations** — critic-loop
    provides sufficient review.
+8. **Never gate what you cannot observe** — if no shell command can see the
+   outcome, state it as an instruction with a completion criterion instead of
+   inventing a command that prints `ok`.
 
 ## Adapter Authoring Checklist
 
 When drafting a new adapter, apply this checklist:
 
 1. Identify all phase boundaries in the adapter flow.
-2. Add a `critic-loop` chain link at each boundary.
+2. Add a `subagent` critic hop at each boundary — never a `forward` hop to
+   `critic-loop`.
 3. Identify all steps that perform irreversible remote mutations.
 4. Add objective solution checks (pre-mutation readiness + post-action
    verification) for each — no `user_input` human-confirmation gate.
@@ -275,7 +295,8 @@ When drafting a new adapter, apply this checklist:
 6. Verify that the critic-loop verdict handoff pattern is present.
 7. Verify that a FAIL gate shell contract follows every critic-loop invocation.
 8. Verify that `train`/`tune` calls include `review_evidence` from the critic.
-9. Ensure the adapter's Reward Signal describes what the critic protects.
+9. Ensure the adapter's Reward Signal describes what the critic protects, and
+   states what the verdict does **not** prove.
 
 Example ```json
 {"contract":{"type":"comment","comment":{"min_length":80},"required":true}}
@@ -288,6 +309,6 @@ Only reachable after all prior steps are solved.
 The agent can now:
 1. Decide when to use critic-loop versus solution checks
 2. Identify irreversible remote mutations that need hard gates
-3. Chain critic-loop into adapters at the correct phase boundaries
+3. Invoke critic-loop from a delegated subagent at the correct phase boundaries
 4. Apply the mutation gate pattern for remote-system actions
 5. Avoid unnecessary solution checks for local or read-only operations

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

@@ -1,5 +1,5 @@
 ---
-version: "5.13.7"
+version: "5.14.0"
 slug: critic-loop
 title: Critic Loop
 ---
@@ -20,8 +20,11 @@ by an explicit iteration ceiling (see Verdict).
 ## Activation Patterns
 
 **Typically invoked by:** another protocol at the end of a plan, implement,
-validation, or review phase via `forward` with the stored adapter URI
-`squadrules://adapter/critic-loop`.
+validation, or review phase, reached from a `subagent` contract whose
+`subagent.mcp` names `forward` with the stored adapter URI
+`squadrules://adapter/critic-loop`. The critic runs in the delegated context, not
+on the audited agent's thread — that separation is why the type is `subagent` and
+not `forward`.
 
 **Can be invoked directly when agent needs:**
 - "review phase output" / "verify plan" / "audit implementation"
@@ -35,6 +38,8 @@ validation, or review phase via `forward` with the stored adapter URI
 - Trust the executor's assertions without independent evidence.
 - Classify a claim as `verified` based only on absence of contradiction.
 - Keep investigating after a precondition failure that blocks verification.
+- Re-delegate this review to another subagent: you are the separation the caller
+  asked for, and nesting a second layer of delegation hides the verdict's author.
 
 **Must Always:**
 - Extract claims before investigating.
@@ -43,6 +48,8 @@ validation, or review phase via `forward` with the stored adapter URI
 - Check every item in the supplied requirement list for coverage; a missing
   requirement is a FAIL even when the output is internally consistent.
 - Include confidence in every verdict and failure class in every FAIL verdict.
+- Write `$VERDICT_FILE` on **every** path, including an early-abort, so the
+  caller's gate always reads a real verdict instead of failing on a missing file.
 - Preserve the boundary between execution and review.
 
 **Good trigger examples:**
@@ -117,14 +124,10 @@ are broken.
 - failure class = `verification_blocked`
 - confidence = `Low`
 - write focused diagnostics
-- skip all later steps
+- write `$VERDICT_FILE` with those diagnostics, then skip all later steps
 
 **Output:** verified preconditions or early-abort diagnostics
 
-```json
-{"contract":{"type":"shell","shell":{"cmd":"test -f \"${WORK_MANIFEST:-}\" || test -f \"${INPUT_FILE:-}\"","interpreter":"bash","timeout_seconds":3},"required":true}}
-```
-
 ## Resolve Submission
 
 Turn the submission into the material under review. What cannot be resolved is
@@ -157,10 +160,6 @@ never guessed at.
 
 **Output:** resolved work inventory for the audit
 
-```json
-{"contract":{"type":"subagent","subagent":{"context":"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
 
 Perform bounded adversarial review of the target against the resolved work
@@ -218,10 +217,6 @@ Any `missing` item — or any `partial` high-risk item — forces FAIL with
 
 **Output:** structured audit findings for the verdict step
 
-```json
-{"contract":{"type":"subagent","subagent":{"context":"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
 
 Turn the audit into a final PASS / FAIL result.
@@ -246,7 +241,8 @@ Turn the audit into a final PASS / FAIL result.
 - Line 1 is `PASS` → the loop is satisfied; the calling adapter may continue.
 - Line 1 is `FAIL` → the calling adapter **MUST NOT** proceed to reward, **MUST
   NOT** ask the user for approval, and **MUST NOT** continue. It must address the
-  findings, increment `context.iteration`, and re-invoke critic-loop.
+  findings, increment `context.iteration`, and re-invoke critic-loop from a fresh
+  delegated subagent — never on the thread that produced the work under review.
 - `failure_class: iteration_ceiling` → stop looping and surface the unresolved
   findings; never silently pass. The ceiling bounds the loop so a weak agent
   cannot thrash forever.
@@ -265,3 +261,14 @@ The phase output has been independently challenged and looped until satisfied. T
 resulting verdict is more truthful because it is based on extracted claims,
 explicit evidence, contradiction search, requirement-by-requirement coverage, and
 a clean boundary between execution and review.
+
+The single contract on this adapter is the verdict-file syntax gate: it is the
+one artifact the critic produces, and everything before it is the critic's own
+reasoning. The precondition, submission-resolution, and audit steps carry no
+contracts because a contract gates an outcome, not a step, and a critic that
+gates itself inward re-delegates work it was delegated to perform.
+
+That gate asserts the verdict file's **shape**, not the review's soundness: a
+`PASS` is this critic's judgment, and the separation that makes it worth
+something is that a critic was run apart from the executor. The caller's own
+`PASS` gate proves only that a file was written saying `PASS`.

package/dist/embed-docs/mem/protocol-linking-guide.md

@@ -1,5 +1,5 @@
 ---
-version: "5.13.7"
+version: "5.14.0"
 slug: protocol-linking-guide
 title: Adapter Linking Guide
 ---
@@ -50,7 +50,12 @@ cohesive concern.
 - the adapter exceeds 350 lines
 - weaker models cannot follow the full adapter in one pass
 - runtime routing to different adapters is needed (Router pattern)
-- a step is reusable across multiple parent adapters (e.g. `critic-loop`)
+- a step is reusable across multiple parent adapters (e.g. a shared
+  deployment-check adapter)
+
+A review is **not** a chain link: reaching `critic-loop` to audit the current
+run's work is a `subagent` hop, because a `forward` hop leaves the critic on the
+thread that made the mistakes.
 
 Chaining is NOT a replacement for layers. A 6-step adapter that fits in 350
 lines should stay as one adapter with 6 H2 layers.
@@ -118,10 +123,12 @@ To run an extension adapter, call **`forward`** with
 Both system and user-authored adapters chain using slugs in `next_action`:
 
 ```text
-call forward with squadrules://adapter/critic-loop ...
 call forward with squadrules://adapter/implement-terraform ...
 ```
 
+A review hop is not a chain link — reach `critic-loop` from a `subagent` contract
+whose `subagent.mcp` names `forward`.
+
 Slugs are globally unique (enforced by `train`), so resolution is
 deterministic — no scoring, no ambiguity.
 

package/dist/embed-docs/mem/refine-search.md

@@ -1,5 +1,5 @@
 ---
-version: "5.13.7"
+version: "5.14.0"
 slug: refine-search
 title: Get help refining your search
 ---