@beyondwork/docx-react-component 1.0.0 → 1.0.2

package/skills/provider-railway/skill.json

@@ -1,71 +0,0 @@
-{
-  "id": "provider-railway",
-  "title": "Railway",
-  "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,97 +0,0 @@
-# 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,54 +0,0 @@
-{
-  "id": "provider-ssh-manual",
-  "title": "SSH Manual",
-  "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,55 +0,0 @@
-# Repo Coding Rules
-
-## Core Rules
-
-- Read `README.md`, `AGENTS.md`, and `DESIGN.md` before making material edits that affect product behavior.
-- Prefer small, reviewable changes that preserve the intended subsystem boundaries.
-- Keep product docs aligned when implementation changes status, architecture, or proof expectations.
-- Do not edit `.tmp/` or other generated Wave runtime artifacts as if they were authored source.
-
-## Product-Specific Constraints
-
-- The editor is schema-first. Do not treat the DOM or HTML serialization as the source of truth.
-- Keep content model, review model, preservation state, UI state, and OOXML IO separate.
-- Do not introduce Web Workers or multi-package indirection for core editing flows.
-- Unsupported OOXML must be preserved or surfaced explicitly. Never silently drop unknown content.
-- If a change risks Word compatibility, anchor mapping, revision integrity, list structure, or table structure, treat it as high risk.
-- If a change affects UI layout, markup rendering, tokens, or controls, align it to `DESIGN.md` rather than ad hoc taste.
-
-## Source Layout Bias
-
-Prefer landing code in these directories:
-
-- `src/model`
-- `src/core`
-- `src/review`
-- `src/io`
-- `src/preservation`
-- `src/validation`
-- `src/runtime`
-- `src/ui`
-- `test/fixtures`
-
-## Test Expectations
-
-- Add focused tests or fixtures for the exact behavior you changed.
-- When touching import/export, preservation, comments, revisions, lists, or tables, prefer fixture-driven tests over narrative claims.
-- A fix that changes mapping behavior should prove anchor or revision stability through edits.
-- A fix that changes OOXML handling should prove round-trip behavior or preservation behavior.
-
-## Doc Alignment
-
-Update docs when you change:
-
-- architecture boundaries
-- component maturity
-- feature scope
-- proof expectations for compatibility-critical subsystems
-
-Most relevant docs:
-
-- `README.md`
-- `docs/roadmap.md`
-- `docs/plans/current-state.md`
-- `docs/plans/master-plan.md`
-- `docs/plans/component-cutover-matrix.md`

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

@@ -1,34 +0,0 @@
-{
-  "id": "repo-coding-rules",
-  "title": "Repo Coding 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

@@ -1,91 +0,0 @@
-# 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.
-- Summaries and inboxes may refresh during execution. Re-read context before each iteration to pick up new evidence or coordination records from other agents.
-
-## 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

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

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

@@ -1,100 +0,0 @@
-# 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 canonical state and typed closure artifacts as authoritative for closure. The final verdict line and gate marker must match that state; earlier markers are compatibility history only.
-
-## Workflow
-
-Execute these steps in order. Do not skip steps.
-
-1. **Receive evidence** -- collect all implementation proof, coordination records, integration output, doc closure output, cont-EVAL output (if present), and security output (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. When the wave declares `### Proof artifacts`, verify those machine-visible artifacts are present.
-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 proof registry** -- check whether operator-registered proof bundles exist. Confirm they are `active` (not `revoked` or `superseded`). Only active bundles count as evidence.
-5. **Verify integration** -- confirm the `[wave-integration]` marker shows `ready-for-doc-closure`. Check that no later coordination records contradict it.
-6. **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.
-7. **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.
-8. **Verify security** -- if the wave includes a security review, confirm the `[wave-security]` marker shows `clear` or `concerns`. A `blocked` marker prevents closure.
-9. **Verify no pending rerun** -- confirm no active rerun request is outstanding. An uncleared rerun blocks closure.
-10. **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.
-- [ ] Declared `### Proof artifacts` (if present) exist as files.
-- [ ] Proof registry bundles are `active`, not `revoked` or `superseded`.
-- [ ] No active rerun request is pending.
-- [ ] Security marker (if present) shows `clear` or `concerns`, not `blocked`.
-
-## 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

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

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