@squadrules/mcp 5.12.0 → 5.12.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/.tsbuildinfo +1 -1
- package/dist/embed-docs/mem/adapter-migration.md +1 -1
- package/dist/embed-docs/mem/author-adapter.md +1 -1
- package/dist/embed-docs/mem/bulk-insert-adapters-via-cli.md +1 -1
- package/dist/embed-docs/mem/challenge-type-guide.md +1 -1
- package/dist/embed-docs/mem/critic-loop-guide.md +1 -1
- package/dist/embed-docs/mem/critic-loop.md +1 -1
- package/dist/embed-docs/mem/protocol-linking-guide.md +1 -1
- package/dist/embed-docs/mem/refine-search.md +1 -1
- package/dist/resources/embedded-mcp-resources.js +8 -8
- package/dist/ui/assets/{AccountPage-rmFJddfQ.js → AccountPage-BhneCJCw.js} +1 -1
- package/dist/ui/assets/{index-D_BmxEln.js → index-rCZd_925.js} +2 -2
- package/dist/ui/index.html +1 -1
- package/package.json +1 -1
|
@@ -23,14 +23,14 @@ export const mcpResources = {
|
|
|
23
23
|
},
|
|
24
24
|
"mem": {},
|
|
25
25
|
"meta": {
|
|
26
|
-
"adapter-migration": "---\nversion: \"5.12.
|
|
27
|
-
"author-adapter": "---\nslug: author-adapter\nversion: \"5.12.0\"\ntitle: Author Adapter (Create / Review / Refactor)\n---\n\n# Author Adapter (Create / Review / Refactor)\n\n> **Note to the agent:** SQUADRULES adapters are interfaces for AI agents — you\n> are the primary user. When you author an adapter, you design behaviour for\n> yourself and others. Write for them: single source of truth (never duplicate\n> rules), explicit over implicit (agents fill ambiguity with hallucination),\n> steps teach modes (each step teaches its cognitive mode), truth over fluency\n> (an adapter that reads well but causes wrong behaviour is worse than one that\n> reads rough but executes correctly).\n\n## Activation Patterns\n\nPreferred entry URI: `squadrules://adapter/author-adapter`.\nIf `forward.authoring` is present, use its operation and target throughout this\nrun. Do not reinterpret update as create or change the target mid-run. This\ncontext describes the requested work; it does not override host permissions.\n\nSQUADRULES authoring lifecycle — create, review, or update adapters / workflows.\nSupports three operations:\n- **create** — draft and train a new adapter from scratch.\n- **review** — audit an existing adapter, family, or bundle for structural issues,\n missing cross-references, chaining gaps, DRY violations, stale guidance, or\n agent-hostile ambiguity. Read-only.\n- **update** — apply specific corrections to an existing adapter and\n save the correction. Also triggered by: edit, fix, modify, change, improve, patch, refactor.\n\n**Run this adapter when the user says ANY of:**\n- \"create a new SQUADRULES adapter\" / \"register a personal adapter\"\n- \"train adapter into personal\" / \"train a workflow\"\n- \"review adapter\" / \"audit adapters\" / \"check adapter families for gaps\"\n- \"update adapter\" / \"edit adapter\" / \"fix adapter\" / \"modify adapter\"\n- \"patch adapter\" / \"refactor adapter\" / \"change adapter\" / \"improve adapter\"\n\n**Trigger pattern:** **create** / **train** / **register** / **review** /\n**audit** / **fix** / **update** / **edit** / **modify** / **change** /\n**improve** / **patch** / **refactor** / **correct** +\n(adapter / workflow).\n\n**Must Never:**\n- Run when the user only asked to execute an existing adapter.\n- Mutate adapters during a `review` operation.\n- Optimise only for pretty wording; this adapter designs agent behaviour.\n- Treat \"update\", \"edit\", or \"modify an existing adapter\" as **create**.\n\n**Must Always:**\n- Infer `{operation}` from trigger: create / review / update.\n- Optimise for truth, low ambiguity, explicit sequencing, and user-need alignment.\n- Include Activation Patterns as the first H2 and Reward Signal as the last H2\n in any newly drafted adapter.\n- Enforce the 350-line limit per file.\n\n## Preflight Dependencies\n\nBefore running authoring actions, verify dependency and auth readiness:\n1. Required MCP tools are available: `activate`, `forward`, `reward`, and the\n operation-dependent tool (`train`, `export`, or `tune`).\n2. Required CLI tools for planned shell steps are installed and callable.\n3. Required auth/session state is valid for the target MCP server.\n\nIf any check fails, attempt AI-assisted remediation automatically, then re-run\npreflight. Only hard-stop when a required tool or auth genuinely cannot be\nestablished autonomously.\n\n```json\n{\"contract\":{\"type\":\"shell\",\"shell\":{\"cmd\":\"echo 'preflight: ok'\",\"interpreter\":\"bash\",\"timeout_seconds\":10},\"required\":true}}\n```\n\n## Resolve Intent Autonomously\n\nUse structured `authoring` when provided. For original calls without it, infer\n`{operation}` from the user's trigger — do not stop to ask for confirmation:\n\n| Signal | Operation |\n|---|---|\n| \"create\", \"new\", \"train\", no match from activate | **create** |\n| \"review\", \"audit\", \"check\", \"gaps\", \"cross-references\" | **review** |\n| \"update\", \"edit\", \"fix\", \"modify\", \"change\", \"improve\", \"patch\", \"refactor\" | **update** |\n\nResolve the target from context without a confirmation prompt. Record the\ninferred operation and target, then continue. Escalate to the user only when\nthe request is genuinely ambiguous and no reasonable default exists.\n\n```json\n{\"contract\":{\"type\":\"subagent\",\"subagent\":{\"instruction\":\"Resolve the authoring operation (create/review/update) and target adapter from user context. Record the decision.\"},\"required\":true}}\n```\n\n## Gather Requirements\n\n### For `create` — collect details for a new adapter\n\n**1. Determine the pattern:**\n\n| Signal | Pattern |\n|---|---|\n| One workflow, no variants | **Standalone** — one adapter, all steps inline |\n| Multiple issue types / output formats | **Router + Extensions** — router classifies, routes via `activate` |\n| Exceeds 350 lines or too complex for weaker models | **Chain** — split into sequential adapters linked via `forward` + slug |\n\n**2. Collect per adapter:**\n- Title, user problem, agent behaviour, mode map, steps, challenge type per step\n- Domain reference, existing adapters to reuse/compose, DRY/size check\n- Chain position, failure analysis\n\n### For `review` — audit existing adapters\n\nExport target adapter(s). Check: user-need fit, mode/step clarity,\ncross-reference completeness, handoff gaps, DRY violations, contract coverage,\ntruth-first behaviour, activation pattern accuracy, structure compliance\n(first H2 Activation Patterns, last H2 Reward Signal, under 350 lines),\nsibling consistency, chained adapter families, critic-loop integration.\n\n### For `update` — identify the specific issue\n\nExport the target adapter, read the current markdown, identify the exact gap or\nerror, and plan the minimal change.\n\n```json\n{\"contract\":{\"type\":\"subagent\",\"subagent\":{\"instruction\":\"Gather requirements for the resolved operation: collect pattern/details for create, audit checklist for review, or identify the specific issue for update.\"},\"required\":true}}\n```\n\n## Draft Markdown\n\n### MCP / Local-Filesystem Boundary\n\n- A personal adapter stored in MCP **cannot** reference local files.\n- Only **system adapters** (bundled in the server) can chain to other system\n adapters via `forward`.\n- Personal adapters must be **self-contained**.\n- When a shell contract needs a reusable script, attach it as an **artifact**\n via `train` (with `mime`, `artifact_name`, `adapter_uri`).\n\n### Drafting rules (all operations)\n\n**Right mode at the right time:** Every adapter must help the agent recognise\nwhether the current step is for exploration, clarification, ideation, planning,\nexecution, validation, review, or handoff.\n\n**Truth over fluency:** Prefer explicit prompts, stop conditions, uncertainty\nescalation, and observable verification over narrative reassurance.\n\n**DRY:** Shared content across adapters must live in one place.\n\n**350-line maximum per file.** Split into linked adapters if exceeded.\n\n**Slug convention:** Every adapter gets a short, unique, lowercase-hyphenated slug.\n\n**Structure:** H1 title, first H2 Activation Patterns, second H2 Preflight\nDependencies, middle H2s one per step with JSON contract block, last H2 Reward\nSignal. Frontmatter: `slug` (required), `version` (optional), `chain_root`\n(required for mid-chain adapters).\n\n**Challenge types:** Load `challenge-type-guide` for decision rules and JSON\nformats (`forward` with `squadrules://adapter/challenge-type-guide`).\n\n**Critic-loop and mutation gates:** Load `critic-loop-guide` for placement,\nFAIL gate, and solution check rules (`forward` with\n`squadrules://adapter/critic-loop-guide`).\n\nFor `create`: draft the full adapter markdown.\nFor `review`: write a structured gap report to `$REVIEW_FINDINGS_FILE`.\nFor `update`: apply the identified change and show a diff-style summary.\n\n```json\n{\"contract\":{\"type\":\"subagent\",\"subagent\":{\"instruction\":\"Draft the adapter markdown (create), findings report (review), or corrected markdown (update) following all shared drafting rules.\"},\"required\":true}}\n```\n\n## Critic-Loop Review (create and update only)\n\nFor `create` and `update`: run critic-loop against the drafted markdown. This is\nan autonomous quality loop — the agent owns content, the critic owns quality, and\nno human approval is requested at any point.\n\n1. Invoke critic-loop via `forward` with `squadrules://adapter/critic-loop`.\n Submit the drafted markdown as a `file_set` work submission — write\n `kind: file_set`, `root: <directory of the draft>`, then the drafted file\n under `items:` into the handoff pointed to by `$WORK_MANIFEST` — with the\n slug as `calling_protocol_slug` and \"structural compliance and agent\n behaviour\" as `verification_target`.\n2. Run the FAIL gate shell contract on the verdict file:\n\n```json\n{\"contract\":{\"type\":\"shell\",\"shell\":{\"cmd\":\"head -1 \\\"$VERDICT_FILE\\\" | grep -qi '^PASS$'\",\"interpreter\":\"bash\",\"timeout_seconds\":5},\"required\":true}}\n```\n\n3. If FAIL: address every finding, then re-invoke critic-loop and re-run the FAIL\n gate. **Loop automatically until the verdict is PASS** — do not proceed and do\n not ask the user whether to continue.\n4. If PASS: capture the verdict file path for the `review_evidence` field\n in the `train` call below.\n\nFor `review`: skip this step (read-only operation).\n\n## FinaliseOperation\n\nNo human approval step. The critic-loop PASS verdict is the sole quality gate.\n\nFor `create`: call `train` with the drafted markdown and `review_evidence`\nfrom the critic-loop step. Use `force_update: false` unless overwrite was\nexplicitly requested.\n\nFor `review`: do not call `train`. Save the findings report only if requested.\n\nFor `update`: use `tune` with the existing adapter URI, corrected content, and\n`review_evidence`. Use `train` with `force_update: true` only for a required\nstructural replacement (changing identity/H1 mapping or layer count). Update the\ncorresponding repository source when the adapter is repo-managed; make repository\nedits in the task's isolated worktree.\n\nReport the outcome: adapter URI(s) for create/update, or findings summary for\nreview.\n\n```json\n{\"contract\":{\"type\":\"comment\",\"comment\":{\"min_length\":80},\"required\":true}}\n```\n\n## Reward Signal\n\nAdapter complete when:\n- `create` — adapter(s) stored via `train` (with review_evidence) and URI(s) reported\n- `review` — findings report delivered\n- `update` — corrected adapter saved via `tune` (or required structural replacement),\n read back and verified; repo-managed source updated in the task worktree\n\nA successful result means the resulting SQUADRULES adapter is more truthful,\nstep-aware, agent-readable, and aligned with human–AI harmony.\n",
|
|
28
|
-
"bulk-insert-adapters-via-cli": "---\nslug: bulk-insert-adapters-via-cli\nversion: \"5.12.
|
|
29
|
-
"challenge-type-guide": "---\nversion: \"5.12.
|
|
30
|
-
"critic-loop-guide": "---\nversion: \"5.12.0\"\nslug: critic-loop-guide\ntitle: Critic Loop Integration and Mutation Gate Guide\n---\n\n# Critic Loop Integration and Mutation Gate Guide\n\nDecision rules for integrating `critic-loop` into adapter protocols: when a\nsolution check (hard verification gate) is required versus when critic-loop\nreview is sufficient, and how to split and batch proofs so reversible work stays\ncheap while irreversible boundaries stay guarded.\n\n## Activation Patterns\n\n**Typically invoked by:** `author-adapter` during adapter drafting, and\nany adapter that includes review or validation phases.\n\n**Can be invoked directly when agent needs:**\n- \"when to add critic loop\" / \"should I use solution check\"\n- \"mutation gate rules\" / \"which actions need hard gates\"\n- \"critic loop vs solution check\" / \"irreversible action rules\"\n- \"add review step to protocol\" / \"where does critic go\"\n\n**Trigger pattern:** **critic loop** / **mutation gate** / **solution check** +\n(integration | when | rules | guide | which | where).\n\n**Must Never:**\n- Be used as an execution protocol.\n- Override the adapter author's judgment on review depth.\n- Recommend solution checks for reversible or local-only actions.\n\n**Must Always:**\n- Distinguish between quality review (critic-loop) and mutation blocking\n (solution checks).\n- Recommend looping critic-loop until PASS at every major phase boundary, fed the\n requirement list and bounded by an iteration ceiling.\n- Restrict solution checks to irreversibility boundaries, and batch reversible\n checkable steps into one strict-conjunction proof.\n\n**Good trigger examples:**\n- drafting a new adapter and deciding where to add review → load this\n- reviewing whether an adapter has the right solution checks → load this\n- \"does my MR step need a solution check?\" → load this\n\n**Bad trigger examples:**\n- \"run the critic loop\" → use `activate` to match `critic-loop`\n- \"create a new protocol\" → use `author-adapter`\n- \"which challenge type for this step?\" → use `challenge-type-guide`\n\n## Core Decision Rule\n\n**Critic-loop** is an adversarial review the calling protocol **loops until it\nreturns PASS** — not a one-shot step. It verifies claims, gathers evidence,\nsearches for contradictions, and checks the work against the original requirement\nlist. Use it for quality and truthfulness review, and whenever a step is\nnon-deterministic or has no objective proof. Run it **before** the work is handed\nto the next step, and before it is presented to the human.\n\n**Solution checks** are per-layer contract verification mechanisms (shell\ncommands, MCP tool calls). Use them ONLY where getting it wrong is expensive or\nimpossible to undo — **irreversible changes on remote systems** and the local\npreconditions that guard them (for example, being on a throwaway worktree/branch\nbefore you commit). Everything else is reversible: give the agent freedom and\nreview with critic-loop instead of adding a hoop.\n\n### What counts as an irreversible remote mutation\n\n| Action | Needs solution check? | Why |\n|--------|----------------------|-----|\n| Create/update merge request | Yes | Remote system state change |\n| Create/update Jira issue | Yes | Remote system state change |\n| Send email | Yes | Cannot unsend |\n| Send Teams message | Yes | Cannot unsend |\n| Create calendar invite | Yes | Sends notifications |\n| Deploy to production | Yes | Irreversible infrastructure change |\n| Delete remote resource | Yes | Irreversible |\n| Push to git remote | Yes | Remote state change |\n| Write/edit local file | No | Use critic-loop instead |\n| Run local tests | No | Read-only / local |\n| Analyze code | No | Read-only |\n| Generate report | No | Local artifact |\n| Read data from API | No | Read-only |\n| Compute / transform data | No | Local operation |\n\n```json\n{\"contract\":{\"type\":\"comment\",\"comment\":{\"min_length\":30},\"required\":true}}\n```\n\n## Proof Splitting: Batch Checkable Steps Into One Proof\n\nSplit proofs by **reversibility cost**, not by step count:\n\n- **One proof per irreversibility boundary.** A boundary is where undoing the next\n part is expensive or impossible: commit to `main`, mutate the human's active\n worktree, `git push`, `gh pr create`, deploy, send.\n- **Batch reversible, checkable steps** and verify them together afterward with a\n single aggregate proof — fewer round-trips, same guarantee.\n- **The aggregate proof must be a strict conjunction** that re-verifies every\n sub-condition (`A && B && C && echo OK`):\n\n```json\n{\"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}}\n```\n\n- **Never let an aggregate proof degrade to `echo \"done\"`.** A proof that asserts\n nothing is worse than no gate because it looks like one. If you cannot write a\n real conjunction, the step is non-deterministic → review it with critic-loop\n instead of faking a proof.\n\n### Guard the boundary before you cross it\n\nThe cheapest proof is the precondition that stops an irreversible mistake before\nit happens — for example, confirm you are on a throwaway worktree and branch (not\n`main`, not the human's active checkout) **before** making changes:\n\n```json\n{\"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}}\n```\n\n## How to Chain Critic-Loop into an Adapter\n\nUse `forward` + slug to invoke `critic-loop` at phase boundaries. The standard\npattern is a `mcp` contract that requires calling `forward` with the\n`critic-loop` slug:\n\n### After a planning phase\n\n```json\n{\"contract\":{\"type\":\"mcp\",\"mcp\":{\"tool_name\":\"forward\",\"arguments\":{\"uri\":\"squadrules://adapter/critic-loop\"}},\"required\":true}}\n```\n\n### After an implementation phase\n\nUse the same contract. The critic-loop adapter receives the calling protocol's\ncontext and independently verifies the work.\n\n### What to submit for review\n\nThe submission is the **work itself**, not a summary of it. Pass `work` with a\n`kind`, an `items` list, and the absolute `root` the items resolve against:\n\n| `kind` | `items` contain | Resolved by | Typical work |\n|---|---|---|---|\n| `file_set` | paths (absolute, or relative to `root`) | read each file | docs, generated code, configs |\n| `links` | URLs, `squadrules://` resource URIs | fetch each one | published pages, external references |\n| `git_diff` | `base..head` refs, or empty for the working tree | `git diff` | an unpushed implementation |\n| `pr` | PR numbers or URLs | `gh pr view` + `gh pr diff` | a reviewable pull request |\n| `command_output` | commands to run from `root` | run and capture | migrations, builds, data pulls |\n| `inline` | the text itself | read the manifest | a plan, a decision, a message draft |\n\nRecord `work` in the handoff file pointed to by `$WORK_MANIFEST`, as flat keys —\n`kind:`, `root:`, then `items:` with one item per line — so the precondition\nstays a machine-checkable file test instead of prose:\n\n```json\n{\"contract\":{\"type\":\"shell\",\"shell\":{\"cmd\":\"test -f \\\"${WORK_MANIFEST:-}\\\" || test -f \\\"${INPUT_FILE:-}\\\"\",\"interpreter\":\"bash\",\"timeout_seconds\":3},\"required\":true}}\n```\n\nAnything that cannot be resolved is `verification_blocked` — an item the critic\ncould not read is never treated as an item that passed. `input_file` still works\nand means a one-item `file_set`; prefer `work_manifest` for anything that is not\na single document. A `pr` or `git_diff` submission is judged on the diff and the\ntests it touches, not on the description written next to it.\n\n### Feed it the requirements, then loop with a ceiling\n\nPass the original requirement list in the forward context. A critic that sees only\nthe output can check internal consistency but **cannot detect an omitted\nrequirement** — omission leaves no trace in the artifact — so \"no requirements\nlost\" is only enforceable if the critic is given the list and asserts coverage\nitem by item. Then loop: on FAIL, fix, increment `iteration`, and re-invoke until\nPASS or until `max_iterations` is reached. The ceiling is a hard stop that\nsurfaces the unresolved findings; it prevents a weak agent from thrashing forever.\n\n### Verdict handoff pattern\n\nCritic-loop writes a verdict file. The calling adapter reads it:\n\n1. Critic-loop writes `$VERDICT_FILE` with `PASS`/`FAIL` on line 1.\n2. Calling adapter's next layer reads the verdict file.\n3. If `FAIL` → **hard stop**: do NOT proceed to reward, do NOT ask the user\n for approval, do NOT continue to the next phase. Address findings first.\n4. If `PASS` → the adapter continues to the next phase.\n\n**FAIL is a hard stop, not an escalation trigger.** A FAIL verdict means the\nwork is not ready. Asking the user \"should I proceed?\" after FAIL bypasses the\nreview. The correct action is to fix the findings and re-invoke critic-loop.\n\n### FAIL gate contract (required after every critic-loop invocation)\n\nEvery adapter that chains critic-loop **must** include a shell contract that\nfails when the verdict is not PASS. This is the mechanical guard that prevents\nweaker agents from proceeding after FAIL:\n\n```json\n{\"contract\":{\"type\":\"shell\",\"shell\":{\"cmd\":\"head -1 \\\"$VERDICT_FILE\\\" | grep -qi '^PASS$'\",\"interpreter\":\"bash\",\"timeout_seconds\":5},\"required\":true}}\n```\n\nIf the critic wrote FAIL, this shell command exits non-zero. The server rejects\nthe solution and the agent cannot advance to the next layer. Protocol wording\nalone does not stop determined agents; this contract does.\n\n## Train/Tune Evidence Requirement\n\n`train` and `tune` enforce critic-loop PASS at the tool level:\n\n- **Adapter (markdown) `train`** requires `review_evidence`: verdict_file path,\n exit_code (must be 0), and stdout (line 1 must be PASS). Without it, the\n server rejects the store with `REVIEW_EVIDENCE_REQUIRED`.\n- **`tune` with content** requires the same `review_evidence`. Space-only moves\n skip this check.\n- **Artifact trains** (non-markdown mime) skip the evidence check.\n\nThis is the tool-level enforcement of the FAIL gate. Even if an agent bypasses\nthe adapter flow and calls `train` directly, the server rejects the store\nwithout PASS evidence. The agent must run critic-loop, capture the verdict\nfile, and pass it as `review_evidence`.\n\n## Mutation Gate Pattern\n\nUnder the AI-ownership model, agents execute autonomously — irreversible remote\nmutations are **not** gated by a human confirmation prompt. Gate them with\nobjective, machine-checkable contracts instead:\n\n### Pre-mutation readiness (objective, no human prompt)\n\nAssert the preconditions with a shell or mcp contract so the action only runs from a\nvalid state — never with a `user_input` \"are you sure?\" prompt:\n\n```json\n{\"contract\":{\"type\":\"shell\",\"shell\":{\"cmd\":\"test -n \\\"$TARGET_REPO\\\" && test -n \\\"$TARGET_BRANCH\\\"\",\"interpreter\":\"bash\",\"timeout_seconds\":5},\"required\":true}}\n```\n\n### Post-mutation verification (objective)\n\nConfirm the mutation actually took effect by reading the remote state back.\nUse a `subagent` contract when the verification requires multi-step reasoning\nor tool orchestration beyond a single shell command:\n\n```json\n{\"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}}\n```\n\nThe guarantee comes from critic-loop (truth of intent) plus these objective\npre/post checks — not from asking a human to approve. Do not add `user_input`\nconfirmation gates for remote mutations.\n\n## Critic-Loop Placement Rules\n\n1. **Loop critic-loop until PASS at every major phase boundary** — after planning,\n after implementation, after validation — feeding it the requirement list and\n bounding it with an iteration ceiling.\n2. **Do NOT add critic-loop between every layer** — it is a phase-level review,\n not a step-level check.\n3. **Put one objective proof at each irreversibility boundary** — remote mutation\n or the local precondition that guards it: pre-mutation readiness +\n post-mutation verification, never a human confirmation prompt.\n4. **Batch reversible, checkable steps into one aggregate strict-conjunction\n proof** instead of one proof per step; never let it degrade to `echo \"done\"`.\n5. **Never replace a boundary proof with critic-loop** — critic-loop reviews truth\n after the fact; it does not block an irreversible step.\n6. **Never add a proof for purely local, reversible operations** — critic-loop\n provides sufficient review.\n\n## Adapter Authoring Checklist\n\nWhen drafting a new adapter, apply this checklist:\n\n1. Identify all phase boundaries in the adapter flow.\n2. Add a `critic-loop` chain link at each boundary.\n3. Identify all steps that perform irreversible remote mutations.\n4. Add objective solution checks (pre-mutation readiness + post-action\n verification) for each — no `user_input` human-confirmation gate.\n5. Verify that no solution checks exist for purely local operations.\n6. Verify that the critic-loop verdict handoff pattern is present.\n7. Verify that a FAIL gate shell contract follows every critic-loop invocation.\n8. Verify that `train`/`tune` calls include `review_evidence` from the critic.\n9. Ensure the adapter's Reward Signal describes what the critic protects.\n\n```json\n{\"contract\":{\"type\":\"comment\",\"comment\":{\"min_length\":80},\"required\":true}}\n```\n\n## Reward Signal\n\nOnly reachable after all prior steps are solved.\n\nThe agent can now:\n1. Decide when to use critic-loop versus solution checks\n2. Identify irreversible remote mutations that need hard gates\n3. Chain critic-loop into adapters at the correct phase boundaries\n4. Apply the mutation gate pattern for remote-system actions\n5. Avoid unnecessary solution checks for local or read-only operations\n",
|
|
31
|
-
"critic-loop": "---\nversion: \"5.12.0\"\nslug: critic-loop\ntitle: Critic Loop\n---\n\n\n\n# Critic Loop\n\nBounded adversarial investigator that the calling protocol **loops until it\nreturns PASS** — not a one-shot review. Receives a work submission (files,\nlinks, a git diff, a pull request, command output, or inline text), the\noriginal requirement list, and the calling protocol's invariants, then\nindependently verifies the submitted work by extracting claims, gathering\nevidence, searching for contradictions, and checking requirement-by-requirement\ncoverage. A FAIL sends the caller back to fix and re-invoke; the loop is bounded\nby an explicit iteration ceiling (see Verdict).\n\n## Activation Patterns\n\n**Typically invoked by:** another protocol at the end of a plan, implement,\nvalidation, or review phase via `forward` with the stored adapter URI\n`squadrules://adapter/critic-loop`.\n\n**Can be invoked directly when agent needs:**\n- \"review phase output\" / \"verify plan\" / \"audit implementation\"\n- \"adversarial review\" / \"critic review\"\n\n**Trigger pattern:** **review** / **verify** / **audit** / **critic** +\n(phase / plan / implementation / output).\n\n**Must Never:**\n- Modify any submitted item or any file other than the verdict path.\n- Trust the executor's assertions without independent evidence.\n- Classify a claim as `verified` based only on absence of contradiction.\n- Keep investigating after a precondition failure that blocks verification.\n\n**Must Always:**\n- Extract claims before investigating.\n- Verify in-scope claims first.\n- Search for contradictory evidence, not only confirming evidence.\n- Check every item in the supplied requirement list for coverage; a missing\n requirement is a FAIL even when the output is internally consistent.\n- Include confidence in every verdict and failure class in every FAIL verdict.\n- Preserve the boundary between execution and review.\n\n**Good trigger examples:**\n- implement protocol fires this after planning → run this protocol\n- compose protocol fires this after output generation → run this protocol\n\n**Bad trigger examples:**\n- \"Create a new protocol\" → use `author-adapter`\n- \"Implement a feature\" → use an execution protocol, not this one\n\n## Artifact Contract\n\nThis protocol receives:\n\n```text\n{\n work: {\n kind: 'file_set' | 'links' | 'git_diff' | 'pr' | 'command_output' | 'inline',\n items: string[], // paths | URLs | 'base..head' refs | PR URL/number | commands | text\n root: string // absolute cwd used to resolve relative paths, refs and commands\n },\n work_manifest: string, // absolute path to the handoff file recording `work`\n input_file: string, // accepted alias: a one-item work.kind='file_set'\n calling_protocol_slug: string,\n verification_target: string,\n requirements: string[], // original intent / requirement list to check coverage against\n context: {\n operation: string,\n verdict_file: string, // absolute path where the verdict will be written\n iteration: number, // 1-based loop pass; caller increments after each FAIL\n max_iterations: number // hard ceiling; exceeding it is a terminal FAIL\n }\n}\n```\n\nThe submission is the **work itself**, not an essay about it. Write `work` to\n`$WORK_MANIFEST` as flat keys so the handoff stays machine-checkable:\n`kind:`, `root:`, then `items:` with one item per line. Callers that still pass\nonly `input_file` are handled as `kind: file_set` with that single path; the\nreview rules do not change, only the scope of what is submitted.\n\nThis protocol produces:\n\n```text\n{\n verdict: \"PASS\" | \"FAIL\",\n confidence: \"High\" | \"Medium\" | \"Low\",\n failure_class: string, // incorrect_claim | verification_blocked | requirement_gap | iteration_ceiling\n uncovered_requirements: string[],// requirement items lacking positive evidence (empty on PASS)\n verdict_file: \"{context.verdict_file}\"\n}\n```\n\n## Precondition Check\n\nVerify foundational preconditions before deep investigation. Early-abort if any\nare broken.\n\n**Input:** `$WORK_MANIFEST` (or the older-spelling `$INPUT_FILE`), calling protocol slug, context\n\n**Actions:**\n1. Verify a submission handoff is present: `$WORK_MANIFEST`, or `$INPUT_FILE`\n when the caller passed no manifest.\n2. Verify the verdict output path is writable (parent directory exists).\n3. Load the calling protocol's Must Never / Must Always sections if possible.\n4. Verify the target state is available for review.\n5. Verify required tools are available for the submission's `kind` (a `pr`\n submission with no `gh` on the host is `verification_blocked`, not skipped).\n\n**On early-abort:**\n- verdict = `FAIL`\n- failure class = `verification_blocked`\n- confidence = `Low`\n- write focused diagnostics\n- skip all later steps\n\n**Output:** verified preconditions or early-abort diagnostics\n\n```json\n{\"contract\":{\"type\":\"shell\",\"shell\":{\"cmd\":\"test -f \\\"${WORK_MANIFEST:-}\\\" || test -f \\\"${INPUT_FILE:-}\\\"\",\"interpreter\":\"bash\",\"timeout_seconds\":3},\"required\":true}}\n```\n\n## Resolve Submission\n\nTurn the submission into the material under review. What cannot be resolved is\nnever guessed at.\n\n**Input:** `work` recorded in `$WORK_MANIFEST` (or the older-spelling `$INPUT_FILE`),\n`work.root`\n\n**Actions:**\n1. Read `kind`, `root`, `items`. An unknown `kind`, an empty `items` list, or a\n malformed manifest is `verification_blocked`.\n2. Resolve every item by kind, always from `work.root`:\n - `file_set` — read each path; relative paths resolve against `root`, and a\n missing path is `verification_blocked`.\n - `links` — fetch each URL; a URL that cannot be fetched is\n `verification_blocked`, not an `unverifiable` claim.\n - `git_diff` — `git -C \"$root\" diff <base>..<head>`, or the working tree when\n no range is given; no `git`, no repository, or a bad ref is\n `verification_blocked`.\n - `pr` — `gh pr view` plus `gh pr diff` for the number or URL; a missing\n `gh`, an expired login, or an unreachable host is `verification_blocked`.\n - `command_output` — run each command from `root` and capture stdout and\n stderr as the material.\n - `inline` — the text recorded in the manifest is the material.\n3. Record the resolved inventory before auditing: `kind`, item count, per-item\n status (`resolved` or `blocked`), and where each item's evidence lives.\n4. A `pr` or `git_diff` submission is reviewed as a diff: claims are checked\n against the changed lines and the tests they touch, never against the\n description written alongside them.\n\n**Output:** resolved work inventory for the audit\n\n```json\n{\"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}}\n```\n\n## Audit\n\nPerform bounded adversarial review of the target against the resolved work\nsubmission and invariants.\n\n**Input:** resolved work inventory, invariants, verification target, requirement list, context\n\n**Actions:**\n\n**Step 1 — Extract claims**\nExtract every verifiable claim that matters operationally:\n- workflows, commands, tool calls\n- configuration and environment variable claims\n- architecture claims that imply behaviour\n- guarantees and constraints\n- security, auth, and permission claims\n\n**Step 2 — Investigate with scope discipline**\n1. verify all in-scope claims first\n2. review high-risk claims with maximum depth\n3. expand beyond scope only when contradiction signals, dependencies, or\n high-risk impact require it\n4. continue reviewing all in-scope claims even after a normal FAIL condition is met;\n only a precondition failure stops the audit early\n\n**High-risk areas:** setup steps, CLI commands, configuration keys, authentication,\ndeployment, external publishing, destructive operations.\n\n**Step 3 — Gather evidence using the hierarchy**\n\n| Priority | Evidence source |\n|---|---|\n| 1 | source code, config files, schemas, route definitions |\n| 2 | direct runtime verification |\n| 3 | tests |\n| 4 | MCP-queried system state |\n| 5 | external docs, web pages, linked references |\n| 6 | conversational assumption or indirect inference |\n\n**Rules:** higher-priority evidence overrides lower; priority 5–6 alone is not\nenough for `verified`; a submitted link or PR description is priority 5.\n\n**Step 4 — Produce claim verdicts**\nFor each claim: CLAIM, EVIDENCE, EVIDENCE PRIORITY, VERDICT\n(`verified` / `partially_verified` / `unverifiable` / `incorrect`).\nA claim must not be marked `verified` without positive supporting evidence.\n\n**Step 5 — Review the phase boundary**\nCheck whether the calling adapter preserved the right mode boundary.\n\n**Step 6 — Check requirement coverage**\nFor every item in `requirements`, confirm coverage with positive evidence.\nAny `missing` item — or any `partial` high-risk item — forces FAIL with\n`failure_class: requirement_gap`.\n\n**Output:** structured audit findings for the verdict step\n\n```json\n{\"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}}\n```\n\n## Verdict\n\nTurn the audit into a final PASS / FAIL result.\n\n**Input:** audit findings and verdict file path from context (use it as\n`$VERDICT_FILE`)\n\n**Actions:**\n1. Fail if any critical claim is incorrect.\n2. Fail if verification was blocked.\n3. Fail if the evidence base is too weak for high-risk claims.\n4. Fail if any requirement is `missing`, or a high-risk requirement is only\n `partial` (`failure_class: requirement_gap`); list the uncovered items.\n5. Fail terminally if `context.iteration` exceeds `context.max_iterations`\n (`failure_class: iteration_ceiling`) so the loop stops instead of thrashing.\n6. Otherwise, pass with the appropriate confidence.\n7. Write `$VERDICT_FILE` so line 1 is `PASS` or `FAIL`,\n line 2 is `High`, `Medium`, or `Low`, and the remaining lines summarise key\n findings and any uncovered requirements.\n\n**Verdict contract (calling adapter must obey):**\n- Line 1 is `PASS` → the loop is satisfied; the calling adapter may continue.\n- Line 1 is `FAIL` → the calling adapter **MUST NOT** proceed to reward, **MUST\n NOT** ask the user for approval, and **MUST NOT** continue. It must address the\n findings, increment `context.iteration`, and re-invoke critic-loop.\n- `failure_class: iteration_ceiling` → stop looping and surface the unresolved\n findings; never silently pass. The ceiling bounds the loop so a weak agent\n cannot thrash forever.\n\n**Output:** final verdict file\n\n```json\n{\"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}}\n```\n\n## Reward Signal\n\nOnly reachable after all prior steps are solved.\n\nThe phase output has been independently challenged and looped until satisfied. The\nresulting verdict is more truthful because it is based on extracted claims,\nexplicit evidence, contradiction search, requirement-by-requirement coverage, and\na clean boundary between execution and review.\n",
|
|
32
|
-
"protocol-linking-guide": "---\nversion: \"5.12.
|
|
33
|
-
"refine-search": "---\nversion: \"5.12.
|
|
26
|
+
"adapter-migration": "---\nversion: \"5.12.1\"\nslug: adapter-migration\ntitle: Adapter Migration Workflow\n---\n\n# Adapter Migration Workflow\n\nBatch-migrate all adapters in a space to the current structural scheme. Exports\nevery adapter, applies conservative structural transformations, reports changes\nper adapter, and re-trains the conforming subset autonomously.\n\nThis workflow handles structural migrations only — it preserves semantic content\n(steps, intent, examples) while updating format, headings, and contract shapes\nto match the latest SQUADRULES requirements.\n\n## Activation Patterns\n\n**Run this workflow when the user says ANY of:**\n\n- \"migrate all adapters\" / \"batch update adapters\"\n- \"update adapters to latest scheme\" / \"update adapter structure\"\n- \"run structural migration\" / \"migrate adapters\"\n- \"update all my adapters\" / \"fix adapter structure\"\n- \"apply latest adapter format\" / \"restructure adapters\"\n\n**Trigger pattern:** **migrate** / **batch update** / **structural migration** /\n**update format** + (adapters | all | space).\n\n**Must Never:**\n- Alter semantic content (step text, trigger phrases, examples, intent).\n- Auto-train an adapter without first producing a per-adapter change report.\n- Guess transformations when the adapter structure is ambiguous.\n- Delete adapters or layers during migration.\n- Migrate adapters that already conform (report them as \"no changes needed\").\n\n**Must Always:**\n- Export every adapter before making any changes.\n- Apply only conservative, reversible structural transformations.\n- Flag ambiguous cases for manual review instead of guessing.\n- Produce a per-adapter change report before executing any writes.\n- Preserve the adapter's slug, version, and chain_root fields.\n\n**Good trigger examples:**\n- \"migrate all my personal adapters to the latest format\" → run this workflow\n- \"update all adapters in the team space\" → run this workflow\n\n**Bad trigger examples:**\n- \"update this one adapter\" → use `author-adapter` with `fix` operation\n- \"create a new adapter\" → use `author-adapter`\n- \"export my adapters\" → use `export` directly\n\n## Preflight Dependencies\n\nBefore running migration, verify readiness:\n\n1. `export` tool is available and callable.\n2. `tune` and `train` tools are available for writes.\n3. Target space is identified (personal or a named group space).\n4. The migration is structural-only (no semantic changes).\n\nIf any tool is unavailable, stop and report the connection blocker with\nremediation guidance.\n\n```json\n{\"contract\":{\"type\":\"shell\",\"shell\":{\"cmd\":\"echo 'preflight: migration tools verified'\",\"interpreter\":\"bash\",\"timeout_seconds\":10},\"required\":true}}\n```\n\n## Export All Adapters\n\nExport every adapter from the target space using bulk export:\n\n1. Call `export` with `all_adapters: true`, `space_name` set to the target\n space, and `format: skill_tree`.\n2. Record the total adapter count from the response.\n3. For each adapter in the response, extract its slug, URI, and content.\n\nIf the space has no adapters, report this and stop.\n\n```json\n{\"contract\":{\"type\":\"subagent\",\"subagent\":{\"instruction\":\"Export all adapters from the target space using the export tool with all_adapters: true. Record the total count and extract slug, URI, and content for each adapter.\"},\"required\":true}}\n```\n\n## Analyze and Transform\n\nFor each exported adapter, perform structural analysis and apply migrations.\n\n### Structural checks (apply all that are needed)\n\n1. **Heading order** — first H2 must be `Activation Patterns`, last H2 must be\n `Reward Signal`. If missing or out of order, flag for restructuring.\n2. **Contract fences** — all contract JSON blocks must use ` ```json ` (not\n plain ` ``` `). If plain fences contain contract JSON, convert them.\n3. **Frontmatter** — must include `slug`. Add `version` if missing. Preserve\n existing `chain_root` when present.\n4. **Line count** — adapters exceeding 350 lines must be flagged for splitting\n (do NOT auto-split; report as manual review needed).\n5. **Shell interpreter** — every shell contract must include `\"interpreter\"`\n field with an allowed value (`bash`, `sh`, `python3`, `python`, `node`).\n6. **MCP forward-link** — every mcp contract must use `tool_name: \"forward\"`\n with `arguments.uri` matching `squadrules://adapter/<slug>`.\n\n### Transformation rules\n\n- **Conservative only:** If a transformation might change meaning, skip it and\n flag for manual review.\n- **Reversible:** Every change must be expressible as a diff.\n- **Idempotent:** Running migration twice produces no additional changes.\n\nFor each adapter, produce:\n- `status`: `needs_changes` | `up_to_date` | `needs_manual_review`\n- `changes`: list of specific transformations applied\n- `warnings`: list of items flagged for manual review\n- `transformed_content`: the full updated markdown (when `needs_changes`)\n\n```json\n{\"contract\":{\"type\":\"subagent\",\"subagent\":{\"instruction\":\"Analyze each exported adapter against structural checks (heading order, contract fences, frontmatter, line count, shell interpreter, mcp forward-link). Apply conservative transformations and produce per-adapter status, changes, warnings, and transformed content.\"},\"required\":true}}\n```\n\n## Report Changes\n\nWrite the migration report to `$MIGRATION_REPORT_FILE` (absolute path under\n`$SQUADRULES_LOCAL_ARTIFACT_DIR`). Record a summary table:\n\n| Adapter slug | Status | Changes | Warnings |\n|-------------|--------|---------|----------|\n| example-adapter | needs_changes | 3 structural fixes | 0 |\n| another-adapter | up_to_date | 0 | 0 |\n\nFor each adapter with `needs_changes`, show the specific transformations.\nFor each `needs_manual_review`, explain what needs human attention.\n\nApply the migration autonomously:\n- **Apply all** `needs_changes` adapters.\n- **Leave untouched** every `needs_manual_review` adapter.\n\n```json\n{\"contract\":{\"type\":\"shell\",\"shell\":{\"cmd\":\"test -f \\\"$MIGRATION_REPORT_FILE\\\" && grep -c '|' \\\"$MIGRATION_REPORT_FILE\\\" | test $(cat) -gt 1\",\"interpreter\":\"bash\",\"timeout_seconds\":10},\"required\":true}}\n```\n\n## Execute Migration\n\nFor each `needs_changes` adapter, apply the structural changes:\n\n1. For adapters needing only content-level fixes (heading reorder, fence\n conversion, interpreter addition): use `tune` with the transformed content\n and the adapter's URI.\n2. For adapters needing structural changes that alter layer count or identity:\n use `train` with `force_update: true` and the transformed content.\n3. Record the outcome (success or failure) for each adapter.\n\nDo NOT change the adapter's space assignment during migration.\n\n```json\n{\"contract\":{\"type\":\"subagent\",\"subagent\":{\"instruction\":\"Execute the migration: for each needs_changes adapter, call tune (content-level fixes) or train with force_update (structural changes). Record success/failure per adapter.\"},\"required\":true}}\n```\n\n## Verify and Report\n\nAfter executing all migrations:\n\n1. Re-export each migrated adapter to verify structural compliance.\n2. Report final status:\n\n| Metric | Count |\n|--------|-------|\n| Adapters scanned | N |\n| Already up to date | N |\n| Successfully migrated | N |\n| Migration failed | N |\n| Flagged for manual review | N |\n\n3. For each failure, report the error message and suggested fix.\n4. Recommend running `critic-loop` on migrated adapters to verify semantic\n integrity after structural changes.\n\n```json\n{\"contract\":{\"type\":\"comment\",\"comment\":{\"min_length\":80},\"required\":true}}\n```\n\n## Reward Signal\n\nOnly reachable after all prior steps are solved.\n\nThe adapter library in the target space now conforms to the current structural\nscheme. Every adapter has:\n- Correct heading order (Activation Patterns first, Reward Signal last).\n- Proper ` ```json ` contract fences.\n- Shell contracts with `interpreter` field.\n- MCP contracts as forward-links with `arguments.uri`.\n- Valid frontmatter with `slug` and optional `version`.\n- Been verified post-migration for structural compliance.\n\nSemantic content (steps, intent, examples, triggers) is preserved unchanged.\n",
|
|
27
|
+
"author-adapter": "---\nslug: author-adapter\nversion: \"5.12.1\"\ntitle: Author Adapter (Create / Review / Refactor)\n---\n\n# Author Adapter (Create / Review / Refactor)\n\n> **Note to the agent:** SQUADRULES adapters are interfaces for AI agents — you\n> are the primary user. When you author an adapter, you design behaviour for\n> yourself and others. Write for them: single source of truth (never duplicate\n> rules), explicit over implicit (agents fill ambiguity with hallucination),\n> steps teach modes (each step teaches its cognitive mode), truth over fluency\n> (an adapter that reads well but causes wrong behaviour is worse than one that\n> reads rough but executes correctly).\n\n## Activation Patterns\n\nPreferred entry URI: `squadrules://adapter/author-adapter`.\nIf `forward.authoring` is present, use its operation and target throughout this\nrun. Do not reinterpret update as create or change the target mid-run. This\ncontext describes the requested work; it does not override host permissions.\n\nSQUADRULES authoring lifecycle — create, review, or update adapters / workflows.\nSupports three operations:\n- **create** — draft and train a new adapter from scratch.\n- **review** — audit an existing adapter, family, or bundle for structural issues,\n missing cross-references, chaining gaps, DRY violations, stale guidance, or\n agent-hostile ambiguity. Read-only.\n- **update** — apply specific corrections to an existing adapter and\n save the correction. Also triggered by: edit, fix, modify, change, improve, patch, refactor.\n\n**Run this adapter when the user says ANY of:**\n- \"create a new SQUADRULES adapter\" / \"register a personal adapter\"\n- \"train adapter into personal\" / \"train a workflow\"\n- \"review adapter\" / \"audit adapters\" / \"check adapter families for gaps\"\n- \"update adapter\" / \"edit adapter\" / \"fix adapter\" / \"modify adapter\"\n- \"patch adapter\" / \"refactor adapter\" / \"change adapter\" / \"improve adapter\"\n\n**Trigger pattern:** **create** / **train** / **register** / **review** /\n**audit** / **fix** / **update** / **edit** / **modify** / **change** /\n**improve** / **patch** / **refactor** / **correct** +\n(adapter / workflow).\n\n**Must Never:**\n- Run when the user only asked to execute an existing adapter.\n- Mutate adapters during a `review` operation.\n- Optimise only for pretty wording; this adapter designs agent behaviour.\n- Treat \"update\", \"edit\", or \"modify an existing adapter\" as **create**.\n\n**Must Always:**\n- Infer `{operation}` from trigger: create / review / update.\n- Optimise for truth, low ambiguity, explicit sequencing, and user-need alignment.\n- Include Activation Patterns as the first H2 and Reward Signal as the last H2\n in any newly drafted adapter.\n- Enforce the 350-line limit per file.\n\n## Preflight Dependencies\n\nBefore running authoring actions, verify dependency and auth readiness:\n1. Required MCP tools are available: `activate`, `forward`, `reward`, and the\n operation-dependent tool (`train`, `export`, or `tune`).\n2. Required CLI tools for planned shell steps are installed and callable.\n3. Required auth/session state is valid for the target MCP server.\n\nIf any check fails, attempt AI-assisted remediation automatically, then re-run\npreflight. Only hard-stop when a required tool or auth genuinely cannot be\nestablished autonomously.\n\n```json\n{\"contract\":{\"type\":\"shell\",\"shell\":{\"cmd\":\"echo 'preflight: ok'\",\"interpreter\":\"bash\",\"timeout_seconds\":10},\"required\":true}}\n```\n\n## Resolve Intent Autonomously\n\nUse structured `authoring` when provided. For original calls without it, infer\n`{operation}` from the user's trigger — do not stop to ask for confirmation:\n\n| Signal | Operation |\n|---|---|\n| \"create\", \"new\", \"train\", no match from activate | **create** |\n| \"review\", \"audit\", \"check\", \"gaps\", \"cross-references\" | **review** |\n| \"update\", \"edit\", \"fix\", \"modify\", \"change\", \"improve\", \"patch\", \"refactor\" | **update** |\n\nResolve the target from context without a confirmation prompt. Record the\ninferred operation and target, then continue. Escalate to the user only when\nthe request is genuinely ambiguous and no reasonable default exists.\n\n```json\n{\"contract\":{\"type\":\"subagent\",\"subagent\":{\"instruction\":\"Resolve the authoring operation (create/review/update) and target adapter from user context. Record the decision.\"},\"required\":true}}\n```\n\n## Gather Requirements\n\n### For `create` — collect details for a new adapter\n\n**1. Determine the pattern:**\n\n| Signal | Pattern |\n|---|---|\n| One workflow, no variants | **Standalone** — one adapter, all steps inline |\n| Multiple issue types / output formats | **Router + Extensions** — router classifies, routes via `activate` |\n| Exceeds 350 lines or too complex for weaker models | **Chain** — split into sequential adapters linked via `forward` + slug |\n\n**2. Collect per adapter:**\n- Title, user problem, agent behaviour, mode map, steps, challenge type per step\n- Domain reference, existing adapters to reuse/compose, DRY/size check\n- Chain position, failure analysis\n\n### For `review` — audit existing adapters\n\nExport target adapter(s). Check: user-need fit, mode/step clarity,\ncross-reference completeness, handoff gaps, DRY violations, contract coverage,\ntruth-first behaviour, activation pattern accuracy, structure compliance\n(first H2 Activation Patterns, last H2 Reward Signal, under 350 lines),\nsibling consistency, chained adapter families, critic-loop integration.\n\n### For `update` — identify the specific issue\n\nExport the target adapter, read the current markdown, identify the exact gap or\nerror, and plan the minimal change.\n\n```json\n{\"contract\":{\"type\":\"subagent\",\"subagent\":{\"instruction\":\"Gather requirements for the resolved operation: collect pattern/details for create, audit checklist for review, or identify the specific issue for update.\"},\"required\":true}}\n```\n\n## Draft Markdown\n\n### MCP / Local-Filesystem Boundary\n\n- A personal adapter stored in MCP **cannot** reference local files.\n- Only **system adapters** (bundled in the server) can chain to other system\n adapters via `forward`.\n- Personal adapters must be **self-contained**.\n- When a shell contract needs a reusable script, attach it as an **artifact**\n via `train` (with `mime`, `artifact_name`, `adapter_uri`).\n\n### Drafting rules (all operations)\n\n**Right mode at the right time:** Every adapter must help the agent recognise\nwhether the current step is for exploration, clarification, ideation, planning,\nexecution, validation, review, or handoff.\n\n**Truth over fluency:** Prefer explicit prompts, stop conditions, uncertainty\nescalation, and observable verification over narrative reassurance.\n\n**DRY:** Shared content across adapters must live in one place.\n\n**350-line maximum per file.** Split into linked adapters if exceeded.\n\n**Slug convention:** Every adapter gets a short, unique, lowercase-hyphenated slug.\n\n**Structure:** H1 title, first H2 Activation Patterns, second H2 Preflight\nDependencies, middle H2s one per step with JSON contract block, last H2 Reward\nSignal. Frontmatter: `slug` (required), `version` (optional), `chain_root`\n(required for mid-chain adapters).\n\n**Challenge types:** Load `challenge-type-guide` for decision rules and JSON\nformats (`forward` with `squadrules://adapter/challenge-type-guide`).\n\n**Critic-loop and mutation gates:** Load `critic-loop-guide` for placement,\nFAIL gate, and solution check rules (`forward` with\n`squadrules://adapter/critic-loop-guide`).\n\nFor `create`: draft the full adapter markdown.\nFor `review`: write a structured gap report to `$REVIEW_FINDINGS_FILE`.\nFor `update`: apply the identified change and show a diff-style summary.\n\n```json\n{\"contract\":{\"type\":\"subagent\",\"subagent\":{\"instruction\":\"Draft the adapter markdown (create), findings report (review), or corrected markdown (update) following all shared drafting rules.\"},\"required\":true}}\n```\n\n## Critic-Loop Review (create and update only)\n\nFor `create` and `update`: run critic-loop against the drafted markdown. This is\nan autonomous quality loop — the agent owns content, the critic owns quality, and\nno human approval is requested at any point.\n\n1. Invoke critic-loop via `forward` with `squadrules://adapter/critic-loop`.\n Submit the drafted markdown as a `file_set` work submission — write\n `kind: file_set`, `root: <directory of the draft>`, then the drafted file\n under `items:` into the handoff pointed to by `$WORK_MANIFEST` — with the\n slug as `calling_protocol_slug` and \"structural compliance and agent\n behaviour\" as `verification_target`.\n2. Run the FAIL gate shell contract on the verdict file:\n\n```json\n{\"contract\":{\"type\":\"shell\",\"shell\":{\"cmd\":\"head -1 \\\"$VERDICT_FILE\\\" | grep -qi '^PASS$'\",\"interpreter\":\"bash\",\"timeout_seconds\":5},\"required\":true}}\n```\n\n3. If FAIL: address every finding, then re-invoke critic-loop and re-run the FAIL\n gate. **Loop automatically until the verdict is PASS** — do not proceed and do\n not ask the user whether to continue.\n4. If PASS: capture the verdict file path for the `review_evidence` field\n in the `train` call below.\n\nFor `review`: skip this step (read-only operation).\n\n## FinaliseOperation\n\nNo human approval step. The critic-loop PASS verdict is the sole quality gate.\n\nFor `create`: call `train` with the drafted markdown and `review_evidence`\nfrom the critic-loop step. Use `force_update: false` unless overwrite was\nexplicitly requested.\n\nFor `review`: do not call `train`. Save the findings report only if requested.\n\nFor `update`: use `tune` with the existing adapter URI, corrected content, and\n`review_evidence`. Use `train` with `force_update: true` only for a required\nstructural replacement (changing identity/H1 mapping or layer count). Update the\ncorresponding repository source when the adapter is repo-managed; make repository\nedits in the task's isolated worktree.\n\nReport the outcome: adapter URI(s) for create/update, or findings summary for\nreview.\n\n```json\n{\"contract\":{\"type\":\"comment\",\"comment\":{\"min_length\":80},\"required\":true}}\n```\n\n## Reward Signal\n\nAdapter complete when:\n- `create` — adapter(s) stored via `train` (with review_evidence) and URI(s) reported\n- `review` — findings report delivered\n- `update` — corrected adapter saved via `tune` (or required structural replacement),\n read back and verified; repo-managed source updated in the task worktree\n\nA successful result means the resulting SQUADRULES adapter is more truthful,\nstep-aware, agent-readable, and aligned with human–AI harmony.\n",
|
|
28
|
+
"bulk-insert-adapters-via-cli": "---\nslug: bulk-insert-adapters-via-cli\nversion: \"5.12.1\"\ntitle: Bulk Insert Adapters via SQUADRULES CLI\n---\n\n# Bulk Insert Adapters via SQUADRULES CLI\n\n## Activation Patterns\n\nBatch-register multiple SQUADRULES adapters from a local directory tree using the\n`squadrules train` CLI. Handles directory scanning, validation, space targeting,\nand error recovery for bulk operations.\n\n**Run this workflow when the user says ANY of:**\n\n- \"bulk insert adapters\" / \"bulk train adapters\"\n- \"train all adapters in a directory\"\n- \"batch register adapters from folder\"\n- \"upload all .md files to SQUADRULES\"\n- \"sync local adapters to SQUADRULES\" / \"push adapters to SQUADRULES\"\n- \"train directory recursively\" / \"train --recursive\"\n\n**Trigger pattern:** **bulk** / **batch** / **all** / **directory** / **recursive** +\n(train | insert | register | upload | push | sync) + (adapters | workflows).\n\n**Must Never:**\n\n- Train files without first validating their structure.\n- Overwrite existing adapters without explicit `--force`.\n- Train files that contain secrets or token-like strings without\n `--allow-sensitive-upload`.\n- Skip reporting partial failures in a batch.\n\n**Must Always:**\n\n- Verify the target directory exists and contains `.md` files.\n- Show the file list and target space before executing.\n- Report per-file success/failure after the batch completes.\n- Respect the user's choice of space (personal or group).\n\n**Good trigger examples:**\n\n- \"Train all adapters in my-adapters/\" → run this workflow\n- \"Bulk insert the adapters from my export folder\" → run this workflow\n- \"Push all .md files in this directory to my personal space\" → run this workflow\n\n**Bad trigger examples:**\n\n- \"Train this one adapter\" → use `squadrules train <file>` directly\n- \"Create a new adapter\" → use `author-adapter`\n- \"Export my adapters\" → use `squadrules export`\n\n## Preflight Dependencies\n\nVerify before execution:\n\n1. `squadrules` CLI is installed and callable (`squadrules --version`).\n2. Authentication is valid (`squadrules token` returns a token without error).\n3. Target directory path exists and contains at least one `.md` file.\n4. If a space is specified, confirm it exists via `squadrules spaces`.\n\nIf any check fails, stop and report the issue with remediation guidance.\n\n```json\n{\"contract\":{\"type\":\"shell\",\"shell\":{\"cmd\":\"squadrules --version && squadrules token > /dev/null 2>&1 && echo 'auth: ok'\",\"interpreter\":\"bash\",\"timeout_seconds\":15},\"required\":true}}\n```\n\n## Resolve Scope and Validate\n\nResolve the batch operation details autonomously:\n\n1. **Source directory** — absolute path.\n2. **File count** — number of `.md` files found (recursive or flat).\n3. **Target space** — personal (default) or a named group space.\n4. **Force mode** — whether `--force` will be used (overwrites existing).\n\nValidate each `.md` file against SQUADRULES adapter requirements:\n- Has an H1 title.\n- First H2 is \"Activation Patterns\".\n- Last H2 is \"Reward Signal\".\n- Contains at least one fenced `json` block with a top-level `contract` object.\n- Does not exceed 350 lines.\n\nSkip invalid files, train the valid subset, and document every skipped file with\nits validation error and a suggested fix. Do not stop to ask the user.\n\n```json\n{\"contract\":{\"type\":\"shell\",\"shell\":{\"cmd\":\"test -d \\\"$SOURCE_DIR\\\" && find \\\"$SOURCE_DIR\\\" -name '*.md' | head -1 | grep -q .\",\"interpreter\":\"bash\",\"timeout_seconds\":10},\"required\":true}}\n```\n\n## Execute Bulk Train\n\nRun the batch train operation using the SQUADRULES CLI:\n\n```\nsquadrules train <directory> --recursive --model <model> --space <space> [--force]\n```\n\nIf the directory contains files that should NOT be trained (README, reference\ndocs), either train file-by-file for the valid subset, or move non-adapter files\nout before running `--recursive`.\n\nCapture stdout and stderr. The CLI reports per-file status.\n\n```json\n{\"contract\":{\"type\":\"shell\",\"shell\":{\"cmd\":\"squadrules train \\\"$SOURCE_DIR\\\" --recursive --model \\\"$MODEL_ID\\\" --space \\\"$TARGET_SPACE\\\"\",\"interpreter\":\"bash\",\"timeout_seconds\":120},\"required\":true}}\n```\n\n## Report Results\n\nSummarise the batch outcome:\n\n| Metric | Value |\n|--------|-------|\n| Files attempted | N |\n| Successfully trained | N |\n| Failed | N |\n| Skipped (invalid) | N |\n\nFor each failure, report: file path, error message, suggested fix.\nIf all succeeded, confirm adapter URIs are accessible via `squadrules spaces`.\n\n```json\n{\"contract\":{\"type\":\"comment\",\"comment\":{\"min_length\":80},\"required\":true}}\n```\n\n## Reward Signal\n\nWorkflow complete when:\n- All valid adapter files in the target directory have been trained to the\n specified space.\n- Per-file results have been reported.\n- Any failures have been documented with remediation guidance.\n\nA successful bulk insert means the user's local adapter library is now\nregistered in SQUADRULES and available for activation by AI agents.\n",
|
|
29
|
+
"challenge-type-guide": "---\nversion: \"5.12.1\"\nslug: challenge-type-guide\ntitle: Challenge Type Selection Guide\n---\n\n# Challenge Type Selection Guide\n\nDecision rules, JSON formats, interpreter selection, and anti-patterns for\nchoosing SQUADRULES challenge types. Loaded by adapter-authoring agents during\ndrafting and review.\n\n## Activation Patterns\n\n**Typically invoked by:** `author-adapter` and `critic-loop`.\n\n**Can be invoked directly when agent needs:**\n- \"challenge type reference\" / \"which challenge type to use\"\n- \"how to write shell challenges\" / \"challenge format\"\n- \"interpreter selection for challenges\"\n\n**Trigger pattern:** **challenge** + (type | format | selection | guide).\n\n**Must Never:**\n- Be used as an execution adapter.\n- Select `comment` merely because it is easy.\n\n**Must Always:**\n- Be consulted before assigning challenge types to adapter steps.\n- Choose the strongest observable contract available.\n- Match challenge choice to the mode of the step: ask, decide, act, verify, or review.\n\n**Good trigger examples:**\n- drafting a new adapter and need challenge types → load this\n- reviewing challenge type selection in a draft → load this\n\n**Bad trigger examples:**\n- \"Create a new adapter\" → use `author-adapter`\n- \"Review my adapter draft\" → use `critic-loop`\n\n## Core Rules\n\n`comment` is the challenge type of **last resort**. If a step produces any\nobservable artifact — a file, a git state change, an API response, or an exit\ncode — use `shell` or `subagent` instead.\n\n**Mode before challenge type:**\n- **clarify / approve** → `user_input`\n- **chain to another adapter** → `mcp` (forward-link only)\n- **execute or verify local state** → `shell`\n- **delegate to another agent** → `subagent`\n- **pure reasoning with no observable artifact** → `comment`\n\n### Decision Tree\n\n```\nDoes the step chain to another adapter via forward?\n ├─ YES → \"mcp\" forward-link (tool_name: \"forward\", arguments.uri: squadrules://adapter/<slug>)\n └─ NO → Does the step produce or verify a file, command result, or system state?\n ├─ YES → \"shell\" (with interpreter)\n └─ NO → Does the step require human approval or choice?\n ├─ YES → \"user_input\"\n └─ NO → Does the step delegate work to another agent?\n ├─ YES → \"subagent\"\n └─ NO → \"comment\" (last resort — no stronger contract possible)\n```\n\n### Challenge JSON Formats\n\n**shell** (interpreter is REQUIRED)\n```json\n{\"contract\":{\"type\":\"shell\",\"shell\":{\"cmd\":\"<command>\",\"interpreter\":\"bash\",\"timeout_seconds\":30},\"required\":true}}\n```\n\nAllowed interpreters: `bash`, `sh`, `python3`, `python`, `node`. Build tools\n(`terraform`, `docker`, `npm`, etc.) are **not** interpreters — wrap them in a\n`bash` command instead.\n\n**mcp** (forward-link only — bare tool_name checks are not valid)\n```json\n{\"contract\":{\"type\":\"mcp\",\"mcp\":{\"tool_name\":\"forward\",\"arguments\":{\"uri\":\"squadrules://adapter/<slug>\"}},\"required\":true}}\n```\n\nThe server validates that `solution.mcp.arguments` is a superset of the\ncontract's `mcp.arguments` (subset/deep matching), proving the agent called\n`forward` with the correct target slug.\n\n**user_input**\n```json\n{\"contract\":{\"type\":\"user_input\",\"user_input\":{\"prompt\":\"<specific question>\"},\"required\":true}}\n```\n\n**subagent**\n```json\n{\"contract\":{\"type\":\"subagent\",\"subagent\":{\"instruction\":\"<task description>\"},\"required\":true}}\n```\n\nUse `subagent` when a step delegates work to another agent (human or AI) rather\nthan executing it directly. The `instruction` field provides task-specific\nguidance. Evidence of completion is collected via the anti-cheat evidence gate.\n\n**comment** (last resort — max 1 per adapter, closing ACK only)\n```json\n{\"contract\":{\"type\":\"comment\",\"comment\":{\"min_length\":50},\"required\":true}}\n```\n\n### Solution JSON Formats\n\nEvery solution follows the same envelope:\n\n```json\n{\n \"type\": \"<challenge_type>\",\n \"outcome\": \"success | failure | skipped\",\n \"evidence\": { /* type-specific proof data */ },\n \"nonce\": \"<echo from contract>\",\n \"proof_hash\": \"<echo from contract>\"\n}\n```\n\n**shell solution**\n```json\n{\"type\":\"shell\",\"outcome\":\"success\",\"evidence\":{\"exit_code\":0,\"stdout\":\"...\",\"stderr\":\"\",\"duration_seconds\":1.2}}\n```\n\n**mcp solution**\n```json\n{\"type\":\"mcp\",\"outcome\":\"success\",\"evidence\":{\"tool_name\":\"forward\",\"arguments\":{\"uri\":\"squadrules://adapter/critic-loop\"},\"response\":{}}}\n```\n\n**subagent solution**\n```json\n{\"type\":\"subagent\",\"outcome\":\"success\",\"evidence\":{\"agent_id\":\"agent-uuid\",\"artifacts\":[\"path/to/output\"],\"summary\":\"Task completed\"}}\n```\n\n**comment solution**\n```json\n{\"type\":\"comment\",\"outcome\":\"success\",\"evidence\":{\"text\":\"Verified all items are complete.\"}}\n```\n\n**user_input solution**\n```json\n{\"type\":\"user_input\",\"outcome\":\"success\",\"evidence\":{\"confirmation\":\"agreed. proceed\",\"timestamp\":\"2026-05-18T14:49:00Z\"}}\n```\n\n## Interpreter Selection\n\n| Task | Interpreter |\n|---|---|\n| File exists, tool installed, git state | `bash` |\n| Simple content grep | `bash` |\n| Multi-line regex or paragraph processing | `python3` |\n| JSON validation | `bash` (jq) or `python3` |\n| YAML / complex data structure checks | `python3` |\n| Node.js ecosystem tools | `node` |\n\n**Rule of thumb:** default to `bash`. If you need multi-line regex, imports for\ndata formats, or complex string processing, use `python3`. Use `node` only when\nthe check requires the Node.js runtime.\n\n## Security and Working Directory Rules\n\nUse `$SQUADRULES_LOCAL_ARTIFACT_DIR` as the base directory for local handoff\nartifacts. File paths within it are provided as variables by the invoking agent\nto avoid collisions between parallel sessions.\n\n**Rules:**\n- all file paths in shell challenges reference variables (e.g., `$DRAFT_FILE`,\n `$VERDICT_FILE`) set by the parent agent — never hardcode filenames\n- the parent agent constructs collision-free paths under\n `$SQUADRULES_LOCAL_ARTIFACT_DIR`\n- when using SQUADRULES MCP, the latest `activate` / `forward` / `next` response\n field `squadrules_local_artifact_dir` is an ordered array of URI hints\n (`project://<rel>`, `user://<rel>`); pick one, resolve on your machine, and\n `export SQUADRULES_LOCAL_ARTIFACT_DIR=\"<absolute>\"`\n- prerequisites create the directory; Reward Signal cleans it up\n- never write credentials or secrets to files\n\n### Resolving `project://` and `user://` URI hints\n\n| Scheme | Resolution | Example |\n|--------|-----------|--------|\n| `project://<rel>` | `<IDE project root>/<rel>` | `project://.local/squadrules/work` |\n| `user://<rel>` | `<$XDG_CONFIG_HOME or $HOME>/<rel>` | `user://.config/squadrules/work` |\n\nWhen your session spans multiple projects, prefer `user://` to avoid ambiguity.\n\n### Worktree placement (for task-isolation adapters)\n\nWhen an adapter requires a git worktree for isolation, the worktree path MUST\nbe **outside** every existing checkout:\n\n```\nREPO_ROOT=/home/user/repos/my-project\n# RIGHT: sibling of the repo\nWT=/home/user/repos/mcp.worktrees/<task-id>\n# WRONG: inside the checkout\n# WT=/home/user/repos/my-project/.mcp.worktrees/<task-id>\n```\n\n**Rule of thumb:** `$(dirname \"$REPO_ROOT\")/mcp.worktrees/<task-id>`\n\n### IDE worktree access limitations\n\nMost IDE file tools scope operations to the open project root. They **cannot**\nreach worktrees placed outside `$REPO_ROOT`. Use the terminal/shell tool for\nexternal worktrees, or open the worktree as a separate project window.\n\n## Composition Patterns\n\n**Multi-check compound command** — chain with `&&`, let the first failure stop.\n\n**Agent-readable shell status** — preserve the original exit status:\n```bash\n( set -o pipefail; <command> ); rc=$?; printf '\\nSQUADRULES_SHELL_EXIT=%s\\n' \"$rc\" >&2; exit \"$rc\"\n```\n\n**Freeze-then-verify** — step N writes checksum, step N+1 verifies before publish.\n\n**Write-then-grep** — subagent writes a verdict file, main agent checks line 1.\n\n**Phase-batch with critic** — batch related items, verify hard artifacts with\nshell, then call `critic-loop` for adversarial review.\n\n**Chain-link via forward + slug** — layer N's contract requires `forward` with a\nspecific adapter slug. Use when the adapter exceeds 350 lines or needs\nmulti-path routing. Example:\n```json\n{\"contract\":{\"type\":\"mcp\",\"mcp\":{\"tool_name\":\"forward\",\"arguments\":{\"uri\":\"squadrules://adapter/implement-plan\"}},\"required\":true}}\n```\n\n## Artifacts for Shell Contracts\n\nWhen a shell contract needs a reusable script, **attach it as an artifact**\nrather than inlining it in the contract JSON:\n\n1. Write the script file.\n2. `train` with `mime: \"text/x-python\"`, `artifact_name: \"isolation-guard.py\"`,\n `adapter_uri: \"squadrules://adapter/my-adapter\"`, and the script content.\n3. In the shell contract, reference it via `export` with\n `squadrules://artifact/{uuid}` at execution time.\n\nThis keeps adapter markdown clean and makes scripts independently versionable.\n\n```json\n{\"contract\":{\"type\":\"comment\",\"comment\":{\"min_length\":30},\"required\":true}}\n```\n\n## Reward Signal\n\nOnly reachable after all prior steps are solved.\n\nThe agent can now:\n1. pick the correct challenge type for each adapter step\n2. match challenge type to the step's mode\n3. choose the right interpreter (bash, python3, node)\n4. apply working-directory and security rules\n5. use forward-link mcp contracts for chain links\n6. use subagent contracts for delegated work\n7. apply stronger verification patterns instead of weak comment checks\n",
|
|
30
|
+
"critic-loop-guide": "---\nversion: \"5.12.1\"\nslug: critic-loop-guide\ntitle: Critic Loop Integration and Mutation Gate Guide\n---\n\n# Critic Loop Integration and Mutation Gate Guide\n\nDecision rules for integrating `critic-loop` into adapter protocols: when a\nsolution check (hard verification gate) is required versus when critic-loop\nreview is sufficient, and how to split and batch proofs so reversible work stays\ncheap while irreversible boundaries stay guarded.\n\n## Activation Patterns\n\n**Typically invoked by:** `author-adapter` during adapter drafting, and\nany adapter that includes review or validation phases.\n\n**Can be invoked directly when agent needs:**\n- \"when to add critic loop\" / \"should I use solution check\"\n- \"mutation gate rules\" / \"which actions need hard gates\"\n- \"critic loop vs solution check\" / \"irreversible action rules\"\n- \"add review step to protocol\" / \"where does critic go\"\n\n**Trigger pattern:** **critic loop** / **mutation gate** / **solution check** +\n(integration | when | rules | guide | which | where).\n\n**Must Never:**\n- Be used as an execution protocol.\n- Override the adapter author's judgment on review depth.\n- Recommend solution checks for reversible or local-only actions.\n\n**Must Always:**\n- Distinguish between quality review (critic-loop) and mutation blocking\n (solution checks).\n- Recommend looping critic-loop until PASS at every major phase boundary, fed the\n requirement list and bounded by an iteration ceiling.\n- Restrict solution checks to irreversibility boundaries, and batch reversible\n checkable steps into one strict-conjunction proof.\n\n**Good trigger examples:**\n- drafting a new adapter and deciding where to add review → load this\n- reviewing whether an adapter has the right solution checks → load this\n- \"does my MR step need a solution check?\" → load this\n\n**Bad trigger examples:**\n- \"run the critic loop\" → use `activate` to match `critic-loop`\n- \"create a new protocol\" → use `author-adapter`\n- \"which challenge type for this step?\" → use `challenge-type-guide`\n\n## Core Decision Rule\n\n**Critic-loop** is an adversarial review the calling protocol **loops until it\nreturns PASS** — not a one-shot step. It verifies claims, gathers evidence,\nsearches for contradictions, and checks the work against the original requirement\nlist. Use it for quality and truthfulness review, and whenever a step is\nnon-deterministic or has no objective proof. Run it **before** the work is handed\nto the next step, and before it is presented to the human.\n\n**Solution checks** are per-layer contract verification mechanisms (shell\ncommands, MCP tool calls). Use them ONLY where getting it wrong is expensive or\nimpossible to undo — **irreversible changes on remote systems** and the local\npreconditions that guard them (for example, being on a throwaway worktree/branch\nbefore you commit). Everything else is reversible: give the agent freedom and\nreview with critic-loop instead of adding a hoop.\n\n### What counts as an irreversible remote mutation\n\n| Action | Needs solution check? | Why |\n|--------|----------------------|-----|\n| Create/update merge request | Yes | Remote system state change |\n| Create/update Jira issue | Yes | Remote system state change |\n| Send email | Yes | Cannot unsend |\n| Send Teams message | Yes | Cannot unsend |\n| Create calendar invite | Yes | Sends notifications |\n| Deploy to production | Yes | Irreversible infrastructure change |\n| Delete remote resource | Yes | Irreversible |\n| Push to git remote | Yes | Remote state change |\n| Write/edit local file | No | Use critic-loop instead |\n| Run local tests | No | Read-only / local |\n| Analyze code | No | Read-only |\n| Generate report | No | Local artifact |\n| Read data from API | No | Read-only |\n| Compute / transform data | No | Local operation |\n\n```json\n{\"contract\":{\"type\":\"comment\",\"comment\":{\"min_length\":30},\"required\":true}}\n```\n\n## Proof Splitting: Batch Checkable Steps Into One Proof\n\nSplit proofs by **reversibility cost**, not by step count:\n\n- **One proof per irreversibility boundary.** A boundary is where undoing the next\n part is expensive or impossible: commit to `main`, mutate the human's active\n worktree, `git push`, `gh pr create`, deploy, send.\n- **Batch reversible, checkable steps** and verify them together afterward with a\n single aggregate proof — fewer round-trips, same guarantee.\n- **The aggregate proof must be a strict conjunction** that re-verifies every\n sub-condition (`A && B && C && echo OK`):\n\n```json\n{\"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}}\n```\n\n- **Never let an aggregate proof degrade to `echo \"done\"`.** A proof that asserts\n nothing is worse than no gate because it looks like one. If you cannot write a\n real conjunction, the step is non-deterministic → review it with critic-loop\n instead of faking a proof.\n\n### Guard the boundary before you cross it\n\nThe cheapest proof is the precondition that stops an irreversible mistake before\nit happens — for example, confirm you are on a throwaway worktree and branch (not\n`main`, not the human's active checkout) **before** making changes:\n\n```json\n{\"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}}\n```\n\n## How to Chain Critic-Loop into an Adapter\n\nUse `forward` + slug to invoke `critic-loop` at phase boundaries. The standard\npattern is a `mcp` contract that requires calling `forward` with the\n`critic-loop` slug:\n\n### After a planning phase\n\n```json\n{\"contract\":{\"type\":\"mcp\",\"mcp\":{\"tool_name\":\"forward\",\"arguments\":{\"uri\":\"squadrules://adapter/critic-loop\"}},\"required\":true}}\n```\n\n### After an implementation phase\n\nUse the same contract. The critic-loop adapter receives the calling protocol's\ncontext and independently verifies the work.\n\n### What to submit for review\n\nThe submission is the **work itself**, not a summary of it. Pass `work` with a\n`kind`, an `items` list, and the absolute `root` the items resolve against:\n\n| `kind` | `items` contain | Resolved by | Typical work |\n|---|---|---|---|\n| `file_set` | paths (absolute, or relative to `root`) | read each file | docs, generated code, configs |\n| `links` | URLs, `squadrules://` resource URIs | fetch each one | published pages, external references |\n| `git_diff` | `base..head` refs, or empty for the working tree | `git diff` | an unpushed implementation |\n| `pr` | PR numbers or URLs | `gh pr view` + `gh pr diff` | a reviewable pull request |\n| `command_output` | commands to run from `root` | run and capture | migrations, builds, data pulls |\n| `inline` | the text itself | read the manifest | a plan, a decision, a message draft |\n\nRecord `work` in the handoff file pointed to by `$WORK_MANIFEST`, as flat keys —\n`kind:`, `root:`, then `items:` with one item per line — so the precondition\nstays a machine-checkable file test instead of prose:\n\n```json\n{\"contract\":{\"type\":\"shell\",\"shell\":{\"cmd\":\"test -f \\\"${WORK_MANIFEST:-}\\\" || test -f \\\"${INPUT_FILE:-}\\\"\",\"interpreter\":\"bash\",\"timeout_seconds\":3},\"required\":true}}\n```\n\nAnything that cannot be resolved is `verification_blocked` — an item the critic\ncould not read is never treated as an item that passed. `input_file` still works\nand means a one-item `file_set`; prefer `work_manifest` for anything that is not\na single document. A `pr` or `git_diff` submission is judged on the diff and the\ntests it touches, not on the description written next to it.\n\n### Feed it the requirements, then loop with a ceiling\n\nPass the original requirement list in the forward context. A critic that sees only\nthe output can check internal consistency but **cannot detect an omitted\nrequirement** — omission leaves no trace in the artifact — so \"no requirements\nlost\" is only enforceable if the critic is given the list and asserts coverage\nitem by item. Then loop: on FAIL, fix, increment `iteration`, and re-invoke until\nPASS or until `max_iterations` is reached. The ceiling is a hard stop that\nsurfaces the unresolved findings; it prevents a weak agent from thrashing forever.\n\n### Verdict handoff pattern\n\nCritic-loop writes a verdict file. The calling adapter reads it:\n\n1. Critic-loop writes `$VERDICT_FILE` with `PASS`/`FAIL` on line 1.\n2. Calling adapter's next layer reads the verdict file.\n3. If `FAIL` → **hard stop**: do NOT proceed to reward, do NOT ask the user\n for approval, do NOT continue to the next phase. Address findings first.\n4. If `PASS` → the adapter continues to the next phase.\n\n**FAIL is a hard stop, not an escalation trigger.** A FAIL verdict means the\nwork is not ready. Asking the user \"should I proceed?\" after FAIL bypasses the\nreview. The correct action is to fix the findings and re-invoke critic-loop.\n\n### FAIL gate contract (required after every critic-loop invocation)\n\nEvery adapter that chains critic-loop **must** include a shell contract that\nfails when the verdict is not PASS. This is the mechanical guard that prevents\nweaker agents from proceeding after FAIL:\n\n```json\n{\"contract\":{\"type\":\"shell\",\"shell\":{\"cmd\":\"head -1 \\\"$VERDICT_FILE\\\" | grep -qi '^PASS$'\",\"interpreter\":\"bash\",\"timeout_seconds\":5},\"required\":true}}\n```\n\nIf the critic wrote FAIL, this shell command exits non-zero. The server rejects\nthe solution and the agent cannot advance to the next layer. Protocol wording\nalone does not stop determined agents; this contract does.\n\n## Train/Tune Evidence Requirement\n\n`train` and `tune` enforce critic-loop PASS at the tool level:\n\n- **Adapter (markdown) `train`** requires `review_evidence`: verdict_file path,\n exit_code (must be 0), and stdout (line 1 must be PASS). Without it, the\n server rejects the store with `REVIEW_EVIDENCE_REQUIRED`.\n- **`tune` with content** requires the same `review_evidence`. Space-only moves\n skip this check.\n- **Artifact trains** (non-markdown mime) skip the evidence check.\n\nThis is the tool-level enforcement of the FAIL gate. Even if an agent bypasses\nthe adapter flow and calls `train` directly, the server rejects the store\nwithout PASS evidence. The agent must run critic-loop, capture the verdict\nfile, and pass it as `review_evidence`.\n\n## Mutation Gate Pattern\n\nUnder the AI-ownership model, agents execute autonomously — irreversible remote\nmutations are **not** gated by a human confirmation prompt. Gate them with\nobjective, machine-checkable contracts instead:\n\n### Pre-mutation readiness (objective, no human prompt)\n\nAssert the preconditions with a shell or mcp contract so the action only runs from a\nvalid state — never with a `user_input` \"are you sure?\" prompt:\n\n```json\n{\"contract\":{\"type\":\"shell\",\"shell\":{\"cmd\":\"test -n \\\"$TARGET_REPO\\\" && test -n \\\"$TARGET_BRANCH\\\"\",\"interpreter\":\"bash\",\"timeout_seconds\":5},\"required\":true}}\n```\n\n### Post-mutation verification (objective)\n\nConfirm the mutation actually took effect by reading the remote state back.\nUse a `subagent` contract when the verification requires multi-step reasoning\nor tool orchestration beyond a single shell command:\n\n```json\n{\"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}}\n```\n\nThe guarantee comes from critic-loop (truth of intent) plus these objective\npre/post checks — not from asking a human to approve. Do not add `user_input`\nconfirmation gates for remote mutations.\n\n## Critic-Loop Placement Rules\n\n1. **Loop critic-loop until PASS at every major phase boundary** — after planning,\n after implementation, after validation — feeding it the requirement list and\n bounding it with an iteration ceiling.\n2. **Do NOT add critic-loop between every layer** — it is a phase-level review,\n not a step-level check.\n3. **Put one objective proof at each irreversibility boundary** — remote mutation\n or the local precondition that guards it: pre-mutation readiness +\n post-mutation verification, never a human confirmation prompt.\n4. **Batch reversible, checkable steps into one aggregate strict-conjunction\n proof** instead of one proof per step; never let it degrade to `echo \"done\"`.\n5. **Never replace a boundary proof with critic-loop** — critic-loop reviews truth\n after the fact; it does not block an irreversible step.\n6. **Never add a proof for purely local, reversible operations** — critic-loop\n provides sufficient review.\n\n## Adapter Authoring Checklist\n\nWhen drafting a new adapter, apply this checklist:\n\n1. Identify all phase boundaries in the adapter flow.\n2. Add a `critic-loop` chain link at each boundary.\n3. Identify all steps that perform irreversible remote mutations.\n4. Add objective solution checks (pre-mutation readiness + post-action\n verification) for each — no `user_input` human-confirmation gate.\n5. Verify that no solution checks exist for purely local operations.\n6. Verify that the critic-loop verdict handoff pattern is present.\n7. Verify that a FAIL gate shell contract follows every critic-loop invocation.\n8. Verify that `train`/`tune` calls include `review_evidence` from the critic.\n9. Ensure the adapter's Reward Signal describes what the critic protects.\n\n```json\n{\"contract\":{\"type\":\"comment\",\"comment\":{\"min_length\":80},\"required\":true}}\n```\n\n## Reward Signal\n\nOnly reachable after all prior steps are solved.\n\nThe agent can now:\n1. Decide when to use critic-loop versus solution checks\n2. Identify irreversible remote mutations that need hard gates\n3. Chain critic-loop into adapters at the correct phase boundaries\n4. Apply the mutation gate pattern for remote-system actions\n5. Avoid unnecessary solution checks for local or read-only operations\n",
|
|
31
|
+
"critic-loop": "---\nversion: \"5.12.1\"\nslug: critic-loop\ntitle: Critic Loop\n---\n\n\n\n# Critic Loop\n\nBounded adversarial investigator that the calling protocol **loops until it\nreturns PASS** — not a one-shot review. Receives a work submission (files,\nlinks, a git diff, a pull request, command output, or inline text), the\noriginal requirement list, and the calling protocol's invariants, then\nindependently verifies the submitted work by extracting claims, gathering\nevidence, searching for contradictions, and checking requirement-by-requirement\ncoverage. A FAIL sends the caller back to fix and re-invoke; the loop is bounded\nby an explicit iteration ceiling (see Verdict).\n\n## Activation Patterns\n\n**Typically invoked by:** another protocol at the end of a plan, implement,\nvalidation, or review phase via `forward` with the stored adapter URI\n`squadrules://adapter/critic-loop`.\n\n**Can be invoked directly when agent needs:**\n- \"review phase output\" / \"verify plan\" / \"audit implementation\"\n- \"adversarial review\" / \"critic review\"\n\n**Trigger pattern:** **review** / **verify** / **audit** / **critic** +\n(phase / plan / implementation / output).\n\n**Must Never:**\n- Modify any submitted item or any file other than the verdict path.\n- Trust the executor's assertions without independent evidence.\n- Classify a claim as `verified` based only on absence of contradiction.\n- Keep investigating after a precondition failure that blocks verification.\n\n**Must Always:**\n- Extract claims before investigating.\n- Verify in-scope claims first.\n- Search for contradictory evidence, not only confirming evidence.\n- Check every item in the supplied requirement list for coverage; a missing\n requirement is a FAIL even when the output is internally consistent.\n- Include confidence in every verdict and failure class in every FAIL verdict.\n- Preserve the boundary between execution and review.\n\n**Good trigger examples:**\n- implement protocol fires this after planning → run this protocol\n- compose protocol fires this after output generation → run this protocol\n\n**Bad trigger examples:**\n- \"Create a new protocol\" → use `author-adapter`\n- \"Implement a feature\" → use an execution protocol, not this one\n\n## Artifact Contract\n\nThis protocol receives:\n\n```text\n{\n work: {\n kind: 'file_set' | 'links' | 'git_diff' | 'pr' | 'command_output' | 'inline',\n items: string[], // paths | URLs | 'base..head' refs | PR URL/number | commands | text\n root: string // absolute cwd used to resolve relative paths, refs and commands\n },\n work_manifest: string, // absolute path to the handoff file recording `work`\n input_file: string, // accepted alias: a one-item work.kind='file_set'\n calling_protocol_slug: string,\n verification_target: string,\n requirements: string[], // original intent / requirement list to check coverage against\n context: {\n operation: string,\n verdict_file: string, // absolute path where the verdict will be written\n iteration: number, // 1-based loop pass; caller increments after each FAIL\n max_iterations: number // hard ceiling; exceeding it is a terminal FAIL\n }\n}\n```\n\nThe submission is the **work itself**, not an essay about it. Write `work` to\n`$WORK_MANIFEST` as flat keys so the handoff stays machine-checkable:\n`kind:`, `root:`, then `items:` with one item per line. Callers that still pass\nonly `input_file` are handled as `kind: file_set` with that single path; the\nreview rules do not change, only the scope of what is submitted.\n\nThis protocol produces:\n\n```text\n{\n verdict: \"PASS\" | \"FAIL\",\n confidence: \"High\" | \"Medium\" | \"Low\",\n failure_class: string, // incorrect_claim | verification_blocked | requirement_gap | iteration_ceiling\n uncovered_requirements: string[],// requirement items lacking positive evidence (empty on PASS)\n verdict_file: \"{context.verdict_file}\"\n}\n```\n\n## Precondition Check\n\nVerify foundational preconditions before deep investigation. Early-abort if any\nare broken.\n\n**Input:** `$WORK_MANIFEST` (or the older-spelling `$INPUT_FILE`), calling protocol slug, context\n\n**Actions:**\n1. Verify a submission handoff is present: `$WORK_MANIFEST`, or `$INPUT_FILE`\n when the caller passed no manifest.\n2. Verify the verdict output path is writable (parent directory exists).\n3. Load the calling protocol's Must Never / Must Always sections if possible.\n4. Verify the target state is available for review.\n5. Verify required tools are available for the submission's `kind` (a `pr`\n submission with no `gh` on the host is `verification_blocked`, not skipped).\n\n**On early-abort:**\n- verdict = `FAIL`\n- failure class = `verification_blocked`\n- confidence = `Low`\n- write focused diagnostics\n- skip all later steps\n\n**Output:** verified preconditions or early-abort diagnostics\n\n```json\n{\"contract\":{\"type\":\"shell\",\"shell\":{\"cmd\":\"test -f \\\"${WORK_MANIFEST:-}\\\" || test -f \\\"${INPUT_FILE:-}\\\"\",\"interpreter\":\"bash\",\"timeout_seconds\":3},\"required\":true}}\n```\n\n## Resolve Submission\n\nTurn the submission into the material under review. What cannot be resolved is\nnever guessed at.\n\n**Input:** `work` recorded in `$WORK_MANIFEST` (or the older-spelling `$INPUT_FILE`),\n`work.root`\n\n**Actions:**\n1. Read `kind`, `root`, `items`. An unknown `kind`, an empty `items` list, or a\n malformed manifest is `verification_blocked`.\n2. Resolve every item by kind, always from `work.root`:\n - `file_set` — read each path; relative paths resolve against `root`, and a\n missing path is `verification_blocked`.\n - `links` — fetch each URL; a URL that cannot be fetched is\n `verification_blocked`, not an `unverifiable` claim.\n - `git_diff` — `git -C \"$root\" diff <base>..<head>`, or the working tree when\n no range is given; no `git`, no repository, or a bad ref is\n `verification_blocked`.\n - `pr` — `gh pr view` plus `gh pr diff` for the number or URL; a missing\n `gh`, an expired login, or an unreachable host is `verification_blocked`.\n - `command_output` — run each command from `root` and capture stdout and\n stderr as the material.\n - `inline` — the text recorded in the manifest is the material.\n3. Record the resolved inventory before auditing: `kind`, item count, per-item\n status (`resolved` or `blocked`), and where each item's evidence lives.\n4. A `pr` or `git_diff` submission is reviewed as a diff: claims are checked\n against the changed lines and the tests they touch, never against the\n description written alongside them.\n\n**Output:** resolved work inventory for the audit\n\n```json\n{\"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}}\n```\n\n## Audit\n\nPerform bounded adversarial review of the target against the resolved work\nsubmission and invariants.\n\n**Input:** resolved work inventory, invariants, verification target, requirement list, context\n\n**Actions:**\n\n**Step 1 — Extract claims**\nExtract every verifiable claim that matters operationally:\n- workflows, commands, tool calls\n- configuration and environment variable claims\n- architecture claims that imply behaviour\n- guarantees and constraints\n- security, auth, and permission claims\n\n**Step 2 — Investigate with scope discipline**\n1. verify all in-scope claims first\n2. review high-risk claims with maximum depth\n3. expand beyond scope only when contradiction signals, dependencies, or\n high-risk impact require it\n4. continue reviewing all in-scope claims even after a normal FAIL condition is met;\n only a precondition failure stops the audit early\n\n**High-risk areas:** setup steps, CLI commands, configuration keys, authentication,\ndeployment, external publishing, destructive operations.\n\n**Step 3 — Gather evidence using the hierarchy**\n\n| Priority | Evidence source |\n|---|---|\n| 1 | source code, config files, schemas, route definitions |\n| 2 | direct runtime verification |\n| 3 | tests |\n| 4 | MCP-queried system state |\n| 5 | external docs, web pages, linked references |\n| 6 | conversational assumption or indirect inference |\n\n**Rules:** higher-priority evidence overrides lower; priority 5–6 alone is not\nenough for `verified`; a submitted link or PR description is priority 5.\n\n**Step 4 — Produce claim verdicts**\nFor each claim: CLAIM, EVIDENCE, EVIDENCE PRIORITY, VERDICT\n(`verified` / `partially_verified` / `unverifiable` / `incorrect`).\nA claim must not be marked `verified` without positive supporting evidence.\n\n**Step 5 — Review the phase boundary**\nCheck whether the calling adapter preserved the right mode boundary.\n\n**Step 6 — Check requirement coverage**\nFor every item in `requirements`, confirm coverage with positive evidence.\nAny `missing` item — or any `partial` high-risk item — forces FAIL with\n`failure_class: requirement_gap`.\n\n**Output:** structured audit findings for the verdict step\n\n```json\n{\"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}}\n```\n\n## Verdict\n\nTurn the audit into a final PASS / FAIL result.\n\n**Input:** audit findings and verdict file path from context (use it as\n`$VERDICT_FILE`)\n\n**Actions:**\n1. Fail if any critical claim is incorrect.\n2. Fail if verification was blocked.\n3. Fail if the evidence base is too weak for high-risk claims.\n4. Fail if any requirement is `missing`, or a high-risk requirement is only\n `partial` (`failure_class: requirement_gap`); list the uncovered items.\n5. Fail terminally if `context.iteration` exceeds `context.max_iterations`\n (`failure_class: iteration_ceiling`) so the loop stops instead of thrashing.\n6. Otherwise, pass with the appropriate confidence.\n7. Write `$VERDICT_FILE` so line 1 is `PASS` or `FAIL`,\n line 2 is `High`, `Medium`, or `Low`, and the remaining lines summarise key\n findings and any uncovered requirements.\n\n**Verdict contract (calling adapter must obey):**\n- Line 1 is `PASS` → the loop is satisfied; the calling adapter may continue.\n- Line 1 is `FAIL` → the calling adapter **MUST NOT** proceed to reward, **MUST\n NOT** ask the user for approval, and **MUST NOT** continue. It must address the\n findings, increment `context.iteration`, and re-invoke critic-loop.\n- `failure_class: iteration_ceiling` → stop looping and surface the unresolved\n findings; never silently pass. The ceiling bounds the loop so a weak agent\n cannot thrash forever.\n\n**Output:** final verdict file\n\n```json\n{\"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}}\n```\n\n## Reward Signal\n\nOnly reachable after all prior steps are solved.\n\nThe phase output has been independently challenged and looped until satisfied. The\nresulting verdict is more truthful because it is based on extracted claims,\nexplicit evidence, contradiction search, requirement-by-requirement coverage, and\na clean boundary between execution and review.\n",
|
|
32
|
+
"protocol-linking-guide": "---\nversion: \"5.12.1\"\nslug: protocol-linking-guide\ntitle: Adapter Linking Guide\n---\n\n# Adapter Linking Guide\n\nDecision rules for structuring adapter relationships: layers vs chains,\n`activate` vs `forward` + slug, chain-root collapsing, and MCP argument\nvalidation for deterministic cross-adapter linking.\n\n## Activation Patterns\n\n**Typically invoked by:** `author-adapter` and `critic-loop`.\n\n**Can be invoked directly when agent needs:**\n- \"layers vs chains\" / \"when to split into multiple adapters\"\n- \"how to link adapters\" / \"cross-adapter linking\"\n- \"activate vs forward\" / \"when to use forward with slug\"\n- \"chain-root collapsing\" / \"how chain_root works\"\n\n**Trigger pattern:** **layers** / **chains** / **linking** / **forward** +\n(slug | adapter | workflow).\n\n**Must Never:**\n- Be used as an execution adapter.\n- Recommend chaining when layers suffice.\n\n**Must Always:**\n- Be consulted before splitting an adapter into multiple adapters.\n- Be consulted before adding `forward` calls or `chain_root` frontmatter.\n\n**Good trigger examples:**\n- \"my adapter is 400 lines, should I split?\" → load this\n- \"how do I link adapter A to adapter B?\" → load this\n- \"what is chain_root?\" → load this\n\n**Bad trigger examples:**\n- \"which challenge type for this step?\" → use `challenge-type-guide`\n- \"create a new adapter\" → use `author-adapter`\n\n## Layers vs Chains\n\n**Layers** (H2 steps within one adapter) are the preferred unit of work. Use\nlayers when all steps fit in one adapter under 350 lines and serve a single\ncohesive concern.\n\n**Chain via `forward` + slug** — use only when:\n- the adapter exceeds 350 lines\n- weaker models cannot follow the full adapter in one pass\n- runtime routing to different adapters is needed (Router pattern)\n- a step is reusable across multiple parent adapters (e.g. `critic-loop`)\n\nChaining is NOT a replacement for layers. A 6-step adapter that fits in 350\nlines should stay as one adapter with 6 H2 layers.\n\n## `activate` vs `forward` + slug\n\n| Situation | Use |\n|---|---|\n| Initial user-intent resolution | `activate` |\n| Target adapter is known at authoring time | `forward` + slug |\n| Target depends on runtime classification the current adapter cannot resolve | `activate` |\n| Linking to the next adapter in a chain | `forward` + slug |\n| Reusable sub-adapter invoked by multiple parents | `forward` + slug |\n\nNever call `activate` just to get a slug you already know — it wastes a\nround-trip and introduces non-determinism.\n\n## Chaining Back and Forward\n\nWhen a family of adapters has a root conductor and smaller domain extensions,\ndocument both directions of chaining.\n\n### Chaining back with `chain_root`\n\nExtension adapters should include `chain_root` frontmatter and a prerequisite\nclause:\n\n**Prerequisite:** Start from `<root-adapter-slug>` unless the caller already\nprovided a mission brief, safety gates, authorization boundary, and evidence\nrequirements.\n\nThis protects activation entry points. If a user or weak agent activates a\nmid-chain extension directly, the extension can collapse back to the root unless\nit already received the required parent context.\n\n### Chaining forward with `forward`\n\n`chain_root` does not replace explicit `forward` calls inside the chain.\n\nWhen the next adapter is known at authoring time or after deterministic runtime\nclassification, use `forward` with the target slug. Do not call `activate` just\nto rediscover a slug already known by the current adapter.\n\nForwarded adapters should receive: current mission brief, safety gates,\nauthorization boundary, evidence requirements, user constraints, and reason for\nforwarding.\n\nUse `activate` only when the next adapter must be discovered from an ambiguous\nruntime need.\n\n### Multi-layer conductors and extension URIs\n\nWhen executing **`forward`** inside a **multi-layer** adapter (for example a root\nconductor), each continuation follows **`next_call`** for the **same**\n`execution_id` until the last layer directs **`reward`**. A layer that mentions\nanother adapter URI only as routing guidance does **not** cause the server to\nswitch executions.\n\nTo run an extension adapter, call **`forward`** with\n`squadrules://adapter/<slug>` as a **new** first call (adapter URI; omit\n`solution`). That starts a **separate** execution with its own layers.\n\n## System adapters vs user adapters\n\nBoth system and user-authored adapters chain using slugs in `next_action`:\n\n```text\ncall forward with squadrules://adapter/critic-loop ...\ncall forward with squadrules://adapter/implement-terraform ...\n```\n\nSlugs are globally unique (enforced by `train`), so resolution is\ndeterministic — no scoring, no ambiguity.\n\n## MCP forward-link contracts for chain links\n\nAll `mcp` contracts MUST be forward-links with `tool_name: \"forward\"` and\n`arguments.uri` pointing to the target adapter slug:\n\n```json\n{\"contract\":{\"type\":\"mcp\",\"mcp\":{\"tool_name\":\"forward\",\"arguments\":{\"uri\":\"squadrules://adapter/code-review-policy\"}},\"required\":true}}\n```\n\nThe server validates that `solution.mcp.arguments` is a superset of the\ncontract's `mcp.arguments` (subset/deep matching). This proves the agent\ncalled `forward` with the correct slug, not just any `forward` call.\n\nBare `mcp` contracts that check only a tool name (without `arguments.uri`)\nare **not valid** — every mcp contract must specify the forward target.\n\n## Chain-root collapsing\n\nWhen a chain has multiple adapters, `activate` might match a mid-chain adapter\ndirectly. Without protection, the agent would start at the wrong step, missing\nprerequisite context gathered by earlier steps.\n\n**`chain_root` frontmatter field** solves this at the server level. Add it to\nevery mid-chain adapter:\n\n```yaml\n---\nslug: implement-plan\nversion: 1.0.0\nchain_root: implement\n---\n```\n\n**Server behaviour:** When `activate` returns a match that has `chain_root`,\nthe server resolves the slug to the root adapter's URI and replaces the\nchoice's `uri` and `next_action` to point there. Multiple mid-chain matches\nfrom the same chain are deduplicated to a single entry.\n\n**Defense in depth:** Each mid-chain adapter should include a **Prerequisites**\nparagraph in its Activation Patterns listing inputs required from earlier steps\nand directing the agent to start from the chain root if those inputs are missing.\n\n**Rules:**\n- The chain root adapter must NOT have `chain_root` in its frontmatter.\n- `chain_root` must refer to an existing slug (the chain entry point).\n- `forward` calls within a chain are unaffected — `chain_root` only changes\n `activate` output routing.\n\n## Personal vs System Adapter Linking\n\n| Adapter type | Can `forward` to | Can be `forward`'d from |\n|---|---|---|\n| System adapter (bundled) | Other system adapters (slug guaranteed to exist) | System or personal adapters |\n| Personal adapter (MCP database) | **Nothing** — must be self-contained | Only via `activate` (runtime discovery) |\n\nPersonal adapters use `subagent` or `comment` contracts to describe what the\nagent should do next, not `mcp forward` contracts to other personal adapters.\nA personal adapter that chains to `squadrules://adapter/some-personal-slug`\nwill fail at runtime when that slug does not exist in the caller's MCP database.\n\n```json\n{\"contract\":{\"type\":\"comment\",\"comment\":{\"min_length\":30},\"required\":true}}\n```\n\n## Reward Signal\n\nOnly reachable after all prior steps are solved.\n\nThe agent can now:\n1. decide when to use layers vs chains\n2. choose `activate` vs `forward` + slug correctly\n3. use slug-based linking for all adapters (system and user)\n4. write valid mcp forward-link contracts with arguments\n5. implement `chain_root` collapsing with defense-in-depth safeguards\n6. document chaining back (`chain_root` + prerequisites) and chaining forward\n (`forward` with known slugs) for root + extension families\n",
|
|
33
|
+
"refine-search": "---\nversion: \"5.12.1\"\nslug: refine-search\ntitle: Get help refining your search\n---\n\n# Get help refining your search\n\n**You are an AI agent.** You ran `activate` and got no solid match, or only weak\n/ ambiguous matches. This adapter helps you turn a vague request into a better\nquery so the next `activate` can find the right adapter.\n\nSQUADRULES principle: before acting, understand the user better. The goal is not\nto repeat the failed phrase with minor edits. The goal is to recover the user's\nreal intent.\n\n## Activation Patterns\n\n**Run this adapter when:**\n- `activate` returned no match.\n- `activate` returned only weak choices.\n- The response included a `refine` choice.\n\n**Trigger pattern:** after `activate` when no strong match exists.\n\n**Must Never:**\n- Run when a strong match already exists.\n- Loop refinement endlessly.\n\n**Must Always:**\n- Infer the real goal, context, and missing constraints from the user's request.\n- Build a more specific query than the one that failed.\n- Run at most once per user request; if the second activation still fails, stop\n and offer clarification or adapter creation.\n\n**Good trigger examples:**\n- activate returned only \"refine\" / weak matches → run this adapter\n- \"No adapter matched 'do the thing'\" → run this adapter\n\n**Bad trigger examples:**\n- activate returned a strong match → use that match instead\n- user asked \"what adapters exist?\" → use `activate` / `spaces`, not this\n\n## Extract User Intent\n\nFrom the user's original message, identify:\n- the real goal\n- relevant context\n- missing constraints\n- likely wording that would help SQUADRULES find the right adapter\n\nWrite your analysis, then construct one refined query with 3–8 specific words.\nDo not reuse the vague phrase that already failed.\n\nCall `activate` with the refined query as your next action:\n- **Strong match (score >= 0.5):** pick that choice and `forward`.\n- **Weak matches only:** ask the user to clarify or offer the create path.\n\nDo not loop more than once.\n\n```json\n{\"contract\":{\"type\":\"comment\",\"comment\":{\"min_length\":60},\"required\":true}}\n```\n\n## Reward Signal\n\nOnly reachable after all prior steps are solved.\n\nThe agent has converted a failed literal search into a more truthful,\nuser-aligned activation attempt.\n"
|
|
34
34
|
}
|
|
35
35
|
};
|
|
36
36
|
/**
|
|
@@ -1 +1 @@
|
|
|
1
|
-
import{g as e,y as t}from"./vendor-xESPQGR9.js";import{t as n}from"./react-BvB9BS1T.js";import{n as r,r as i,t as a}from"./index-
|
|
1
|
+
import{g as e,y as t}from"./vendor-xESPQGR9.js";import{t as n}from"./react-BvB9BS1T.js";import{n as r,r as i,t as a}from"./index-rCZd_925.js";import{t as o}from"./api-BgTb-tmJ.js";async function s(){let e=await o(`/api/me`);if(!e.ok){let t=await e.json().catch(()=>({})),n=Error(t.message??e.statusText);throw n.statusCode=e.status,n}return e.json()}function c(){return e({queryKey:[`me`],queryFn:s,retry:!1})}var l=n(),u={light:`account.themeOptionLight`,dark:`account.themeOptionDark`};function d(e){if(e.name&&e.name.trim().length>0)return e.name;let t=[e.given_name,e.family_name].filter(e=>typeof e==`string`&&e.trim().length>0);return t.length>0?t.join(` `):e.preferred_username&&e.preferred_username.length>0?e.preferred_username:e.sub}function f(){let{t:e}=t(),{data:n,isLoading:o,isError:s}=c(),{preference:f,setPreference:p}=i();return o?(0,l.jsx)(`p`,{className:`text-[var(--color-text-muted)]`,children:e(`account.loading`)}):s||!n?(0,l.jsxs)(`div`,{children:[(0,l.jsx)(`h1`,{className:`text-[var(--color-text-heading)] text-2xl font-semibold mb-4`,children:e(`account.title`)}),(0,l.jsx)(`p`,{className:`text-[var(--color-text-muted)]`,children:e(`account.notSignedIn`)}),(0,l.jsx)(`a`,{href:`/auth/callback`,className:`mt-4 min-h-[44px] min-w-[44px] inline-flex items-center justify-center px-4 py-2 rounded-[var(--radius-md)] font-medium bg-[var(--color-primary)] text-white no-underline hover:bg-[var(--color-primary-hover)] focus-visible:outline focus-visible:outline-2 focus-visible:outline-[var(--color-focus-ring)] focus-visible:outline-offset-2`,children:e(`account.signIn`)})]}):(0,l.jsxs)(`div`,{children:[(0,l.jsx)(`h1`,{className:`text-[var(--color-text-heading)] text-2xl font-semibold mb-6`,children:e(`account.title`)}),(0,l.jsx)(`p`,{className:`text-[var(--color-text-muted)] mb-6`,children:e(`account.intro`)}),(0,l.jsxs)(`div`,{className:`rounded-[var(--radius-md)] border border-[var(--color-border)] bg-[var(--color-surface-elevated)] p-6`,children:[(0,l.jsxs)(`div`,{className:`mb-6 rounded-[var(--radius-md)] border border-[var(--color-border)] bg-[var(--color-surface)] p-4`,children:[(0,l.jsx)(`h2`,{className:`mb-1 text-base font-semibold text-[var(--color-text-heading)]`,children:e(`account.themeTitle`)}),(0,l.jsx)(`p`,{className:`mb-3 text-sm text-[var(--color-text-muted)]`,children:e(`account.themeDescription`)}),(0,l.jsx)(`label`,{htmlFor:`account-theme-preference`,className:`sr-only`,children:e(`account.themePreferenceLabel`)}),(0,l.jsxs)(`select`,{id:`account-theme-preference`,value:f,onChange:e=>{let t=e.target.value;r(t)&&p(t)},className:`min-h-[44px] w-full max-w-xs rounded-[var(--radius-md)] border border-[var(--color-border)] bg-[var(--color-surface)] px-3 py-2 text-[var(--color-text)] focus-visible:outline focus-visible:outline-2 focus-visible:outline-[var(--color-focus-ring)] focus-visible:outline-offset-2`,children:[(0,l.jsx)(`option`,{value:`system`,children:e(`account.themeOptionSystem`)}),a.map(t=>(0,l.jsx)(`option`,{value:t,children:e(u[t])},t))]})]}),(0,l.jsxs)(`div`,{className:`mb-4`,children:[(0,l.jsx)(`span`,{className:`block text-xs uppercase tracking-wider text-[var(--color-text-muted)] mb-1`,children:e(`account.name`)}),(0,l.jsx)(`span`,{className:`text-[var(--color-text-heading)]`,children:d(n)})]}),n.preferred_username&&n.preferred_username!==d(n)&&(0,l.jsxs)(`div`,{className:`mb-4`,children:[(0,l.jsx)(`span`,{className:`block text-xs uppercase tracking-wider text-[var(--color-text-muted)] mb-1`,children:e(`account.username`)}),(0,l.jsx)(`span`,{className:`text-[var(--color-text-heading)]`,children:n.preferred_username})]}),n.email&&(0,l.jsxs)(`div`,{className:`mb-4`,children:[(0,l.jsx)(`span`,{className:`block text-xs uppercase tracking-wider text-[var(--color-text-muted)] mb-1`,children:e(`account.email`)}),(0,l.jsxs)(`span`,{className:`text-[var(--color-text-heading)]`,children:[n.email,n.email_verified===!0?` (${e(`account.emailVerified`)})`:``]})]}),(0,l.jsxs)(`div`,{className:`mb-4`,children:[(0,l.jsx)(`span`,{className:`block text-xs uppercase tracking-wider text-[var(--color-text-muted)] mb-1`,children:e(`account.accountType`)}),(0,l.jsx)(`span`,{className:`text-[var(--color-text-heading)]`,children:n.account_label})]}),(0,l.jsxs)(`div`,{className:`mb-4`,children:[(0,l.jsx)(`span`,{className:`block text-xs uppercase tracking-wider text-[var(--color-text-muted)] mb-1`,children:e(`account.realm`)}),(0,l.jsx)(`span`,{className:`text-[var(--color-text-heading)]`,children:n.realm})]}),n.identity_provider&&(0,l.jsxs)(`div`,{className:`mb-4`,children:[(0,l.jsx)(`span`,{className:`block text-xs uppercase tracking-wider text-[var(--color-text-muted)] mb-1`,children:e(`account.identityProvider`)}),(0,l.jsx)(`span`,{className:`text-[var(--color-text-heading)]`,children:n.identity_provider})]}),n.groups.length>0&&(0,l.jsxs)(`div`,{className:`mb-4`,children:[(0,l.jsx)(`span`,{className:`block text-xs uppercase tracking-wider text-[var(--color-text-muted)] mb-1`,children:e(`account.groups`)}),(0,l.jsx)(`ul`,{className:`list-disc list-inside text-[var(--color-text-heading)] space-y-1`,children:n.groups.map(e=>(0,l.jsx)(`li`,{children:e},e))})]}),(0,l.jsx)(`div`,{className:`mt-6 flex gap-2 flex-wrap`,children:(0,l.jsx)(`a`,{href:`/auth/logout`,className:`min-h-[44px] min-w-[44px] inline-flex items-center justify-center px-4 py-2 rounded-[var(--radius-md)] font-medium border border-[var(--color-border)] text-[var(--color-text)] bg-transparent no-underline hover:bg-[var(--color-surface-elevated)] focus-visible:outline focus-visible:outline-2 focus-visible:outline-[var(--color-focus-ring)] focus-visible:outline-offset-2`,children:e(`account.logOut`)})})]})]})}export{f as AccountPage};
|
|
@@ -1,8 +1,8 @@
|
|
|
1
|
-
const __vite__mapDeps=(i,m=__vite__mapDeps,d=(m.f||(m.f=["assets/HomePage-B--ESwM9.js","assets/vendor-xESPQGR9.js","assets/rolldown-runtime-hePW80VL.js","assets/react-BvB9BS1T.js","assets/tiptap-CCr8bvo1.js","assets/SpaceSelect-D3al0TgQ.js","assets/api-BgTb-tmJ.js","assets/SurfaceCard-BzJidvvn.js","assets/SquadrulesPage-C37VEZnc.js","assets/ErrorAlert-BoPXaBKG.js","assets/RunsPage-BSgcu2TO.js","assets/useRunSession-CB5wPJ8O.js","assets/ProtocolEditPage-IvFbUiUS.js","assets/export-skill-zip-seCWjJSV.js","assets/ChallengeCard-DVXo4j0b.js","assets/RichTextEditor-DWLV579w.js","assets/RunGuidedPage-Db_CQ-9q.js","assets/StepFlowGraph-BXsWPPO0.js","assets/SkillBundlePage-DV9CXjfI.js","assets/ProtocolDetailPage-kPGgNobg.js","assets/AccountPage-
|
|
1
|
+
const __vite__mapDeps=(i,m=__vite__mapDeps,d=(m.f||(m.f=["assets/HomePage-B--ESwM9.js","assets/vendor-xESPQGR9.js","assets/rolldown-runtime-hePW80VL.js","assets/react-BvB9BS1T.js","assets/tiptap-CCr8bvo1.js","assets/SpaceSelect-D3al0TgQ.js","assets/api-BgTb-tmJ.js","assets/SurfaceCard-BzJidvvn.js","assets/SquadrulesPage-C37VEZnc.js","assets/ErrorAlert-BoPXaBKG.js","assets/RunsPage-BSgcu2TO.js","assets/useRunSession-CB5wPJ8O.js","assets/ProtocolEditPage-IvFbUiUS.js","assets/export-skill-zip-seCWjJSV.js","assets/ChallengeCard-DVXo4j0b.js","assets/RichTextEditor-DWLV579w.js","assets/RunGuidedPage-Db_CQ-9q.js","assets/StepFlowGraph-BXsWPPO0.js","assets/SkillBundlePage-DV9CXjfI.js","assets/ProtocolDetailPage-kPGgNobg.js","assets/AccountPage-BhneCJCw.js","assets/NotFoundPage-bTE_mpMC.js"])))=>i.map(i=>d[i]);
|
|
2
2
|
import{r as e}from"./rolldown-runtime-hePW80VL.js";import{_ as t,b as n,c as r,d as i,f as a,i as o,l as s,o as c,u as l,v as u,x as d,y as f}from"./vendor-xESPQGR9.js";import{i as p,n as m,t as h}from"./react-BvB9BS1T.js";(function(){let e=document.createElement(`link`).relList;if(e&&e.supports&&e.supports(`modulepreload`))return;for(let e of document.querySelectorAll(`link[rel="modulepreload"]`))n(e);new MutationObserver(e=>{for(let t of e)if(t.type===`childList`)for(let e of t.addedNodes)e.tagName===`LINK`&&e.rel===`modulepreload`&&n(e)}).observe(document,{childList:!0,subtree:!0});function t(e){let t={};return e.integrity&&(t.integrity=e.integrity),e.referrerPolicy&&(t.referrerPolicy=e.referrerPolicy),t.credentials=e.crossOrigin===`use-credentials`?`include`:e.crossOrigin===`anonymous`?`omit`:`same-origin`,t}function n(e){if(e.ep)return;e.ep=!0;let n=t(e);fetch(e.href,n)}})(),d.use(n).init({lng:`en`,fallbackLng:`en`,ns:[`translation`],defaultNS:`translation`,resources:{en:{translation:{"nav.home":`Home`,"nav.squadrules":`Browse`,"nav.create":`Create`,"nav.runs":`Test Run`,"nav.account":`Account`,"layout.squadrulesVersion":`SQUADRULES v{{version}}`,skipToMain:`Skip to main content`,"home.title":`Home`,"home.tagline":`Start from a clear task: browse protocols, create a new workflow, or continue protocol testing.`,"home.findCardTitle":`Find the right protocol`,"home.findCardSubtitle":`Home stays lightweight. Search and deeper discovery live in Browse.`,"home.goToBrowse":`Go to Browse`,"home.cardBrowseTitle":`Browse protocols`,"home.cardBrowseSubtitle":`Search or browse by label.`,"home.cardBrowseCta":`Open Browse`,"home.cardCreateTitle":`Create protocol`,"home.cardCreateSubtitle":`Use the rendered editor to draft a new workflow.`,"home.cardCreateCta":`Create new`,"home.cardRunsTitle":`Test Run`,"home.cardRunsSubtitle":`Resume a saved test run from this device.`,"home.cardRunsCta":`Open Test Run`,"home.spacesHeading":`Spaces`,"home.searchLabel":`Search protocols`,"home.searchPlaceholder":`e.g. deploy and test`,"home.searchHint":`Enter a query to find the best matching protocol. Results open in Browse.`,"home.statsLabel":`Space and protocol counts`,"home.stats.personalProtocols":`—`,"home.stats.personalProtocolsLabel":`Personal protocols`,"home.stats.squadrulesApp":`—`,"home.stats.squadrulesAppLabel":`Squadrules app`,"home.stats.spaces":`—`,"home.stats.spacesLabel":`Spaces`,"home.stats.protocolCount":`{{count}} protocol`,"home.stats.protocolCount_plural":`{{count}} protocols`,"home.ctaPre":`Search and manage protocols in`,"home.ctaSuffix":`.`,"squadrules.title":`Browse`,"squadrules.searchLabel":`Activation query`,"squadrules.searchPlaceholder":`e.g. deploy and test`,"squadrules.searchHint":`Search or browse by label. The default view lists protocols by their label.`,"squadrules.searchHintShort":`Run an activation query to rank the best matches, or browse the list below.`,"squadrules.browseByLabel":`Browse by label`,"squadrules.browseByLetterHint":`Click a letter to list protocols whose title starts with that letter (A–Z).`,"squadrules.letterCount":`Letter {{letter}}, {{count}} protocols`,"squadrules.labelsStartingWith":`Labels starting with {{letter}}`,"squadrules.noLabelsForLetter":`No protocols starting with this letter.`,"squadrules.browseFlatListHint":`Protocols listed by label. This is the default view when you open Browse.`,"squadrules.browseEmpty":`No protocols found in your spaces yet.`,"squadrules.enterQueryHint":`Enter an activation query above to find the best matching protocol. Results appear below.`,"spaces.filterAll":`All spaces`,"spaces.type.personal":`Personal`,"spaces.type.group":`Group`,"spaces.type.app":`App`,"spaces.type.other":`Other`,"squadrules.scopeSpaceLabel":`Limit search to a space`,"squadrules.spaceLabel":`Space`,"squadrules.search":`Activate`,"squadrules.loading":`Activating…`,"squadrules.empty":`No matching protocols found`,"squadrules.foundMatches":`Found {{count}} activation choices (top confidence: {{top}}%). View one, refine the query, or create a new protocol.`,"squadrules.resultsLabel":`Activation results`,"squadrules.score":`Score`,"squadrules.version":`Version`,"squadrules.tagsLabel":`Tags`,"squadrules.refineMeta":`Refine query`,"squadrules.createMeta":`Start from scratch`,"squadrules.view":`View`,"squadrules.viewProtocol":`View {{title}}`,"squadrules.refineSearch":`Refine query`,"squadrules.createNew":`Create new`,"protocol.loading":`Loading protocol…`,"protocol.notFound":`Protocol not found`,"protocol.uri":`URI`,"protocol.spaceLabel":`Space`,"protocol.readOnly":`Read-only`,"protocol.copyUri":`Copy URI`,"protocol.download":`Download`,"protocol.downloadAsMarkdown":`Download as Markdown`,"protocol.downloadAsSkill":`Download as Skill`,"protocol.editAsSkill":`Edit as Skill`,"protocol.expand":`Expand`,"protocol.collapse":`Collapse`,"protocol.edit":`Edit`,"protocol.duplicate":`Duplicate`,"protocol.runGuided":`Test Run`,"protocol.steps":`Steps`,"protocol.stepFlow":`Step flow`,"protocol.exportCardTitle":`Export`,"protocol.exportCardSubtitle":`Clear language replaces internal dump terminology.`,"protocol.exportFooter":`Skill export prepares a portable bundle for external AI tools.`,"protocol.triggers":`Activation patterns`,"protocol.completion":`Reward signal`,"protocol.howToUse":`How to use this protocol`,"protocol.howToUseInProduct":`The public UI helps people read, edit, export, and manually test protocol steps. Live AI execution still happens through MCP or CLI tooling.`,"protocol.howToUseCopy":`Use Test Run from the button above to step through this protocol in the browser. For agents or CLI, use Cursor (MCP) or the command line. See`,"protocol.docsLink":`documentation`,"runs.title":`Test Run`,"runs.subtitle":`Continue a test run you started earlier on this device.`,"runs.empty":`No runs yet.`,"runs.listLabel":`Test Run list`,"runs.status":`Status`,"runs.updated":`Updated`,"runs.stepsDone":`{{count}} steps completed`,"runs.resume":`Resume`,"runs.remove":`Remove`,"run.title":`Test Run`,"run.guidedIntro":`Step through the saved run in the browser and submit the same data the current run flow expects.`,"run.progressHeading":`Progress`,"run.currentStepHeading":`Current step`,"run.challengeHeading":`Challenge`,"run.stepProgress":`Step {{current}} of {{total}}`,"run.sessionBadge":`Active manual test session`,"run.flowStepN":`{{n}}`,"run.copyShellCommand":`Copy command`,"run.adapterUri":`Adapter URI`,"run.backToProtocol":`Back to adapter`,"run.start":`Start run`,"run.starting":`Starting…`,"run.safety.title":`Safe by default`,"run.safety.copy":`This guided run never executes shell commands in your browser. For shell challenges, run the command yourself and paste the real results.`,"run.serverMessage":`Server message`,"run.currentLayer":`Current layer`,"run.layerUri":`Layer URI`,"run.noLayerContent":`(No layer content)`,"run.contract":`Contract`,"run.contractType":`Type`,"run.advanced":`Advanced`,"run.nonce":`Nonce`,"run.proofHash":`Challenge proof_hash`,"run.previousProofHash":`Previous proof_hash`,"run.copy":`Copy`,"run.copied":`Copied`,"run.solution":`Solution`,"run.solutionFormLabel":`Submit solution`,"run.submitStep":`Submit step`,"run.shell.command":`Command`,"run.shell.invocation":`Invocation`,"run.shell.exitCode":`Exit code`,"run.shell.stdout":`Stdout`,"run.shell.stderr":`Stderr`,"run.mcp.toolName":`Tool`,"run.mcp.toolMissing":`(Missing tool name)`,"run.mcp.success":`Success`,"run.mcp.arguments":`Arguments (JSON)`,"run.mcp.result":`Result (JSON)`,"run.userInput.prompt":`Prompt`,"run.userInput.promptMissing":`(Missing prompt)`,"run.userInput.confirmation":`User confirmation`,"run.comment.minLength":`Minimum {{count}} characters`,"run.comment.count":`{{count}} typed`,"run.comment.text":`Comment`,"run.reward.title":`Reward completion`,"run.reward.subtitle":`Finalize the run outcome for reward and export quality.`,"run.reward.outcomeLabel":`Outcome`,"run.reward.success":`Success`,"run.reward.failure":`Failure`,"run.reward.feedback":`Feedback`,"run.reward.submit":`Submit reward`,"run.reward.submitting":`Submitting…`,"run.reward.defaultFeedback":`Completed guided run.`,"run.stepperProgress":`{{completed}} step(s) completed`,"run.history":`History`,"run.historyLabel":`Run history`,"run.completed":`Run completed`,"run.missingUri":`Missing adapter URI.`,"protocolEdit.newTitle":`New protocol`,"protocolEdit.editTitle":`Edit protocol`,"protocolEdit.hint":`Write as a human. The editor renders text on input and output while keeping the saved format compatible with generic Markdown.`,"protocolEdit.stepHeading":`Step {{n}}`,"protocolEdit.stepEditorHint":`Human-friendly editor with Markdown-safe formatting.`,"protocolEdit.triggersEditorHint":`Shown to humans as rendered text and serialized as Markdown-compatible content.`,"protocolEdit.previewRenderedTitle":`Rendered preview`,"protocolEdit.previewRenderedSubtitle":`Reading flow is fully rendered. Editing keeps a Markdown-safe rich text surface and this card previews section structure.`,"protocolEdit.previewStepLine":`Step {{n}}: {{label}}`,"protocolEdit.skillShortcutTitle":`Skill bundle shortcut`,"protocolEdit.skillShortcutSubtitle":`Authors can turn a protocol into a reusable skill bundle without learning repo-internal file names.`,"protocolEdit.formLabel":`Protocol form`,"protocolEdit.protocolLabel":`Protocol label`,"protocolEdit.triggersLabel":`Activation patterns`,"protocolEdit.triggersHint":`Describe when this protocol should run (e.g. deploy and test).`,"protocolEdit.stepLabel":`Step label`,"protocolEdit.stepContent":`Step content`,"protocolEdit.challengeType":`Challenge type`,"protocolEdit.addStep":`Add step`,"protocolEdit.removeStep":`Remove step`,"protocolEdit.completionLabel":`Reward signal`,"protocolEdit.challengeShell":`Shell command`,"protocolEdit.challengeMcp":`MCP tool call`,"protocolEdit.challengeUserInput":`User input`,"protocolEdit.challengeComment":`Comment`,"protocolEdit.shellCmd":`Command`,"protocolEdit.shellTimeout":`Timeout (seconds)`,"protocolEdit.shellInterpreter":`Interpreter`,"protocolEdit.shellInterpreterPlaceholder":`Select an interpreter`,"protocolEdit.shellInterpreterHint":`Required. One of: bash, sh, python3, python, node.`,"protocolEdit.shellFlags":`Flags (one per line, optional)`,"protocolEdit.shellArgs":`Args (one per line, optional)`,"protocolEdit.shellWorkdir":`Workdir (optional)`,"protocolEdit.mcpToolName":`Tool name`,"protocolEdit.userInputPrompt":`Prompt`,"protocolEdit.commentMinLength":`Minimum length (characters)`,"protocolEdit.importCardTitle":`Import existing content`,"protocolEdit.uploadHint":"Uploading a `.md` file fills this editor form. It does not publish or overwrite anything until you save.","protocolEdit.contentLabel":`Protocol content (markdown)`,"protocolEdit.previewLabel":`Protocol preview`,"protocolEdit.previewTitle":`Live preview`,"protocolEdit.previewSteps":`Steps`,"protocolEdit.previewNoSteps":`No steps yet.`,"protocolEdit.previewSections":`Key sections`,"protocolEdit.present":`present`,"protocolEdit.missing":`missing`,"protocolEdit.insertTemplate":`Insert template`,"protocolEdit.upload":`Upload .md file`,"skill.title":`Edit as Skill`,"skill.subtitle":`Prepare a skill bundle for external AI tools before downloading the zip. Protocol content stays connected to the original workflow.`,"skill.bundleContentsTitle":`Bundle contents`,"skill.bundleContentsSubtitle":`Optional protocol references can be included in a dedicated folder.`,"skill.chipReadme":`Include README snippet`,"skill.chipPrompts":`Include example prompts`,"skill.comingSoon":`Coming soon`,"skill.bundlePreviewTitle":`Bundle preview`,"skill.bundlePreviewSubtitle":`Zip root contains the skill folder so users can upload it directly.`,"skill.whyExportTitle":`Why this export exists`,"skill.whyExportSubtitle":`The bundle is for human-friendly reuse, not an internal raw dump.`,"skill.whyExportBody":`Authors can package a protocol as a portable skill with polished naming and usage guidance, then download the final zip in one step.`,"skill.skillName":`Skill name`,"skill.description":`Skill description`,"skill.descriptionHint":`Describe what the skill does and when an AI assistant should use it.`,"skill.whenToUse":`When to use it`,"skill.includeReferences":`Include references folder`,"skill.downloadAsSkill":`Download as Skill`,"skill.backToProtocol":`Back to protocol`,"protocolEdit.placeholder":`# Protocol title
|
|
3
3
|
|
|
4
4
|
## Activation Patterns
|
|
5
5
|
...
|
|
6
6
|
|
|
7
7
|
## Step 1
|
|
8
|
-
...`,"protocolEdit.contentHint":`Include: Activation Patterns (first H2), steps (H2 + optional challenge block), Reward Signal (last H2).`,"protocolEdit.targetSpaceLabel":`Save to space`,"protocolEdit.targetSpaceHint":`New protocols are stored in the space you pick (default: Personal).`,"protocolEdit.forkSourceLabel":`Fork from adapter (optional)`,"protocolEdit.forkSourcePlaceholder":`squadrules://adapter/{slug}`,"protocolEdit.forkSourceHint":`Leave empty for a brand-new protocol, or paste an adapter URI to copy its markdown into the target space as a new adapter.`,"protocolEdit.forkUriInvalid":`Fork source must be a squadrules://adapter/{slug} URI.`,"protocolEdit.moveSpaceLabel":`Space for this protocol`,"protocolEdit.moveSpaceHint":`Change the space and save to move every layer to the selected space (same as tune with a space parameter).`,"protocolEdit.save":`Save`,"protocolEdit.saving":`Saving…`,"protocolEdit.cancel":`Cancel`,"account.title":`Account`,"account.intro":`You are signed in. Sign out below or use the options to manage your profile.`,"account.loading":`Loading…`,"account.notSignedIn":`You are not signed in.`,"account.signIn":`Sign in`,"account.name":`Name`,"account.username":`Username`,"account.email":`Email`,"account.emailVerified":`verified`,"account.accountType":`Account type`,"account.realm":`Realm`,"account.identityProvider":`Login provider`,"account.groups":`Groups`,"account.themeTitle":`Theme`,"account.themeDescription":`Choose how SQUADRULES UI appearance should be rendered.`,"account.themePreferenceLabel":`Theme preference`,"account.themeOptionLight":`Light`,"account.themeOptionDark":`Dark`,"account.themeOptionSystem":`Match system`,"account.logOut":`Log out`,"notFound.title":`Page not found`,"notFound.message":`The page you requested could not be found.`,"notFound.goHome":`Go to Home`,"error.title":`Something went wrong`,"error.retry":`Retry`,"error.goBack":`Go to Home`,"error.support":`Support`}}},interpolation:{escapeValue:!1}});var g=e(p(),1),_=m(),v=`/ui/assets/squadrules-mcp-Qc5pokoj.svg`,y=h(),b=e=>e.startsWith(`/protocols`)||e.startsWith(`/runs`);function x(){let{t:e}=f(),t=a().pathname,n=({isActive:e})=>`min-h-[var(--layout-touch-target)] flex items-center px-4 py-3 text-[var(--color-text)] no-underline border-l-[3px] border-transparent outline-offset-2 focus-visible:outline focus-visible:outline-2 focus-visible:outline-[var(--color-focus-ring)] hover:bg-[var(--color-surface)] hover:text-[var(--color-text-heading)] ${e?`font-semibold text-[var(--color-primary)] border-l-[var(--color-primary)] bg-[var(--color-surface)]`:``}`,r=b(t)?`min(100%, var(--layout-main-max), var(--layout-main-wide))`:`min(100%, var(--layout-main-max), var(--layout-main-narrow))`;return(0,y.jsxs)(y.Fragment,{children:[(0,y.jsx)(`a`,{href:`#main`,className:`skip-link`,children:e(`skipToMain`)}),(0,y.jsxs)(`div`,{className:`flex min-h-screen`,children:[(0,y.jsxs)(`aside`,{className:`flex min-h-screen w-[var(--layout-sidebar-width)] flex-shrink-0 flex-col border-r border-[var(--color-border)] bg-[var(--color-surface-elevated)] py-4`,"aria-label":`Main navigation`,children:[(0,y.jsx)(`div`,{className:`px-4 pb-4`,children:(0,y.jsxs)(c,{to:`/`,end:!0,className:`flex min-h-[var(--layout-touch-target)] min-w-[var(--layout-touch-target)] items-center gap-3 rounded-md outline-offset-2 focus-visible:outline focus-visible:outline-2 focus-visible:outline-[var(--color-focus-ring)]`,children:[(0,y.jsx)(`img`,{src:v,alt:``,className:`h-10 w-10 flex-shrink-0 rounded-lg object-contain`,width:`40`,height:`40`}),(0,y.jsxs)(`span`,{className:`flex flex-col leading-tight`,children:[(0,y.jsx)(`span`,{className:`font-bold text-[var(--color-text-heading)] text-lg`,children:`Squadrules`}),(0,y.jsx)(`span`,{className:`font-bold text-[var(--color-text-muted)] text-xs uppercase tracking-wide`,children:`MCP`})]})]})}),(0,y.jsxs)(`nav`,{className:`flex min-h-0 flex-1 flex-col gap-0.5`,children:[(0,y.jsx)(c,{to:`/`,end:!0,"aria-current":t===`/`?`page`:void 0,className:n,children:e(`nav.home`)}),(0,y.jsx)(c,{to:`/squadrules`,"aria-current":t===`/squadrules`?`page`:void 0,className:n,children:e(`nav.squadrules`)}),(0,y.jsx)(c,{to:`/protocols/new`,"aria-current":t===`/protocols/new`?`page`:void 0,className:n,children:e(`nav.create`)}),(0,y.jsx)(c,{to:`/runs`,"aria-current":t===`/runs`?`page`:void 0,className:n,children:e(`nav.runs`)}),(0,y.jsx)(c,{to:`/account`,"aria-current":t===`/account`?`page`:void 0,className:n,children:e(`nav.account`)})]}),(0,y.jsx)(`div`,{className:`mt-auto border-t border-[var(--color-border)] px-4 pt-3`,children:(0,y.jsx)(`p`,{className:`m-0 text-xs text-[var(--color-text-muted)]`,children:e(`layout.squadrulesVersion`,{version:`5.12.
|
|
8
|
+
...`,"protocolEdit.contentHint":`Include: Activation Patterns (first H2), steps (H2 + optional challenge block), Reward Signal (last H2).`,"protocolEdit.targetSpaceLabel":`Save to space`,"protocolEdit.targetSpaceHint":`New protocols are stored in the space you pick (default: Personal).`,"protocolEdit.forkSourceLabel":`Fork from adapter (optional)`,"protocolEdit.forkSourcePlaceholder":`squadrules://adapter/{slug}`,"protocolEdit.forkSourceHint":`Leave empty for a brand-new protocol, or paste an adapter URI to copy its markdown into the target space as a new adapter.`,"protocolEdit.forkUriInvalid":`Fork source must be a squadrules://adapter/{slug} URI.`,"protocolEdit.moveSpaceLabel":`Space for this protocol`,"protocolEdit.moveSpaceHint":`Change the space and save to move every layer to the selected space (same as tune with a space parameter).`,"protocolEdit.save":`Save`,"protocolEdit.saving":`Saving…`,"protocolEdit.cancel":`Cancel`,"account.title":`Account`,"account.intro":`You are signed in. Sign out below or use the options to manage your profile.`,"account.loading":`Loading…`,"account.notSignedIn":`You are not signed in.`,"account.signIn":`Sign in`,"account.name":`Name`,"account.username":`Username`,"account.email":`Email`,"account.emailVerified":`verified`,"account.accountType":`Account type`,"account.realm":`Realm`,"account.identityProvider":`Login provider`,"account.groups":`Groups`,"account.themeTitle":`Theme`,"account.themeDescription":`Choose how SQUADRULES UI appearance should be rendered.`,"account.themePreferenceLabel":`Theme preference`,"account.themeOptionLight":`Light`,"account.themeOptionDark":`Dark`,"account.themeOptionSystem":`Match system`,"account.logOut":`Log out`,"notFound.title":`Page not found`,"notFound.message":`The page you requested could not be found.`,"notFound.goHome":`Go to Home`,"error.title":`Something went wrong`,"error.retry":`Retry`,"error.goBack":`Go to Home`,"error.support":`Support`}}},interpolation:{escapeValue:!1}});var g=e(p(),1),_=m(),v=`/ui/assets/squadrules-mcp-Qc5pokoj.svg`,y=h(),b=e=>e.startsWith(`/protocols`)||e.startsWith(`/runs`);function x(){let{t:e}=f(),t=a().pathname,n=({isActive:e})=>`min-h-[var(--layout-touch-target)] flex items-center px-4 py-3 text-[var(--color-text)] no-underline border-l-[3px] border-transparent outline-offset-2 focus-visible:outline focus-visible:outline-2 focus-visible:outline-[var(--color-focus-ring)] hover:bg-[var(--color-surface)] hover:text-[var(--color-text-heading)] ${e?`font-semibold text-[var(--color-primary)] border-l-[var(--color-primary)] bg-[var(--color-surface)]`:``}`,r=b(t)?`min(100%, var(--layout-main-max), var(--layout-main-wide))`:`min(100%, var(--layout-main-max), var(--layout-main-narrow))`;return(0,y.jsxs)(y.Fragment,{children:[(0,y.jsx)(`a`,{href:`#main`,className:`skip-link`,children:e(`skipToMain`)}),(0,y.jsxs)(`div`,{className:`flex min-h-screen`,children:[(0,y.jsxs)(`aside`,{className:`flex min-h-screen w-[var(--layout-sidebar-width)] flex-shrink-0 flex-col border-r border-[var(--color-border)] bg-[var(--color-surface-elevated)] py-4`,"aria-label":`Main navigation`,children:[(0,y.jsx)(`div`,{className:`px-4 pb-4`,children:(0,y.jsxs)(c,{to:`/`,end:!0,className:`flex min-h-[var(--layout-touch-target)] min-w-[var(--layout-touch-target)] items-center gap-3 rounded-md outline-offset-2 focus-visible:outline focus-visible:outline-2 focus-visible:outline-[var(--color-focus-ring)]`,children:[(0,y.jsx)(`img`,{src:v,alt:``,className:`h-10 w-10 flex-shrink-0 rounded-lg object-contain`,width:`40`,height:`40`}),(0,y.jsxs)(`span`,{className:`flex flex-col leading-tight`,children:[(0,y.jsx)(`span`,{className:`font-bold text-[var(--color-text-heading)] text-lg`,children:`Squadrules`}),(0,y.jsx)(`span`,{className:`font-bold text-[var(--color-text-muted)] text-xs uppercase tracking-wide`,children:`MCP`})]})]})}),(0,y.jsxs)(`nav`,{className:`flex min-h-0 flex-1 flex-col gap-0.5`,children:[(0,y.jsx)(c,{to:`/`,end:!0,"aria-current":t===`/`?`page`:void 0,className:n,children:e(`nav.home`)}),(0,y.jsx)(c,{to:`/squadrules`,"aria-current":t===`/squadrules`?`page`:void 0,className:n,children:e(`nav.squadrules`)}),(0,y.jsx)(c,{to:`/protocols/new`,"aria-current":t===`/protocols/new`?`page`:void 0,className:n,children:e(`nav.create`)}),(0,y.jsx)(c,{to:`/runs`,"aria-current":t===`/runs`?`page`:void 0,className:n,children:e(`nav.runs`)}),(0,y.jsx)(c,{to:`/account`,"aria-current":t===`/account`?`page`:void 0,className:n,children:e(`nav.account`)})]}),(0,y.jsx)(`div`,{className:`mt-auto border-t border-[var(--color-border)] px-4 pt-3`,children:(0,y.jsx)(`p`,{className:`m-0 text-xs text-[var(--color-text-muted)]`,children:e(`layout.squadrulesVersion`,{version:`5.12.1`})})})]}),(0,y.jsx)(`main`,{id:`main`,className:`flex-1 mx-auto w-full py-[var(--layout-main-padding-y)] px-[var(--layout-main-padding-x)]`,style:{maxWidth:r},tabIndex:-1,children:(0,y.jsx)(s,{})})]})]})}var S=(0,g.lazy)(()=>r(()=>import(`./HomePage-B--ESwM9.js`).then(e=>({default:e.HomePage})),__vite__mapDeps([0,1,2,3,4,5,6,7]))),C=(0,g.lazy)(()=>r(()=>import(`./SquadrulesPage-C37VEZnc.js`).then(e=>({default:e.SquadrulesPage})),__vite__mapDeps([8,2,1,3,4,6,5,9]))),w=(0,g.lazy)(()=>r(()=>import(`./RunsPage-BSgcu2TO.js`).then(e=>({default:e.RunsPage})),__vite__mapDeps([10,1,2,3,4,11]))),T=(0,g.lazy)(()=>r(()=>import(`./ProtocolEditPage-IvFbUiUS.js`).then(e=>({default:e.ProtocolEditPage})),__vite__mapDeps([12,2,1,3,4,6,5,7,13,14,15]))),E=(0,g.lazy)(()=>r(()=>import(`./RunGuidedPage-Db_CQ-9q.js`).then(e=>({default:e.RunGuidedPage})),__vite__mapDeps([16,2,1,3,4,6,7,9,14,17,11]))),D=(0,g.lazy)(()=>r(()=>import(`./SkillBundlePage-DV9CXjfI.js`).then(e=>({default:e.SkillBundlePage})),__vite__mapDeps([18,2,1,3,4,7,13,6,15]))),O=(0,g.lazy)(()=>r(()=>import(`./ProtocolDetailPage-kPGgNobg.js`).then(e=>({default:e.ProtocolDetailPage})),__vite__mapDeps([19,2,1,3,4,7,13,6,14,17]))),k=(0,g.lazy)(()=>r(()=>import(`./AccountPage-BhneCJCw.js`).then(e=>({default:e.AccountPage})),__vite__mapDeps([20,1,2,3,4,6]))),A=(0,g.lazy)(()=>r(()=>import(`./NotFoundPage-bTE_mpMC.js`).then(e=>({default:e.NotFoundPage})),__vite__mapDeps([21,1,2,3,4,9])));function j(){return(0,y.jsx)(`div`,{className:`flex min-h-[12rem] items-center justify-center text-[var(--color-text-muted)]`,"aria-busy":`true`,children:`Loading…`})}function M(){return(0,y.jsx)(i,{children:(0,y.jsxs)(l,{path:`/`,element:(0,y.jsx)(x,{}),children:[(0,y.jsx)(l,{index:!0,element:(0,y.jsx)(g.Suspense,{fallback:(0,y.jsx)(j,{}),children:(0,y.jsx)(S,{})})}),(0,y.jsx)(l,{path:`squadrules`,element:(0,y.jsx)(g.Suspense,{fallback:(0,y.jsx)(j,{}),children:(0,y.jsx)(C,{})})}),(0,y.jsx)(l,{path:`runs`,element:(0,y.jsx)(g.Suspense,{fallback:(0,y.jsx)(j,{}),children:(0,y.jsx)(w,{})})}),(0,y.jsx)(l,{path:`protocols/new`,element:(0,y.jsx)(g.Suspense,{fallback:(0,y.jsx)(j,{}),children:(0,y.jsx)(T,{})})}),(0,y.jsx)(l,{path:`protocols/:uri/edit`,element:(0,y.jsx)(g.Suspense,{fallback:(0,y.jsx)(j,{}),children:(0,y.jsx)(T,{})})}),(0,y.jsx)(l,{path:`protocols/:uri/run`,element:(0,y.jsx)(g.Suspense,{fallback:(0,y.jsx)(j,{}),children:(0,y.jsx)(E,{})})}),(0,y.jsx)(l,{path:`protocols/:uri/skill`,element:(0,y.jsx)(g.Suspense,{fallback:(0,y.jsx)(j,{}),children:(0,y.jsx)(D,{})})}),(0,y.jsx)(l,{path:`protocols/:uri`,element:(0,y.jsx)(g.Suspense,{fallback:(0,y.jsx)(j,{}),children:(0,y.jsx)(O,{})})}),(0,y.jsx)(l,{path:`account`,element:(0,y.jsx)(g.Suspense,{fallback:(0,y.jsx)(j,{}),children:(0,y.jsx)(k,{})})}),(0,y.jsx)(l,{path:`*`,element:(0,y.jsx)(g.Suspense,{fallback:(0,y.jsx)(j,{}),children:(0,y.jsx)(A,{})})})]})})}function N(){return(0,y.jsx)(o,{basename:`/ui`,children:(0,y.jsx)(M,{})})}var P=[`light`,`dark`],F=`squadrules:ui:theme-preference`,I=`(prefers-color-scheme: dark)`,L=`system`;function R(e){return e===null?!1:e===`system`||P.includes(e)}function z(e,t){return e===`system`?t?`dark`:`light`:e}function B(){if(typeof window>`u`)return L;try{let e=window.localStorage.getItem(F);return R(e)?e:L}catch{return L}}function V(){return typeof window>`u`||typeof window.matchMedia!=`function`?!1:window.matchMedia(I).matches}function H(e){if(typeof document>`u`)return;let t=document.documentElement;t.setAttribute(`data-theme`,e),t.style.colorScheme=e===`light`?`light`:`dark`}function U(){let[e,t]=(0,g.useState)(()=>B()),[n,r]=(0,g.useState)(()=>V()),i=(0,g.useMemo)(()=>z(e,n),[e,n]);return(0,g.useEffect)(()=>{H(i)},[i]),(0,g.useEffect)(()=>{if(typeof window>`u`||e!==`system`||typeof window.matchMedia!=`function`)return;let t=window.matchMedia(I);r(t.matches);let n=e=>{r(e.matches)};return typeof t.addEventListener==`function`?(t.addEventListener(`change`,n),()=>t.removeEventListener(`change`,n)):(t.addListener(n),()=>t.removeListener(n))},[e]),(0,g.useEffect)(()=>{if(typeof window>`u`)return;let e=e=>{e.key===`squadrules:ui:theme-preference`&&t(R(e.newValue)?e.newValue:L)};return window.addEventListener(`storage`,e),()=>window.removeEventListener(`storage`,e)},[]),{preference:e,effectiveTheme:i,setPreference:(0,g.useCallback)(e=>{if(t(e),typeof window<`u`)try{window.localStorage.setItem(F,e)}catch{}},[])}}var W=(0,g.createContext)(null);function G({children:e}){let t=U();return(0,y.jsx)(W.Provider,{value:t,children:e})}function K(){let e=(0,g.useContext)(W);if(!e)throw Error(`useThemePreferenceContext must be used within ThemeProvider`);return e}var q=new t;(0,_.createRoot)(document.getElementById(`root`)).render((0,y.jsx)(g.StrictMode,{children:(0,y.jsx)(u,{client:q,children:(0,y.jsx)(G,{children:(0,y.jsx)(N,{})})})}));export{R as n,K as r,P as t};
|
package/dist/ui/index.html
CHANGED
|
@@ -26,7 +26,7 @@
|
|
|
26
26
|
root.style.colorScheme = theme;
|
|
27
27
|
})();
|
|
28
28
|
</script>
|
|
29
|
-
<script type="module" crossorigin src="/ui/assets/index-
|
|
29
|
+
<script type="module" crossorigin src="/ui/assets/index-rCZd_925.js"></script>
|
|
30
30
|
<link rel="modulepreload" crossorigin href="/ui/assets/rolldown-runtime-hePW80VL.js">
|
|
31
31
|
<link rel="modulepreload" crossorigin href="/ui/assets/react-BvB9BS1T.js">
|
|
32
32
|
<link rel="modulepreload" crossorigin href="/ui/assets/tiptap-CCr8bvo1.js">
|
package/package.json
CHANGED