@beyondwork/docx-react-component 1.0.0 → 1.0.1

package/skills/signal-hygiene/SKILL.md

@@ -1,51 +0,0 @@
----
-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

@@ -1,20 +0,0 @@
-{
-  "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

@@ -1,77 +0,0 @@
----
-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

@@ -1,259 +0,0 @@
-# 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

@@ -1,36 +0,0 @@
-{
-  "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

@@ -1,141 +0,0 @@
-# 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

@@ -1,70 +0,0 @@
-# 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

@@ -1,35 +0,0 @@
-{
-  "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
-    }
-  ]
-}