@beyondwork/docx-react-component 1.0.0

package/docs/agents/wave-infra-role.md

@@ -0,0 +1,34 @@
+---
+title: "Wave Infra Role"
+summary: "Standing prompt for an infra-focused wave agent that proves machine, identity, admission, or environment state."
+---
+
+# Wave Infra Role
+
+Use this prompt when an agent should own infra or environment proof for a wave.
+
+## Standing prompt
+
+```text
+You are the infra-focused agent for the current wave.
+
+Your job is to verify and, when explicitly assigned, implement the machine, identity, admission, dependency, or environment work needed for the wave. You are responsible for making infra state explicit instead of leaving it buried in shell output.
+
+Operating rules:
+- Re-read the compiled shared summary, your inbox, and the generated wave board projection before major decisions, before validation, and before final output.
+- Prefer explicit infra proof over vague notes like "looks good" or "seems configured".
+- Treat machine conformance, workload identity, service dependencies, node admission, and approved machine actions as first-class deliverables.
+- Keep repository guidance and lane safety rules authoritative. Do not improvise destructive machine changes.
+
+What you must do:
+- identify the exact infra surface you own for the wave
+- surface missing dependencies, identity gaps, admission blockers, and machine drift early
+- emit durable coordination records when the work depends on another agent or a human decision
+- leave enough exact evidence that the integration steward and cont-QA can tell whether the infra surface is conformant, still in setup, or blocked
+- emit structured infra markers whenever the task touches machine validation, workload identity, node admission, deployment bootstrap, or approved machine actions:
+  `[infra-status] kind=<conformance|role-drift|dependency|identity|admission|action> target=<machine-or-surface> state=<checking|setup-required|setup-in-progress|conformant|drift|blocked|failed|action-required|action-approved|action-complete> detail=<short-note>`
+
+Use `conformant` only when the required infra proof is actually present.
+If the work is still waiting on a safe same-wave setup step, use `setup-required` or `setup-in-progress` instead of pretending the wave is blocked forever.
+Use `blocked`, `drift`, or `failed` only when the wave genuinely cannot claim that infra surface as healthy.
+```

package/docs/agents/wave-integration-role.md

@@ -0,0 +1,37 @@
+---
+title: "Wave Integration Role"
+summary: "Standing prompt for the integration steward that reconciles cross-agent state after cont-EVAL and before documentation and cont-QA closure."
+---
+
+# Wave Integration Role
+
+Use this prompt when an agent should act as the integration steward for a wave.
+
+## Standing prompt
+
+```text
+You are the integration steward for the current wave.
+
+Your job is to synthesize cross-agent state after any `cont-EVAL` tuning pass and before the documentation steward and cont-QA make their final pass. You do not replace implementation ownership. You decide whether the wave is coherent enough for doc closure.
+
+Operating rules:
+- Re-read the generated wave inboxes and coordination board projection before major decisions.
+- Treat summaries and board projections as generated views over canonical state, not as the only source of closure truth.
+- Treat contradictions, unresolved blockers, interface drift, and unowned follow-up work as first-class integration failures.
+- Prefer explicit follow-up requests over vague warnings.
+- Keep the integration summary machine-readable and short enough to drive relaunch decisions.
+- Read docs/reference/wave-planning-lessons.md before making final judgments.
+- Prefer the current attempt's authoritative proof bundles and landed artifacts over stale blocker or request residue from earlier failed attempts.
+- When runtime and UI describe the same state at different abstraction levels, treat the runtime-owned contract as authoritative and only block on a real canonical mismatch.
+
+What you must do:
+- identify open claims that are still unsupported
+- identify conflicting claims or incompatible interface assumptions
+- identify unresolved blockers and cross-component impacts
+- identify proof gaps, doc gaps, and deploy or release risks that still block closure
+- reduce the result to the smallest current blocker set instead of carrying forward superseded blockers
+- emit one final structured marker:
+  `[wave-integration] state=<ready-for-doc-closure|needs-more-work> claims=<n> conflicts=<n> blockers=<n> detail=<short-note>`
+
+Use `ready-for-doc-closure` only when the remaining work is documentation and cont-QA closure, not when material implementation or integration risk still exists.
+```

package/docs/agents/wave-launcher-role.md

@@ -0,0 +1,41 @@
+---
+title: "Wave Launcher Role"
+summary: "Standing prompt for the operator that runs waves through the orchestrator."
+---
+
+# Wave Launcher Role
+
+Use this prompt when an agent or human operator should launch waves through the orchestrator.
+
+## Standing prompt
+
+```text
+You are the wave launcher operator.
+
+Your job is to run wave files safely, one wave at a time by default, while respecting launcher locks, runtime policy, reducer state, clarification barriers, optional `cont-EVAL` gates, integration gates, documentation closure, and cont-QA closure.
+
+Before launching:
+1. Run `pnpm exec wave doctor`.
+2. Run `pnpm exec wave launch --lane main --dry-run --no-dashboard`.
+3. Run `pnpm exec wave coord show --lane main --wave 0 --dry-run --json` and `pnpm exec wave coord inbox --lane main --wave 0 --agent A1 --dry-run` when you need to inspect seeded state.
+4. Run `pnpm exec wave launch --lane main --reconcile-status`.
+5. Run `pnpm exec wave feedback list --lane main --pending`.
+6. Inspect `.tmp/main-wave-launcher/` state and dashboards when relevant.
+
+Completion requires:
+- all agents exit `0`
+- reducer and control-plane state show no unresolved helper-assignment, clarification, contradiction, or rerun blockers
+- if `cont-EVAL` is present, it must report satisfied targets before integration closure runs
+- integration must be `ready-for-doc-closure` before documentation and cont-QA closure run
+- cont-QA verdict is `PASS`
+- prompt hashes still match the current wave definitions
+- shared-plan documentation closure is resolved when required
+- no routed clarification chain or unresolved human escalation remains open
+- runtime mix targets and retry fallbacks remain within lane policy
+- live attempts write a hermetic `traceVersion: 2` trace bundle with `run-metadata.json`, `quality.json`, structured signals, copied launched-agent summaries, and recorded artifact hashes
+
+Generated boards, inboxes, and dashboards are operator surfaces. When they disagree with landed code, control-plane state, or typed result artifacts, trust the canonical state and rerun the projections instead of treating the projection as authority.
+
+Dry-run rule:
+- `wave launch --dry-run` is pre-attempt only. It should seed derived state and leave `traces/` without `attempt-<k>` files.
+```

package/docs/agents/wave-orchestrator-role.md

@@ -0,0 +1,52 @@
+---
+title: "Wave Orchestrator Role"
+summary: "Standing prompt for a resident orchestrator session that monitors a live wave and intervenes through coordination state."
+---
+
+# Wave Orchestrator Role
+
+Use this prompt for an optional resident orchestrator session that stays alive during a live wave.
+
+## Standing prompt
+
+```text
+You are the resident Wave orchestrator.
+
+Your job is to monitor the live wave for its full duration and intervene through the control plane instead of through product-code ownership.
+
+You do not own implementation files, proof markers, or closure verdicts.
+You do not override reducer, gate, retry, or closure decisions with narrative claims.
+
+Operate through durable state:
+- coordination log
+- control-plane log
+- typed result artifacts when present
+- shared summary
+- per-wave dashboard
+- clarification triage artifacts
+- human feedback queue
+
+Primary duties:
+1. Inspect open clarifications, routed follow-up requests, and human-feedback state.
+2. Watch for overdue acknowledgements and stale clarification chains.
+3. Resolve from repo state, prior decisions, ownership, or targeted rerouting before escalating to a human.
+4. Post durable coordination records that explain the intervention and the exact unblock condition.
+5. Stay available. If nothing needs action, keep monitoring instead of exiting early.
+
+Hard limits:
+- do not edit product code, tests, or implementation-owned docs
+- do not satisfy another agent's deliverables or proof obligations
+- do not emit implementation, integration, documentation, or cont-QA closure markers
+- do not override reducer, gate, retry, or closure outputs with narrative claims
+
+Good interventions:
+- route or reroute a clarification to the current owner
+- resolve a clarification from existing repo policy or published artifacts
+- open or summarize a human escalation only after orchestrator-first routing is exhausted
+- post concise projection or coordination notes when timing or routing policy changed
+
+Bad interventions:
+- taking over code ownership because an owner is slow
+- calling the wave complete based on chat alone
+- escalating to human while a routed follow-up is still within policy
+```

package/docs/agents/wave-planner-role.md

@@ -0,0 +1,39 @@
+---
+title: "Wave Planner Role"
+summary: "Standing prompt for the read-only planner that turns a simple request into a high-fidelity, reviewable wave roadmap."
+---
+
+# Wave Planner Role
+
+Use this prompt when an agent should act as the planner for a future wave or set of waves.
+
+## Standing prompt
+
+```text
+You are the wave planner for the current repository.
+
+Your job is to turn a simple task request into a narrow, executable, reviewable wave plan that matches the repository's real architecture and closure model. You are read-only during planning. Do not propose work that depends on improvised runtime behavior or undocumented proof.
+
+Operating rules:
+- Read repository truth first: AGENTS.md, wave.config.json, planner docs, current-state, master-plan, component matrix, sample waves, and the planning-lessons document.
+- Treat repo-local lessons and docs as higher priority than generic external research when they conflict.
+- Prefer narrow, layered waves. Split broad or fuzzy work instead of overloading one wave.
+- Match the maturity claim, owned slices, runtime setup, deliverables, proof artifacts, and closure docs to the same truth level.
+- Treat live-proof waves as a different class of wave, not as repo-landed waves with extra prose.
+
+What you must do:
+- choose an honest target maturity level for each promoted component
+- keep each component promotion to one honest maturity jump per wave unless the request explicitly says otherwise
+- map each promoted component to one or more complementary implementation owners
+- require exact Deliverables for implementation owners
+- require exact Proof artifacts for proof-centric owners
+- require an explicit live-proof owner, `.tmp/` proof bundle, rollback or restart evidence, and an operations runbook under `docs/plans/operations/` for `pilot-live` and above
+- keep A8, A9, and A0 as real closure gates
+- pin runtime choices, budgets, and Context7 deliberately enough to avoid preventable execution failures
+- surface open questions explicitly when repo truth is missing instead of inventing policy
+
+Output contract:
+- Return structured JSON only.
+- The JSON must be decision-ready for verifier checks and markdown rendering.
+- Do not return a vague narrative summary in place of the structured plan.
+```

package/docs/agents/wave-security-role.md

@@ -0,0 +1,40 @@
+---
+title: "Wave Security Role"
+summary: "Standing prompt for the security reviewer that performs a threat-model-first review before integration closure."
+---
+
+# Wave Security Role
+
+Use this prompt when an agent should act as the security reviewer for a wave.
+
+## Standing prompt
+
+```text
+You are the wave security reviewer for the current wave.
+
+Your job is to review the landed change set before integration closure, identify security-sensitive risks, and route exact fixes or approvals while the wave is still active. You are report-only by default. Do not replace implementation ownership.
+
+Operating rules:
+- Re-read the compiled shared summary, your inbox, the generated wave board projection, and the owned reports before major decisions.
+- Do a threat-model pass before finalizing conclusions. Identify trust boundaries, attacker-controlled inputs, sensitive assets, approval-sensitive operations, and any external execution or data access paths touched by the wave.
+- Prefer exact findings and exact requested fixes over vague warnings.
+- Route fixes to the owning agent when the required change is outside your report path.
+- Keep the final output short enough to drive relaunch decisions and closure gates.
+
+What you must do:
+- leave a security review report with these sections in order:
+  `Threat Model`
+  `Risky Surfaces`
+  `Findings`
+  `Required Approvals`
+  `Requested Fixes`
+  `Final Disposition`
+- record each finding with severity, concrete file or surface, exploit or failure mode, and the owner expected to fix it
+- record each approval-sensitive action explicitly, even if the wave can proceed without blocking
+- emit one final structured marker:
+  `[wave-security] state=<clear|concerns|blocked> findings=<n> approvals=<n> detail=<short-note>`
+
+Use `clear` only when no unresolved findings or approvals remain.
+Use `concerns` when findings remain advisory for this wave and do not automatically block progression.
+Use `blocked` only when the wave must stop before integration until a finding or approval is resolved.
+```

package/docs/architecture/docx/README.md

@@ -0,0 +1,10 @@
+# Docx Architecture
+
+This directory is reserved for docx-specific architecture material as the broader `react-ooxml-office` docs hierarchy fills out.
+
+Current docx architecture contracts still live in the legacy reference paths:
+
+- `docs/reference/word-review-editor-frontend-architecture.md`
+- `docs/reference/word-review-editor-ux-guide.md`
+
+Those remain the canonical shipped docx architecture docs today.

package/docs/architecture/future/README.md

@@ -0,0 +1,8 @@
+# Future Architecture
+
+This directory is reserved for future architecture work that sits outside the current shipped docx runtime and outside the first shared OOXML sibling set.
+
+For now, that mainly means:
+
+- future pdf exploration
+- later cross-vertical capabilities that should not be implied by current shipped contracts

package/docs/architecture/ooxml-upgrade-analysis.md

@@ -0,0 +1,134 @@
+# Architectural Analysis: Preserve-Only → Supported Upgrade Path
+
+## Architecture Summary
+
+Our codebase has 4 layers for handling OOXML features:
+
+1. **OPC Layer** (src/io/opc/) — ZIP package read/write, part discovery, relationship tracking
+2. **Preservation Layer** (src/preservation/) — opaque fragment store, package part retention, MC handling
+3. **Canonical Model** (src/model/) — typed document nodes, style catalog, media catalog
+4. **Surface Projection** (src/runtime/) → **PM Schema** (src/ui-tailwind/) → rendered editor
+
+### How features graduate from preserve-only to supported:
+
+```
+PRESERVE-ONLY:                           SUPPORTED:
+OPC part bytes → opaque fragment    →    OPC part bytes → parser → canonical node
+opaque block in surface            →    typed block in surface
+locked in PM (no editing)          →    editable in PM schema
+reattach original bytes on export  →    serialize from canonical on export
+```
+
+The key insight: our preservation system already handles ALL unknown content safely.
+Graduating a feature means: add a parser, add a canonical type, add surface projection,
+add PM rendering, and add a serializer. The preservation system handles the fallback.
+
+### Validation strategy per tier:
+
+- **Tier 1 (parse + pass-through)**: Unit test parse/serialize. Fixture round-trip.
+- **Tier 2 (read-only projected)**: Above + surface projection test. No editing.
+- **Tier 3 (fully editable)**: Above + PM schema + command tests + edit round-trip.
+
+---
+
+## Feature Groups by Architectural Pattern
+
+### Group A: Simple Property Parsing (13 features, ~14h)
+Pattern: Add field to existing canonical node type, parse from XML attr, serialize back.
+No new PM nodes, no new surface blocks. Properties affect rendering CSS only.
+
+Features: widowControl, pBdr, pShd, bidi, charSpacing, kerning, emboss/shadow,
+columnBreaks, symbols, suppressLineNumbers, cnfStyle, tblLook, latentStyles.
+
+Architecture:
+- Extend ParagraphNode/TextMark interfaces in canonical-document.ts
+- Parse in parse-main-document.ts (add cases to existing paragraph/run property loops)
+- Serialize in serialize-main-document.ts (add cases to existing property serializers)
+- Surface projection: carry properties through for CSS rendering
+- PM schema: add attrs to paragraph/text nodes for styling
+- Tests: parse + serialize round-trip per property
+
+### Group B: Document Sub-Parts (9 features, ~42h)
+Pattern: Parse a separate XML part (headerN.xml, footnotes.xml, etc.), create a sub-document
+model, link from body references, render in dedicated UI zones.
+
+Features: headers (3 types), footers (3 types), footnotes, endnotes, theme.
+
+Architecture:
+- Add new canonical types: HeaderDocument, FooterDocument, FootnoteCollection, ThemeDefinition
+- New parsers: parse-headers.ts, parse-footnotes.ts, parse-theme.ts
+- New serializers: serialize-headers.ts, serialize-footnotes.ts
+- DocxSession: add owned paths for these parts, parse them alongside main document
+- Surface projection: add footer/header/footnote zones to EditorSurfaceSnapshot
+- PM schema: render in separate PM editors or as read-only zones
+- Export: serialize owned header/footer/footnote parts, reattach the rest
+- Theme resolution: resolve theme colors/fonts in style inheritance
+
+### Group C: Structural Block Types (4 features, ~19h)
+Pattern: New block-level canonical node, parser, surface block, PM node.
+
+Features: SDT (content controls), customXml, altChunk, nestedTables.
+
+Architecture:
+- SDT: Parse w:sdt as a wrapper node containing block/inline children.
+  Canonical type: SdtNode { type, properties, children }. PM: contentEditable container.
+  Challenge: Many SDT subtypes (richText, date, dropdown, checkbox) with different editing UX.
+- customXml: Parse as wrapper node, treat inner content as editable.
+  Simpler than SDT — just structural container.
+- altChunk: Import embedded HTML/RTF by resolving the relationship.
+  Complex: would need an HTML/RTF → canonical converter.
+  Pragmatic: parse as read-only projected block showing content preview.
+- nestedTables: Recursive table parsing. PM: prosemirror-tables supports nesting.
+  Main work: surface-projection recursion for table-in-cell.
+
+### Group D: Inline Content Types (4 features, ~22h)
+Pattern: New inline canonical node, parser, PM inline atom, serializer.
+
+Features: floatingImages, footnoteRefs, ruby, OLE objects.
+
+Architecture:
+- Floating images: Parse wp:anchor DrawingML. Canonical: FloatingImageNode with position/wrap props.
+  PM: Positioned absolute/relative node (complex — needs position map outside text flow).
+  Pragmatic: Render as inline with "floating" badge, preserve position on export.
+- Footnote refs: Parse w:footnoteReference. Canonical: FootnoteRefNode { noteId }.
+  PM: Inline atom with superscript number. Click → navigate to footnote zone.
+  Requires Group B footnote parsing.
+- Ruby: Parse w:ruby (base + annotation). Canonical: RubyNode { base, annotation }.
+  PM: Inline with ruby annotation rendering (CSS ruby-position).
+- OLE objects: Parse w:object. Canonical: OleObjectNode { progId, fallbackImage }.
+  PM: Inline atom showing fallback image or icon. No editing.
+
+### Group E: Track Change Extensions (4 features, ~16h)
+Pattern: Extend revision model and store.
+
+Features: pPrChange, sectPrChange, tblPrChange, moveTo/moveFrom.
+
+Architecture:
+- Property changes: Parse old/new property pairs from w:*Change elements.
+  Store in revision record as PropertyChangeRevision { before, after }.
+  Surface: Show diff indicator on paragraph/section/table.
+  Accept: Apply "after" properties. Reject: Restore "before" properties.
+- Move tracking: Parse w:moveFrom/moveTo with matching IDs.
+  Store as MoveRevision { moveId, direction, range }.
+  Surface: Render as deletion at source + insertion at destination with linking indicator.
+  Accept: Keep destination. Reject: Restore source.
+
+### Group F: Complex Rendering (5 features, ~83h)
+Pattern: Full subsystem — parser, model, renderer.
+
+Features: charts, SmartArt, shapes, WordArt, VML.
+
+Architecture:
+- Charts: ChartML parser → chart model → Canvas/SVG renderer.
+  Full charting library. Huge scope. Consider: read-only SVG preview from XML.
+- SmartArt: DiagramML → layout algorithm → SVG rendering.
+  Extremely complex layout engine. Consider: fallback to EMF/PNG preview image.
+- Shapes/WordArt/VML: Parse geometry, text, fills, effects.
+  Consider: Read-only SVG rendering for shapes, skip editing.
+  VML is legacy — render as fallback for pre-2007 content.
+
+### Group G: Security (2 features, intentionally excluded)
+- Digital signatures: Full XMLDSIG. Out of scope.
+- Password encryption: Upstream concern. Out of scope.
+
+---

package/docs/architecture/platform/shared-openxml-editor-platform.md

@@ -0,0 +1,153 @@
+# Shared OOXML Editor Platform
+
+## Status
+
+- This is the canonical umbrella architecture doc for the broader `react-ooxml-office` repo story.
+- The only shipped runtime in source today is the `docx` implementation behind `WordReviewEditor`.
+- `xlsx` is planned and documented here as the next OOXML sibling, not as a shipped runtime.
+- `pdf` is a future vertical and is intentionally outside this first shared OOXML platform contract.
+
+## Purpose
+
+This repository is evolving from a docx-only product narrative into a broader office-document platform with three distinct layers:
+
+1. shared platform capabilities
+2. format-specific runtimes
+3. host-facing editor surfaces
+
+The goal is to broaden the docs without pretending the codebase is already neutral. The shared platform should capture what is genuinely common across OOXML siblings such as `docx` and `xlsx`, while each format keeps its own canonical model, editing semantics, and UX.
+
+## Core Platform Principles
+
+- Treat OOXML files as OPC packages first, not as isolated XML files.
+- Keep runtime-owned structured state as the only source of truth.
+- Route every mutation through commands and transactions.
+- Preserve unsupported but preservable content instead of silently discarding it.
+- Keep compatibility posture explicit through typed warnings, errors, and export blockers.
+- Use host application behavior as the final fidelity gate.
+- Keep shipped runtimes main-thread only unless an explicit architecture change is made.
+
+## Layered Architecture
+
+```text
+Host App
+  |
+  v
+Embeddable Editor Surface
+  |
+  v
+Format Runtime
+  |
+  v
+Shared OOXML Platform
+  |
+  v
+OPC package, preservation, diagnostics, validation
+```
+
+### Shared Platform Responsibilities
+
+The shared OOXML platform is responsible for concerns that remain honest across multiple OOXML formats:
+
+- OPC package reading and writing
+- part manifests, content types, and relationship integrity
+- preservation of unknown or unsupported but preservable parts
+- compatibility reporting vocabulary and export blocking
+- host persistence and snapshot doctrine
+- validation integration with the internal Open XML SDK service
+- shared runtime-to-UI doctrine: runtime owns truth, UI renders projections
+- future shared AI or agent mediation boundaries above format runtimes
+
+These concerns are intentionally narrower than a full editor runtime. The platform should not pretend that Word paragraphs and spreadsheet cells share one canonical model.
+
+### Format Runtime Responsibilities
+
+Each format runtime owns its own domain model, editing rules, and projections:
+
+- `docx`: paragraphs, runs, comments, revisions, review anchors, and the current `WordReviewEditor` surface
+- `xlsx`: workbook, sheets, ranges, formulas, merges, spreadsheet annotations, and a grid-first editor surface
+- `pdf`: future non-OOXML work; outside the first shared platform contract
+
+Format runtimes may reuse platform services, but they must not be flattened into a lowest-common-denominator editor abstraction.
+
+## Current State In This Repo
+
+Today the source tree is still organized around the active `docx` implementation:
+
+```text
+src/
+  api/
+  model/
+  core/
+  review/
+  io/
+  preservation/
+  validation/
+  runtime/
+  ui/
+services/
+  react-word-editor/
+  openxml-validator/
+```
+
+That remains the truthful description of the landed code.
+
+The broader target architecture for future work is:
+
+```text
+src/
+  platform/
+  formats/
+    docx/
+    xlsx/
+    pdf/
+services/
+  office-harness/
+  openxml-validator/
+```
+
+This target layout is a documentation and planning direction, not a claim that the source has already been moved.
+
+## Current Format Status
+
+### `docx`
+
+- implemented in source
+- shipped public component name: `WordReviewEditor`
+- current public API contract remains under `docs/reference/public-api.md`
+- current compliance contract remains under `docs/reference/ooxml-compliance.md`
+
+### `xlsx`
+
+- not implemented in source
+- promoted from raw research into planned canonical docs
+- intended to reuse shared platform capabilities while keeping spreadsheet-native runtime and UX boundaries
+
+### `pdf`
+
+- future exploration only
+- should not be forced into the OOXML platform contract unless a later architecture intentionally broadens the platform beyond OOXML
+
+## Future Shared Capability: Agent Layer
+
+The agent or LLM interaction layer belongs above the shared platform and format runtimes, not inside the current shipped `WordReviewEditor` contract.
+
+That future layer should:
+
+- request structured context from format runtimes
+- propose typed commands instead of mutating state directly
+- respect compatibility and export blockers
+- remain reviewable and auditable
+
+It is a roadmap capability, not a current public API guarantee.
+
+## Doc Map
+
+- Repo overview: `README.md`
+- Docs navigation: `docs/README.md`
+- Current docx implementation contracts: `docs/reference/public-api.md`, `docs/reference/ooxml-compliance.md`, `docs/reference/word-review-editor-frontend-architecture.md`
+- Planned xlsx architecture: `docs/architecture/xlsx/spreadsheet-editor-frontend-architecture.md`
+- Planned xlsx canonical model: `docs/architecture/xlsx/canonical-workbook-model-and-commands.md`
+- Planned xlsx compliance: `docs/reference/xlsx/xlsx-ooxml-compliance.md`
+- Planned xlsx fixture and certification program: `docs/plans/xlsx/xlsx-fixture-corpus-and-certification-plan.md`
+- Research intake: `docs/xlsx-react/README.md`