Claude Opus 4.8
aaa9a253ae
Some checks failed
CD / Deploy to Test (push) Blocked by required conditions
CD / Smoke tests against Test (push) Blocked by required conditions
CD / Promote to Int (push) Blocked by required conditions
CD / Build and push images (push) Failing after 27m51s
CI / Lint, typecheck, test (push) Successful in 3m11s
CI / Auth e2e pack (push) Successful in 4m0s
CI / Import/export fidelity gate (push) Failing after 36s
CI / Build container images (push) Has been skipped
Make the "structure-true best effort" fidelity contract (ADR 0009) an objective, pipeline-gated suite so "best effort" cannot erode silently. - New CI job "Import/export fidelity gate" (.gitea/workflows/ci.yml) runs the corpus suites against the pinned sidecar images the stages use (pandoc/core:3.6, gotenberg/gotenberg:8), started via docker run and reached over the host gateway. Small and separate so it stays well under five minutes; the suites self-skip in the main checks job (no sidecars). - Export fidelity: fixtures/export corpus + gen-export-fixtures.mjs + export.fidelity.test.ts — exports Markdown to docx/odt through the real pinned pandoc and reads it back, snapshotting the round trip so a writer drift (ours or a version bump) fails the gate. - PDF smoke: pdf.fidelity.test.ts renders a page through real Gotenberg and asserts the extracted text and a sane page count (pdf-parse, dev-only). - Fidelity contract doc: fixtures/README.md defines "corpus green = fidelity acceptable" and the fixture-first bug process; per-corpus READMEs updated. Because the snapshots are byte-exact and generated with the pinned tools, bumping a sidecar without regenerating shifts the output and fails the suite (AC3). The import corpus (#63) is folded into the same gate. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EwZ4jR4KFAPvpjWevfUGX1
42 lines
1.6 KiB
Markdown
42 lines
1.6 KiB
Markdown
# Export fixture corpus (issue #69, ADR 0009)
|
|
|
|
Source Markdown documents and the Markdown our export produces after a full
|
|
**export → re-read round trip** through the pinned pandoc. `export.fidelity.test.ts`
|
|
exports each source to `.docx`/`.odt` exactly as `ExportService` does
|
|
(`gfm → <ext>`, standalone), reads the document back (`<ext> → gfm`), and asserts
|
|
the result matches its snapshot — so a change in pandoc's office _writer_ (ours
|
|
or a version bump) surfaces as a snapshot diff to review, not a silent
|
|
regression. See [`../README.md`](../README.md) for the fidelity contract and the
|
|
fixture-first bug process.
|
|
|
|
## Files
|
|
|
|
For each source `<name>.md` and format `<ext>` (`docx`, `odt`):
|
|
|
|
- `<name>.md` — the source Markdown (the shape a page's cached Markdown has).
|
|
- `<name>.<ext>.expected.md` — the Markdown read back after exporting to `<ext>`.
|
|
|
|
`article` covers headings, **bold**/_italic_, a link, a nested bullet list, and
|
|
an ordered list. `formatting` covers strikethrough, inline code, a blockquote,
|
|
and a fenced code block.
|
|
|
|
## Fidelity notes (structure, not layout — ADR 0009)
|
|
|
|
The round-trip snapshots record genuine pinned-pandoc writer behaviour, not
|
|
bugs:
|
|
|
|
- **ODT loosens tight lists** (blank lines appear between items) where DOCX keeps
|
|
them tight.
|
|
- **ODT flattens a fenced code block** to a plain paragraph; DOCX preserves it as
|
|
code. Extend the corpus rather than chasing these.
|
|
|
|
## Regenerating
|
|
|
|
Generated with the **pinned** `pandoc/core:3.6` (the production sidecar) so the
|
|
snapshots match CI:
|
|
|
|
```sh
|
|
docker run --rm -p 3030:3030 pandoc/core:3.6 server
|
|
PANDOC_URL=http://localhost:3030 node scripts/gen-export-fixtures.mjs
|
|
```
|