@beyondwork/docx-react-component 1.0.0 → 1.0.1

package/docs/xlsx-react/xlsx-fixture-corpus-and-certification-plan.md

@@ -1,436 +0,0 @@
-# XLSX Fixture Corpus, Scenario Program, and Certification Plan
-
-This research paper is source material.
-
-Canonical repo-aligned planned doc:
-
-- `docs/plans/xlsx/xlsx-fixture-corpus-and-certification-plan.md`
-
-## Interpretation of the problem
-
-You’re not asking how to build an XLSX editor. You’re asking for the **permanent compatibility program** that keeps an XLSX editor honest over time: a fixture corpus, scenario runner, automated validation, and manual Excel certification gates that enforce the principle “exported files must reopen in recent Excel environments without repair prompts or silent supported-content loss.”
-
-Key constraints that drive this plan:
-
-An `.xlsx` file is an **OOXML / Open Packaging Conventions (OPC) package** (ZIP physical mapping; parts + relationships as a directed graph), not “some XML.” The package has required structural items like the content types part and package relationships part, with strict relationship-part naming conventions.
-
-The editor must support **import → runtime edit → export → reopen** as the standard for “supported.” Where that cannot be guaranteed, the feature must be explicitly classified as **preserve-only** or **unsupported-fatal**, not “best effort.” This is aligned with how the OOXML ecosystem expects forward compatibility via **Markup Compatibility and Extensibility** mechanisms (e.g., `mc:Ignorable`, `AlternateContent`, `extLst`) and vendor extensions (notably Excel’s `.xlsx` extensions) so older consumers can ignore unknown markup without breaking.
-
-Schema conformance is necessary but insufficient: the Open XML SDK exposes validators (e.g., `OpenXmlValidator`) and strongly-typed part models, but Excel can still surface “repair” behavior even when validators pass, and conversely validators can flag issues that Excel tolerates. Therefore, “Excel reopen without repair prompts” must be a **manual certification** (and later possibly semi-automated) release gate.
-
-Source constraints for this response: you asked to start with your GitHub connector and the repo `bwllaming/docx-react-component`, but the GitHub connector was not actually accessible in this environment (tooling reported no repo selection / no results), so this plan is built from primary OOXML/OPC sources and Microsoft/OpenXML documentation instead.
-
-## Research plan
-
-Information that must be true to produce an implementation-ready compatibility program:
-
-OPC/OOXML packaging invariants to validate for every fixture (content types stream, relationship graph invariants, relationship part naming rules, minimal SpreadsheetML package structure).
-
-SpreadsheetML part topology and “minimum workbook scenario” (workbook + worksheets + relationship IDs), plus major feature part families: shared strings, styles, calc chain, tables, pivot tables/caches, conditional formatting, formulas, drawings/charts.
-
-Excel-specific extensions and forward-compat contract: which parts and relationships are used by Excel extensions (e.g., threaded comments; slicers; persons list; named sheet views), what “MUST” relationships exist, and what compatibility mechanisms Excel relies on (`mc:Ignorable`, `extLst`).
-
-Validation tooling surface area: Open XML SDK creation and validation entrypoints; validator configuration by Office version (e.g., `FileFormatVersions` enum).
-
-Host matrix facts that matter for certification and “reopen expectations”: which Excel versions/products are relevant, worksheet limits for stress fixtures, and cross-origin export realities (Google Sheets and LibreOffice both export `.xlsx`, but conversion limitations exist and must be treated as a hostile input class).
-
-## Findings
-
-OPC structure is graph-first: packages are navigated starting at `/_rels/.rels`, then following relationships to locate parts; relationship parts live in `_rels` folders and are named by appending `.rels` to the source part’s name. This implies fixture validation must treat **missing / dangling / mis-targeted relationships** as first-class failures independent of XML element validity.
-
-A SpreadsheetML package has hard minimums: it “shall contain” at least a content-type item and package-relationship item, with a required relationship to exactly one workbook part, and worksheets referenced by relationship IDs from the workbook. The Microsoft Open XML SDK documentation mirrors this minimum structure (workbook part + at least one worksheet part).
-
-The ecosystem expects “future content” survival: SpreadsheetML frequently uses extension/compatibility constructs (e.g., `extLst`, `mc:Ignorable`) and Excel documents can embed non-core parts and markup that are required for fidelity in newer Excel. Microsoft’s `.xlsx` extensions spec explicitly requires that compatibility mechanisms like `Ignorable`, `AlternateContent`, or `extLst` be used to maintain compatibility with base ISO/IEC 29500 consumers. A concrete example: the Excel threaded comments feature is stored in a dedicated part type with a defined content type, sourced via a relationship from the worksheet, and includes additional reconciliation behavior with legacy comment placeholders.
-
-Validation has two different “truths”: OpenXmlValidator exists, is configurable by Office version, and is useful for schema-level sanity checks, but real-world evidence (and developer reports) show Excel can still repair files even when OpenXmlValidator reports no errors. That means the certification program must treat OpenXmlValidator as **necessary but not sufficient**, and include explicit Excel-open certification.
-
-Cross-origin exporters are guaranteed fixture sources, not edge cases:
-- Google Sheets explicitly supports downloading spreadsheets as “Microsoft Excel (.xlsx).”
-- LibreOffice explicitly states it can load/save Office Open XML formats (including `.xlsx`) while warning that complex Microsoft Office features can be handled differently or be unsupported, requiring manual reformatting.
-These exporters therefore produce “valid-looking but hostile” packages that your editor must either support end-to-end, preserve-only, or reject as unsupported-fatal.
-
-Performance/stress fixtures must be aligned to Excel’s published limits: Microsoft documents worksheet limits such as 1,048,576 rows by 16,384 columns, maximum characters per cell, and limits on unique cell formats. Stress fixtures should be sized to trigger algorithmic pitfalls (sharedStrings explosion, style record blowups, dense sheetData) without requiring maximum theoretical size.
-
-## Recommended design / decisions
-
-This section is the core: the fixture corpus and certification plan are as important to architecture as your runtime state model, because they define “what correctness is.”
-
-### Decision: split the corpus into “release-gate fixtures” and “representative scenarios,” with explicit support classification
-
-**Release-gate fixtures** are the permanent, minimal set that blocks a release if they regress. They must be deterministic, small, and cover every supported feature and every preservation contract. Their goal is to catch correctness regressions early, not to be exhaustive.
-
-**Representative scenarios** are larger, more realistic workbooks (including cross-origin exports) used for broader confidence, manual exploration, and periodic certification. They can be noisy and are allowed to evolve.
-
-Each fixture must carry an explicit classification per feature scope:
-
-- **supported**: must survive import → edit (at least a no-op or scoped edit) → export → reopen in Excel without repair prompts, and with specified semantics preserved.
-- **preserve-only**: editor must load and round-trip without dropping content, but must not claim correctness for edits affecting that feature; the UI should lock/warn. (This is aligned with OOXML forward-compat constructs and Excel extensions: you will see `mc:Ignorable`, `extLst`, and vendor parts you don’t implement.)
-- **unsupported-fatal**: the editor must refuse to export (block/fail) if a user attempts to load or modify the workbook in a way that cannot be safely round-tripped without causing Excel repair prompts or silent loss.
-
-### Decision: preservation is tested structurally (package graph + byte preservation for unknown parts), not only semantically
-
-Because OPC navigation is relationship-graph-based and relationship parts have strict naming conventions, the lowest-level preservation contract is:
-
-- Every unknown package part and relationship must be preserved in the output OPC graph, unless explicitly stripped by a declared policy.
-- Relationship part naming and placement must remain valid (e.g., `/a/b/_rels/c.xml.rels`).
-- Content types must still map every part; content types are required for consumers and are central to OPC characterization.
-
-For unknown parts, the only safe automated assertion is **byte-for-byte identity** (or, if your pipeline normalizes ZIP ordering/deflate metadata, at least a stable hash of the part payload stream). For known parts, allow canonicalization (namespace prefix differences, attribute ordering) but enforce semantic invariants.
-
-### Decision: automated validation is multi-layered and version-targeted; Excel-open certification is the release truth
-
-Automated validation layers:
-
-- **OPC structural validator**: checks existence and correctness of `[Content_Types].xml`, `/_rels/.rels`, relationship-part naming conventions, reachable part graph, dangling relationship targets, invalid TargetMode usage, and content-type coverage.
-- **SpreadsheetML schema/structure baseline**: minimum workbook scenario validation (workbook, sheets, worksheet parts), plus constraints like “one Worksheet part per worksheet.”
-- **Open XML SDK validator lane** (CI optional but strongly recommended): run `OpenXmlValidator` against exported packages for multiple file format versions (Office2007…Microsoft365). This catches a class of schema errors and version-gating differences.
-
-Manual Excel certification:
-
-- For each release candidate, open and save exported fixtures in recent Excel hosts (Windows/Mac/Web minimum) and verify: no repair prompt, no repair log, and no silent loss of supported content (checked by predeclared “audit fields” per fixture).
-- This is required because schema validators are not equivalent to Excel acceptance.
-
-### Decision: host matrix is explicit, and “Excel for Microsoft 365” is the primary bar
-
-Your stated standard is “recent Excel environments.” Microsoft’s own Open XML format guidance is scoped across Microsoft 365 and recent perpetual releases. The certification host matrix must include:
-
-- Excel Desktop on Windows (Microsoft 365 current channel) — primary truth bar.
-- Excel Desktop on macOS (Microsoft 365) — necessary for feature parity differences (rendering, fonts, some chart behaviours).
-- Excel for the web — important because Excel web-origin files are a required corpus category, and because web can reserialize workbooks differently.
-
-Optional expansion hosts (phase-based): Excel LTSC/perpetual (e.g., 2021/2024), and at least one “older but still common” version if your customers demand it.
-
-### Decision: waves/phases aligned to feature support maturity and fixture enforcement
-
-Wave planning prevents “premature support claims.” Example alignment:
-
-- **Wave 0 (Foundation)**: OPC correctness + minimal workbook + basic grid editing + styles baseline; unknown part preservation with strict byte preservation.
-- **Wave 1 (Spreadsheet core)**: formulas, shared strings, styles, merged cells, freeze panes, filters, hyperlinks, notes/comments (legacy).
-- **Wave 2 (Structured features)**: tables, conditional formatting, data validation, drawings/images.
-- **Wave 3 (Advanced Excel objects)**: charts, pivot tables, slicers, threaded comments, data model — initially preserve-only unless you also implement the coupled parts/relationships and Excel’s behavioral invariants.
-
-## Risks and open questions
-
-Excel behavior drift vs standard: Excel implements ISO/ECMA plus extensions and product behaviors that change over time; Microsoft provides “implementation information” documents for ECMA-376 and ISO/IEC 29500 support, but some materials require authorization in certain contexts. You should expect mismatches and treat Excel as the arbiter.
-
-Validator mismatch risk: `OpenXmlValidator` can be version-targeted but will not guarantee Excel-open success; relying on it as a gate will produce false confidence.
-
-Cross-origin hostility: Google Sheets and LibreOffice exports are explicitly supported workflows, but both can produce edge-case constructs; LibreOffice explicitly warns about conversion challenges and unsupported features. Your corpus must include these to prevent “works on Excel-made files only” bias.
-
-Preserve-only complexity: Preservation is not free. If your editor rewrites parts it doesn’t understand (or drops unrecognized relationships), you can easily produce Excel repair prompts or quiet content loss. This is why unknown-part fixtures must be first-class and release-gated. The risk is highest in areas where Excel uses extension parts and compatibility constructs such as threaded comments and their legacy placeholders.
-
-“Malformed package” scope question: decide what “malformed” means for your product. Some malformed inputs should be rejected immediately (unsupported-fatal), but others might be salvageable as preserve-only under a “best-effort import with warnings” mode. OPC and minimum workbook requirements give you the hard floor for “cannot proceed.”
-
-Stress fixture realism: Excel’s published worksheet limits are enormous; fixtures near those maxima are hard to keep deterministic and will be slow in CI. The open question is what practical “large” sizes match your runtime constraints while still surfacing algorithmic performance failures.
-
-## Concrete deliverable in the requested format
-
-This is the repo-ready spec you can drop into a new `xlsx-compat` or `fixtures/` directory and implement against.
-
-### Repository layout
-
-- `fixtures/`
-  - `README.md` (how to run corpus + certification)
-  - `schema/fixture-metadata.schema.json`
-  - `schema/scenario-run.schema.json`
-  - `gates/`
-    - `release-gate-manifest.json` (ordered list of gate fixture IDs)
-    - `scenario-manifest.json` (grouped scenario sets)
-  - `cases/<fixtureId>/`
-    - `input/original.xlsx` (canonical “as received”)
-    - `input/origin-notes.md` (creation steps + origin app/version)
-    - `expected/expectations.json` (expected results)
-    - `expected/part-hashes.json` (hashes for preserve-only parts)
-    - `expected/audit.xlsx.json` (optional: expected cell/style audits)
-    - `scripts/scenario.ts` (optional: scenario program for edit steps)
-    - `artifacts/` (generated outputs per run; ignored by git)
-- `tools/`
-  - `fixture-runner/` (Node CLI: import → edit → export → validate)
-  - `opc-lint/` (OPC structural validator)
-  - `excel-cert/` (manual certification harness + checklists)
-- `reports/`
-  - `latest/` (CI outputs + Excel cert logs archived per release)
-
-### Fixture metadata schema (authoritative contract)
-
-Each fixture has a `fixture.json` embedded into `expected/expectations.json` under `meta`:
-
-**Required fields**
-
-- `id`: string (stable, kebab-case, never reused)
-- `title`: string
-- `category`: one of the minimum categories below (multi-valued allowed)
-- `origin`:
-  - `producer`: enum: `excel-desktop-win`, `excel-desktop-mac`, `excel-web`, `google-sheets`, `libreoffice-calc`, `generated`, `third-party`
-  - `producerVersion`: string (freeform; required for non-generated)
-  - `createdAt`: ISO date
-  - `creationSteps`: string (human instructions)
-- `size`:
-  - `bytes`: integer
-  - `sheets`: integer
-  - `usedRangeSummary`: per sheet, `(maxRow, maxCol, usedCells)`
-- `featureFlags`: map of feature → `supported|preserve-only|unsupported-fatal`
-- `expectedImport`:
-  - `result`: enum `ok|warn|block|fail`
-  - `warnings`: array of stable warning codes
-  - `locks`: array of lock codes (UI should lock these features)
-- `expectedExport`:
-  - `result`: enum `ok|warn|block|fail`
-  - `warnings`: array
-- `preservationContract`:
-  - `unknownPartsPolicy`: `preserve-bytes` (default) | `strip-with-manifest` (rare)
-  - `partHashAlgorithm`: `sha256`
-  - `mustPreserveParts`: array of OPC part names (exact)
-  - `mustPreserveRelationships`: array of `{sourcePartName, relType, target}` triples
-- `excelCertification`:
-  - `gateLevel`: `release-gate` | `scenario-only`
-  - `requiredHosts`: array from the host matrix
-  - `openChecks`: checklist IDs
-  - `saveChecks`: checklist IDs (if “open+save” is required)
-
-**Stable warning/lock vocabulary (shared across product + tests)**
-These are the compliance states you require (preserve, lock, warn, block, fail), made testable:
-
-- `warn/*`: e.g. `warn/unsupported-feature-present`, `warn/will-preserve-only-pivot`, `warn/calcchain-dropped`
-- `lock/*`: e.g. `lock/pivot-editing`, `lock/threaded-comments-editing`, `lock/protection-locked`
-- `block/*`: e.g. `block/malformed-opc`, `block/encrypted-package`, `block/unsupported-fatal-feature`
-- `fail/*`: internal invariant breaks (export must not proceed)
-
-### Minimum fixture categories and required coverage
-
-The corpus must include at least the following **minimum categories**, each split into **release-gate fixtures** (small, deterministic) and **scenario fixtures** (realistic, possibly larger). The list below is not a loose brainstorm; it defines *what must exist* and what gets gated.
-
-For each category: create **at least 2 release-gate fixtures** (one “clean”, one “hostile/edge”), and **at least 1 representative scenario**.
-
-**Simple sheets**
-- Gate fixtures:
-  - `minimal-blank-1sheet`: minimum workbook scenario (workbook + one sheet + basic sheetData).
-  - `cells-types-mix`: numbers, strings (sharedStrings), booleans, dates (as numeric + format), blanks.
-- Scenarios:
-  - `simple-budget-sheet`: realistic grid with formats and totals.
-
-**Multi-sheet workbooks**
-- Gate fixtures: 3+ sheets with cross-sheet references; hidden sheet; veryHidden sheet.
-- Scenarios: workbook with named ranges and hyperlinks across sheets.
-
-**Style-heavy files**
-- Gate fixtures:
-  - `styles-baseline`: fonts/fills/borders/number formats; verify styles part round-trip and “unique cell formats” stress within reason (avoid Excel’s 65,490 unique format ceiling in gates).
-  - `conditional-numberformats`: mixed date/currency/percent.
-- Scenario: “design-heavy report” workbook.
-
-**Formula-heavy files**
-- Gate fixtures:
-  - `formula-arithmetic`: relative/absolute refs, ranges, SUM/IF.
-  - `formula-cross-sheet`: 3D refs; named ranges.
-- Scenario: model sheet that forces recalculation and checks cached results. (Be explicit whether your editor recalculates or preserves cached values.)
-
-**Merged cells**
-- Gate fixtures:
-  - `merge-rectangular`: standard merges with styles.
-  - `merge-overlap-invalid`: malformed merge definitions → expectedImport `block` or `warn` depending on salvage policy.
-- Scenario: printable layout with merged headers.
-
-**Comments/notes**
-- Gate fixtures:
-  - `legacy-notes`: classic comments/notes stored in the standard comment mechanisms.
-  - `threaded-comments-preserve-only`: threaded comments part + legacy placeholders; editing locked; preserve-only.
-- Scenario: collaboration annotation workbook exported from Excel web.
-
-**Hyperlinks**
-- Gate fixtures: internal hyperlink (sheet/cell), external hyperlink (URL, mailto).
-- Scenario: workbook used as a navigation hub.
-
-**Tables**
-- Gate fixtures: one structured table with header row; filters; table styles.
-- Scenario: import from a business report exported by another system.
-
-**Filters/frozen panes**
-- Gate fixtures: autoFilter + freeze panes + split panes; verify view state survives.
-- Scenario: large table with frozen headers.
-
-**Data validation**
-- Gate fixtures: list validation (dropdown), numeric range, custom formula validation.
-- Scenario: form-like sheet mapping to validations.
-
-**Conditional formatting**
-- Gate fixtures: simple color scale + icon set + formula-based rule.
-- Scenario: KPI dashboard.
-
-**Images/drawings**
-- Gate fixtures:
-  - `image-anchored`: one image anchored to cells (drawing part relationships).
-  - `unknown-drawing-extension`: include ignorable extensions around drawing markup; preserve-only.
-- Scenario: marketing sheet with multiple images.
-
-**Charts**
-- Gate fixtures: one basic chart linked to a data range; verify chart parts + drawing relationships survive.
-- Scenario: dashboard with multiple chart types.
-- Default classification: **preserve-only** until you can guarantee edits won’t break chart caches/relationships.
-
-**Pivot tables**
-- Gate fixtures: existing pivot table + cache parts; preserve-only by default.
-- Scenario: pivot workbook exported from Excel desktop.
-- Upgrade to supported only when you can maintain pivot cache integrity and Excel-open behavior.
-
-**Workbook/sheet protection**
-- Gate fixtures:
-  - `sheet-protection`: protected worksheet with unlockable ranges.
-  - `workbook-protection`: structure protected.
-- Classification: If you cannot correctly update hashes/flags when editing, treat as **lock + preserve-only** or **unsupported-fatal** for edits that would violate protection semantics.
-
-**Unknown OOXML / unknown package parts**
-- Gate fixtures (these are non-negotiable):
-  - `unknown-part-unreferenced`: extra part not referenced by any relationship (tests whether your exporter drops “garbage”; expected behavior: preserve if policy says so, or strip only with explicit manifest).
-  - `unknown-part-referenced`: unknown part reachable via relationships from workbook/worksheet; must be preserved and relationship graph must remain valid.
-  - `mc-ignorable-markup`: ignorable namespaces in worksheet/drawing; verify your XML round-tripper doesn’t erase ignorable markup nodes.
-
-**Files originating from Excel web**
-- Scenario fixtures:
-  - `excel-web-export-basic`
-  - `excel-web-collab-comments` (often includes modern comment systems; likely preserve-only initially).
-
-**Files exported from Google Sheets then reopened in Excel**
-- Scenario fixtures:
-  - `gsheets-export-formulas`
-  - `gsheets-export-formatting`
-  - `gsheets-export-validation`
-- These are grounded by the fact that Google Sheets supports downloading as `.xlsx`.
-
-**Files exported from LibreOffice then reopened in Excel**
-- Scenario fixtures:
-  - `libreoffice-export-basic`
-  - `libreoffice-export-chart`
-  - `libreoffice-export-validation`
-- Treat as hostile: LibreOffice explicitly warns about conversion differences and unsupported features for complex documents.
-
-**Malformed packages**
-- Gate fixtures (block/fail by design):
-  - `missing-content-types`: no `[Content_Types].xml` → `block/malformed-opc`.
-  - `missing-root-rels`: no `/_rels/.rels` → `block/malformed-opc`.
-  - `dangling-relationship-target`: relationship to missing part.
-  - `bad-rels-naming`: incorrect relationship part placement/name.
-- Policy: malformed fixtures must clearly assert expected behavior (`block` vs `fail`) and required diagnostic codes.
-
-**Very large workbooks**
-- Scenario + performance suite (not always release-gate):
-  - `wide-sheet-16k`: near 16,384 columns but modest rows.
-  - `tall-sheet-1m-lite`: large rows but sparse data to test streaming import.
-  - `dense-sharedstrings`: many repeated strings to stress shared string table behavior.
-- Release-gate should include at least one “medium large” workbook that runs quickly in CI but still triggers your virtualized grid and serialization paths.
-
-### Release-gate fixture policy
-
-A fixture is **release-gate** if any of the following are true:
-
-- It covers a feature marked `supported` in product docs.
-- It covers a preservation contract (unknown parts, ignorable markup) that, if violated, would cause silent loss or Excel repair risk.
-- It is a regression reproducer for a previously shipped bug.
-
-Release-gate fixtures must be:
-- Under a size cap (e.g., ≤2–5 MB uncompressed total parts unless justified).
-- Deterministic: generated or accompanied by precise creation steps and “expected audit” files.
-- Version-pinned: `origin.producerVersion` recorded and never “floating.”
-
-### Representative scenario policy
-
-Scenario fixtures can be larger/noisier and should represent:
-- Real business sheets (financial models, reports, dashboards).
-- Cross-origin files (Excel web, Google Sheets export, LibreOffice export).
-- “Kitchen sink” workbooks with many features combined.
-
-Scenarios are not automatically release blockers unless promoted to gate via regression policy.
-
-### Regression fixture policy
-
-When a bug is found in production or during certification:
-
-- Create the **smallest possible reproducer** fixture (prefer generated or simplified Excel-created).
-- Add the fixture with:
-  - `meta.regression`: `{issueId, introducedInVersion?, fixedInVersion}`
-  - `expectedImport/Export` states for the failing and fixed behavior.
-- Promote to `release-gate` if the bug affected:
-  - Supported features,
-  - Preservation contracts,
-  - Any “Excel repair prompt” incident.
-
-### Source-baseline-neutral cases
-
-To avoid “Excel as fixture generator” bias, include **generated** fixtures constructed to satisfy OPC and minimum SpreadsheetML structure requirements. This is justified by the published minimum workbook scenario and package structure requirements.
-
-Required generated fixture types:
-- Minimal workbook (1 sheet).
-- Minimal workbook with sharedStrings and styles.
-- Relationships edge cases (but still valid).
-- Unknown-part injection (extra part + relationship) to test preservation.
-
-Generated fixtures should be built by your own fixture generator (Node or small .NET tool) so your corpus can evolve without relying on proprietary UI actions.
-
-### Automated validation program
-
-Implement a single CLI runner that executes:
-
-1) **Import**: parse OPC package, build internal “package manifest” (list parts, relationships, content types).
-2) **Normalize**: canonicalize ZIP and XML for comparison where allowed.
-3) **Scenario program** (optional per fixture): execute a bounded edit script (no direct mutation; this is your command/transaction system under test).
-4) **Export**: write `.xlsx`.
-5) **Validate**:
-   - OPC lint: graph integrity, naming conventions, required parts.
-   - SpreadsheetML structure checks: workbook/sheets/worksheet parts, required relationships.
-   - Preservation checks:
-     - Unknown parts: payload hash equality against `part-hashes.json`.
-     - Relationship triples preserved.
-   - Optional: Open XML SDK validator lane (matrix by Office version enum; include `Microsoft365` at minimum).
-
-**Outputs**:
-- `reports/<runId>/fixture-results.json` with per-fixture pass/fail, warnings, diffs, and hashes.
-- `reports/<runId>/exported/<fixtureId>.xlsx` for manual Excel certification.
-
-### Manual Excel certification program
-
-A release candidate cannot ship until the following is complete:
-
-**Host matrix (minimum bar)**
-- `excel-desktop-win-m365`
-- `excel-desktop-mac-m365`
-- `excel-web`
-
-Rationale: Microsoft’s published Open XML format guidance targets Microsoft 365 and recent Excel releases, and Excel web is explicitly a core product surface.
-
-**Manual procedure per release-gate fixture**
-- Open exported file.
-- Confirm:
-  - No “Repair” prompt (and no repair log generated).
-  - Worksheet count and names match expected.
-  - Key audit cells match expected values and formats (from `audit.xlsx.json`).
-  - For preserve-only features: confirm feature still exists when viewed in Excel (e.g., pivot table present; chart renders; threaded comments visible).
-- Save-as (same format `.xlsx`) and re-open:
-  - Confirm no repair prompt.
-  - Compare the re-saved file to expected “Excel-normalized” tolerances (you will need separate expectations because Excel can reserialize). This prevents “passes on open but breaks on save,” which is a common hidden failure mode.
-
-**Certification artifacts**
-- Store results in `reports/cert/<releaseVersion>/host/<hostId>/…`
-- Include screenshots or logs of any failures.
-- Promote any discovered failure into a regression fixture.
-
-## Sources
-
-ECMA-376 standard landing page (parts and editions; downloads).
-
-Open Packaging Conventions overview and requirements (content types stream, relationships-based discovery, relationship parts).
-
-SpreadsheetML structure and minimum workbook scenario; key parts (workbook, worksheets, shared strings, calc chain, pivot parts, conditional formatting, formulas).
-
-Microsoft Open XML SDK documentation for spreadsheet creation and part model (SpreadsheetDocument, WorkbookPart, WorksheetPart).
-
-OpenXmlValidator API surface and version targeting; Open XML file format version enum (Office2007…Microsoft365).
-
-Evidence and risk that validator success ≠ Excel success (Excel repair despite validation).
-
-Microsoft Excel `.xlsx` extensions and compatibility mechanisms (`extLst`, `mc:Ignorable` usage requirements) and explicit part definitions (threaded comments part and requirements; slicer cache part requirements; legacy comment placeholder behavior).
-
-Microsoft Support: Open XML formats applicability across recent Excel products; Excel workbook limits (rows/cols, cell character limits, unique formats).
-
-Google Sheets export capability to `.xlsx` (official Google Docs Editors Help). and Microsoft Support guidance referencing Google Sheets “Download → Microsoft Excel (.xlsx)”.
-
-LibreOffice ability to load/save `.xlsx` and warning about conversion limitations (official LibreOffice help + documentation).