@beyondwork/docx-react-component 1.0.0

package/skills/signal-hygiene/SKILL.md

@@ -0,0 +1,51 @@
+---
+name: signal-hygiene
+description: Use for long-running resident or waiting agents that must stay idle until the orchestrator writes a new signal version, then acknowledge that change before acting.
+---
+
+# Signal Hygiene
+
+Use this skill only when the agent is intentionally long-running.
+
+This is not a generic polling skill for normal one-shot implementation work.
+
+## Core loop
+
+- Treat the signal state file as the orchestrator-controlled wakeup surface.
+- Treat the signal ack file as your durable confirmation that you observed a specific signal version.
+- Stay idle while the signal version is unchanged.
+- Act once when the signal version increases and the new signal is actionable.
+
+## Required behavior
+
+- Read the signal state path provided in the prompt before deciding whether to keep waiting or resume work.
+- If the signal file is missing, assume the orchestrator has not published a new signal yet and keep waiting.
+- Compare the signal file's `version` to the version already recorded in the signal ack file.
+- When the signal version increases, write the ack file immediately before you act on the change.
+- Write the ack file as JSON with exactly these keys:
+  - `agentId`
+  - `version`
+  - `signal`
+  - `observedAt`
+- After acknowledging the new version, re-read the inbox, shared summary, message board, and any explicitly referenced artifacts before taking action.
+- If the signal kind is `completed` or `failed`, stop the waiting loop and finish cleanly.
+
+## Do not do this
+
+- Do not busy-loop or emit repeated status chatter while the signal version is unchanged.
+- Do not keep re-processing the same signal version.
+- Do not invent your own wakeup surface when the orchestrator already provided signal and ack paths.
+- Do not stay resident forever once the signal clearly becomes terminal.
+
+## Actionability rule
+
+Treat these signal kinds as actionable by default:
+
+- `feedback-requested`
+- `feedback-answered`
+- `coordination-action`
+- `resume-ready`
+- `completed`
+- `failed`
+
+Treat `waiting` and `stable` as non-actionable until the version changes again.

package/skills/signal-hygiene/skill.json

@@ -0,0 +1,20 @@
+{
+  "id": "signal-hygiene",
+  "title": "Long-Running Signal Hygiene",
+  "description": "Use for long-running resident or waiting agents that must stay idle until the orchestrator writes a new signal version, then acknowledge that change before acting.",
+  "activation": {
+    "when": "Attach explicitly when an agent is expected to stay resident, wait for human feedback or coordination changes, and react only when the orchestrator updates the signal state file.",
+    "roles": [],
+    "runtimes": [],
+    "deployKinds": []
+  },
+  "termination": "Stop when the signal reaches a terminal state or the agent is no longer expected to stay resident and wait for follow-up work.",
+  "permissions": {
+    "network": [],
+    "shell": [],
+    "mcpServers": []
+  },
+  "trust": {
+    "tier": "repo-owned"
+  }
+}

package/skills/tui-design/SKILL.md

@@ -0,0 +1,77 @@
+---
+name: tui-design
+description: Reviews terminal UI and operator-surface design against world-class TUI principles for focus, trust, navigation, information architecture, and recovery. Use when designing or reviewing TUIs, operator shells, dashboards, keyboard flows, or live terminal UX.
+---
+
+# TUI Design
+
+Use this skill when the work involves terminal UX, operator shells, dashboards, or live operator-facing review.
+
+## Core stance
+
+- Treat the TUI as an operating instrument, not a styled CLI.
+- Optimize for observe, decide, act, verify loops rather than one-shot command execution.
+- Keep the surface keyboard-first, focus-driven, interruptible, and operationally honest.
+- Prefer stable information architecture over visual cleverness.
+- Treat trust, recovery, and state visibility as first-class UX requirements.
+
+## Review priorities
+
+When reviewing or designing a TUI, check these in order:
+
+1. **Operational honesty**
+   - Can the operator tell what is live, stale, partial, pending, failed, or only requested?
+   - Does the UI ever imply success before backend confirmation?
+
+2. **Focus and keyboard flow**
+   - Is the focused pane or widget always obvious?
+   - Are navigation, action, command-entry, and escape keys separated cleanly?
+   - Is there always a safe back, cancel, help, and quit path?
+
+3. **Information architecture**
+   - Are scope, identity, freshness, and top-level health always visible?
+   - Does the default view answer what changed, what is broken, and what needs action?
+   - Is detail one step away instead of dumped everywhere at once?
+
+4. **Streaming and live-state behavior**
+   - Do updates preserve selection and focus?
+   - Can users pause or freeze moving views when they need to read?
+   - Are lag, dropped updates, or replay versus live mode visible?
+
+5. **Recovery and trust**
+   - Are retries, resume paths, and error next steps explicit?
+   - Are destructive or high-risk actions confirmed and auditable?
+
+## Design rules
+
+- Keep layouts stable. Avoid reflow and selection jumps during streaming updates.
+- Use color semantically, never decoratively or as the only signal.
+- Prefer compact summaries with drill-down over dense unreadable dashboards.
+- Use explicit action-state ladders such as requested, accepted, running, applied, failed.
+- Make filters, scopes, and auth context visible at all times.
+- Support narrow-terminal degradation gracefully instead of forcing broken split panes.
+- Avoid ambiguous-width glyphs or emoji for alignment-critical UI.
+
+## Output guidance
+
+For design review, prefer findings shaped like:
+
+- exact surface
+- exact failure mode
+- operator impact
+- blocking or advisory status
+- concrete fix direction
+
+For design proposals, prefer:
+
+- interaction model
+- layout model
+- keyboard model
+- trust and recovery model
+- drill-down model
+
+## Reference
+
+For the full TUI design guidance distilled for this repo, read:
+
+- [references/tui-design.md](./references/tui-design.md)

package/skills/tui-design/references/tui-design.md

@@ -0,0 +1,259 @@
+# TUI Design Reference
+
+This reference distills reusable design guidance for Wave's terminal UX and operator-review work.
+
+## What a TUI is for
+
+A TUI is for live operation of a changing system:
+
+- observe
+- decide
+- act
+- verify
+- repeat
+
+That means the UX must prioritize:
+
+- stable state visibility
+- continuous feedback
+- keyboard throughput
+- interruptibility
+- recovery
+
+It should not behave like:
+
+- a one-shot CLI with colors
+- a browser dashboard squeezed into a terminal
+
+## Core operating principles
+
+### Operational honesty
+
+The TUI must make these obvious:
+
+- what it knows
+- how fresh that knowledge is
+- what it is currently doing
+- what is only requested versus confirmed
+- what is partial, stale, blocked, or degraded
+
+Never imply:
+
+- "done" when the backend only accepted a request
+- "live" when the data is cached or lagged
+- "success" when verification has not happened
+
+### Keyboard-first interaction
+
+Good TUIs separate input into four lanes:
+
+1. navigation
+2. actions
+3. command entry
+4. escapes and cancellation
+
+Required behaviors:
+
+- visible focus
+- predictable pane switching
+- context-sensitive help
+- cancel and back semantics that always work
+
+### Stable information architecture
+
+The screen should answer:
+
+- where am I operating?
+- what changed?
+- what is wrong?
+- what needs action now?
+
+Use three state layers:
+
+- global: scope, identity, connectivity, freshness
+- session: filters, selected object, follow mode
+- local: pane scroll, cursor, input buffer
+
+### Progressive disclosure
+
+Default views should summarize:
+
+- what's broken
+- what changed
+- what is actionable
+
+Details should be one step away:
+
+- inspect
+- drill down
+- open logs
+- open proof
+- open events
+
+### Recovery-first UX
+
+Every serious TUI needs:
+
+- retry
+- resume
+- replay or event history
+- clear next-step messaging on failure
+
+Errors should distinguish:
+
+- what failed
+- what scope it affected
+- whether the system is safe
+- what the operator can do next
+
+## Focus and navigation heuristics
+
+### Good focus rules
+
+- the active pane is visually obvious
+- the selected row is visually obvious
+- streaming updates never steal focus
+- selection stays pinned unless the operator changes it
+
+### Good navigation rules
+
+- tab and shift-tab always get the user unstuck
+- direct hotkeys may exist, but there is always a universal path
+- search and filter are first-class
+- command palette or command bar is ideal for power actions
+
+### Bad signs
+
+- mode confusion
+- accidental action keys
+- focus ambiguity
+- selection jumps during refresh
+
+## Visual system guidance
+
+### Use color semantically
+
+Recommended semantic roles:
+
+- critical
+- warning
+- success
+- info
+- muted
+- focus
+- selection
+
+Rules:
+
+- never rely on color alone
+- support monochrome or no-color use
+- avoid decorative rainbow dashboards
+
+### Respect terminal constraints
+
+Design for:
+
+- limited width
+- resizing
+- unicode width issues
+- non-uniform terminal support
+
+Implications:
+
+- keep glyph choices conservative
+- use ASCII fallbacks where needed
+- degrade gracefully on small terminals
+
+## Live-system feedback rules
+
+### Loading and streaming
+
+The operator must be able to tell:
+
+- loading
+- syncing
+- replaying
+- paused
+- lagging
+- dropping updates
+
+If the system is slow:
+
+- say what is happening
+- show progress if possible
+- show completed-so-far if total work is unknown
+- provide interruption
+
+### Success and failure
+
+For low-risk actions:
+
+- a small confirmation is enough
+
+For high-risk or asynchronous actions:
+
+- show a receipt
+- show the exact target
+- show request versus applied versus verified state
+
+## Layout patterns that work
+
+### Best default pattern
+
+For serious ops TUIs, prefer:
+
+- dashboard or navigation pane
+- list or queue pane
+- inspector or detail pane
+
+This supports:
+
+- fast scanning
+- stable orientation
+- low-friction drill-down
+
+### Good drill-down flow
+
+The path should be predictable:
+
+- summary
+- selected entity
+- details
+- logs, proof, events, or raw view
+
+### Narrow terminal fallback
+
+When width collapses:
+
+- reduce columns
+- stack panels
+- keep the same semantics
+- prefer honest condensed output over broken split panes
+
+## Trust checklist for operator surfaces
+
+Before approving a TUI or operator UX, ask:
+
+- Is scope always visible?
+- Is freshness always visible?
+- Are action states honest?
+- Are filters and selection visible?
+- Can the user recover from errors?
+- Can the user cancel?
+- Can the user tell replay from live?
+- Can the user tell pending from complete?
+- Can the user audit what happened?
+
+## Anti-patterns
+
+Reject designs that:
+
+- flicker or constantly reflow
+- hide scope or auth context
+- overload color
+- force memorization without help
+- provide no cancel path
+- show fake success
+- use unstable alignment-critical glyphs
+- stream in ways that steal focus
+- hide blockers behind decorative dashboards

package/skills/tui-design/skill.json

@@ -0,0 +1,36 @@
+{
+  "id": "tui-design",
+  "title": "TUI Design Review",
+  "description": "Reviews terminal UI and operator-surface design against world-class TUI principles for focus, trust, navigation, information architecture, and recovery. Use when designing or reviewing TUIs, operator shells, dashboards, keyboard flows, or live terminal UX.",
+  "activation": {
+    "when": "Attach when the agent is designing or reviewing a TUI, operator shell, dashboard, keyboard interaction model, live status surface, or terminal-native information architecture.",
+    "roles": [
+      "design"
+    ],
+    "runtimes": [],
+    "deployKinds": []
+  },
+  "termination": "Stop when the design work clearly states whether the TUI is operationally honest, keyboard-first, focus-safe, and aligned with the repo's terminal UX expectations.",
+  "permissions": {
+    "network": [],
+    "shell": [],
+    "mcpServers": []
+  },
+  "trust": {
+    "tier": "repo-owned"
+  },
+  "evalCases": [
+    {
+      "id": "tui-design-review",
+      "role": "design",
+      "runtime": "codex",
+      "expectActive": true
+    },
+    {
+      "id": "implementation-review",
+      "role": "implementation",
+      "runtime": "codex",
+      "expectActive": false
+    }
+  ]
+}

package/skills/wave-core/SKILL.md

@@ -0,0 +1,141 @@
+# Wave Core
+
+<!-- CUSTOMIZE: Add project-specific coordination channels, artifact locations, or naming conventions below. -->
+
+## Core Rules
+
+- Re-read the compiled shared summary, inbox, and board projection before major decisions and before final output.
+- Treat those summaries and projections as convenience views over canonical state, not as the only closure authority.
+- Treat file ownership, exit contracts, and structured markers as hard requirements.
+- Post coordination records for meaningful progress, blockers, decisions, and handoffs.
+- Make gaps explicit with exact files, exact fields, and exact follow-up owners.
+- Do not infer closure from intent alone. Closure requires proof artifacts and consistent shared state.
+- Silence is not evidence. If a deliverable is not mentioned in landed artifacts, it is not done.
+- When two sources conflict, prefer the one backed by landed code or durable proof over the one backed by prose.
+
+## Coordination Protocol
+
+1. Read the shared summary and your inbox at the start of every major step. Summaries and inboxes may refresh during execution, so re-read before major decisions.
+2. Post a coordination record when any of these occur:
+   - meaningful progress on an exit contract deliverable
+   - a blocker is discovered or resolved
+   - a decision changes scope, ownership, or interface
+   - a handoff to another agent is needed
+   - a helper assignment is opened or resolved
+   - a clarification is routed or answered
+3. Each coordination record must include: agent id, timestamp context, topic, and actionable detail.
+4. Do not batch coordination. Post records as events occur so downstream agents see them promptly.
+5. When a record references another agent, name that agent explicitly.
+6. Coordination records are append-only. Do not edit or delete previous records; post corrections as new records.
+7. When you receive an inbox message that requires action, acknowledge it with a coordination record before proceeding. Unacknowledged requests become overdue and may be rerouted.
+
+## Coordination State
+
+The canonical authority set for a wave is:
+
+- wave definitions under `docs/plans/waves/`
+- the coordination JSONL log under `.tmp/<lane>-wave-launcher/coordination/`
+- the control-plane event log under `.tmp/<lane>-wave-launcher/control-plane/`
+- immutable attempt-scoped result artifacts under `.tmp/<lane>-wave-launcher/results/`
+
+The markdown board, shared summary, inboxes, ledgers, proof registries, retry overrides, and dashboards are projections over that state.
+
+Operator tasks, rerun requests, proof bundles, attempt lifecycle, contradictions, facts, and human-input workflow state are tracked in the control-plane event log. Proof registries and retry overrides under `proof/` and `control/` are projections from this log.
+
+Operators interact through `wave control`:
+- `wave control status` — why the wave is blocked or retrying.
+- `wave control task` — create, list, and act on coordination tasks.
+- `wave control rerun` — targeted retry intent.
+- `wave control proof` — authoritative proof bundle lifecycle.
+
+Legacy `wave coord`, `wave retry`, and `wave proof` remain available as compatibility surfaces.
+
+## Ownership & Boundaries
+
+- Only modify files you own. File ownership is declared in the wave definition under each agent.
+- If you need a change in a file you do not own, open a follow-up request naming the owning agent, the exact file, and the exact change needed.
+- Shared-plan docs (current-state.md, component matrix, roadmap) are owned by the documentation steward, not implementation agents.
+- Implementation-specific docs (inline comments, subsystem READMEs) stay with the implementation owner.
+- When ownership is ambiguous, post a coordination record requesting clarification before editing.
+- Helper assignments create temporary cross-boundary access. They remain blocking until the linked follow-up resolves.
+- Cross-lane dependencies require explicit dependency tickets. Do not assume another lane's state without a resolved ticket.
+
+## Proof Requirements
+
+- Every exit contract deliverable must have a corresponding proof artifact: a passing test, a generated file, a durable summary, or an explicit structured marker.
+- Generic claims ("tests pass", "works correctly") are not proof. Name the exact test file, command, or artifact.
+- Component promotions require evidence that the component actually reached the declared level, not just that adjacent code landed.
+- Runtime-facing proof must be real evidence (logs, health checks, build output), not future-work notes.
+- Proof must be durable. Transient output (terminal scrollback, ephemeral logs) is not proof unless captured into a file.
+- When proof cannot be produced within the wave, record the gap explicitly with the reason and the follow-up owner.
+- When the wave declares `### Proof artifacts`, those machine-visible local artifacts are required for closure in addition to deliverables and structured markers.
+- Operators may register authoritative proof bundles via `wave control proof register`. Registered proof has lifecycle state: `active`, `superseded`, or `revoked`. Only active bundles satisfy closure. Do not rely on proof that has been revoked or superseded.
+
+## Closure Checklist
+
+A wave is closable only when all nine conditions are satisfied:
+
+1. **Exit contracts pass** -- every agent's declared exit contract deliverables are present and backed by proof artifacts.
+2. **Deliverables exist within ownership** -- each deliverable lives in files owned by the agent that produced it.
+3. **Component proof/promotions pass** -- promoted components reached their declared target level with evidence.
+4. **Helper assignments resolved** -- every helper assignment posted during the wave has a linked resolution.
+5. **Dependency tickets resolved** -- all inbound cross-lane dependency tickets are resolved or explicitly deferred.
+6. **Clarification follow-ups resolved** -- every routed clarification chain has a linked follow-up that is closed.
+7. **cont-EVAL satisfies targets** -- if the wave includes cont-EVAL, the eval marker shows `satisfied` with matching target and benchmark ids.
+8. **Integration recommends closure** -- the integration result is `ready-for-doc-closure` and is not contradicted by later evidence.
+9. **Documentation and cont-QA pass** -- documentation closure is `closed` or `no-change`, and the cont-QA verdict is `PASS` with a matching gate result.
+
+If any condition is not met, the wave remains open. Do not approximate closure.
+
+Closure runs in staged order:
+1. Implementation and proof (all implementation agents).
+2. Optional security review -- must report `clear` or `concerns` before integration.
+3. cont-EVAL (if present) -- must report `satisfied` before integration runs.
+4. Integration -- must report `ready-for-doc-closure` before documentation and cont-QA run.
+5. Documentation -- must report `closed` or `no-change`.
+6. cont-QA -- final verdict. Only PASS allows the wave to close.
+
+Do not skip stages. Each stage depends on the prior stage completing.
+
+An active rerun request blocks closure until consumed. If the operator has filed a rerun via `wave control rerun request`, the retry engine applies it on the next retry and clears it afterward.
+
+## Structured Markers Reference
+
+Emit markers exactly as shown. Parsers depend on the format.
+
+| Marker | Format |
+|---|---|
+| `[wave-gate]` | `[wave-gate] architecture=<pass\|concerns\|blocked> integration=<pass\|concerns\|blocked> durability=<pass\|concerns\|blocked> live=<pass\|concerns\|blocked> docs=<pass\|concerns\|blocked> detail=<text>` |
+| `[wave-eval]` | `[wave-eval] state=<satisfied\|needs-more-work\|blocked> targets=<n> benchmarks=<n> regressions=<n> target_ids=<csv> benchmark_ids=<csv> detail=<text>` |
+| `[wave-integration]` | `[wave-integration] state=<ready-for-doc-closure\|needs-more-work> claims=<n> conflicts=<n> blockers=<n> detail=<text>` |
+| `[wave-doc-closure]` | `[wave-doc-closure] state=<closed\|no-change\|delta> paths=<comma-separated-paths> detail=<text>` |
+| `[infra-status]` | `[infra-status] kind=<conformance\|role-drift\|dependency\|identity\|admission\|action> target=<surface> state=<checking\|setup-required\|setup-in-progress\|conformant\|drift\|blocked\|failed\|action-required\|action-approved\|action-complete> detail=<text>` |
+| `[deploy-status]` | `[deploy-status] state=<deploying\|healthy\|failed\|rolled-back> service=<name> detail=<text>` |
+
+- Every marker must appear on a single line.
+- The `detail` field is free text but should be concise (under 120 characters).
+- Only the role that owns the marker type should emit it. Do not emit markers for other roles.
+
+Marker ownership:
+
+| Marker | Emitted by |
+|---|---|
+| `[wave-gate]` | cont-QA role |
+| `[wave-eval]` | cont-EVAL role |
+| `[wave-integration]` | Integration role |
+| `[wave-doc-closure]` | Documentation role |
+| `[infra-status]` | Infra role |
+| `[deploy-status]` | Deploy role |
+
+When you encounter a marker in the coordination log or a role report, treat it as a role-owned closure output and compatibility surface. If it conflicts with landed code, canonical state, or typed result artifacts, escalate the contradiction instead of treating the marker text as unchallengeable authority.
+
+<!-- CUSTOMIZE: Add project-specific marker types or extend existing formats here. -->
+
+## Customization
+
+<!-- CUSTOMIZE: Override or extend any section above. Common additions:
+  - Project-specific coordination record format
+  - Additional closure conditions beyond the nine listed
+  - Custom marker types for project-specific workflows
+  - Ownership rules for monorepo sub-packages
+-->

package/skills/wave-core/references/marker-syntax.md

@@ -0,0 +1,70 @@
+# Structured Marker Syntax Reference
+
+This reference documents the exact format for all structured markers used in wave coordination.
+
+## wave-gate (cont-QA closure)
+Emitted by: cont-QA agent (A0)
+Format:
+`[wave-gate] architecture=<pass|concerns|blocked> integration=<pass|concerns|blocked> durability=<pass|concerns|blocked> live=<pass|concerns|blocked> docs=<pass|concerns|blocked> detail=<short-note>`
+
+Must be accompanied by a verdict line:
+`Verdict: PASS` or `Verdict: CONCERNS` or `Verdict: BLOCKED`
+
+Example:
+`[wave-gate] architecture=pass integration=pass durability=pass live=pass docs=pass detail=all-exit-contracts-met`
+`Verdict: PASS`
+
+## wave-eval (cont-EVAL closure)
+Emitted by: cont-EVAL agent (E0)
+Format:
+`[wave-eval] state=<satisfied|needs-more-work|blocked> targets=<n> benchmarks=<n> regressions=<n> target_ids=<comma-separated-ids> benchmark_ids=<comma-separated-ids> detail=<short-note>`
+
+Example:
+`[wave-eval] state=satisfied targets=2 benchmarks=2 regressions=0 target_ids=prompt-quality,response-accuracy benchmark_ids=bench-01,bench-02 detail=all-targets-within-threshold`
+
+## wave-integration (integration closure)
+Emitted by: Integration steward (A8)
+Format:
+`[wave-integration] state=<ready-for-doc-closure|needs-more-work> claims=<n> conflicts=<n> blockers=<n> detail=<short-note>`
+
+Example:
+`[wave-integration] state=ready-for-doc-closure claims=0 conflicts=0 blockers=0 detail=all-agents-coherent-no-contradictions`
+
+## wave-doc-closure (documentation closure)
+Emitted by: Documentation steward (A9)
+Format:
+`[wave-doc-closure] state=<closed|no-change|delta> paths=<comma-separated-file-list> detail=<short-note>`
+
+Example:
+`[wave-doc-closure] state=closed paths=docs/plans/current-state.md,docs/plans/component-cutover-matrix.md detail=status-and-ownership-updated`
+
+## wave-security (security review)
+Emitted by: Security reviewer
+Format:
+`[wave-security] state=<clear|concerns|blocked> findings=<n> approvals=<n> detail=<short-note>`
+
+Example:
+`[wave-security] state=clear findings=0 approvals=0 detail=no-blocking-security-findings`
+
+## infra-status (infrastructure verification)
+Emitted by: Infra agent
+Format:
+`[infra-status] kind=<conformance|role-drift|dependency|identity|admission|action> target=<surface> state=<checking|setup-required|setup-in-progress|conformant|drift|blocked|failed|action-required|action-approved|action-complete> detail=<short-note>`
+
+Example:
+`[infra-status] kind=dependency target=node-22 state=conformant detail=node-v22.15.0-confirmed`
+
+## deploy-status (deployment verification)
+Emitted by: Deploy agent
+Format:
+`[deploy-status] state=<deploying|healthy|failed|rolled-back> service=<name> detail=<short-note>`
+
+Example:
+`[deploy-status] state=healthy service=api-server detail=health-endpoint-200-latency-under-50ms`
+
+## Rules
+- Markers must appear on a single line, not wrapped across lines.
+- Field values must not contain spaces; use hyphens for compound values.
+- Markers are machine-parsed; do not add extra fields or change field order.
+- Each closure role emits exactly one final marker per wave attempt.
+- Markers in agent output are role-owned compatibility and review surfaces. Live gate evaluation should prefer canonical state and typed result artifacts when they are available.

package/skills/wave-core/skill.json

@@ -0,0 +1,35 @@
+{
+  "id": "wave-core",
+  "title": "Wave Core",
+  "description": "Ensures every agent follows coordination protocol, respects ownership boundaries, produces durable proof, and meets closure requirements before claiming done.",
+  "activation": {
+    "when": "Attach to every agent to enforce Wave coordination, proof, and closure protocol.",
+    "roles": [],
+    "runtimes": [],
+    "deployKinds": []
+  },
+  "termination": "Stop when ownership boundaries, proof obligations, and required Wave markers are satisfied or explicitly handed off.",
+  "permissions": {
+    "network": [],
+    "shell": [],
+    "mcpServers": []
+  },
+  "trust": {
+    "tier": "repo-owned"
+  },
+  "evalCases": [
+    {
+      "id": "implementation-codex",
+      "role": "implementation",
+      "runtime": "codex",
+      "expectActive": true
+    },
+    {
+      "id": "documentation-opencode",
+      "role": "documentation",
+      "runtime": "opencode",
+      "deployKind": "railway-cli",
+      "expectActive": true
+    }
+  ]
+}