The print already named its marks, and nothing had asked

[omars-lab]

packages/core/src/skins.ts has said since Loop 6a that a tajweed colour cannot land on part of a word, because the print's glyphs are "anonymous outlined <path>s". That is true of assets/pages/**, which is what the app draws — and false of the ligature corpus, which names every mark it draws in a data-diacritic attribute. The same comment already named that corpus as its own gate.

This PR is the measurement that settles it, and ships nothing to apps/web/public/assets.

What it adds

file	what
packages/core/src/diacritics.ts (+ test)	the twenty-six names, in frequency order, and the id a shard would use
packages/etl/scripts/lib/diacritics.mjs	readDiacritics(svg, apply) — a named, exact box per mark, grouped by its word
packages/etl/scripts/probe-diacritics.mjs	pnpm probe:diacritics — the corpus-wide run
docs/design/sub-word-marks.md	the design of record, plus four open-question rows

What was measured

pnpm probe:diacritics, all 604 cached pages:

measure	result
distinct data-diacritic values	26 of 26 in DIACRITICS; none unknown
marks extracted	326,515 on 86,964 of 91,451 words
marks outside their own word's box	0 (slack 0.2 — rounding, not registration)
words with no box in the committed shard	0
what the shards would weigh	7.35 MB raw / 2.28 MB gz across 604 files

The 4,487 words carrying no mark are the 4,486 pause marks gate:words already counts, plus exactly one — 20:1's opening, which this print writes with nothing above or below it. An off-by-one would have scattered those empties.

Three decisions worth reviewing

The order of DIACRITICS is a wire format. A shard says 0, not "fatha", because a page carries ~540 marks and the names are the larger half of the bytes. Appending is safe; reordering silently re-labels the whole corpus and moves no geometry, so nothing that measures rectangles would notice. Six ids are pinned in a test for that reason, and it is filed as its own open row (④).

Containment is the invariant, and it is checked against the committed shards. A word's shipped box is union(pathBBox) over every path in its group, marks included — so containment holds by construction, and an escape can only be an alignment error, a mark filed under the wrong word. That is the failure class behind gate:edges. Verifying against boxes computed in the same pass would let two sides of one computation share their mistakes and agree about them.

Nothing here fits anything. apply is handed in; applierFromPin rebuilds it from the four numbers word-boxes.pin.json already records. A second fit could disagree with the first by a tenth of a unit, which is indistinguishable from a mark on the wrong letter.

Why it ships nothing

2.28 MB of assets no caller fetches is the same waste gate:assets names for a non-vendored edition — the download is paid for and unreachable. So the order is mark-A (this) → mark-B, draw the marks in the encoding inspector and see whether a tajweed span lands on one → mark-C, only then pay the bytes. That is also the answer given when asked where the marks should appear first: the inspector, then the app.

skins.ts's stale comment is left in place and filed as confirmed (③) rather than edited: it is load-bearing prose about why a shipped feature has the granularity it has, and rewriting it before the replacement exists would leave the file claiming a capability the app does not have.

Verification

• pnpm --filter @hifth/core test — 470 passing, 6 new
• make ci green under the lock (33s); gate:issues OK, 87 indexed across 13 registers; gate:map OK, 154 pointers
• docs/map.json hand-edited, never generated

🤖 Generated with Claude Code

https://claude.ai/code/session_01EuhvbUKjGesE3uMhjCzBGt