Emit sequence ordinals as nodes, not CSS counters
A numbered sequence renders its ordinal through CSS:
A numbered sequence renders its ordinal through CSS:
Tracking started Sep 21 — check back for trends.
The governing rule, which ADR-030 rule 3 states as a semantic fact: a numbered sequence's ordinal is information. A playlist's 7 is the track number, an identifier a listener says out loud; a recipe's 3 is referenceable ("go back to step 3"). Information belongs in the document, not in a stylesheet.
The mirror case confirms the rule rather than weakening it. A connected sequence — timeline, itinerary — renders no number, because each item carries its own positional label (timeline.ts:44 emits a <time>), and a numeral there would be false information. Decorative marks stay in CSS; a dot connector or a separator is correctly generated content precisely because it must not be copied.
In the DOM if it's information. In CSS if it's ornament.
Three payoffs beyond correctness:
groups.[data-sequence] stops generating content and becomes pure geometry.In: sequence: 'numbered' only.
Out: connected and plain keep no marker content — there is nothing to promote. The decorative dot on connected stays a CSS ::before.
data-name="ordinal", data-meta-type="quantity" for tabular-nums).track.ts:192 only emits numberMeta when the author passed number=, so playlist must number its children — the parent-retypes-children pattern the SPEC-130 D9 comment at track.ts:128 already describes.counter-reset / counter-increment / content: counter(…) from sequence.css, keeping the marker's box geometry.number= authoritative where supplied, so a playlist with a gap or a non-1-based numbering renders what the author wrote.BUG-024 removes four runes' duplicate counters and should land first. This item then changes the single remaining mechanism. Doing it in the other order means editing five counter implementations instead of one.
connected and plain sequences emit no ordinal nodenumber= on an item wins over the assigned ordinalplaylist assigns ordinals to tracks that carry nonelayout tree by namestructures.json are regenerated together and the new node appears in eachnpm run seo:baseline:check passes, or the baseline is regenerated and the diff reviewed — no schema change is expected, so an unexpected diff is a findingContract and baseline churn. A new node in every numbered sequence touches both contract copies and possibly the SEO baseline. Expected and reviewable, but it makes this a poor candidate to batch with unrelated changes.
Double-rendering during migration. If the node ships before the CSS counter is removed, items render two numbers. The two changes belong in one commit.