@squadrules/mcp 5.6.1 → 5.7.0

package/dist/embed-docs/mem/adapter-migration.md

@@ -1,5 +1,5 @@
 ---
-version: "5.6.1"
+version: "5.7.0"
 slug: adapter-migration
 title: Adapter Migration Protocol
 ---

package/dist/embed-docs/mem/author-adapter.md

@@ -1,6 +1,6 @@
 ---
 slug: author-adapter
-version: "5.6.1"
+version: "5.7.0"
 title: Author Adapter (Create / Review / Refactor)
 ---
 
@@ -274,9 +274,11 @@ autonomous quality loop — the agent owns content, the critic owns quality, and
 human approval is requested at any point.
 
 1. Invoke critic-loop via `forward` with `squadrules://adapter/critic-loop`.
-   Provide the drafted markdown as `input_file`, the slug as
-   `calling_protocol_slug`, and "structural compliance and agent behaviour"
-   as `verification_target`.
+   Submit the drafted markdown as a `file_set` work submission — write
+   `kind: file_set`, `root: <directory of the draft>`, then the drafted file
+   under `items:` into the handoff pointed to by `$WORK_MANIFEST` — with the
+   slug as `calling_protocol_slug` and "structural compliance and agent
+   behaviour" as `verification_target`.
 2. Run the FAIL gate shell contract on the verdict file:
 
 ```json

package/dist/embed-docs/mem/bulk-insert-adapters-via-cli.md

@@ -1,6 +1,6 @@
 ---
 slug: bulk-insert-adapters-via-cli
-version: "5.6.1"
+version: "5.7.0"
 title: Bulk Insert Adapters via SQUADRULES CLI
 ---
 

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

@@ -1,5 +1,5 @@
 ---
-version: "5.6.1"
+version: "5.7.0"
 slug: challenge-type-guide
 title: Challenge Type Selection Guide
 ---

package/dist/embed-docs/mem/create-new-protocol.md

@@ -1,5 +1,5 @@
 ---
-version: "5.6.1"
+version: "5.7.0"
 slug: create-new-protocol
 title: Create New Protocol (Redirect to Author Adapter)
 ---

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

@@ -1,5 +1,5 @@
 ---
-version: "5.6.1"
+version: "5.7.0"
 slug: critic-loop-guide
 title: Critic Loop Integration and Mutation Gate Guide
 ---
@@ -54,7 +54,8 @@ any adapter that includes review or validation phases.
 returns PASS** — not a one-shot step. It verifies claims, gathers evidence,
 searches for contradictions, and checks the work against the original requirement
 list. Use it for quality and truthfulness review, and whenever a step is
-non-deterministic or has no objective proof.
+non-deterministic or has no objective proof. Run it **before** the work is handed
+to the next step, and before it is presented to the human.
 
 **Solution checks** are per-layer contract verification mechanisms (shell
 commands, MCP tool calls). Use them ONLY where getting it wrong is expensive or
@@ -134,6 +135,34 @@ pattern is a `mcp` contract that requires calling `forward` with the
 Use the same contract. The critic-loop adapter receives the calling protocol's
 context and independently verifies the work.
 
+### What to submit for review
+
+The submission is the **work itself**, not a summary of it. Pass `work` with a
+`kind`, an `items` list, and the absolute `root` the items resolve against:
+
+| `kind` | `items` contain | Resolved by | Typical work |
+|---|---|---|---|
+| `file_set` | paths (absolute, or relative to `root`) | read each file | docs, generated code, configs |
+| `links` | URLs, `squadrules://` resource URIs | fetch each one | published pages, external references |
+| `git_diff` | `base..head` refs, or empty for the working tree | `git diff` | an unpushed implementation |
+| `pr` | PR numbers or URLs | `gh pr view` + `gh pr diff` | a reviewable pull request |
+| `command_output` | commands to run from `root` | run and capture | migrations, builds, data pulls |
+| `inline` | the text itself | read the manifest | a plan, a decision, a message draft |
+
+Record `work` in the handoff file pointed to by `$WORK_MANIFEST`, as flat keys —
+`kind:`, `root:`, then `items:` with one item per line — so the precondition
+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}}
+```
+
+Anything that cannot be resolved is `verification_blocked` — an item the critic
+could not read is never treated as an item that passed. `input_file` still works
+and means a one-item `file_set`; prefer `work_manifest` for anything that is not
+a single document. A `pr` or `git_diff` submission is judged on the diff and the
+tests it touches, not on the description written next to it.
+
 ### Feed it the requirements, then loop with a ceiling
 
 Pass the original requirement list in the forward context. A critic that sees only

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

@@ -1,5 +1,5 @@
 ---
-version: "5.6.1"
+version: "5.7.0"
 slug: critic-loop
 title: Critic Loop
 ---
@@ -9,12 +9,13 @@ title: Critic Loop
 # Critic Loop
 
 Bounded adversarial investigator that the calling protocol **loops until it
-returns PASS** — not a one-shot review. Receives a reference document, the
+returns PASS** — not a one-shot review. Receives a work submission (files,
+links, a git diff, a pull request, command output, or inline text), the
 original requirement list, and the calling protocol's invariants, then
-independently verifies the target by extracting claims, gathering evidence,
-searching for contradictions, and checking requirement-by-requirement coverage.
-A FAIL sends the caller back to fix and re-invoke; the loop is bounded by an
-explicit iteration ceiling (see Verdict).
+independently verifies the submitted work by extracting claims, gathering
+evidence, searching for contradictions, and checking requirement-by-requirement
+coverage. A FAIL sends the caller back to fix and re-invoke; the loop is bounded
+by an explicit iteration ceiling (see Verdict).
 
 ## Activation Patterns
 
@@ -30,7 +31,7 @@ validation, or review phase via `forward` with the stored adapter URI
 (phase / plan / implementation / output).
 
 **Must Never:**
-- Modify any file outside the provided input and output paths.
+- Modify any submitted item or any file other than the verdict path.
 - 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.
@@ -58,10 +59,16 @@ This protocol receives:
 
 ```text
 {
-  input_file: string,              // absolute path to the document under review
+  work: {
+    kind: 'file_set' | 'links' | 'git_diff' | 'pr' | 'command_output' | 'inline',
+    items: string[],              // paths | URLs | 'base..head' refs | PR URL/number | commands | text
+    root: string                  // absolute cwd used to resolve relative paths, refs and commands
+  },
+  work_manifest: string,          // absolute path to the handoff file recording `work`
+  input_file: string,             // accepted alias: a one-item work.kind='file_set'
   calling_protocol_slug: string,
   verification_target: string,
-  requirements: string[],          // original intent / requirement list to check coverage against
+  requirements: string[],         // original intent / requirement list to check coverage against
   context: {
     operation: string,
     verdict_file: string,          // absolute path where the verdict will be written
@@ -71,6 +78,12 @@ This protocol receives:
 }
 ```
 
+The submission is the **work itself**, not an essay about it. Write `work` to
+`$WORK_MANIFEST` as flat keys so the handoff stays machine-checkable:
+`kind:`, `root:`, then `items:` with one item per line. Callers that still pass
+only `input_file` are handled as `kind: file_set` with that single path; the
+review rules do not change, only the scope of what is submitted.
+
 This protocol produces:
 
 ```text
@@ -88,14 +101,16 @@ This protocol produces:
 Verify foundational preconditions before deep investigation. Early-abort if any
 are broken.
 
-**Input:** `$INPUT_FILE` (absolute path), calling protocol slug, context
+**Input:** `$WORK_MANIFEST` (or the older-spelling `$INPUT_FILE`), calling protocol slug, context
 
 **Actions:**
-1. Verify the input file exists: `test -f "$INPUT_FILE"`.
+1. Verify a submission handoff is present: `$WORK_MANIFEST`, or `$INPUT_FILE`
+   when the caller passed no manifest.
 2. Verify the verdict output path is writable (parent directory exists).
 3. Load the calling protocol's Must Never / Must Always sections if possible.
 4. Verify the target state is available for review.
-5. Verify required tools are available.
+5. Verify required tools are available for the submission's `kind` (a `pr`
+   submission with no `gh` on the host is `verification_blocked`, not skipped).
 
 **On early-abort:**
 - verdict = `FAIL`
@@ -107,15 +122,52 @@ are broken.
 **Output:** verified preconditions or early-abort diagnostics
 
 ```json
-{"contract":{"type":"shell","shell":{"cmd":"test -f \"$INPUT_FILE\"","timeout_seconds":3},"required":true}}
+{"contract":{"type":"shell","shell":{"cmd":"test -f \"${WORK_MANIFEST:-}\" || test -f \"${INPUT_FILE:-}\"","timeout_seconds":3},"required":true}}
+```
+
+## Resolve Submission [SUBAGENT]
+
+Turn the submission into the material under review. What cannot be resolved is
+never guessed at.
+
+**Input:** `work` recorded in `$WORK_MANIFEST` (or the older-spelling `$INPUT_FILE`),
+`work.root`
+
+**Actions:**
+1. Read `kind`, `root`, `items`. An unknown `kind`, an empty `items` list, or a
+   malformed manifest is `verification_blocked`.
+2. Resolve every item by kind, always from `work.root`:
+   - `file_set` — read each path; relative paths resolve against `root`, and a
+     missing path is `verification_blocked`.
+   - `links` — fetch each URL; a URL that cannot be fetched is
+     `verification_blocked`, not an `unverifiable` claim.
+   - `git_diff` — `git -C "$root" diff <base>..<head>`, or the working tree when
+     no range is given; no `git`, no repository, or a bad ref is
+     `verification_blocked`.
+   - `pr` — `gh pr view` plus `gh pr diff` for the number or URL; a missing
+     `gh`, an expired login, or an unreachable host is `verification_blocked`.
+   - `command_output` — run each command from `root` and capture stdout and
+     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.
+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.
+
+**Output:** resolved work inventory for the audit
+
+```json
+{"contract":{"type":"comment","comment":{"min_length":80},"required":true}}
 ```
 
 ## Audit [SUBAGENT]
 
-Perform bounded adversarial review of the target against the reference document
-and invariants.
+Perform bounded adversarial review of the target against the resolved work
+submission and invariants.
 
-**Input:** reference document, invariants, verification target, requirement list, context
+**Input:** resolved work inventory, invariants, verification target, requirement list, context
 
 **Actions:**
 
@@ -158,6 +210,8 @@ Extract every verifiable claim that matters operationally:
 **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
 
 **Step 4 — Produce claim verdicts**
 

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

@@ -1,5 +1,5 @@
 ---
-version: "5.6.1"
+version: "5.7.0"
 slug: phase-critic-guide
 title: Phase Critic Guide (Redirect to Critic Loop Guide)
 ---

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

@@ -1,5 +1,5 @@
 ---
-version: "5.6.1"
+version: "5.7.0"
 slug: phase-critic
 title: Phase Critic (Redirect to Critic Loop)
 ---
@@ -26,7 +26,8 @@ against this slug — use `squadrules://adapter/critic-loop`.
 
 **Must Always:**
 - Send the caller to `squadrules://adapter/critic-loop`, forwarding the same
-  `input_file`, `requirements`, and `context` it received.
+  `work` submission (or the older-spelling `input_file`), `requirements`, and
+  `context` it received.
 
 ## Redirect
 

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

@@ -1,5 +1,5 @@
 ---
-version: "5.6.1"
+version: "5.7.0"
 slug: protocol-linking-guide
 title: Protocol Linking Guide
 ---

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

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

package/dist/embed-docs/mem/skill-format-guide.md

@@ -1,5 +1,5 @@
 ---
-version: "5.6.1"
+version: "5.7.0"
 slug: skill-format-guide
 title: Skill Format and Local Authoring Guide
 ---