[gvonnessi]

Closes #134.

§4.3.1 item 5 enumerated the causes of its post-rewrite mark re-sort — "relabeling an anchor id or a link href" — instead of stating the condition, and the enumeration was short. The same item rewrites an academic:theorem-ref/equation-ref/algorithm-ref target, which sits on a mark; and its walk relabels ids inside a mark's own content. The reference re-sorts every text node's marks unconditionally and so was already correct — but nothing in spec/ required it, so an implementer following the written text computes a different document ID.

Why it survived CI

Not because the divergence is hard to reach. It needs only two relabeled ids whose string order runs against their document order, and relabel-marks-resort-after-rewrite has been such a witness in the suite since before this change.

It survived because every pre-existing case that depends on the re-sort reorders through a link href — a cause the enumeration names, and which a selective implementation therefore handles. Measured by deleting the re-sort against main: exactly 2 of 380 checks fail, both [link, link]. The suite had no witness for an unrecognized cause.

The measured matrix

Six variants of the re-sort, each built as a real patch and run through check:conformance:

vector	A: two named causes	B: + *-ref	E: only if JCS moved	D: no dedup	F: skip inside mark content	N: digit-aware order
relabel-marks-resort-not-only-anchor-or-href	✗					✗
relabel-marks-resort-id-inside-mark-content	✗	✗				✗
relabel-marks-resort-two-ids-authored-order	✗
relabel-marks-resort-inside-mark-content-no-relabel	✗	✗	✗	✗	✗
relabel-marks-resort-inside-mark-content-permuted	✗	✗	✗	✗	✗

No single vector is individually indispensable — an earlier draft of the changelog claimed otherwise and the panel disproved it. Three groupings are: the two mark-content vectors jointly reach a position nothing else in the suite touches (verified across 220 vectors and all 164 .cdx archives — zero other hits), not-only/id-inside jointly catch the digit-aware comparator, and two-ids-authored-order is dominated outright and published for legibility, which the changelog says in those words.

The permuted twin carries an identical expectedCanonicalJcs and expectedId from different parts.content. That pair binds alpha-equivalence on a third-party implementation, which a single vector cannot express.

Also here

• Item 5's walk definition now states that the walk enters a mark's content, unlike item 4. That reach decides which ids receive canonical names and was stated nowhere, while item 4 primes the opposite reading one item earlier. Over-generalizing that premise is the recorded root cause of the reverted §4.3.1 item 4 and §4.3.2 item 2 are keyed on element shape, not position — and the obvious fix has a regression #121 PR 2.
• A test-canonicalize case pinning alpha-equivalence inside a mark's content — the one position where this rule is what makes two orderings agree. The same test in block content passes with the rule deleted, because item 3 already sorted there.
• A floor in canonicalize_oracle.py: a vector may pin no expectedId only if it is a reject vector. Otherwise every gate counted it as a pass with its id never compared (A vector with no expectedId is COUNTED AS A PASS, not skipped: "384/384 passed, 0 skipped" with the document ID never compared #137).

Review

Two /review-fix cycles. Cycle 1: six lenses, 11 verified findings. Cycle 2: three bounded lenses against a closed list, plus a dedicated claim sweep that enumerated 74 clauses, decided 69 by a command it ran, and falsified 8. A third panel was refused by the review-cycle guard — correctly, since the delivered code was byte-identical to what cycle 2 reviewed — so the remaining prose was verified in place by measurement.

No finding in either cycle was a runtime-behaviour defect in shipped code. The reference was correct throughout. All eight falsifications were in prose written about it, every one an explanatory clause or a count hung off a true statement — two of them introduced by the fix for the previous one. Item 5's addition went from ~120 words to ~45; everything cut was either false or explanation.

Notes for the reviewer

• suiteVersion 0.2.5 → 0.2.6 (patch position: added cases, pre-1.0). 216 → 221 vectors, 164 fixtures, 380 → 385 checks. canonicalize.json is a pure insertion; no published expectation changes and no document ID moves.
• canonicalize.ts is comments only — verified by diffing the comment-stripped file against 8ce0b5d. (test-canonicalize.ts does add executable code.)
• A #121 PR-2-shaped mutant was applied and all 385 checks stay green, with a live positive control proving the mutant is not a no-op — so this PR publishes no expectation §4.3.1 item 4 and §4.3.2 item 2 are keyed on element shape, not position — and the obvious fix has a regression #121's sequel must break.
• CI will be red on npm audit: a pre-existing fast-uri advisory, unrelated to this change, filed as CI: npm audit --audit-level=high red on four fast-uri advisories; the lockfile pins 3.1.5 while ajv permits 3.1.7 #135 with the actual cause (the lockfile pins 3.1.5 while ajv already permits ^3.0.1 and 3.1.7 is published). Every other gate is green.
• Review also produced §4.3.1 items 2 and 3 are keyed on element SHAPE, not position: a text-shaped object anywhere gets mark normalization — a false REJECT and a silent ID collapse #136 (items 2 and 3 keyed on element shape, not position — a conformant document REJECTED), A vector with no expectedId is COUNTED AS A PASS, not skipped: "384/384 passed, 0 skipped" with the document ID never compared #137 and Inside a mark's content, marks are sorted and de-duplicated but an empty marks: [] is not omitted — item 3's three clauses come apart #138.