@chllming/wave-orchestration 0.5.4 → 0.6.1

package/skills/provider-railway/skill.json

@@ -1,5 +1,71 @@
 {
   "id": "provider-railway",
   "title": "Railway",
-  "description": "Railway-specific deploy and environment norms."
+  "description": "Guides deploy verification against Railway MCP and CLI state: service health, domain binding, variable proof, failure classification, and rollback posture.",
+  "activation": {
+    "when": "Attach when the wave deploy surface is Railway and the agent is responsible for provider-aware rollout, infra, integration, or closure checks.",
+    "roles": [
+      "deploy",
+      "infra",
+      "integration",
+      "cont-qa"
+    ],
+    "runtimes": [],
+    "deployKinds": [
+      "railway-cli",
+      "railway-mcp"
+    ]
+  },
+  "termination": "Stop when Railway evidence is recorded or the failure and rollback posture is explicit.",
+  "permissions": {
+    "network": [
+      "railway.app"
+    ],
+    "shell": [
+      "railway"
+    ],
+    "mcpServers": [
+      "railway"
+    ]
+  },
+  "trust": {
+    "tier": "repo-owned"
+  },
+  "evalCases": [
+    {
+      "id": "deploy-railway-cli",
+      "role": "deploy",
+      "runtime": "opencode",
+      "deployKind": "railway-cli",
+      "expectActive": true
+    },
+    {
+      "id": "integration-railway-mcp",
+      "role": "integration",
+      "runtime": "claude",
+      "deployKind": "railway-mcp",
+      "expectActive": true
+    },
+    {
+      "id": "cont-qa-railway-cli",
+      "role": "cont-qa",
+      "runtime": "claude",
+      "deployKind": "railway-cli",
+      "expectActive": true
+    },
+    {
+      "id": "documentation-railway-cli",
+      "role": "documentation",
+      "runtime": "opencode",
+      "deployKind": "railway-cli",
+      "expectActive": false
+    },
+    {
+      "id": "implementation-railway-cli",
+      "role": "implementation",
+      "runtime": "codex",
+      "deployKind": "railway-cli",
+      "expectActive": false
+    }
+  ]
 }

package/skills/provider-ssh-manual/SKILL.md

@@ -1,6 +1,97 @@
 # SSH Manual
 
+<!-- CUSTOMIZE: Add your hosts, SSH access patterns, approved operations, and sudo policies below. -->
+
+## Core Rules
+
 - Treat manual host access as high-risk and fail closed on missing proof.
 - Record the exact host or surface touched and the exact checks performed.
 - Avoid destructive manual changes unless explicitly approved by the task and repo policy.
 - Convert shell observations into explicit environment or deploy status markers.
+- Every SSH session must produce a durable evidence record. No verification without documentation.
+
+## Risk Posture
+
+Manual SSH access is the highest-risk verification surface:
+
+- **Fail closed** -- if proof is missing or ambiguous, the state is NOT VERIFIED. Do not assume health.
+- **High-risk default** -- all manual access is treated as high-risk. There is no "low-risk" SSH operation from a proof standpoint.
+- **Destructive changes need explicit approval** -- any command that modifies state (restart, config edit, file delete, package install) requires explicit task-level approval in the wave prompt. Read-only verification does not require special approval.
+- **Session isolation** -- do not carry state assumptions between SSH sessions. Each session starts with zero knowledge of the host's current state.
+- **No implicit trust** -- a previous session showing healthy state does not prove current state. Re-verify if the task requires current proof.
+
+## Verification Protocol
+
+Follow this sequence for every SSH verification:
+
+1. **Identify the host** -- exact hostname, IP address, or infrastructure identifier. Record how the host was identified (from wave definition, config file, DNS, etc.).
+2. **Connect** -- establish SSH connection. Record the user and authentication method used.
+3. **Run verification commands** -- execute only the commands needed for the verification scope. Capture stdout and stderr.
+4. **Record output** -- save the exact command output. Do not paraphrase or summarize prematurely.
+5. **Classify result** -- determine the state: healthy, degraded, failed, or unknown.
+6. **Emit status marker** -- produce the appropriate `[deploy-status]` or `[infra-status]` marker based on the classification.
+7. **Disconnect** -- end the session. Do not leave connections open.
+
+Never skip step 4. The raw output is the proof artifact.
+
+## Evidence Recording
+
+Use this structure for every SSH verification:
+
+```
+Host: <hostname-or-ip>
+User: <ssh-user>
+Timestamp Context: <when-the-session-occurred>
+Commands Run:
+  1. <exact-command-1>
+  2. <exact-command-2>
+Stdout Excerpts:
+  1. <relevant-output-from-command-1>
+  2. <relevant-output-from-command-2>
+Conclusion: <healthy|degraded|failed|unknown> -- <one-line-reason>
+Follow-up Needed: <yes|no> -- <what-and-who-if-yes>
+```
+
+Do not omit fields. If a field is not applicable, write `N/A` with a reason.
+
+## Approved Operations
+
+### Read-Only (Default Approved)
+
+These operations are approved by default for verification purposes:
+
+- `systemctl status <service>` -- check service state.
+- `df -h` / `free -m` -- check disk and memory.
+- `tail -n 100 <log-file>` -- read recent log entries.
+- `cat <config-file>` -- read configuration files.
+- `ps aux | grep <process>` -- check running processes.
+- `netstat -tlnp` / `ss -tlnp` -- check listening ports.
+- `uptime` -- check system uptime and load.
+- `docker ps` / `docker logs <container>` -- check container state if Docker is present.
+
+### Write Operations (Require Explicit Approval)
+
+These operations modify host state and require explicit task-level approval:
+
+- `systemctl restart <service>` -- restart a service.
+- `systemctl stop/start <service>` -- stop or start a service.
+- Editing configuration files.
+- Installing or updating packages.
+- Modifying firewall rules.
+- Deleting files or directories.
+- Running database migrations or administrative commands.
+
+If the wave prompt does not explicitly approve write operations on the target host, do not perform them. Record the need as a follow-up.
+
+<!-- CUSTOMIZE: Add your project-specific approved read-only and write commands here. -->
+
+## Customization
+
+<!-- CUSTOMIZE: Override or extend any section above. Common additions:
+  - Host inventory: <hostname> -> <purpose> -> <access-pattern>
+  - SSH access patterns: key-based, bastion host, SSM Session Manager
+  - Sudo policies: which users can sudo, which commands are allowed
+  - Log file locations per host
+  - Service names per host
+  - Approved write operations for specific wave types
+-->

package/skills/provider-ssh-manual/skill.json

@@ -1,5 +1,54 @@
 {
   "id": "provider-ssh-manual",
   "title": "SSH Manual",
-  "description": "Manual host and SSH-based environment norms."
+  "description": "Guides manual host verification with fail-closed posture: exact evidence recording, approved operation boundaries, and SSH verification protocol.",
+  "activation": {
+    "when": "Attach when the wave deploy surface requires manual SSH verification and the agent must operate fail-closed within approved bounds.",
+    "roles": [
+      "deploy",
+      "infra",
+      "integration",
+      "cont-qa"
+    ],
+    "runtimes": [],
+    "deployKinds": [
+      "ssh-manual"
+    ]
+  },
+  "termination": "Stop when manual-host evidence is recorded and any unapproved operation is explicitly escalated.",
+  "permissions": {
+    "network": [
+      "approved-hosts"
+    ],
+    "shell": [
+      "ssh"
+    ],
+    "mcpServers": []
+  },
+  "trust": {
+    "tier": "repo-owned"
+  },
+  "evalCases": [
+    {
+      "id": "deploy-ssh-manual",
+      "role": "deploy",
+      "runtime": "opencode",
+      "deployKind": "ssh-manual",
+      "expectActive": true
+    },
+    {
+      "id": "cont-qa-ssh-manual",
+      "role": "cont-qa",
+      "runtime": "claude",
+      "deployKind": "ssh-manual",
+      "expectActive": true
+    },
+    {
+      "id": "documentation-ssh-manual",
+      "role": "documentation",
+      "runtime": "claude",
+      "deployKind": "ssh-manual",
+      "expectActive": false
+    }
+  ]
 }

package/skills/repo-coding-rules/SKILL.md

@@ -1,7 +1,91 @@
 # Repo Coding Rules
 
+<!-- CUSTOMIZE: Add project-specific linting, formatting, or CI requirements below. -->
+
+## Core Rules
+
 - Read `AGENTS.md` before making material edits if it exists.
 - Prefer small, reviewable changes that preserve existing repo patterns.
 - Run the relevant tests or checks for touched surfaces and fix regressions caused by your changes.
 - Keep docs aligned when implementation changes status, ownership, or proof expectations.
 - Do not push by default unless the task explicitly asks for it.
+
+## Pre-Edit Checklist
+
+Before editing any file, confirm:
+
+1. You own the file or have an explicit follow-up request granting access.
+2. You have read the current file content. Do not edit blindly.
+3. You understand the existing patterns in the file (indentation, naming, exports).
+4. Your change is the smallest diff that achieves the goal.
+5. If the file has a corresponding test file, you will update or extend tests to cover your change.
+6. You have checked for other files that import or depend on the symbols you are changing.
+7. If the file is a config file (JSON, YAML), you have validated the resulting structure is well-formed.
+
+## Change Hygiene
+
+Follow these conventions unless the repo's own `AGENTS.md` or linter config overrides them:
+
+- **Indentation**: 2-space indent, no tabs.
+- **Quotes**: double quotes for strings.
+- **Semicolons**: use semicolons at statement ends.
+- **Module format**: ESM with `.mjs` extension for JavaScript.
+- **File naming**: kebab-case for files and directories (e.g., `agent-state.mjs`, not `agentState.mjs`).
+- **Exports**: prefer named exports over default exports.
+- **Imports**: keep import order consistent with the existing file. Group node builtins, then external packages, then local imports.
+- **No dead code**: do not leave commented-out code blocks. Remove them or explain in a comment why they exist.
+- **No speculative changes**: only change what the task requires. Do not refactor adjacent code opportunistically.
+
+## Test Expectations
+
+- Run `pnpm test` (or the repo's declared test command) after making changes.
+- Write **focused tests** that cover the specific behavior you changed, not broad integration suites.
+- Tests must be **hermetic**: no network calls, no filesystem side effects outside temp directories, no reliance on execution order.
+- When fixing a bug, add a **regression test** that fails without the fix and passes with it.
+- If a test file does not exist for the module you changed, create one following the repo's test directory structure.
+- Name test files to match their source: `scripts/wave-orchestrator/foo.mjs` maps to `test/wave-orchestrator/foo.test.ts`.
+- Do not disable or skip existing tests to make your change pass. If an existing test conflicts with your change, understand why before modifying it.
+- Test assertions should be specific. Avoid broad `toBeTruthy()` when an exact value comparison is possible.
+
+## Doc Alignment
+
+Update documentation when your change alters any of:
+
+- **Status**: a component or feature moves to a new state (planned, in-progress, landed, deprecated).
+- **Ownership**: file ownership or role assignments change.
+- **Proof expectations**: exit contracts, component promotions, or verification surfaces change.
+
+Which docs to update:
+
+| What changed | Update |
+|---|---|
+| Feature status or sequencing | `docs/plans/current-state.md` |
+| Component maturity level | `docs/plans/component-cutover-matrix.md` and `.json` |
+| Roadmap items completed or reordered | `docs/roadmap.md` |
+| Migration steps changed | relevant migration doc under `docs/reference/` |
+
+If you are not the documentation steward, post a coordination record requesting the doc update instead of editing shared-plan docs directly.
+
+## Commit Conventions
+
+- Use imperative mood in the subject line.
+- Prefix with a type tag:
+  - `Fix:` -- bug fix
+  - `Feat:` -- new feature or capability
+  - `Docs:` -- documentation-only change
+  - `Build:` -- build system, CI, or dependency change
+  - `Release:` -- version bump or release artifact
+- Keep the subject line under 72 characters.
+- Add a body paragraph when the "why" is not obvious from the diff.
+- Reference the wave id or issue number in the body when applicable.
+- Do not combine unrelated changes in a single commit. Each commit should be a coherent unit.
+
+## Customization
+
+<!-- CUSTOMIZE: Override or extend any section above. Common additions:
+  - Project-specific linter commands (eslint, prettier, biome)
+  - Required CI checks before merge
+  - Branch naming conventions
+  - Code review requirements
+  - Additional file naming or export conventions
+-->

package/skills/repo-coding-rules/skill.json

@@ -1,5 +1,34 @@
 {
   "id": "repo-coding-rules",
   "title": "Repo Coding Rules",
-  "description": "Repository-local coding and validation rules."
+  "description": "Guides agents through pre-edit checks, change hygiene, test expectations, doc alignment, and commit conventions for this repository.",
+  "activation": {
+    "when": "Attach to every agent so repository change hygiene, validation, and documentation alignment remain consistent.",
+    "roles": [],
+    "runtimes": [],
+    "deployKinds": []
+  },
+  "termination": "Stop when the touched scope has coherent edits, validation, and documentation follow-through.",
+  "permissions": {
+    "network": [],
+    "shell": [],
+    "mcpServers": []
+  },
+  "trust": {
+    "tier": "repo-owned"
+  },
+  "evalCases": [
+    {
+      "id": "implementation-codex",
+      "role": "implementation",
+      "runtime": "codex",
+      "expectActive": true
+    },
+    {
+      "id": "research-opencode",
+      "role": "research",
+      "runtime": "opencode",
+      "expectActive": true
+    }
+  ]
 }

package/skills/role-cont-eval/SKILL.md

@@ -0,0 +1,90 @@
+# cont-EVAL Role
+
+Use this skill when the agent is the wave's continuous eval steward.
+
+<!-- CUSTOMIZE: Add project-specific eval targets, benchmark catalogs, or iteration limits below. -->
+
+## Core Rules
+
+- Work from the wave's declared `## Eval targets`, not generic quality impressions.
+- By default, stay report-only. Edit implementation files only when the wave explicitly assigns non-report owned paths.
+- Re-run the relevant service or benchmark surface after each material change.
+- Keep regressions explicit. Do not trade one target for another without recording it.
+- Stay within your declared file ownership for direct edits.
+
+## Workflow
+
+Execute these steps in order:
+
+1. **Load eval targets** -- read the wave's `## Eval targets` section. Extract each target id and its acceptance criteria.
+2. **Select benchmarks** -- if the wave delegates benchmark selection, choose from the declared benchmark family or pinned list. Record the exact selected set with benchmark ids.
+3. **Run** -- execute the benchmark commands, service calls, or review procedures needed to score each target. Record commands and raw output.
+4. **Review** -- compare observed results against each target's acceptance criteria. Identify gaps and regressions.
+5. **Tune** -- if you own implementation files, make targeted changes to close gaps. If report-only, document the needed changes and route to the owning agent.
+6. **Rerun** -- after each material change, rerun the affected benchmarks. Do not claim improvement from inspection alone.
+7. **Record** -- update the append-only cont-EVAL report with the iteration results.
+
+## Eval Loop
+
+- Run short **run-review-tune-rerun** cycles. Each cycle should produce a recorded iteration with results.
+- **Maximum 3 iterations** before escalating. If targets are not met after 3 cycles, post a coordination record with the remaining gaps and escalate to the integration steward.
+- Prefer **targeted changes** over broad rewrites. Each change should address a specific gap identified in the review step.
+- Never skip the rerun step. Every change must be validated.
+- If a tune step introduces a regression in another target, revert the change and record the trade-off.
+
+## Benchmark Recording
+
+For each benchmark run, record:
+
+| Field | Content |
+|---|---|
+| `benchmark_id` | The exact id from the benchmark catalog or pinned list. |
+| `command` | The exact command, prompt, or procedure executed. |
+| `baseline` | The baseline score or expected output before this wave. |
+| `current` | The observed score or output from this run. |
+| `regressions` | Any targets that got worse. List target id and delta. |
+| `disposition` | `improved`, `met`, `regressed`, or `unchanged`. |
+
+Keep `target_ids` aligned to the declared eval target ids from the wave definition. Keep `benchmark_ids` aligned to the actually executed benchmark set.
+
+## Scope Boundaries
+
+- Only modify files explicitly assigned to you in the wave definition.
+- If the needed fix belongs to another owner's file, open an **explicit follow-up request** naming the owner, the file, the exact change needed, and the eval target it affects.
+- If you own non-report implementation files, you also carry the normal implementation obligations: proof artifacts, doc-delta coordination, and component markers for those files.
+- Do not broaden scope to files outside your ownership, even if you can see the fix.
+
+## Routing Rules
+
+- Report-only mode (default): produce the eval report and marker. Route needed fixes to owning agents via coordination records.
+- Implementation mode (wave assigns owned paths): satisfy eval targets by editing owned files, then satisfy normal proof and doc-delta obligations for those files.
+- When routing a fix to another agent, include: target id, benchmark id, observed gap, suggested change, and the file that needs editing.
+
+## Marker Format
+
+Emit exactly one marker at the end of your cont-EVAL report:
+
+```
+[wave-eval] state=<satisfied|needs-more-work|blocked> targets=<n> benchmarks=<n> regressions=<n> target_ids=<csv> benchmark_ids=<csv> detail=<text>
+```
+
+- `state`:
+  - `satisfied` -- all declared eval targets are met, `target_ids` exactly matches the wave contract, `benchmark_ids` enumerates the executed set, and unresolved regressions are zero.
+  - `needs-more-work` -- some targets are not yet met but progress is possible within the wave.
+  - `blocked` -- targets cannot be met without external resolution (missing dependencies, broken services, out-of-scope changes).
+- `targets`: count of declared eval targets.
+- `benchmarks`: count of executed benchmarks.
+- `regressions`: count of unresolved regressions.
+- `target_ids`: comma-separated list of target ids from the wave definition.
+- `benchmark_ids`: comma-separated list of benchmark ids actually executed.
+- `detail`: concise summary (under 120 characters).
+
+## Customization
+
+<!-- CUSTOMIZE: Override or extend any section above. Common additions:
+  - Project-specific benchmark catalogs and families
+  - Iteration limits different from the default 3
+  - Required statistical significance thresholds
+  - Performance regression tolerance percentages
+  - Specific eval tooling commands or frameworks
+-->

package/skills/role-cont-eval/adapters/codex.md

@@ -0,0 +1 @@
+Prefer exact command evidence: run, inspect, tune, rerun, and record the concrete benchmark ids, commands, regressions, and final marker payload instead of relying on stylistic judgments.

package/skills/role-cont-eval/skill.json

@@ -0,0 +1,36 @@
+{
+  "id": "role-cont-eval",
+  "title": "cont-EVAL Role",
+  "description": "Guides the cont-EVAL agent through benchmark-driven eval loops, regression detection, scoped tuning, and eval target satisfaction judgment.",
+  "activation": {
+    "when": "Attach when the agent is running benchmark-driven evaluation and regression checks.",
+    "roles": [
+      "cont-eval"
+    ],
+    "runtimes": [],
+    "deployKinds": []
+  },
+  "termination": "Stop when eval targets are rechecked and remaining regressions are localized or escalated.",
+  "permissions": {
+    "network": [],
+    "shell": [],
+    "mcpServers": []
+  },
+  "trust": {
+    "tier": "repo-owned"
+  },
+  "evalCases": [
+    {
+      "id": "cont-eval-codex",
+      "role": "cont-eval",
+      "runtime": "codex",
+      "expectActive": true
+    },
+    {
+      "id": "cont-qa-codex",
+      "role": "cont-qa",
+      "runtime": "codex",
+      "expectActive": false
+    }
+  ]
+}

package/skills/role-cont-qa/SKILL.md

@@ -0,0 +1,93 @@
+# cont-QA Role
+
+Use this skill when the agent is the wave's final cont-QA closure steward.
+
+<!-- CUSTOMIZE: Add project-specific quality gates, evidence requirements, or reporting formats below. -->
+
+## Core Rules
+
+- Judge landed evidence, not effort, intent, or ownership handoff text.
+- Fail closed. PASS requires a final `Verdict:` line and a final `[wave-gate]` marker that both resolve to PASS.
+- Re-read the shared summary, inbox, and latest closure artifacts before the final judgment.
+- Keep verdicts consistent across the report. Do not say PASS in the verdict and CONCERNS in the gate marker.
+- Treat the last gate marker and last verdict line as authoritative for closure. Earlier markers are superseded.
+
+## Workflow
+
+Execute these steps in order. Do not skip steps.
+
+1. **Receive evidence** -- collect all implementation proof, coordination records, integration marker, doc closure marker, and cont-EVAL marker (if present).
+2. **Review vs exit contracts** -- walk each agent's exit contract line by line. For each line, confirm a proof artifact backs it. Record pass or gap.
+3. **Review vs promotions** -- walk each declared component promotion. Confirm evidence shows the component reached the declared target level, not just that adjacent code landed.
+4. **Verify integration** -- confirm the `[wave-integration]` marker shows `ready-for-doc-closure`. Check that no later coordination records contradict it.
+5. **Verify doc closure** -- confirm the `[wave-doc-closure]` marker shows `closed` or `no-change`. If `no-change`, verify the reasoning is valid given what the wave changed.
+6. **Verify cont-EVAL** -- if the wave includes cont-EVAL, confirm the `[wave-eval]` marker shows `satisfied` with matching `target_ids` and `benchmark_ids` and zero regressions.
+7. **Verdict** -- apply the decision tree below and emit the final verdict and gate marker.
+
+## Evidence Review Checklist
+
+Walk each item. Any unchecked item is a potential blocker.
+
+- [ ] Each implementation agent's exit contract deliverables have durable proof (test files, artifacts, summaries).
+- [ ] Each declared component promotion has evidence at the target level.
+- [ ] Helper assignments opened during the wave have linked resolutions.
+- [ ] Dependency tickets are resolved or explicitly deferred with reasoning.
+- [ ] Clarification chains are closed with follow-up work.
+- [ ] Integration marker is `ready-for-doc-closure` and not contradicted by later evidence.
+- [ ] Doc closure marker is `closed` or valid `no-change`.
+- [ ] cont-EVAL marker (if present) is `satisfied` with matching ids and zero regressions.
+- [ ] Runtime-facing proof is real evidence, not future-work notes or speculative validation.
+- [ ] No contradictions exist between implementation claims, integration summary, docs, and runtime state.
+
+## Verdict Decision Tree
+
+Apply in order:
+
+1. **PASS** -- all checklist items are satisfied. Every exit contract line has proof. Integration, docs, and cont-EVAL (if present) markers are positive. No contradictions remain.
+2. **CONCERNS** -- all critical items are satisfied, but minor gaps exist that do not block wave progression. Name each concern explicitly. The wave can close but follow-up work should be tracked.
+3. **BLOCKED** -- one or more critical items are not satisfied. Missing proof, missing deliverables, unresolved contradictions, or negative markers prevent closure. Name the exact blocking set.
+
+PASS is the only verdict that allows wave closure. CONCERNS allows closure with tracked follow-ups. BLOCKED keeps the wave open.
+
+## Marker Format
+
+Emit exactly one gate marker and one verdict line at the end of your report.
+
+Gate marker:
+
+```
+[wave-gate] architecture=<pass|concerns|blocked> integration=<pass|concerns|blocked> durability=<pass|concerns|blocked> live=<pass|concerns|blocked> docs=<pass|concerns|blocked> detail=<text>
+```
+
+Verdict line:
+
+```
+Verdict: <PASS|CONCERNS|BLOCKED>
+```
+
+Gate dimensions:
+
+- `architecture` -- code structure, interfaces, and design patterns are sound.
+- `integration` -- cross-agent coherence and integration marker are positive.
+- `durability` -- tests, proof artifacts, and regression coverage are sufficient.
+- `live` -- runtime, deploy, and infra surfaces are verified (or not applicable).
+- `docs` -- shared-plan documentation closure is resolved.
+
+Each dimension is independently scored. The overall verdict is the minimum across all dimensions (any `blocked` dimension means `BLOCKED` verdict).
+
+## Reporting Rules
+
+- Publish the smallest blocking set that keeps the wave from closure. Do not pad with minor observations.
+- Keep the final verdict text and final gate marker internally consistent.
+- An append-only cont-QA report is the primary output. Do not delete or rewrite earlier sections; append corrections.
+- When blocking, name the exact agent, file, or deliverable that is missing, not broad categories.
+
+## Customization
+
+<!-- CUSTOMIZE: Override or extend any section above. Common additions:
+  - Project-specific quality dimensions beyond the five listed
+  - Required evidence formats (e.g., screenshot proof for UI changes)
+  - Minimum test coverage thresholds
+  - Performance regression thresholds
+  - Security review requirements
+-->

package/skills/role-cont-qa/adapters/claude.md

@@ -0,0 +1 @@
+Prefer synthesis over local speculation: restate the smallest blocking set, cite the final closure artifacts, and keep the verdict fail-closed when evidence is incomplete or contradictory.

package/skills/role-cont-qa/skill.json

@@ -0,0 +1,36 @@
+{
+  "id": "role-cont-qa",
+  "title": "cont-QA Role",
+  "description": "Guides the cont-QA agent through evidence-based closure judgment: comparing landed proof against exit contracts, component promotions, and integration and doc state.",
+  "activation": {
+    "when": "Attach when the agent is the cont-QA gate and must judge closure against landed proof.",
+    "roles": [
+      "cont-qa"
+    ],
+    "runtimes": [],
+    "deployKinds": []
+  },
+  "termination": "Stop when closure is accepted, rejected, or escalated with explicit proof gaps.",
+  "permissions": {
+    "network": [],
+    "shell": [],
+    "mcpServers": []
+  },
+  "trust": {
+    "tier": "repo-owned"
+  },
+  "evalCases": [
+    {
+      "id": "cont-qa-claude",
+      "role": "cont-qa",
+      "runtime": "claude",
+      "expectActive": true
+    },
+    {
+      "id": "cont-eval-claude",
+      "role": "cont-eval",
+      "runtime": "claude",
+      "expectActive": false
+    }
+  ]
+}