@squadrules/mcp 5.6.0 → 5.7.0

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

@@ -1,355 +1,44 @@
 ---
+version: "5.7.0"
 slug: create-new-protocol
-version: "5.6.0"
-title: Create / Review / Refactor SQUADRULES Protocol
+title: Create New Protocol (Redirect to Author Adapter)
 ---
 
+# Create New Protocol (Redirect to Author Adapter)
 
-
-# Create / Review / Refactor SQUADRULES Protocol
-
-> **Note to the agent:** SQUADRULES protocols are interfaces for AI agents — you
-> are the primary user. When you author a protocol, you design behaviour for
-> yourself and others. Write for them: single source of truth (never duplicate
-> rules), explicit over implicit (agents fill ambiguity with hallucination),
-> phases teach modes (each step teaches its cognitive mode), truth over fluency
-> (a protocol that reads well but causes wrong behaviour is worse than one that
-> reads rough but executes correctly).
+`create-new-protocol` was renamed to **`author-adapter`** in 5.6.0. This adapter
+is a redirect tombstone: it exists only so a stored adapter that still chains to
+`squadrules://adapter/create-new-protocol` resolves and is sent to the replacement
+instead of dangling. It carries no authoring logic. Do not author new adapters
+against this slug — use `squadrules://adapter/author-adapter`.
 
 ## Activation Patterns
 
-SQUADRULES authoring lifecycle — create, review, or update adapters / protocols / workflows.
-In this context, those words refer to the same stored artifact and can be treated
-as synonyms. Supports three operations:
-
-- **create** — draft and train a new adapter / protocol from scratch.
-- **review** — audit an existing adapter, family, or bundle for structural issues,
-  missing cross-references, chaining gaps, DRY violations, stale guidance, or
-  agent-hostile ambiguity. Read-only.
-- **update** — apply specific corrections to an existing adapter / protocol and
-  re-train. Also triggered by: edit, fix, modify, change, improve, patch, refactor.
+**Typically invoked by:** a stored adapter that still forwards to the retired
+`create-new-protocol` slug.
 
-**Run this protocol when the user says ANY of:**
-
-- "create a new SQUADRULES protocol" / "create new protocol adapter"
-- "register personal SQUADRULES adapter" / "register a personal adapter"
-- "train adapter into personal" / "train protocol into personal"
-- "train a workflow" / "register a new adapter" / "create a new workflow"
-- "review protocol" / "audit adapters" / "check protocol families for gaps"
-- "update adapter" / "edit adapter" / "fix protocol" / "modify adapter"
-- "patch protocol" / "refactor protocol" / "change adapter" / "improve adapter"
-- "create new protocol" (when `activate` found no match and user confirms)
-
-**Trigger pattern:** **create** / **train** / **register** / **review** /
-**audit** / **fix** / **update** / **edit** / **modify** / **change** /
-**improve** / **patch** / **refactor** / **correct** +
-(protocol / adapter / workflow).
+**Can be invoked directly when agent needs:**
+- "create new protocol" — the retired name for the author adapter
 
 **Must Never:**
-- Run when the user only asked to execute an existing protocol.
-- Mutate adapters during a `review` operation.
-- Optimise only for pretty wording; this protocol designs agent behaviour.
-- Treat "update", "edit", or "modify an existing adapter" as the **update**
-  operation — never as create.
+- Perform any authoring itself; this tombstone only redirects.
+- Be used as the target of a new adapter chain.
 
 **Must Always:**
-- Infer `{operation}` from trigger: create / review / update.
-  When the user says "update", "edit", "modify", or "fix" → operation is **update**.
-- Optimise for truth, low ambiguity, explicit sequencing, and user-need alignment.
-- Design or review phase transitions explicitly: discovery, clarification,
-  ideation, planning, execution, validation, review, handoff.
-- Include Activation Patterns as the first H2 and Reward Signal as the last H2
-  in any newly drafted adapter.
-- Enforce the 350-line limit per file.
-
-**Good trigger examples:**
-- "Create a new SQUADRULES protocol for code review" → run this protocol (create)
-- "No match found; I want to create a new protocol" → run this protocol (create)
-- "Review all v4 protocol families for missing cross-references" → run this protocol (review)
-- "Update the MR adapter to include a review step" → run this protocol (update)
-- "Edit the critic-loop adapter triggers" → run this protocol (update)
-- "Refactor the MR adapter to be less ambiguous" → run this protocol (update)
-
-**Bad trigger examples:**
-- "Run the standardise project protocol" → use activate / forward
-- "Search for deployment protocol" → use activate
-- "Create an MR" → use the MR adapter, not this protocol
-
-## Preflight Dependencies
-
-Before running authoring actions, verify dependency and auth readiness for this
-run:
-
-1. Required MCP tools are available and reachable: `activate`, `forward`,
-   `reward`, and the operation-dependent tool (`train`, `export`, or `tune`).
-2. Required CLI tools for planned shell steps are installed and callable.
-3. Required auth/session state is valid for the target MCP server.
-
-If any check fails, attempt AI-assisted remediation automatically (install or
-configure the missing tool, refresh auth/session), then re-run preflight. Only
-hard-stop when a required tool or auth genuinely cannot be established
-autonomously; report the concrete blocker and the remediation already attempted.
-Do not continue to intent resolution until preflight passes.
-
-```json
-{"contract":{"type":"comment","comment":{"min_length":80},"required":true}}
-```
-
-## Resolve Intent Autonomously
-
-Infer `{operation}` from the user's trigger — do not stop to ask for confirmation:
-
-| Signal | Operation |
-|---|---|
-| "create", "new", "train", no match from activate | **create** |
-| "review", "audit", "check", "gaps", "cross-references" | **review** |
-| "update", "edit", "fix", "modify", "change", "improve", "patch", "refactor", "add missing", "correct" | **update** |
-
-Resolve the target from context without a confirmation prompt: for `create`,
-proceed to author a new adapter; for `review`, select the adapter(s), family, or
-bundle named or implied by the request; for `update`, select the adapter and the
-specific issue. Record the inferred operation and target, then continue. Escalate
-to the user only when the request is genuinely ambiguous and no reasonable default
-exists.
-
-```json
-{"contract":{"type":"comment","comment":{"min_length":80},"required":true}}
-```
-
-## Gather Requirements
-
-### For `create` — collect details for a new protocol
-
-**1. Determine the pattern:**
-
-| Signal | Pattern |
-|---|---|
-| One workflow, no variants | **Standalone** — one protocol, all steps inline |
-| Multiple issue types / output formats / media | **Router + Extensions** — router classifies, routes via `activate` |
-| Domain has a decision tree | **Router + Extensions** |
-| Single workflow but exceeds 350 lines or too complex for weaker models | **Chain** — split into sequential adapters linked via `forward` + slug |
-| Reference material needed by steps | Extract to a separate file, not a protocol |
-
-**2. Collect per protocol:**
-
-- **Title** — clear, descriptive H1.
-- **User problem** — what real problem does this solve?
-- **Agent behaviour** — what behaviour should this create in the agent?
-- **Mode map** — which steps are for discovery, clarification, ideation,
-  planning, execution, validation, review, or handoff?
-- **Steps** — each H2 must earn its place and end with a challenge.
-- **Challenge type per step** — use the strongest observable contract possible.
-- **Domain reference** — guides / docs the protocol should load.
-- **Existing protocols** — reuse, compose, or extract shared content.
-- **DRY / size check** — extract duplicated content; split if >350 lines.
-- **Chain position** — entry, middle, or exit? What slug does the previous link forward to?
-- **Failure analysis** — where would a weaker agent misread this protocol?
-
-**3. If Router pattern:** variants, classification questions, forbidden types,
-and which parts stay in the router vs extensions.
-
-**4. If Chain pattern:** Load `protocol-linking-guide` for full rules
-(`forward` with `squadrules://adapter/protocol-linking-guide`). Collect: chain
-links and concerns, minimum number of links, entry point (matched by
-`activate`), and artifacts flowing between links.
-
-### For `review` — audit existing adapters against this checklist
-
-Export target adapter(s). For each adapter, check:
-
-1. **User-need fit** — does the adapter solve a real user problem, or merely
-   mirror literal wording?
-2. **Mode / phase clarity** — are discovery, clarification, ideation,
-   execution, validation, and review clearly separated?
-3. **Cross-reference completeness** — are all required related adapters linked?
-4. **Adapter handoff gaps** — does it hand off where another adapter should own
-   the work?
-5. **DRY violations** — is policy content duplicated instead of linked?
-6. **Contract coverage** — does every executable H2 have the right contract?
-7. **Truth-first behaviour** — does it reduce guessing, fake certainty, and
-   silent assumption-making?
-8. **Activation pattern accuracy** — do triggers match what users actually say?
-9. **Structure compliance** — first H2 Activation Patterns, last H2 Reward
-   Signal, no duplicate H2s, under 350 lines.
-10. **Sibling consistency** — are equivalent steps present across sibling
-    adapters in the same family?
-11. **Chained adapter families** (when applicable) — extension adapters include
-    `chain_root` and a prerequisite clause pointing at the root; parent adapters
-    use explicit `forward` when the next adapter slug is already known; reserve
-    `activate` for ambiguous runtime discovery (see `protocol-linking-guide`,
-    **Chaining Back and Forward**).
-12. **Critic-loop integration** — does the adapter include critic-loop chain
-    links at major phase boundaries? Does each critic-loop invocation have a
-    FAIL gate shell contract (`grep -qi '^PASS$'` on the verdict file)? Are
-    solution checks restricted to irreversible remote mutations (see
-    `critic-loop-guide`)?
-
-### For `update` — identify the specific issue
-
-Export the target adapter, read the current markdown, identify the exact gap or
-error, and plan the minimal change. Do not alter unrelated layers.
-
-Summarise gathered requirements or findings.
-
-```json
-{"contract":{"type":"comment","comment":{"min_length":80},"required":true}}
-```
-
-## Draft Markdown
-
-### For `create` — draft new adapter markdown
-
-Draft the full markdown for `train`.
-
-### For `review` — draft findings report
-
-Write a structured gap report to `$REVIEW_FINDINGS_FILE` (an absolute path
-provided by the invoking agent or chosen by you under
-`$SQUADRULES_LOCAL_ARTIFACT_DIR` with a session-unique segment). For each finding
-include:
-
-- adapter title
-- gap type
-- severity
-- why the issue matters for AI-agent behaviour
-- specific recommended fix
-
-### For `update` — draft corrected adapter markdown
-
-Apply the identified change and show a diff-style summary of what changed.
-
-### Shared drafting rules (all operations)
+- Send the caller to `squadrules://adapter/author-adapter`, forwarding the same
+  context it received.
 
-**Core SQUADRULES rule — right mode at the right time:**
+## Redirect
 
-Every protocol must help the agent recognise whether the current step is for
-exploration, clarification, ideation, planning, execution, validation, review,
-or handoff. Do not blur those modes.
-
-**Truth over fluency:**
-
-Design protocols to reduce guessing and fake certainty. Prefer explicit prompts,
-explicit stop conditions, explicit uncertainty escalation, and observable
-verification over narrative reassurance.
-
-**User need over literal phrasing:**
-
-The protocol should help the agent provide what the user actually needs, not
-just echo the wording used in the request.
-
-**DRY:**
-
-Shared content across protocols must live in one place. If two protocols share
->50% of their body, extract shared logic.
-
-**350-line maximum per file:**
-
-No protocol file may exceed 350 lines. If it grows beyond that, split it into
-linked adapters or extract a reference file.
-
-**Generic-first — create generic, link from detailed:**
-
-Create protocols from generic to detailed. The generic adapter must stand alone.
-Extensions should contain only the delta.
-
-**Slug convention — deterministic protocol linking:**
-
-Every protocol gets a short, unique, lowercase-hyphenated `slug`.
-
-**Artifacts:**
-
-Store scripts or config blobs as artifacts via `train` (set `mime`,
-`artifact_name`, `adapter_uri`). Retrieve with `export` using
-`squadrules://artifact/{uuid}`.
-
-**Protocol structure:** H1 title, first H2 Activation Patterns, second H2
-Preflight Dependencies, middle H2s one per step with JSON contract block, last
-H2 Reward Signal. Frontmatter: `slug` (required), `version` (optional),
-`chain_root` (required for mid-chain adapters).
-
-**Challenge types:** Load `challenge-type-guide` for decision rules and JSON
-formats (`forward` with `squadrules://adapter/challenge-type-guide`).
-
-**Critic-loop and mutation gates:** Load `critic-loop-guide` for placement,
-FAIL gate, and solution check rules (`forward` with `squadrules://adapter/critic-loop-guide`).
-
-**If Router pattern:** draft the router and each extension as separate files.
-
-Post the full drafted markdown.
+Forward to the replacement and continue the run there. `author-adapter` is the
+create / review / update lifecycle that replaced `create-new-protocol`; its
+integration rules live in the adapter itself. See ADR 0016 (the rename).
 
 ```json
-{"contract":{"type":"comment","comment":{"min_length":120},"required":true}}
-```
-
-## Critic-Loop Review (create and update only)
-
-For `create` and `update`: run critic-loop against the drafted markdown. This is an
-autonomous quality loop — the agent owns content, the critic owns quality, and no
-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`.
-2. Run the FAIL gate shell contract on the verdict file:
-
-```json
-{"contract":{"type":"shell","shell":{"cmd":"head -1 \"$VERDICT_FILE\" | grep -qi '^PASS$'","timeout_seconds":5},"required":true}}
-```
-
-3. If FAIL: address every finding, then re-invoke critic-loop and re-run the FAIL
-   gate. **Loop automatically until the verdict is PASS** — do not proceed and do
-   not ask the user whether to continue.
-4. If PASS: capture the verdict file path for the `review_evidence` field
-   in the `train` call below.
-
-For `review`: skip this step (read-only operation).
-
-```json
-{"contract":{"type":"comment","comment":{"min_length":80},"required":true}}
-```
-
-## Autonomous Review Gate
-
-No human approval step. The critic-loop PASS verdict from the previous step is the
-sole quality gate; once it is PASS, proceed directly to finalise.
-
-For `create`: record the drafted adapter slug(s) and the critic-loop verdict, then
-continue to `train`.
-
-For `review`: record the findings and the actions taken, then continue.
-
-For `update`: record the corrected markdown, the change summary, and the critic
-verdict, then continue.
-
-```json
-{"contract":{"type":"comment","comment":{"min_length":80},"required":true}}
-```
-
-## FinaliseOperation
-
-For `create`: call `train` with the drafted markdown and `review_evidence`
-from the critic-loop step. Use `force_update: false` unless overwrite was
-explicitly requested.
-
-For `review`: do not call `train`. Save the findings report only if requested.
-
-For `update`: call `train` with `force_update: true`, `review_evidence` from
-the critic-loop step, and update the corresponding repo file.
-
-Report the outcome: adapter URI(s) for create / update, or findings summary for
-review.
-
-```json
-{"contract":{"type":"comment","comment":{"min_length":80},"required":true}}
+{"contract":{"type":"mcp","mcp":{"tool_name":"forward","arguments":{"uri":"squadrules://adapter/author-adapter"}},"required":true}}
 ```
 
 ## Reward Signal
 
-Protocol complete when:
-- `create` — adapter(s) stored via `train` (with review_evidence) and URI(s) reported
-- `review` — findings report delivered
-- `update` — corrected adapter trained with `force_update: true` + review_evidence, repo file updated
-
-A successful result means the resulting SQUADRULES adapter is more truthful,
-phase-aware, agent-readable, and aligned with human–AI harmony.
+The caller reached `squadrules://adapter/author-adapter`, so the retired slug
+resolved and redirected instead of dangling.

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

@@ -1,5 +1,5 @@
 ---
-version: "5.6.0"
+version: "5.7.0"
 slug: critic-loop-guide
 title: Critic Loop Integration and Mutation Gate Guide
 ---
@@ -13,7 +13,7 @@ cheap while irreversible boundaries stay guarded.
 
 ## Activation Patterns
 
-**Typically invoked by:** `create-new-protocol` during adapter drafting, and
+**Typically invoked by:** `author-adapter` during adapter drafting, and
 any adapter that includes review or validation phases.
 
 **Can be invoked directly when agent needs:**
@@ -45,7 +45,7 @@ any adapter that includes review or validation phases.
 
 **Bad trigger examples:**
 - "run the critic loop" → use `activate` to match `critic-loop`
-- "create a new protocol" → use `create-new-protocol`
+- "create a new protocol" → use `author-adapter`
 - "which challenge type for this step?" → use `challenge-type-guide`
 
 ## Core Decision Rule
@@ -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.0"
+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.
@@ -49,7 +50,7 @@ validation, or review phase via `forward` with the stored adapter URI
 - compose protocol fires this after output generation → run this protocol
 
 **Bad trigger examples:**
-- "Create a new protocol" → use `create-new-protocol`
+- "Create a new protocol" → use `author-adapter`
 - "Implement a feature" → use an execution protocol, not this one
 
 ## Artifact Contract
@@ -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.0"
+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.0"
+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.0"
+version: "5.7.0"
 slug: protocol-linking-guide
 title: Protocol Linking Guide
 ---
@@ -14,7 +14,7 @@ validation for deterministic cross-protocol linking.
 
 ## Activation Patterns
 
-**Typically invoked by:** `create-new-protocol` and
+**Typically invoked by:** `author-adapter` and
 `critic-loop`.
 
 **Can be invoked directly when agent needs:**
@@ -41,7 +41,7 @@ validation for deterministic cross-protocol linking.
 
 **Bad trigger examples:**
 - "which challenge type for this step?" → use `challenge-type-guide`
-- "create a new protocol" → use `create-new-protocol`
+- "create a new protocol" → use `author-adapter`
 
 ## Layers vs Chains
 

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

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