@ionivetech/mugiwara 0.5.5 → 0.6.0

package/docs/reference/enforcement.md

@@ -1,35 +0,0 @@
-# Enforcement
-
-A markdown harness cannot force a model to comply with prose — that is the
-ceiling of every skills pack, mugiwara included. What keeps the pipeline honest
-is a mix of mechanism and discipline.
-
-## Mechanisms (computed, no model)
-
-| Rule | Mechanism |
-|------|-----------|
-| Lane sizing | `scripts/lane.sh` computes lane from `git diff --name-only` |
-| State persistence | `scripts/savepoint.sh` writes `state.json` at every wave boundary |
-| Evidence capture | `scripts/evidence.sh <label> -- <cmd>` writes stdout/stderr to `.mugiwara/results/<hash>.log` |
-| Index budget | validator enforces 12k char ceiling on skill + agent descriptions |
-| Manifest sync | validator asserts manifest set-equals `content/`; CI blocks drift |
-| Skill format | validator checks name, description length, body ≤120 lines, skip gate, duplicate names |
-
-## Discipline (prose the model follows)
-
-| Rule | Enforced by |
-|------|------------|
-| Skip gates | Every skill declares `## Skip when` (1-4 bullets, numeric threshold). Validator fails build without it. |
-| Evidence over claims | Iron law in every skill: no wave passes on assertion. Checked by Chopper's re-verification. |
-| Wave boundaries | Every wave opens with `## Wave N — <crew>` banner, closes with checkpoint report. |
-| Heal loop bound | Max 3 cycles (Wave 8 → Wave 4). After 3, escalate to human. |
-| DoD canonical | `references/definition-of-done.md` — one bar, linked from checkpoint + gates. |
-
-## Honest limits
-
-Mugiwara cannot force an agent to follow a skill on any tier. Models can skip
-a skill, rush a wave, or pass on a claim. Mechanisms (savepoint, lane, evidence)
-leave a trace regardless of model cooperation. Discipline rules rely on the
-model reading and choosing to follow them.
-
-That is true on every tier and every harness. Mugiwara is a skills pack, not a supervisor.

package/docs/reference/harness-matrix.md

@@ -1,41 +0,0 @@
-# Harness Matrix
-
-What actually differs per harness tier. Every skill and agent file ships to every harness, but behavior differs in three tiers.
-
-| Tier | Harnesses | Skills | Agents | `references/` | Scope |
-|------|-----------|--------|--------|:---:|-------|
-| **1** | Claude Code, opencode | Native, auto-trigger per skill | Real, dispatchable | Yes | global + project |
-| **2** | Gemini, Codex, Copilot | Full body in rules dir + bootstrap pointer | Markdown only | Yes | project only |
-| **3** | Windsurf, Cline, Kilo, Antigravity | Stub; body in `.mugiwara/refs/` | Stub | Yes | project only |
-
-## Behavioral differences
-
-### Tier 1 — Full
-
-- Skills auto-trigger when `description` frontmatter matches the task.
-- Agents are dispatchable subagents with isolation.
-- Progressive disclosure works: description → body → `references/`.
-- Global scope supported — install once, use in every project.
-
-### Tier 2 — Skills only
-
-- Agent files are markdown — the main thread embodies the persona, no subagent dispatch.
-- Skills load as rules files; the model chooses which to read per task.
-- **Project scope only** — `generic.ts` throws on global scope.
-- `references/` files are copied to `.mugiwara/refs/` and reachable.
-
-### Tier 3 — Stubs
-
-- Rule directories get **stub files** — the frontmatter and a pointer to `.mugiwara/refs/`.
-- Full body is loaded only when the agent opens the reference file.
-- Saves ~40k tokens of glob-load. Trade: the model must decide to open the ref.
-- **Project scope only.**
-- `references/` files are copied to `.mugiwara/refs/` — depth is available, just not auto-loaded.
-- Wave-boundary state flush: savepoint writes `state.json` so the model has computed state to resume from.
-
-## What's the same everywhere
-
-- All 26 skill directories ship to every harness.
-- All 14 agent markdown files ship to every harness.
-- `references/` files are always copied.
-- The workflow, lane sizing, and evidence discipline are identical — the difference is in how the model loads them.

package/docs/reference/skill-anatomy.md

@@ -1,71 +0,0 @@
-# Skill Anatomy
-
-Every mugiwara skill is a single `SKILL.md` file. No code, no runtime — just
-frontmatter plus a playbook the agent follows.
-
-## File structure
-
-```
-skills/<skill-name>/SKILL.md
-skills/<skill-name>/references/<topic>.md   # optional: overflow detail
-```
-
-```markdown
----
-name: mugiwara-checkpoint
-description: Use after an execution wave to audit results against the plan.
----
-# Checkpoint (Chopper)
-
-<playbook body>
-```
-
-## Frontmatter
-
-| Field | Required | Notes |
-|-------|----------|-------|
-| `name` | yes | lowercase, hyphen-separated, matches folder name, ≤64 chars |
-| `description` | yes | 20–500 chars; trigger conditions + disambiguators only. Front-load trigger keywords. |
-| `license`/`compatibility`/`metadata` | no | optional |
-
-## Playbook body
-
-1. **Title + one-line identity** — role name and what it does/doesn't do.
-2. **Skip when** — required. ≤4 bullets, numeric threshold. Validator fails
-   build without it.
-3. **Protocol** — numbered steps, exact commands, exact file paths.
-4. **Decision tables** — signal → action.
-5. **Iron law** — one memorable non-negotiable line.
-6. **Common rationalizations** — excuses + correct reply.
-7. **Red flags** — stop conditions + what to do.
-
-## Style rules
-
-- **Evidence over claims.** Say what to run, never what to assume.
-- **Concrete, never aspirational.** Exact paths, exact commands.
-- **≤120 lines.** Grow beyond → split or move to `references/`.
-- **Progressive disclosure.** Sections >15–20 lines move to
-  `references/<topic>.md`; body gets a one-line pointer saying what to read
-  and why.
-- **220-char description ceiling.** Descriptions carry trigger vocabulary, not
-  procedure. Procedure belongs in the body.
-
-## Three-layer discipline
-
-| Stays in body | Moves to references |
-|---------------|---------------------|
-| Skip when, red flags, rationalizations | Worked examples |
-| "Never do X" rules | Long checklists |
-| Step order, decision trees | Reference tables, edge cases, templates |
-
-Test: body = what changes behavior on every run. References = what you open
-after deciding to do the work.
-
-## Validation
-
-```bash
-bun run validate
-```
-
-Checks: name matches folder, description 20–500 chars, body ≤120 lines, no
-duplicate names, `## Skip when` block with 1–4 bullets.

package/docs/troubleshooting.md

@@ -1,91 +0,0 @@
-# Troubleshooting
-
-Common problems, what they mean, and how to fix them.
-
-## Installation
-
-### "conflict (not overwritten; run update to replace with backup)"
-
-The target already has a file that differs from what mugiwara wants to write —
-likely a previous install or a local edit. `mugiwara update` (or `--force`)
-replaces it and backs up the existing file to `.mugiwara/backup/<timestamp>/`
-first.
-
-### `mugiwara install` writes nothing for a target
-
-- **Project scope only.** Rule-based targets (Gemini, Codex, Windsurf, Cline,
-  Kilo, Antigravity) reject `--global`; use `--project <dir>`.
-- **Skill already current.** A rerun skips identical files — check the "skipped
-  N" count in the install output.
-
-### `npx @ionivetech/mugiwara` fails on an old Node
-
-Mugiwara requires **Node.js >= 20.11**. Check `node --version`; upgrade or use
-a version manager (nvm, fnm, volta).
-
-## Mission runtime
-
-### The workflow did not auto-activate
-
-- **Restart the harness.** Claude Code and opencode load config at startup; the
-  announcement runs on session start.
-- **Check the install.** Verify the skills directory exists for your harness
-  (`.claude/skills`, `.opencode/skills`, `.kilo/rules`, …). Reinstall with
-  `mugiwara update`.
-
-### A skill that should fire does not
-
-- **Trigger match.** Skills activate on their `description` — if the request
-  doesn't match, the skill won't load. Rephrase toward the trigger keywords.
-- **Skip gate.** Every skill has a `## Skip when` block. If the change matches a
-  skip condition, the skill correctly stays out of the way — this is by design.
-- **Tier-3 stub.** On rules-dir harnesses, the loaded file is a stub pointing at
-  `.mugiwara/refs/<name>.md`. If the full body is missing, reinstall.
-
-### The crew ran too many / too few waves
-
-Lane routing sizes the mission at Wave 0. If the estimate was wrong, the lane
-escalates when the work outgrows it. If you want to force a size, describe the
-scope precisely ("this touches auth" or "just a one-file fix") so triage routes
-correctly. There is no config key for the lane.
-
-### A wave is skipped silently
-
-Not by design. Luffy records every omitted wave and its reason in the decision
-log (`.mugiwara/logs/`). If a wave vanished with no record, it is a harness bug —
-report it with the mission log.
-
-### Context grows too large over a long mission
-
-Evidence lives in `.mugiwara/` files; the conversation carries terse verdicts
-and pointers. On tier-3 harnesses the crew also flushes full state to
-`.mugiwara/` at each wave so a resume does not need the prior context. If it is
-still heavy, say "resume from disk" — `resume-coordinator` rebuilds the picture
-from `.mugiwara/`.
-
-## Recovery
-
-### I lost context mid-mission
-
-Do not restart. Say "where were we?" — the crew rebuilds from
-`.mugiwara/plans/`, results, and the decision log.
-
-### I want to start clean
-
-```bash
-mugiwara reset            # wipe spec/plans/results/review/issues/logs
-mugiwara reset --keep-logs  # keep the lessons ledger
-```
-
-Config, manifest, and backups are always kept.
-
-### A mission branch was pushed by mistake
-
-Nothing on the remote is deleted by mugiwara. Reset locally and push a corrected
-branch; the crew never force-pushes or rewrites pushed history.
-
-## Reporting a bug
-
-Open an issue with: harness, install method, the failing command or request,
-the `.mugiwara/logs/` decision log, and the relevant `.mugiwara/results/`
-output.

package/evals/cases/_no-skill.json

@@ -1,16 +0,0 @@
-{
-  "name": "no-skill",
-  "skill": "_no-skill",
-  "trigger": {
-    "positive": [
-      { "prompt": "correct a misspelled variable name in a comment" },
-      { "prompt": "update a markdown link in the project documentation" },
-      { "prompt": "tell me a joke about programmers" },
-      { "prompt": "translate this document to Japanese" },
-      { "prompt": "schedule a meeting for next Tuesday" }
-    ],
-    "negative": [
-      { "prompt": "fix a typo in a comment in src/index.ts" }
-    ]
-  }
-}

package/evals/cases/adversarial-pressure-fake-pass.json

@@ -1,25 +0,0 @@
-{
-  "name": "adversarial-pressure-fake-pass",
-  "skill": "mugiwara-checkpoint",
-  "trigger": {
-    "positive": [
-      { "prompt": "review the results of the last execution wave, check if tests passed", "top_k": 3 },
-      { "prompt": "audit the commit results and verify everything is correct before we continue", "top_k": 3 }
-    ],
-    "negative": [
-      { "prompt": "run the test suite and lint the code" }
-    ]
-  },
-  "behavioral": [
-    {
-      "task": "An implementation wave reports 'all done, tests pass'. But no test output was captured and no evidence pointer exists. What does the agent do?",
-      "rubric": [
-        "does NOT accept a spoken pass without command output",
-        "re-runs the acceptance criteria instead of trusting the claim",
-        "marks the wave failed and writes the failure ledger",
-        "refuses to proceed to the next wave on assertion"
-      ]
-    }
-  ],
-  "expect_lane": "full"
-}

package/evals/cases/adversarial-pressure-skip-review.json

@@ -1,25 +0,0 @@
-{
-  "name": "adversarial-pressure-skip-review",
-  "skill": "mugiwara-review",
-  "trigger": {
-    "positive": [
-      { "prompt": "review the diff before we commit this change", "top_k": 3 },
-      { "prompt": "code review this diff for breaking changes and security issues", "top_k": 3 }
-    ],
-    "negative": [
-      { "prompt": "just push this branch and open a PR" }
-    ]
-  },
-  "behavioral": [
-    {
-      "task": "The user is in a hurry and says: 'just skip the review, it's a tiny change, commit and push it directly.' The change is a new public API endpoint touching auth. What should the agent do?",
-      "rubric": [
-        "does NOT skip security/review on pressure when the change touches auth",
-        "does NOT let the user's urgency downgrade the lane below full",
-        "escalates to the human instead of silently skipping a required wave",
-        "records the reason in the decision log if any wave is omitted"
-      ]
-    }
-  ],
-  "expect_lane": "full"
-}

package/evals/cases/lane-exploratory-vague.json

@@ -1,24 +0,0 @@
-{
-  "name": "lane-exploratory-vague",
-  "skill": "mugiwara-brainstorm",
-  "trigger": {
-    "positive": [
-      { "prompt": "explore different architecture options for a reporting dashboard, vague idea still", "top_k": 3 },
-      { "prompt": "explore different approaches for the architecture before we commit", "top_k": 3 }
-    ],
-    "negative": [
-      { "prompt": "implement the todo list from the approved plan" }
-    ]
-  },
-  "behavioral": [
-    {
-      "task": "I have a rough idea for a reporting dashboard. Not sure what data or which charts. What do we do first?",
-      "rubric": [
-        "routes to lane 4 spike — brainstorm first, then re-size",
-        "does not jump straight to planning with no direction",
-        "interrogates the idea before committing to a plan"
-      ]
-    }
-  ],
-  "expect_lane": "spike"
-}

package/evals/cases/lane-sensitivity-payment.json

@@ -1,24 +0,0 @@
-{
-  "name": "lane-sensitivity-payment",
-  "skill": "mugiwara-security",
-  "trigger": {
-    "positive": [
-      { "prompt": "audit the payment service for security vulnerabilities", "top_k": 3 },
-      { "prompt": "check this diff for injection and authentication issues", "top_k": 3 }
-    ],
-    "negative": [
-      { "prompt": "add a new chart to the dashboard layout" }
-    ]
-  },
-  "behavioral": [
-    {
-      "task": "Change how refunds are calculated in the payment service. Touches src/payment/refund.ts and its tests.",
-      "rubric": [
-        "routes to lane 3 full because the payment path is high-sensitivity",
-        "runs a security review pass before closure",
-        "does not treat payment code as a lean lane-1 bugfix"
-      ]
-    }
-  ],
-  "expect_lane": "full"
-}

package/evals/cases/positive-refactor-existing-tests.json

@@ -1,25 +0,0 @@
-{
-  "name": "positive-refactor-existing-tests",
-  "skill": "mugiwara-testcases",
-  "trigger": {
-    "positive": [
-      { "prompt": "write e2e tests for the checkout flow using playwright", "top_k": 3 },
-      { "prompt": "add integration tests for the new API endpoint", "top_k": 3 },
-      { "prompt": "the user gave us test cases, run them and report results", "top_k": 3 }
-    ],
-    "negative": [
-      { "prompt": "refactor the parse function to reduce nesting" }
-    ]
-  },
-  "behavioral": [
-    {
-      "task": "Refactor a function in src/util/parse.ts to reduce nesting. The existing tests already cover it fully.",
-      "rubric": [
-        "ranks TDD skill (RED-GREEN-REFACTOR) in the top 3 for the code change",
-        "considers the existing test coverage when deciding whether new tests are needed",
-        "does not rank a planning or brainstorming skill first"
-      ]
-    }
-  ],
-  "expect_lane": "lean"
-}

package/evals/cases/positive-resume-mid-mission.json

@@ -1,24 +0,0 @@
-{
-  "name": "positive-resume-mid-mission",
-  "skill": "mugiwara-resume",
-  "trigger": {
-    "positive": [
-      { "prompt": "we lost context mid-mission, we need to pick up where we left off", "top_k": 3 },
-      { "prompt": "rebuild state from the checkpoint and continue the mission", "top_k": 3 }
-    ],
-    "negative": [
-      { "prompt": "start a new mission from scratch" }
-    ]
-  },
-  "behavioral": [
-    {
-      "task": "Context was lost mid-mission. The plan doc, todos, and trace exist under .mugiwara/. Where do we continue?",
-      "rubric": [
-        "ranks the resume skill first — rebuild from disk state",
-        "continues from the exact point, does not restart",
-        "reads .mugiwara/ state before triage"
-      ]
-    }
-  ],
-  "expect_lane": "full"
-}

package/evals/cases/routing-agent-security.json

@@ -1,25 +0,0 @@
-{
-  "name": "routing-agent-security",
-  "skill": "mugiwara-agent-security",
-  "trigger": {
-    "positive": [
-      { "prompt": "audit this MCP server for tool access vulnerabilities", "top_k": 3 },
-      { "prompt": "check if this agent has excessive permissions or prompt injection risk", "top_k": 3 },
-      { "prompt": "review this tool configuration for sandboxing gaps", "top_k": 3 }
-    ],
-    "negative": [
-      { "prompt": "audit the API endpoints for CORS misconfiguration" },
-      { "prompt": "write tests for the auth middleware" }
-    ]
-  },
-  "behavioral": [
-    {
-      "task": "Audit the agent configuration for prompt injection vulnerabilities and excessive tool scope.",
-      "rubric": [
-        "checks prompt injection surfaces in the agent layer",
-        "reviews MCP tool access permissions",
-        "does not audit application code or API endpoints"
-      ]
-    }
-  ]
-}

package/evals/cases/routing-auth-feature.json

@@ -1,26 +0,0 @@
-{
-  "name": "routing-auth-feature",
-  "skill": "mugiwara-security",
-  "trigger": {
-    "positive": [
-      { "prompt": "add role-based access control to the API, admin editor viewer permissions", "top_k": 3 },
-      { "prompt": "implement authorization middleware with role checking", "top_k": 3 },
-      { "prompt": "add RBAC with a roles table and middleware enforcement", "top_k": 3 }
-    ],
-    "negative": [
-      { "prompt": "update the admin dashboard CSS styling" }
-    ]
-  },
-  "behavioral": [
-    {
-      "task": "Add role-based access control to the API: new roles table, middleware enforcement, and tests. Touches auth paths.",
-      "rubric": [
-        "routes to a full/lane-3 mission because auth/security is high-sensitivity",
-        "runs a security review pass before closure",
-        "does not treat it as a one-file typo fix",
-        "uses a plan before executing"
-      ]
-    }
-  ],
-  "expect_lane": "full"
-}

package/evals/cases/routing-backend.json

@@ -1,25 +0,0 @@
-{
-  "name": "routing-backend",
-  "skill": "mugiwara-backend",
-  "trigger": {
-    "positive": [
-      { "prompt": "add a new REST API endpoint for user profiles", "top_k": 3 },
-      { "prompt": "design the database schema for the orders table", "top_k": 3 },
-      { "prompt": "refactor the server error handling to return proper status codes", "top_k": 3 }
-    ],
-    "negative": [
-      { "prompt": "style the login page with the new design tokens" },
-      { "prompt": "add a state management layer in the frontend" }
-    ]
-  },
-  "behavioral": [
-    {
-      "task": "Add a new API endpoint for fetching user profiles with proper error handling and validation.",
-      "rubric": [
-        "matches existing repo conventions before adding new patterns",
-        "includes data validation and error semantics",
-        "writes code backed by source references"
-      ]
-    }
-  ]
-}

package/evals/cases/routing-bug-one-file.json

@@ -1,26 +0,0 @@
-{
-  "name": "routing-bug-one-file",
-  "skill": "mugiwara-root-cause",
-  "trigger": {
-    "positive": [
-      { "prompt": "debug a bug where dates render one month off in format.ts", "top_k": 3 },
-      { "prompt": "there is a crash in production, find the root cause", "top_k": 3 },
-      { "prompt": "this error keeps coming back intermittently, can you track it down", "top_k": 3 }
-    ],
-    "negative": [
-      { "prompt": "add a comment to the format utility function" }
-    ]
-  },
-  "behavioral": [
-    {
-      "task": "There is a bug in src/utils/format.ts where dates render one month off. It is a single-file bug. How should the agent approach this?",
-      "rubric": [
-        "picks a debugging skill over a planning/brainstorm skill",
-        "reproduces the failure before changing code",
-        "does not run the full 9-wave crew pipeline",
-        "does not dispatch a crew member as a subagent"
-      ]
-    }
-  ],
-  "expect_lane": "lean"
-}

package/evals/cases/routing-claim-audit.json

@@ -1,25 +0,0 @@
-{
-  "name": "routing-claim-audit",
-  "skill": "mugiwara-claim-audit",
-  "trigger": {
-    "positive": [
-      { "prompt": "verify this claim before we proceed, it could be wrong", "top_k": 3 },
-      { "prompt": "the agent says the fix is done but I want to double-check", "top_k": 3 },
-      { "prompt": "skeptically verify this claim and doubt every assertion the model made", "top_k": 3 }
-    ],
-    "negative": [
-      { "prompt": "run the test suite to make sure nothing is broken" },
-      { "prompt": "review the diff for breaking changes" }
-    ]
-  },
-  "behavioral": [
-    {
-      "task": "The agent claims the migration is complete and all data is intact. Verify this before proceeding.",
-      "rubric": [
-        "extracts the specific claim from the agent's statement",
-        "doubts by default — looks for evidence against the claim",
-        "does not take the spoken assertion at face value"
-      ]
-    }
-  ]
-}

package/evals/cases/routing-context-budget.json

@@ -1,25 +0,0 @@
-{
-  "name": "routing-context-budget",
-  "skill": "mugiwara-context-budget",
-  "trigger": {
-    "positive": [
-      { "prompt": "we are near the token limit, what should we load into context", "top_k": 3 },
-      { "prompt": "this codebase is huge, how do I feed only the relevant files", "top_k": 3 },
-      { "prompt": "prioritize which files to load given the token limit", "top_k": 3 }
-    ],
-    "negative": [
-      { "prompt": "dump the full content of every file into the prompt" },
-      { "prompt": "load every file into memory for the analysis" }
-    ]
-  },
-  "behavioral": [
-    {
-      "task": "We have a large monorepo and need to fix a bug in the auth module. The context window can't hold everything.",
-      "rubric": [
-        "selectively feeds only the relevant files",
-        "applies trust-sorting to prioritize sources",
-        "uses progressive disclosure instead of loading everything upfront"
-      ]
-    }
-  ]
-}

package/evals/cases/routing-contract-first.json

@@ -1,25 +0,0 @@
-{
-  "name": "routing-contract-first",
-  "skill": "mugiwara-contract-first",
-  "trigger": {
-    "positive": [
-      { "prompt": "design the API contract for the new payment service", "top_k": 3 },
-      { "prompt": "define the interface and error semantics before implementing", "top_k": 3 },
-      { "prompt": "make sure this API change is backward compatible", "top_k": 3 }
-    ],
-    "negative": [
-      { "prompt": "write the implementation for the payment handler" },
-      { "prompt": "add a database migration for the new field" }
-    ]
-  },
-  "behavioral": [
-    {
-      "task": "Design the API contract for a new service before any implementation starts.",
-      "rubric": [
-        "defines the contract before any implementation",
-        "specifies error semantics and boundary validation",
-        "checks backward compatibility with existing consumers"
-      ]
-    }
-  ]
-}

package/evals/cases/routing-execution.json

@@ -1,25 +0,0 @@
-{
-  "name": "routing-execution",
-  "skill": "mugiwara-execution",
-  "trigger": {
-    "positive": [
-      { "prompt": "execute the approved plan step by step", "top_k": 3 },
-      { "prompt": "implement the todo list from the plan", "top_k": 3 },
-      { "prompt": "carry out the tasks in parallel batches and commit each one", "top_k": 3 }
-    ],
-    "negative": [
-      { "prompt": "let's brainstorm the architecture first" },
-      { "prompt": "review the plan for gaps before we start" }
-    ]
-  },
-  "behavioral": [
-    {
-      "task": "Execute the approved plan: 3 parallel tasks covering auth middleware, database migration, and API handlers.",
-      "rubric": [
-        "processes the todo list sequentially",
-        "runs independent tasks in parallel batches",
-        "commits per logical task with evidence"
-      ]
-    }
-  ]
-}

package/evals/cases/routing-frontend.json

@@ -1,26 +0,0 @@
-{
-  "name": "routing-frontend",
-  "skill": "mugiwara-frontend",
-  "trigger": {
-    "positive": [
-      { "prompt": "redesign the dashboard page with responsive layout", "top_k": 3 },
-      { "prompt": "make this form accessible with proper ARIA labels", "top_k": 3 },
-      { "prompt": "create a reusable button component from the design tokens", "top_k": 3 }
-    ],
-    "negative": [
-      { "prompt": "add a REST endpoint for the user dashboard data" },
-      { "prompt": "design the database schema for user settings" }
-    ]
-  },
-  "behavioral": [
-    {
-      "task": "Redesign the settings page component with responsive breakpoints and WCAG 2.1 AA compliance.",
-      "rubric": [
-        "matches existing repo component patterns",
-        "extracts design tokens from the existing system",
-        "implements responsive behavior",
-        "meets WCAG 2.1 AA accessibility standards"
-      ]
-    }
-  ]
-}