0.8.0

v0.8.0 — Phase 7.5 Acrobat parity close

Cuts the Phase 7.5 milestone: full Bucket B (B2 Compare Files / B6 Compress /
B8 Password Encryption / B9 Action Wizard / B14 Spell Check / B18 Font Swap /
B20 Sanitize / B21 Document Properties Security) + full Bucket C (C1 Read
Aloud / C2 Preflight / C3 Tag PDF / C4 Reading Order / C5 Alt Text / C6
Accessibility Checker / Export Report) Acrobat parity work.

- Principal-authorized minor bump 0.7.20 -> 0.8.0 ("do all" ruling 2026-06-17).
- Phase 7.5 marked SHIPPED in docs/project-roadmap.md (Nathan Wave 12 c5f3d66).
- Ships bundled qpdf 11.9.1 (Apache-2.0; ~7.5 MB Windows) for B8/B21.
- All seven L-001..L-007 locks held at the moment of commit.
- Julian's Wave 11 §7.1 sign-off: YELLOW -> effectively GREEN-with-one-honest-follow-up
  (11.1 HIGH R12 Acrobat-fixture regression test is defer-to-post-v0.8.0;
  see docs/build-report.md v0.8.0 row "Known follow-ups" stanza).

Build-report row: docs/build-report.md (2026-06-22 v0.8.0 cut section).
Hard-Won Playbook recurrence: 9th of the post-wave release-ceremony rule.

0.7.20

v0.7.20

chore(release): v0.7.20 — Phase 7.2 (Ubuntu CI unblock + dev-mode SQL…

0.7.19

v0.7.19 - Phase 7.1: real-PDF e2e OCR integration test

Closes the v0.7.13->v0.7.18 OCR-chain arc with a real-PDF end-to-end
integration test that catches 5 of 6 historical bugs at the e2e tier.

Highlights:
- __test:seedOcrJob test-only IPC channel (structural NODE_ENV gate; absent from prod IPC surface)
- Deterministic fixture PDFs (scan-1p-eng, scan-2p-eng) with CI hash-verify gate
- Playwright Electron e2e spec exercising rasterize->tesseract->overlay->persist
- Catch-coverage walk: each prior v0.7.x bug maps to a specific assertion
- Sub-5s fixture-hash CI gate catches fixture substitution BEFORE the 3-4m Tesseract round-trip

Wave 1: Riley (design + catch-coverage walk)
Wave 2: David (IPC channel 4f272e8) + Diego (fixtures + spec + CI 67c74c5, b61f516, 85b0325)
Wave 3: Julian (GO-with-follow-up; finding 7.1.5 -> Phase 7.2 dev-mode SQLite bundling)
Wave 4: Nathan (developer-guide section a26ac2b)
Release: Diego (this tag, post-wave handoff seam)

0.7.18

v0.7.18

chore(learnings): Phase 5.2 wave entries (Marcus + Diego)

0.7.17

v0.7.17

chore(release): v0.7.17 - OCR overlay mount + applyEdit dispatch + do…

0.7.16

chore(release): v0.7.16 - tesseract.js v7 output shape fix

Wraps 446499a (the tesseract.js v7 adapt) into a release bump.

v0.7.14 fixed OCR cold-start Path2D ordering, v0.7.15 fixed OCR
pdf.js buffer detach, v0.7.16 fixes the next downstream OCR defect:
tesseract.js v7 dropped r.data.words and r.data.imageWidth/Height
from the top-level recognize output. Word data is now nested under
r.data.blocks[].paragraphs[].lines[].words[], opted in via
recognize(..., ..., { blocks: true }). PNG dims are read directly
from the rasterizer's input bytes via the IHDR header.

4 new unit tests pin the PNG-dim reader; 1900/1900 vitest tests
green on Node 24 via the L-003 escape hatch (+4 vs v0.7.15's 1896).
Typecheck + lint clean.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

0.7.15

chore(release): v0.7.15 - OCR pdf.js buffer-detach fix

Single-fix release on top of v0.7.14. Bumps version from 0.7.14 to 0.7.15.

Carries one functional commit (4c7033e):

  fix(ocr): copy bytes before handing to pdf.js to prevent buffer detach

  rasterizePageProd passed documentStore.get(handle).bytes directly to
  pdfjs.getDocument({ data }). pdf.js v4's legacy build ships the buffer
  via postMessage to the fake worker with transferList -- detaching the
  underlying ArrayBuffer. After rasterize returned, the document-store's
  Uint8Array view went to length 0, so the OCR composer's
  PDFDocument.load(originalBytes) saw an empty buffer and threw
  "Failed to parse PDF document (line:0 col:0 offset=0): No PDF header
  found" -- surfaced as "unexpected: ..." in the renderer toast.

  Mirrors the existing discipline in src/main/export/pdfjs-source.ts:475
  (`spec.sourceBytes.slice()` with the same inline comment naming the
  exact problem). The OCR path was the parallel implementation that
  missed the same fix. Same lesson as v0.7.14's Path2D ordering --
  src/main/export/ had the answer for months; src/main/pdf-ops/ keeps
  drifting because nobody mirrors it.

Pre-flight on this Node 24 host via L-003 escape hatch:
- node scripts/rebuild-native-for-node.mjs -> cached
  99329f-better-sqlite3-v12.9.0-node-v137-win32-x64.tar.gz prebuild.
- npm run typecheck: clean across main + preload + renderer.
- npm run lint (--max-warnings 0): clean.
- npx vitest run (full suite): 1896 passed / 1896 total / 0 failed
  across 177 test files in 25.46s. +1 test vs v0.7.14 (the new
  "preserves documentStore bytes across rasterize" regression).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

0.7.14

chore(release): v0.7.14 - OCR cold-start Path2D ordering fix

99b25b8 reorders tryLoadCanvas() to run BEFORE the dynamic
pdfjs-dist import in loadPdfJs(). v0.7.10..v0.7.13 all installed
canvas globals (Image, Path2D, ImageData, DOMMatrix) on
globalThis, but the install ran AFTER pdf.js's legacy module
was eval'd -- so pdf.js captured a missing Path2D at load
time and built its internal Path polyfill, which
@napi-rs/canvas's native ctx.fill() then rejected with
"Value is none of these types `String`, `Path`," at
paintChar -> showText.

The 2026-06-04 diagnostic log from a real user
(ocr-rasterize-1780572483000.json) confirmed
hasGlobalPath2D=function at failure time -- proving the
ordering, not the install, was the bug.

Tests reordered (ocr-bootstrap.prod-render.test.ts) so the
rasterize-real-PDF cold-start case runs first and can't be
masked again by an earlier explicit tryLoadCanvas() call.

Pre-flight on main: typecheck clean, lint clean, full vitest
suite 1895/1895 green (Node-24 escape hatch via
scripts/rebuild-native-for-node.mjs per L-003).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

0.7.13

v0.7.13

chore(release): v0.7.13 - file-association argv + OCR diagnostic logs…

0.7.12

v0.7.12

chore(release): v0.7.12 - OCR rasterize fix (@napi-rs/canvas globals)…