@squadrules/mcp 5.3.0 → 5.4.0

package/dist/config/mem-boot.d.ts

@@ -0,0 +1,3 @@
+/** Force delete-then-retrain of all shipped adapters at boot (repair path). */
+export declare const MEM_BOOT_FORCE_INJECT: boolean;
+//# sourceMappingURL=mem-boot.d.ts.map

package/dist/config/mem-boot.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"mem-boot.d.ts","sourceRoot":"","sources":["../../src/config/mem-boot.ts"],"names":[],"mappings":"AAkBA,+EAA+E;AAC/E,eAAO,MAAM,qBAAqB,SAAgD,CAAC"}

package/dist/config/mem-boot.js

@@ -0,0 +1,21 @@
+/**
+ * Boot-injection force switch (ADR 0002 / issue #24) — kept out of `config.ts`
+ * to satisfy the max-lines budget, following the `src/config/*` convention.
+ *
+ * Normal boots leave this false so `injectMemResourcesAtBoot` honours the
+ * version-based reuse skip: an app-space adapter already stored at (or newer
+ * than) its shipped version is left untouched instead of being deleted and
+ * re-embedded on every start. Setting `MEM_BOOT_FORCE_INJECT=true` is the
+ * structural-repair escape hatch — it bypasses the version check and forces a
+ * delete-then-retrain of every shipped adapter, which is how an operator
+ * recovers a corrupted or duplicated app-space store without a code change.
+ */
+function getEnvBoolean(key, defaultValue) {
+    const raw = process.env[key];
+    if (raw === undefined || raw.trim() === '')
+        return defaultValue;
+    return ['1', 'true', 'yes', 'on'].includes(raw.trim().toLowerCase());
+}
+/** Force delete-then-retrain of all shipped adapters at boot (repair path). */
+export const MEM_BOOT_FORCE_INJECT = getEnvBoolean('MEM_BOOT_FORCE_INJECT', false);
+//# sourceMappingURL=mem-boot.js.map

package/dist/config/mem-boot.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"mem-boot.js","sourceRoot":"","sources":["../../src/config/mem-boot.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;GAWG;AACH,SAAS,aAAa,CAAC,GAAW,EAAE,YAAqB;IACvD,MAAM,GAAG,GAAG,OAAO,CAAC,GAAG,CAAC,GAAG,CAAC,CAAC;IAC7B,IAAI,GAAG,KAAK,SAAS,IAAI,GAAG,CAAC,IAAI,EAAE,KAAK,EAAE;QAAE,OAAO,YAAY,CAAC;IAChE,OAAO,CAAC,GAAG,EAAE,MAAM,EAAE,KAAK,EAAE,IAAI,CAAC,CAAC,QAAQ,CAAC,GAAG,CAAC,IAAI,EAAE,CAAC,WAAW,EAAE,CAAC,CAAC;AACvE,CAAC;AAED,+EAA+E;AAC/E,MAAM,CAAC,MAAM,qBAAqB,GAAG,aAAa,CAAC,uBAAuB,EAAE,KAAK,CAAC,CAAC"}

package/dist/embed-docs/mem/README.md

@@ -5,7 +5,7 @@ documents that are injected into the Squadrules app space at boot.
 
 <!-- squadrules-doc-keep: directory-local authority for the shipped meta-protocol bundle (slugs, versions, chain-linking rules); source of truth for these files, not a restatement of wiki Core Concepts -->
 
-Version: **4.2.0**
+Version: **4.3.0**
 
 ## Philosophy
 
@@ -16,6 +16,13 @@ time: discovery, clarification, ideation, planning, execution, validation,
 review, and handoff. The bundle prefers truth, explicit sequencing, and
 observable verification over polished but weak wording.
 
+**Autonomy (AI-ownership).** The bundle is written for autonomous execution:
+adapters resolve intent from context, run critic-loop in a loop until it returns
+`PASS`, and gate irreversible remote mutations with objective pre/post contracts
+(shell/mcp) rather than human confirmation. They do **not** stop to ask a human to
+approve or acknowledge. Human escalation is reserved for genuinely ambiguous intent
+or a hard blocker (a required tool/auth that cannot be established automatically).
+
 Bundled mem resources that intentionally use **protocol** and **adapter** as
 synonyms. Prefer **adapter** in new copy when you are not mirroring user-facing trigger phrases.
 
@@ -25,13 +32,13 @@ synonyms. Prefer **adapter** in new copy when you are not mirroring user-facing
 |------|------|---------|
 | [create-new-protocol.md](create-new-protocol.md) | `create-new-protocol` | Authoring adapter — create, review, or refactor SQUADRULES protocols |
 | [refine-search.md](refine-search.md) | `refine-search` | Refine search — recover user intent after failed `activate` |
-| [phase-critic.md](phase-critic.md) | `phase-critic` | Phase-boundary adversarial review — verify claims against evidence |
+| [critic-loop.md](critic-loop.md) | `critic-loop` | Phase-boundary adversarial review — verify claims against evidence |
 | [adapter-migration.md](adapter-migration.md) | `adapter-migration` | Batch structural migration — update all adapters to latest scheme |
 
 ### Linked authoring flow
 
 ```text
-create-new-protocol (Author) → forward(squadrules://adapter/phase-critic) → phase-critic (Phase-Critic Review) → train (with review_evidence)
+create-new-protocol (Author) → forward(squadrules://adapter/critic-loop) → critic-loop (Critic-Loop Review) → train (with review_evidence)
 ```
 
 ## Reference Documents
@@ -40,7 +47,7 @@ create-new-protocol (Author) → forward(squadrules://adapter/phase-critic) →
 |------|------|---------|
 | [challenge-type-guide.md](challenge-type-guide.md) | `challenge-type-guide` | Challenge type selection, interpreter choice, and stronger verification patterns |
 | [protocol-linking-guide.md](protocol-linking-guide.md) | `protocol-linking-guide` | Layers vs chains, `activate` vs `forward` + slug, chaining back/forward, multi-layer conductor vs extension URI, chain-root collapsing, MCP argument validation |
-| [phase-critic-guide.md](phase-critic-guide.md) | `phase-critic-guide` | Phase-critic integration rules, mutation gates, solution check vs critic decision table |
+| [critic-loop-guide.md](critic-loop-guide.md) | `critic-loop-guide` | Critic-loop integration rules, mutation gates, solution check vs critic decision table |
 
 ## Cross-Protocol Linking
 
@@ -55,7 +62,7 @@ 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. `phase-critic`)
+- a step is reusable across multiple parent adapters (e.g. `critic-loop`)
 
 Chaining is NOT a replacement for layers. A 6-step protocol that fits in 350
 lines should stay as one adapter with 6 H2 layers.
@@ -65,7 +72,7 @@ lines should stay as one adapter with 6 H2 layers.
 Both system and user-authored adapters chain using slugs in `next_action`:
 
 ```text
-call forward with squadrules://adapter/phase-critic and no solution to start the phase critic
+call forward with squadrules://adapter/critic-loop and no solution to start the critic loop
 call forward with squadrules://adapter/implement-terraform and no solution to start this adapter
 ```
 

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

@@ -1,5 +1,5 @@
 ---
-version: "5.3.0"
+version: "5.4.0"
 slug: adapter-migration
 title: Adapter Migration Protocol
 ---
@@ -8,7 +8,7 @@ title: Adapter Migration Protocol
 
 Batch-migrate all adapters in a space to the current structural scheme. Exports
 every adapter, applies conservative structural transformations, reports changes
-per adapter, and re-trains only after user approval.
+per adapter, and re-trains the conforming subset autonomously.
 
 This protocol handles structural migrations only — it preserves semantic content
 (steps, intent, examples) while updating format, headings, and contract shapes
@@ -30,7 +30,7 @@ to match the latest SQUADRULES requirements.
 
 **Must Never:**
 - Alter semantic content (step text, trigger phrases, examples, intent).
-- Auto-train without showing the user a change report first.
+- Auto-train an adapter without first producing a per-adapter change report.
 - Guess transformations when the adapter structure is ambiguous.
 - Delete adapters or layers during migration.
 - Migrate adapters that already conform (report them as "no changes needed").
@@ -39,7 +39,7 @@ to match the latest SQUADRULES requirements.
 - Export every adapter before making any changes.
 - Apply only conservative, reversible structural transformations.
 - Flag ambiguous cases for manual review instead of guessing.
-- Show a per-adapter change report before executing any writes.
+- Produce a per-adapter change report before executing any writes.
 - Preserve the adapter's slug, version, and chain_root fields.
 
 **Good trigger examples:**
@@ -59,9 +59,10 @@ Before running migration, verify readiness:
 1. `export` tool is available and callable.
 2. `tune` and `train` tools are available for writes.
 3. Target space is identified (personal or a named group space).
-4. User understands this is a structural-only migration.
+4. The migration is structural-only (no semantic changes).
 
-If any tool is unavailable, stop and ask the user to fix the connection.
+If any tool is unavailable, stop and report the connection blocker with
+remediation guidance.
 
 ```json
 {"contract":{"type":"comment","comment":{"min_length":80},"required":true}}
@@ -98,16 +99,16 @@ For each exported adapter, perform structural analysis and apply migrations.
    existing `chain_root` when present.
 5. **Line count** — adapters exceeding 350 lines must be flagged for splitting
    (do NOT auto-split; report as manual review needed).
-6. **Phase-critic integration** — check whether the adapter includes at least
-   one `phase-critic` chain link. If not, add a recommendation (do NOT
+6. **Critic-loop integration** — check whether the adapter includes at least
+   one `critic-loop` chain link. If not, add a recommendation (do NOT
    auto-add; report as suggestion).
 
 ### Transformation rules
 
 - **Conservative only:** If a transformation might change meaning, skip it and
   flag for manual review.
-- **Reversible:** Every change must be expressible as a diff so the user can
-  reject individual changes.
+- **Reversible:** Every change must be expressible as a diff so it is auditable
+  and reversible.
 - **Idempotent:** Running migration twice on the same adapter produces no
   additional changes.
 
@@ -123,7 +124,7 @@ For each adapter, produce:
 
 ## Report Changes
 
-Present a summary table to the user:
+Record a summary table:
 
 | Adapter slug | Status | Changes | Warnings |
 |-------------|--------|---------|----------|
@@ -138,18 +139,18 @@ For each adapter with `needs_changes`, show the specific transformations:
 For each adapter with `needs_manual_review`, explain what needs human
 attention and why the protocol cannot auto-fix it.
 
-Ask the user to choose:
-- **Apply all** — train all `needs_changes` adapters.
-- **Select individually** — choose which adapters to update.
-- **Abort** — cancel the migration without changes.
+Apply the migration autonomously:
+- **Apply all** `needs_changes` adapters.
+- **Leave untouched** every `needs_manual_review` adapter and report it with the
+  reason it cannot be auto-fixed.
 
 ```json
-{"contract":{"type":"user_input","user_input":{"prompt":"Review the migration report above. Choose: apply all, select individually, or abort."},"required":true}}
+{"contract":{"type":"comment","comment":{"min_length":120},"required":true}}
 ```
 
 ## Execute Migration
 
-For each approved adapter, apply the structural changes:
+For each `needs_changes` adapter, apply the structural changes:
 
 1. For adapters needing only content-level fixes (heading reorder, fence
    conversion, field rename): use `tune` with the transformed content and
@@ -166,7 +167,7 @@ Do NOT change the adapter's space assignment during migration.
 
 ## Verify and Report
 
-After executing all approved migrations:
+After executing all migrations:
 
 1. Re-export each migrated adapter to verify structural compliance.
 2. Report final status:
@@ -180,7 +181,7 @@ After executing all approved migrations:
 | Flagged for manual review | N |
 
 3. For each failure, report the error message and suggested fix.
-4. Recommend running `phase-critic` on migrated adapters to verify semantic
+4. Recommend running `critic-loop` on migrated adapters to verify semantic
    integrity after structural changes.
 
 ```json

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

@@ -1,6 +1,6 @@
 ---
 slug: bulk-insert-adapters-via-cli
-version: "5.3.0"
+version: "5.4.0"
 title: Bulk Insert Adapters via SQUADRULES CLI
 ---
 
@@ -65,9 +65,9 @@ If any check fails, stop and report the issue with remediation guidance.
 {"contract":{"type":"shell","shell":{"cmd":"squadrules --version && squadrules token > /dev/null 2>&1 && echo 'auth: ok'","timeout_seconds":15},"required":true}}
 ```
 
-## Confirm Scope
+## Resolve Scope Autonomously
 
-Present the batch operation details to the user:
+Resolve and record the batch operation details:
 
 1. **Source directory** — absolute path.
 2. **File count** — number of `.md` files found (recursive or flat).
@@ -75,10 +75,11 @@ Present the batch operation details to the user:
 4. **Force mode** — whether `--force` will be used (overwrites existing).
 5. **Model attribution** — which `--model` value to use.
 
-List the files that will be trained and ask for confirmation.
+List the files that will be trained, record the resolved scope, and proceed
+autonomously — no confirmation prompt.
 
 ```json
-{"contract":{"type":"user_input","user_input":{"prompt":"Confirm batch scope: directory, file list, target space, force mode, and model ID"},"required":true}}
+{"contract":{"type":"comment","comment":{"min_length":80},"required":true}}
 ```
 
 ## Validate Structure
@@ -91,9 +92,9 @@ Before training, validate each `.md` file against SQUADRULES adapter requirement
 - Contains at least one fenced `json` block with a top-level `contract` object.
 - Does not exceed 350 lines.
 
-Report any files that fail validation. Ask user whether to:
-- skip invalid files and proceed with valid ones
-- abort and fix issues first
+Report any files that fail validation, then proceed autonomously: skip the invalid
+files, train the valid subset, and document every skipped file with its validation
+error and a suggested fix. Do not stop to ask the user.
 
 ```json
 {"contract":{"type":"shell","shell":{"cmd":"echo 'Validation complete — see output above for results'","timeout_seconds":30},"required":true}}

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

@@ -1,5 +1,5 @@
 ---
-version: "5.3.0"
+version: "5.4.0"
 slug: challenge-type-guide
 title: Challenge Type Selection Guide
 ---
@@ -15,7 +15,7 @@ drafting and review.
 ## Activation Patterns
 
 **Typically invoked by:** `create-new-protocol` and
-`phase-critic`.
+`critic-loop`.
 
 **Can be invoked directly when agent needs:**
 - "challenge type reference" / "which challenge type to use"
@@ -39,7 +39,7 @@ drafting and review.
 
 **Bad trigger examples:**
 - "Create a new protocol" → use `create-new-protocol`
-- "Review my protocol draft" → use `phase-critic`
+- "Review my protocol draft" → use `critic-loop`
 
 ## Core Rules
 
@@ -243,7 +243,7 @@ to avoid collisions between parallel sessions.
 **Phase-batch with critic**
 - batch related TODO items into one phase
 - verify hard artifacts with shell
-- then call `phase-critic` for adversarial review
+- then call `critic-loop` for adversarial review
 
 **Dry-run before execution**
 - dry-run command

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

@@ -1,6 +1,6 @@
 ---
 slug: create-new-protocol
-version: "5.3.0"
+version: "5.4.0"
 title: Create / Review / Refactor SQUADRULES Protocol
 ---
 
@@ -67,7 +67,7 @@ as synonyms. Supports three operations:
 - "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 phase-critic adapter triggers" → 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:**
@@ -85,19 +85,19 @@ run:
 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, stop before main execution and ask the user to choose one:
-- proceed with AI-assisted setup and then resume
-- abort this protocol run now
-
-Do not continue to intent confirmation until preflight passes.
+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}}
 ```
 
-## Confirm Intent
+## Resolve Intent Autonomously
 
-Infer `{operation}` from the user's trigger:
+Infer `{operation}` from the user's trigger — do not stop to ask for confirmation:
 
 | Signal | Operation |
 |---|---|
@@ -105,12 +105,15 @@ Infer `{operation}` from the user's trigger:
 | "review", "audit", "check", "gaps", "cross-references" | **review** |
 | "update", "edit", "fix", "modify", "change", "improve", "patch", "refactor", "add missing", "correct" | **update** |
 
-For `create`: ask whether to create a new protocol or refine the search.
-For `review`: ask which adapter(s), family, or bundle to review.
-For `update`: ask which adapter to update and what the issue is.
+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":"user_input","user_input":{"prompt":"Confirm operation and target"},"required":true}}
+{"contract":{"type":"comment","comment":{"min_length":80},"required":true}}
 ```
 
 ## Gather Requirements
@@ -175,11 +178,11 @@ Export target adapter(s). For each adapter, check:
     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. **Phase-critic integration** — does the adapter include phase-critic chain
-    links at major phase boundaries? Does each phase-critic invocation have a
+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
-    `phase-critic-guide`)?
+    `critic-loop-guide`)?
 
 ### For `update` — identify the specific issue
 
@@ -267,8 +270,8 @@ H2 Reward Signal. Frontmatter: `slug` (required), `version` (optional),
 **Challenge types:** Load `challenge-type-guide` for decision rules and JSON
 formats (`forward` with `squadrules://adapter/challenge-type-guide`).
 
-**Phase-critic and mutation gates:** Load `phase-critic-guide` for placement,
-FAIL gate, and solution check rules (`forward` with `squadrules://adapter/phase-critic-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.
 
@@ -278,13 +281,13 @@ Post the full drafted markdown.
 {"contract":{"type":"comment","comment":{"min_length":120},"required":true}}
 ```
 
-## Phase-Critic Review (create and update only)
+## Critic-Loop Review (create and update only)
 
-For `create` and `update`: run phase-critic against the drafted markdown before
-presenting to the user. This is the quality gate — the agent owns content, the
-critic owns quality.
+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 phase-critic via `forward` with `squadrules://adapter/phase-critic`.
+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`.
@@ -294,7 +297,9 @@ critic owns quality.
 {"contract":{"type":"shell","shell":{"cmd":"head -1 \"$VERDICT_FILE\" | grep -qi '^PASS$'","timeout_seconds":5},"required":true}}
 ```
 
-3. If FAIL: address findings, re-invoke phase-critic. Do NOT proceed.
+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.
 
@@ -304,29 +309,33 @@ For `review`: skip this step (read-only operation).
 {"contract":{"type":"comment","comment":{"min_length":80},"required":true}}
 ```
 
-## User Review
+## Autonomous Review Gate
 
-For `create`: present the drafted protocol(s) and the phase-critic verdict.
-User acknowledges (informational, not an approval 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 `review`: present the findings report and ask which findings to act on.
+For `create`: record the drafted adapter slug(s) and the critic-loop verdict, then
+continue to `train`.
 
-For `update`: present the corrected markdown, change summary, and critic verdict.
+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":"user_input","user_input":{"prompt":"Acknowledge the draft and verdict (create/update) or review findings"},"required":true}}
+{"contract":{"type":"comment","comment":{"min_length":80},"required":true}}
 ```
 
 ## FinaliseOperation
 
 For `create`: call `train` with the drafted markdown and `review_evidence`
-from the phase-critic step. Use `force_update: false` unless overwrite was
+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 phase-critic step, and update the corresponding repo file.
+the critic-loop step, and update the corresponding repo file.
 
 Report the outcome: adapter URI(s) for create / update, or findings summary for
 review.
@@ -339,7 +348,7 @@ review.
 
 Protocol complete when:
 - `create` — adapter(s) stored via `train` (with review_evidence) and URI(s) reported
-- `review` — findings report delivered and acknowledged
+- `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,