Report renderer drops pandoc and converts in process (LLP 0208)

[bgmcmullen]

What

Replaces pandocPage in src/core/reports/render.js with in-process conversion via marked (pinned exact, zero transitive dependencies), and exports the renderer as hypaware/core/reports so the server can share it. Everything else in the renderer is untouched: href rewriting, asset install, masthead, discovery, landing page.

Supersedes LLP 0196 open question 1's keep-pandoc resolution through the escape hatch that resolution named for itself: the only pandoc property the component vocabulary relies on is gfm passing raw HTML through untouched, "so in-process rendering stays available if the dependency ever becomes a problem." LLP 0208 (new in this PR) records the decision.

Why now

The HypAware server generates reports server-side (hypaware-server LLP 0108/0112) and reuses this renderer rather than growing a second one (hypaware-server LLP 0110). On that surface pandoc's costs bite twice:

• it would be the server daemon's first non-npm binary dependency, on a runtime with a deliberate minimal-dependency posture, and
• execFileSync blocks the single thread every customer org shares, measured at ~40ms per page (~1.1s frozen for a 27-page report).

Evidence the swap is safe

• Measured before written: all 94 markdown files of a real reports tree converted under both engines; 66 structurally identical, 28 differing only in pandoc's syntax-highlighting markup, 0 genuine differences. Component blocks survive byte-for-byte; fenced ready-to-apply artifacts stay verbatim with their language-* class; tables and links match exactly.
• After the swap: the same tree renders to 94 pages with zero structural diffs against the pandoc reference, and the style-before-theme link order holds on every page (LLP 0196#theme-layer).
• A renderer override reproduces pandoc's heading ids (-1 suffixes on repeats included) so existing in-page anchors keep resolving.
• 3892 tests pass, and the render tests lose their skip guard: a renderer with no external dependency runs everywhere, so CI drops its apt-get install pandoc step and the previously-skipping suites now always run.

Visible change

Syntax highlighting in code blocks, light mode only: pandoc emitted per-token spans, marked emits plain <pre><code class="language-*">. The stylesheet's only token rules sit in its dark-mode block and flattened pandoc's spans to one colour anyway. The language-* class survives, so colour can return as a stylesheet choice later.

Also in this PR

• "./core/reports" added to the package exports map (the server-side consumer imports through it).
• CLI: the hyp report render pandoc preflight and help text go; the report skill's Render stage loses the prerequisite in both trees.
• LLP 0196 gains a Superseded-by forward-note on open question 1.

Downstream consumer already landed against this branch: hypaware-server feat/server-side-report-generation (its LLP 0110/0112/0113 document the shared-renderer decision and the live verification, including a real end-to-end generated report rendered by this code).

🤖 Generated with Claude Code

[philcunliffe]

Review round 1 - head cc489bb (adopted PR)

Verdict: request changes (all eight fixed in fb48bfa). The direction is right and the dependency claim holds, but the equivalence claim did not: an A/B of real pandoc 3.1.11 (-f gfm -t html5) against the PR's exact marked config over 36 constructs found two genuine user-visible regressions, one of which broke the very thing the PR added code to preserve. This PR carries neutral:adopt, so the fixes were pushed to this branch.

Gates at cc489bb: npm test 3906 pass / 0 fail, npm run typecheck clean, npm pack --dry-run clean.

blocker 1 - heading ids diverged from pandoc's, so in-page anchors dangled

render.js:176-183. headingId was fed this.parser.parseInline(tokens), which is already HTML-escaped: & arrives as &, ' as '. The [^\w\s-] strip then left the entity letters in the slug. Separately .replace(/\s+/g, '-') collapsed whitespace runs where pandoc maps each space to one hyphen.

End-to-end this produced <h2 id="what39s-next"> while an authored [link](#whats-next) pointed at nothing - exactly the failure the doc comment at render.js:170-172 says the override exists to prevent, with the in-page-anchor convention in active use at reviewing.md:247.

Fixed with a unescapeHtml step and a Unicode-aware slug, where each step's position is load-bearing: strip tags before unescaping (so a decoded < is not eaten by the tag regex), collapse whitespace before punctuation removal (so Cost & Usage still yields pandoc's double hyphen), and hyphenate per-space not per-run. Measured against a real pandoc binary end-to-end through renderReports: pre-fix 14/24, post-fix 24/24, including Café résumé (was caf-rsum), 日本語 heading (was heading), Emoji 🚀 heading, and repeat-heading -1 suffixing.

A correction to the review's own table: the HYP_CENTRAL fleet row diverges only when the dash is non-ASCII. With an ASCII hyphen pandoc emits three hyphens and both old and new code already matched. The original finding's example had been flattened to an ASCII hyphen when it was written up (this repo forbids em dashes in prose), which changed the case it was demonstrating. The underlying defect was real; that one row was not.

blocker 2 - table column alignment was silently lost

render.js:198-209. marked emits align="right" (marked.esm.js:75, not configurable); pandoc emitted style="text-align: right;". assets/style.css:145-149 sets th, td { text-align: left }, and align= is a presentational hint that CSS Cascade ranks below author rules, so pandoc's inline style won where marked's attribute loses. Every right-aligned numeric and centred column rendered left-aligned - in a stylesheet that sets font-variant-numeric: tabular-nums on non-first columns, that is a real degradation.

Fixed with a tablecell override, verified byte-identical to pandoc across all four alignments including the bare unaligned cell.

major 3 - the tests pinned nothing about the conversion

test/core/report-render.test.js was unchanged apart from removing five { skip } guards. The fixture had only ASCII # headings, bold paragraphs and links: no table, no code fence, no component block, no heading with & or ', no in-page anchor. Neither blocker would have failed a single test.

Fixed with a vocabulary fixture and two tests: one asserting the component block survives byte-for-byte (including indentation), the exact aligned-table <thead> block, doesNotMatch /<t[hd] align=/, the exact language-sql code block and four heading ids; and one extracting every href="#..." and asserting a matching id="..." exists. Proven to fail pre-fix: "table headers must carry pandoc's inline text-align" and index.html links to ids it does not define: whats-next,opus-output-tokens--mo.

major 4 - src/core/reports/README.md was stale and ships in the package

npm pack --dry-run confirms it publishes. It still described head.html as "inlined by pandoc's -H" and stated "pandoc is still a hard dependency (LLP 0196 open question 1, resolved: keep it, install it in CI)". Fixed; the only remaining mentions are the LLP filename and the historical note.

minor 5, 6, 7, 8

• Footnotes silently stop rendering - pandoc's gfm has footnotes on by default, marked does not implement them, so [^1] now appears as body text. Exposure is low (no skill doc uses them). Documented in LLP 0208 ## Consequences rather than adding an extension.
• Task lists lost their list-style suppression - pandoc's template injected ul.task-list{list-style:none}; marked emits no task-list class, so checkbox lists rendered with a bullet and a checkbox. Fixed with a :has() rule matching on content, plus a note in 0208.
• LLP 0208 overstated the measurement ("tables and links match exactly" was false for tables; "reproduces pandoc's heading ids" was false as shipped). Narrowed to what is true, with a note that a structural comparison is exactly what rates align="right" as equal.
• LLP 0196 had no header-level forward-ref. The inline **Superseded-by: LLP 0208** was correctly placed and compliant, but a reader of the header got no pointer. Fixed with **Superseded-in-part-by:** LLP 0208, settled text untouched.

Verified clean

• LLP 0196's edit is permitted. It is Status: Accepted, and the edit adds a forward-ref above the settled text without altering the "keep pandoc" resolution - which CLAUDE.md explicitly sanctions.
• Dependency claim holds:marked@18.0.9 has no dependencies, peerDependencies or optionalDependencies, MIT, ESM, pinned exact under dependencies - correct for a package that ships.
• The new export works:await import('hypaware/core/reports') resolves from a scratch consumer, npm run build:types emits real signatures (no any), and the type-import specifier follows the repo-root-anchored convention.
• CI change is safe: pandoc appeared exactly once in ci.yml and nowhere else in the tree; the render tests now always run rather than skipping, which is strictly more coverage.
• Sanitization is unchanged, not improved and not degraded. Both engines pass raw HTML through untouched including <script>. Report Markdown is model-authored, so anything it emits becomes live HTML in the rendered page - a real exposure, but identical to what shipped before, so not a regression this PR introduces.
• Everything else in the renderer is genuinely untouched (rewriteHrefs, installAssets, masthead, discovery, THEME_STUB, landing page are byte-identical), and the head-ordering that LLP 0196 #theme-layer requires is preserved.
• Cosmetic divergences confirmed harmless: void-element spelling, "/' escaping, entity preservation, whitespace placement, <tr class="odd|even"> (nothing selects them), pandoc's sourceCode wrapper, and the light-mode highlighting loss that 0208 states accurately.

The head moved to fb48bfa, so the next tick reviews it as round 2.

[philcunliffe]

Review round 2 - head fb48bfa (adopted PR)

Verdict: approve. All eight round-1 findings are genuinely fixed, re-verified against a real pandoc 3.1.11 binary over 89 headings end-to-end through renderReports rather than by unit-testing the helper. Four residual items, none blocking; all four fixed in 05c8f54. Gates at fb48bfa: npm test 3908 pass / 0 fail, typecheck clean, npm pack --dry-run clean, and types/core/reports/render.d.ts ships so import('hypaware/core/reports') resolves from a scratch consumer with all seven named exports.

Round-1 fixes, independently re-verified

Heading ids are at parity for &, ', ", /, %, #, $, |, ~, ^, @, inline code, inline HTML, emphasis, links-in-headings, Café résumé (precomposed), 日本語, Cyrillic, Greek, Thai, emoji-in-text, leading/trailing and multiple inner spaces, tabs, under_score, leading/trailing hyphens, and -1/-2 repeat suffixing. The three order-of-operations risks all hold: strip-before-unescape does not resurrect a <; an author-written & does not double-decode; collapse-before-punctuation reproduces pandoc's double hyphen. On the disputed dash row from round 1: both directions confirmed - ASCII hyphen, en dash, em dash, non-breaking hyphen and minus all match. The round-1 correction was right.

Table alignment is byte-identical to pandoc for all four alignments and the unaligned case, in both <th> and <td>, with <thead>/<tbody> intact. The only remaining diffs are pandoc's <tr class="header|odd|even"> and whitespace, and style.css selects none of those classes.

The tests discriminate independently. Reverting render.js wholesale fails both new tests; reverting onlyheadingId still fails them ("an \&` heading keeps pandoc's double hyphen"`), so the heading assertions stand on their own rather than riding on the table assertion.

Findings (all fixed in 05c8f54)

A. minor - heading ids dropped combining marks, mangling Indic and decomposed text. The retained class [^\p{L}\p{N}_\s-] stripped \p{M}, while pandoc keeps combining marks and NFC-normalizes first. Measured: decomposed Café résumé gave cafe-resume vs pandoc's café-résumé; Turkish İstanbul dropped U+0307; and Devanagari was outright mangled. Unconditional for Indic, Thai-with-tone-marks, Arabic/Hebrew vowels and Vietnamese. The code comment justified the class by claiming pandoc keeps Café résumé intact - true only of the precomposed spelling of its own example.
Fixed with .normalize('NFC') before lowercasing and \p{M} added to the retained class, pandoc-verified on all three rows, comment corrected.

B. minor - unescapeHtml covered only the five entities marked emits, so author-written entities leaked their letters into slugs.## What’s next plus an authored [link](#whats-next) dangled silently - the round-1 blocker's exact symptom with a narrower trigger. Also —,  , ×, ', '.
Fixed with a general decoder: numeric (&#\d+;, &#x...;) plus a bounded WHATWG-sourced named table (~260 entries), stored as codepoints so no decoded character appears as a literal in source. No new dependency, which matters here since marked was chosen precisely for having zero transitive deps.

Two things the fix worker got right by measuring rather than following instructions. First, it declined the "case-insensitive" suggestion in the brief: real pandoc decodes & (a genuine legacy dual-case alias) but not— or ’, and case-folding would wrongly collide Α/α. Exact-case matching against a table including the legacy uppercase aliases reproduces pandoc including the negative cases. Second, the fix surfaced a latent ordering bug: whitespace-collapse had to move before entity decoding, or a decoded   merges with adjacent real spaces into one hyphen instead of pandoc's one-per-token.

C. minor - the :has() rule missed loose task lists.:has() support itself is fine (the sheet already uses color-mix() and text-wrap: pretty, both with a later baseline). But marked emits <li><p><input ...> for a blank-line-separated checklist, so ul:has(> li > input) did not match and those lists still rendered bullet and checkbox.
Fixed to match both shapes, with LLP 0208's bullet corrected to name them. The worker also took the cosmetic option, restoring pandoc's own indent handling (negative margin rather than padding-left: 0, using pandoc's generated values) so task lists no longer un-indent relative to other lists.

D. nit - a heading reducing to nothing emitted id="" where pandoc emits no id.
Fixed: the attribute is omitted when the slug is empty, while a later duplicate still gets pandoc's own -1 de-dup suffix, with a comment explaining why an unauthorable anchor is still worth disambiguating.

Tests: five new tests pin each fix (combining marks, the general entity table, ’ with an authored in-page link, empty id, and loose-task-list markup plus the CSS selector), each verified to fail against the pre-fix code.

Gate

At 05c8f54: npm test 3913 pass / 0 fail, typecheck clean, npm pack --dry-run 900 files, llp-ref-hygiene 11/11.

The head moved to 05c8f54, so this PR has used its two review rounds and the next tick triages it.

[philcunliffe]

Stuck at triage: a blocker neutral introduced, past its review-round budget

What neutral was doing. PR #705 (adopted) replaces pandoc with in-process marked. It went through two review rounds: round 1 found 8 findings including two blockers, round 2 approved with 4 residual items. Neutral pushed fixes for all of them. With the 2-round budget spent, triage re-checks whether the PR can ship safely (LLP 0017).

Why it cannot proceed. Triage found a true blocker at the current head 05c8f54, and it was introduced by neutral's own round-2 fix, not by the original contribution.

The blocker: a heading with an out-of-range numeric character reference crashes the entire render

A heading like ## A � B (or decimal � through �) makes renderReports throw RangeError: Invalid code point 1114112.

• Cause:unescapeHtml at src/core/reports/render.js:236 calls String.fromCodePoint(codePoint) behind only a Number.isFinite guard. Codepoints above 0x10FFFF throw. The reachable window is exactly what marked's escaper passes through untouched (up to 7 decimal / 6 hex digits), so every value in �-� and 1114112-9999999 reaches fromCodePoint.
• Not pre-existing: stock marked renders the same input fine (<h2>A &#x110000; B</h2>), and real pandoc 3.1.11 renders it fine too (id a--b). The general entity decoder added in 05c8f54 is what introduced it. Only headings trigger it; the same entity in body text passes through literally.
• The impact is worse than a crash.renderReports wipes html/ before building and builds in sorted slug order, so one bad heading in one report crashes the run after destroying the already-built pages of every report that sorts at or after it, leaving the landing page stale. One malformed entity breaks the whole rendered site until someone hand-edits the markdown - where the pandoc pipeline this PR replaces rendered it without complaint.

That is a crash plus destruction of build output on author-controllable input, which is a production defect under LLP 0017 rather than a preference. Reports here are model-authored, so the input is not fully under a human's control.

The fix is small and known: guard codePoint <= 0x10FFFF. Pandoc effectively substitutes U+FFFD, which its slug then strips, minting a--b; returning the entity unchanged would also avoid the crash but diverge on the slug. Lone surrogates (�) are already fine - fromCodePoint accepts them and the /u strip removes them, matching pandoc.

A second, non-blocking divergence that should ride the same fix

headingId runs .trim()after punctuation-stripping; pandoc does not trim at that stage. Any heading starting or ending with stripped punctuation adjacent to a space mints a different id. Pandoc-verified: 🚀 Rollout plan gives pandoc -rollout-plan vs this renderer rollout-plan; ✅ Done items gives -done-items vs done-items; end & gives end- vs end. Emoji-led headings are common in model-authored reports, so a pandoc-era authored anchor (#-rollout-plan) now dangles silently. This contradicts LLP 0208's "existing in-page anchors keep resolving" claim. Minor alone, but a genuine divergence worth fixing or documenting in the same pass.

What neutral needs from you

The PR has used both of its review rounds (LLP 0059), so neutral will not keep iterating on its own - that cap exists to stop unbounded self-directed churn. Your call, and either is one comment:

1. Grant more rounds - reply neutral: rounds +1 and neutral will apply the 0x10FFFF guard plus a regression test, decide the trim divergence, and re-review.
2. Take it yourself - the fix is a one-line guard at render.js:236 plus a test; the trim question is the only real judgement call.
3. Ship without it - if you consider a malformed numeric entity in a heading out of scope for this repo's reports, say so and neutral will record that in LLP 0208's Consequences and mark the PR triaged.

What is verified good at this head

Everything else checks out, independently re-derived against a real pandoc 3.1.11 binary rather than from the earlier rounds' tables: 35 of 36 heading-id cases at parity (the one miss is the trim case above), including combining marks, Devanagari, Turkish dotted capital I in both spellings, ’/—/ /×/'/', & decoding while —/’ correctly do not, Α vs α staying distinct, the whitespace-before-decode ordering, emoji-only headings omitting the id, and unterminated &amp / &#; / &foobar; all handled. Table alignment is byte-identical to pandoc for all four alignments; a multi-line component block with nested raw HTML and entities survives byte-for-byte. Gates: npm test 3913 pass / 0 fail, typecheck clean, npm pack --dry-run clean, llp-ref-hygiene 11/11. LLP 0208's recorded consequences are accurate except the anchors claim the trim finding falsifies.

How to unstick: reply with a comment on this PR (or push to the branch). Neutral monitors this thread and will re-engage with your guidance on its next tick.

[philcunliffe]

neutral: rounds +2 — granted by U099BSGPZU4 via Slack

[philcunliffe]

add 2 more rounds

— relayed from Slack

[philcunliffe]

Re-engaging with your guidance - two extra review rounds granted, so neutral will guard the String.fromCodePoint call at render.js:236 against codepoints above 0x10FFFF, add a regression test, decide the headingId trim divergence from pandoc (emoji- and punctuation-edged headings currently mint a different id), and re-review.

[philcunliffe]

Review round 3 - head 05c8f54 (adopted PR, on the maintainer's granted budget)

Verdict: the blocker is fixed, and so is the trim divergence. Both are resolved in 606e70a. This round exists because the maintainer replied neutral: rounds +2 to the stuck report - neutral had spent its budget on a bug it introduced itself and stopped rather than iterating on unchanged authorization.

The blocker, reproduced before being fixed

Built a three-report tree (aaa-good, mmm-bad, zzz-good), rendered clean, then changed only the middle report's heading to ## A � B:

pass1 html/: .nojekyll, aaa-good, mmm-bad, zzz-good
pass2 THREW: RangeError: Invalid code point 1114112
after-crash html/: .nojekyll, aaa-good, mmm-bad
aaa-good/index.html exists: true
mmm-bad/index.html exists: false
zzz-good/index.html exists: false
landing still has pass1 marker (stale): true

That is the blast radius the triage predicted, confirmed rather than argued: html/ is wiped up front, so the crash at mmm-bad took that report and everything sorting after it with it, leaving the landing page advertising a build that no longer exists. The reachable window was confirmed empirically too - marked passes �-� and �-� through untouched, escaping the & only at 8+ decimal / 7+ hex digits.

What pandoc actually does was measured, not assumed:pandoc 3.1.11 -f gfm -t html5 on that input emits <h2 id="a--b">A ? B</h2>, and a codepoint dump confirms the substituted character is literally fffd. So pandoc substitutes U+FFFD and its slug strips it. Returning the entity unchanged would have minted a-x110000-b and diverged, so the fix substitutes U+FFFD to match. Also measured: � and � likewise become U+FFFD in pandoc and already matched via the existing path, so lone surrogates stay untouched;  and  are real codepoints and still decode.

The trim divergence: matched pandoc rather than documented

The .trim() after punctuation-stripping is gone. The decisive evidence was the all-whitespace case, the one place a trim could plausibly have been right: pandoc mints id="-" for ## ( ), ## 🚀 ✅ and ##  , not a missing id. Only a heading reducing to the genuinely empty string (## 🚀, ## ..., ## &) goes without an id, and that survives dropping the trim. Pandoc's de-dup counters over those degenerate bases (- / --1, no-id / -1, -plan / -plan-1) were verified separately and the renderer now reproduces all eight identically.

This makes LLP 0208's "existing in-page anchors keep resolving" claim true rather than needing an exception, so no doc edit was required.

Parity: 22/41 before, 41/41 after

heading	pandoc	pre-fix	post-fix
## A � B	a--b	THREW	a--b
## A � B	a--b	THREW	a--b
## A�B	ab	THREW	ab
## �	(no id)	THREW	(no id)
## A � B	a--b	a--b	a--b
## 🚀 Rollout plan	-rollout-plan	rollout-plan	-rollout-plan
## ✅ Done items	-done-items	done-items	-done-items
## end &	end-	end	end-
## & start	-start	start	-start
## Hello  	hello--	hello	hello--
## ( )	-	(no id)	-
## *emph* &	emph-	emph	emph-
## Hello	hello	hello	hello
## Cost & Usage	cost--usage	cost--usage	cost--usage

Seven of the nineteen pre-fix divergences were crashes; twelve were wrong ids. The last rows are pre-existing contracts, confirmed unregressed. The fix worker found two divergences beyond the briefed table - ## Hello   and inline markup followed by stripped punctuation (## *emph* &, ## `code` &) - same root cause, same fix.

Tests

Three new tests, each verified to fail pre-fix for the right reason: the out-of-range test with RangeError: Invalid code point 1114112 at render.js:236:50, the trim test with an emoji-led heading keeps pandoc's leading hyphen, and a blast-radius test that renders clean, then adds both a bad heading to the middle report and a brand-new report after it, asserting all four pages exist and the landing page lists the new one (a stale landing page would not). That last one pins the amplifying factor, not just the crash.

Gate

npm test 3916 pass / 0 fail, typecheck clean, npm pack --dry-run clean, llp-ref-hygiene 11/11.

The head moved to 606e70a, so the next tick reviews it as round 4 on the granted budget.

[philcunliffe]

Review round 4 - head 606e70a (adopted PR, last of the granted budget)

Verdict: no blocker. Both round-3 fixes verified correct. Six residual findings, four fixed in 3c6876e and two deliberately skipped with measurement behind the decision.

Round-3 fixes, independently verified against real pandoc 3.1.11

• The crash class is closed. Pre-fix threw RangeError on 6 cases; this head throws on none. A 4000-iteration fuzz over adversarial entity atoms (&#;, &#x;, &#-1;, 18-digit decimals, lone surrogates, �, U+2028, bare </>/&) produced no crash.
• U+FFFD is the right substitution: pandoc emits literal U+FFFD; this head emits the entity verbatim into body text, which the HTML5 parser maps to U+FFFD - same glyph, same id. �, �, � all route the same way and match.
• Dropping .trim() broke nothing: 16/16 on probes the parity table would have missed (leading/trailing tabs, double trailing spaces, NBSP-padded headings, headings ending in a decoded whitespace entity). No previously-correct id changed.
• The blast-radius test was tested adversarially: restoring only the crash makes it fail, and so does a containment-only "fix" that swallows the error (mmm-bad must survive the bad heading). It defeats both the crash and the cheat.

A measurement correction worth recording: the first aggregate run reported 74/93, but running one heading per document gives 79/84. A dedup-counter drift in one case was cascading into the next and misreporting parity. All numbers here are from isolated runs.

Findings

1. minor - uppercase &#X...; never decoded. Fixed. The alternative was #x[0-9a-fA-F]+, lowercase only, so the existing body[1] === 'X' guard was unreachable while marked's escaper passes the uppercase form through. ## A A B gave pandoc a-a-b vs a-x41-b. Now #[xX][0-9a-fA-F]+. This also fixed a false claim in the round-3 comment: � was in the reachable window and leaked its digits, the exact outcome that comment said could not happen.

2. minor - ' missing from NAMED_ENTITIES. Fixed, and the whole class closed.## What's next gave pandoc whats-next vs whataposs-next - silent, since the visible heading rendered ' correctly while the anchor carried apos. The fix worker added all 27 ASCII-punctuation names rather than just apos, verifying each individually against pandoc first: all 27 diverged pre-fix, all 27 match now. Two would have been easy to get wrong by assumption - 	/
 decode to whitespace and mint a hyphen each, and _ decodes to _, which the retained class keeps.

3. minor - <br> dropped where pandoc yields a space. Fixed, and the fix was subtler than the finding.## Line one<br/>Line two gave line-oneline-two vs pandoc's line-one-line-two.

Substituting <br> with a space before the tag strip was not sufficient: pandoc counts that space as its own token, so ## A <br /> B is a---b, and a naive substitution before the \s+ collapse merges it to a-b. The correct order is collapse, then <br>-to-space, then tag strip - a reorder that is load-bearing, and which incidentally fixed three more measured divergences where pandoc likewise counts a tag's inner whitespace as its own token (A <span> </span> B, Title <span class="badge"> new </span>, A <!-- c --> B).

Two details the finding did not state, both found by measurement: the match must be case-sensitive (pandoc treats <BR> as raw inline HTML contributing nothing, so ## A <BR> B is a--b), and the regex must be <br(?:\s[^>]*)?\/?> rather than <br[^>]*> so it does not swallow <brand>. The three cases round 4 warned against generalising over (<span>tagged</span> text, <span>a</span>b, A<em>B</em>C) are pinned in the test and still match.

4. nit - JS \s matches three separators pandoc drops. Skipped deliberately, and correctly. Measurement showed this is not the one-liner it looks like: the literal-authored U+2028/U+2029 spellings break upstream in marked's block parser (no heading is emitted at all), and literal U+FEFF diverges differently again. A class-level fix would close only the entity half and leave the literal half diverging, which is worse than a documented known gap on a final pass.

5. nit - image-only heading loses pandoc's alt-text id. Skipped deliberately. Measurement made it non-trivial: pandoc slugs alt text for Markdown images in all positions but emits no id for a raw-HTML <img alt="...">, which this renderer already matches. marked emits byte-identical HTML for both, so there is no string-level discriminator in headingId; a correct fix must discriminate on marked's token types in the heading renderer. That is a structural change, not a nit.

6. nit - LLP 0208's footnote consequence incomplete. Fixed. A single-token definition ([^1]: notes.md) is parsed as a link reference definition, so the definition line disappears and rewriteHrefs rewrites the accidental href. Both shapes verified before the wording was tightened.

Parity, one heading per document

case set	pre-fix	post-fix
round-4 finding cases (29)	17/29	25/29 (only the two skipped nits remain)
ASCII-punct named entities (27)	0/27	27/27
<br> and tag-whitespace (17)	5/17	17/17
broad prose regression sweep (46)	46/46	46/46, no regression

Each new test gives every heading distinct letters so no two share a base - otherwise the de-dup counter masks divergences, the exact aggregate-run trap noted above.

Gate

At 3c6876e: npm test 3919 pass / 0 fail, typecheck clean, npm pack --dry-run clean, llp-ref-hygiene 11/11.

Scoping note for the maintainer: every finding in this round pre-dated the round-3 commit, so none is a regression of the granted rounds. They are regressions relative to master, which shelled out to real pandoc, so each silently dangled the corresponding pandoc-era anchor. The granted +2 budget is now spent and the head moved to 3c6876e, so the next tick triages it.

[philcunliffe]

Triage at head 3c6876e (after round 4, granted budget spent)

Verdict: no true blocker; the PR is marked triaged. Every remaining divergence is preference or documented-gap class, filed as #709.

Independently re-derived, none of it taken from the earlier rounds' tables:

• Heading-id parity against a real pandoc 3.1.11 binary, one heading per document: 107/109. The sweep covered the round-4 fixes (uppercase &#X...;, all 27 ASCII-punctuation entity names at 27/27, the <br> family including attributes, self-closing, adjacent pairs, <BR>, and a <br>-only heading), the round-3 fixes (out-of-range numeric references at both boundaries: / decode while �/�/� substitute U+FFFD, lone surrogates, all the trim cases including ( ) minting -, and dedup counters over degenerate bases), and the earlier contracts (combining marks including decomposed spellings and Devanagari, ’/'/'/', & decoding while —/'/&TAB; correctly do not on either side, Cost & Usage, repeat -1/-2 suffixing, and tag-inner-whitespace tokens). Table alignment is byte-identical to pandoc for all four alignments in <th> and <td>; a component block with nested raw HTML and entities survives byte-for-byte modulo the documented href rewrite; a 500-document adversarial fuzz through renderReports produced no crash and no destroyed output.
• The 2 misses are one family, and the round-4 record has it backwards (Follow-up: deferred review findings from PR #705 #709 item 1): pandoc's stringify maps any raw inline tag with the case-sensitive prefix <br to a space, so ## A <brand> B mints pandoc a---b where this head mints a--b. The round-4 claim that the narrow regex exists "so it does not swallow <brand>" is the opposite of measured pandoc behaviour, and the headingId comment repeats it. Nit-class: the vocabulary never puts such a tag in a heading, nothing crashes, and the candidate fix is one character class, but the false rationale in the code comment should not outlive Follow-up: deferred review findings from PR #705 #709.
• Both round-4 deliberate skips verified as characterised and correctly non-blocking (Follow-up: deferred review findings from PR #705 #709 items 2 and 3): the U+2028/U+2029/U+FEFF entity forms diverge while their literal forms break upstream in marked's block parser, so a headingId fix closes only half; and marked emits byte-identical HTML for Markdown and raw-HTML images (measured), so alt-text ids need token-type discrimination, a structural change. Exposure for both rounds down to headings no report has written: the authoring vocabulary contains no images, and nobody hand-types separator entities.
• LLP 0208 gap (Follow-up: deferred review findings from PR #705 #709 item 4): the doc records footnotes, task lists, and highlighting, but the three heading-id known gaps above live only in this thread.

Gates at 3c6876e: npm test 3919 pass / 0 fail, npm run typecheck clean, npm pack --dry-run 900 files, llp-ref-hygiene 11/11.

The granted rounds +2 budget is spent and this triage closes it: ship-safe, with #709 as the follow-up record.