Spec errata: define block-level content, scope the transforms by enclosing field

[gvonnessi]

Closes #122, #126, and #129's first defect. Three spec decisions researched, decided, and written down, plus the one code fix that could not be separated from them.

#122 — "block-level content" was a MUST nothing defined

§7.2 rules 6 and 11 require table-cell and admonition children to be "block-level content". The term appears four times in spec/ and is defined nowhere, which makes both an unenforceable MUST. The admissibility question the issue asks is downstream of that.

The answer the taxonomy already gives is yes: §4.1 "Text Leaf Nodes" sits under "## 4. Core Block Types", §1.4 calls a text node "the only block type that holds text", and $defs/textNode composes blockBase, whose description reads "shared by every block". The issue's two premises are both false — there is no sentence saying a text node is not a block object, and a text node does carry the base fields.

It is also already assumed by published artifacts: the KAT vector reject-unpaired-surrogate ships blocks:[{"type":"text","value":"\ud83d"}] and rejects it for the surrogate, not the position. Twenty-one arrays resolve their items to $defs/block — seven core, fourteen from extensions — and every one admits a text node.

So the erratum states what is true rather than changing it, and carves text nodes out of the rules that would otherwise now reach them: item 5's relabeled namespace, §3.2's id requirements, and 03a §4's uniqueness bullets.

#126 — the narrowing in PR #128 had no licence in spec/

That PR scoped §4.3.1 item 4 and §4.3.2 item 2 to block-content positions in both implementations and changed no spec file. The transform preamble admits exactly one carve-out — "uniformly, but for the two id-relabeling exceptions item 5 names" — and item 4 is not one of them.

Item 5 is the template: it scoped by enclosing field, named its arrays exhaustively, and amended the preamble. Item 4 now does all three. Item 2's referent moves from "each block" to "each maximal run of adjacent text nodes within a block-content array", which licenses a run in the root array — the content root is not a block (§7.1 rule 5), so a run directly there had no referent at all, though both implementations reject one.

Membership is keyed on the field NAME, not the owner's type. Four owner classes carry no type — subfigure, exercisePart, solution, a structured abstract's section — and an implementation keying on the owner computes a different document ID.

#129 defect 1 — an authored b0 on a text node

Item 5 already stated the prohibition and gave the reason: an id left as authored beside a generated b0 puts two identifiers into the canonical output under one name. But it is scoped to namespace MEMBERS, and a text node is not one. Measured before the fix: two b0s in hashed content, no error, so a #b0 reference had two candidate referents.

The check is keyed on position — a member is a text node only inside a block-content array, outside the attributes barrier — with controls for a JSON-LD annotation and a CSL entries member, both of which a shape test rejects.

Review

Two /review-fix cycles, the branch's cap. 19 findings, all closed or filed.

Cycle 1 (citation audit + normative consistency) raised 11. Cycle 2 (closed-list verification + an adversarial implementer reading from the text alone) raised 8, three of which the first cycle's fixes had already closed.

Both cycles were overwhelmingly finding defects in this branch's own new prose, not in the codebase. Two are worth naming because they are the same mistake:

• The erratum said "a block's caption, children, hints" while describing BLOCK_CONTENT_KEYS, whose own comment reads "KEYS, NOT (type, key) PAIRS… several content arrays hang off sub-objects that carry no type at all".
• The A text-node id escapes both the uniqueness check and the canonical-name prohibition #129 check was keyed on element shape, inside a slice whose purpose is replacing shape-keying with position-keying. It rejected a CSL entries member.

The adversarial lens's verdict before those fixes was "no — a from-the-text implementation computes a different document ID for academic exercise content". After them, both readings converge.

Five sites still quoted the referent the erratum replaced, two of them published — a fixture description and its generator quoted a sentence grep spec/ no longer finds. A repo-wide grep for every phrasing now returns nothing.

Filed, not fixed

• check:block-content-positions: derivation gaps, a cardinality floor, and its own central property unpinned #127 gains a sixth item: isContentRef matches ref paths by suffix rather than resolving them, so an array of a block-typed $def is invisible to the derivation.
• A block index cannot describe id-less top-level blocks, and blockCount does not say which form it counts #130 (new): a block index cannot describe id-less top-level blocks — blockEntry requires id while §3.2 makes it optional, and a published fixture ships three id-less root members — and blockCount does not say whether it counts the stored or canonical form, which differ (3 → 2, measured).
• A text-node id escapes both the uniqueness check and the canonical-name prohibition #129 defect 2 — a text-node id may duplicate a block id — turns on whether text-node ids belong in the uniqueness namespace, a different question from colliding with a generated name.

Verification

30/30 gates green, plus the CI steps that are not npm scripts (npm audit --audit-level=high → 0 vulnerabilities, generate:template into a fresh empty dir). check:conformance: 378/378 (215 vectors + 163 fixtures), 0 failed, 0 advisory, 0 skipped. errors.json unchanged at v0.14 / 86 codes — its note and summary were corrected, which its own compatibilityPolicy permits without a bump.