PT9 glosses section headings, we exclude heading text, so every heading analysis is lost and reported as `formMismatch`

PT9 interlinearizes section-heading text and stores it in the preceding verse's cluster data. Our extractor excludes heading markers from the baseline, so those clusters can never anchor: no candidate token exists, and anchorVerseClusters counts them as formMismatch (clusterAnchoring.ts:186-190) — a reason that points at form matching when the real cause is that the text was never tokenized.

Evidence

In a quasi-realistic mini project (Paratext 9.5.110.9), PHP 1:2 is Grace and peace to you from God our Father and the Lord Jesus Christ. — 69 characters — followed by \s Thanksgiving and Prayer. Every PT9 offset in that verse is verse-text index + 5, the \v 2 prefix:

That string ends at 74. PT9 also recorded a cluster at index 78, length 12 — Thanksgiving, from the heading that follows the verse.

Our side: HEADING_PARA_MARKERS (usjBookExtractor.ts:79-110) excludes s, s1-s4, ms*, mr, r, sp, qa, b, ib, imt*, is* from the verse baseline, so heading text produces no tokens. In the end-to-end run over that project, the heading cluster was the only drop in the whole import (formMismatch: 1 of 29 clusters).

Why it matters

• Back translation exists to render the whole published text. Headings are ordinary work in that flow, so a project with glossed headings loses all of it, silently.
• The drop reason misleads whoever reads the report: formMismatch invites someone to go looking at morpheme forms, and the forms are irrelevant.
• Secondary distortion of legitimate anchors. verseExtent is max(index + length) over a verse's clusters (clusterAnchoring.ts:169), so a heading cluster inflates it — 90 here against a 69-character baseline. Every ambiguous anchor in that verse is then placed by pickByProportionalPrior against a skewed denominator. All four ambiguous anchors in the run above were in verses carrying that inflation.

What to decide

1. Do we support heading analyses at all? If yes, headings need to become part of the text layer (their own segments, most likely, since they are not verse content), and this becomes a feature spanning the extractor, the model, and the UI. If no, they should be dropped under their own reason — headingText or similar — so the report tells the truth.
2. Either way, exclude heading clusters from verseExtent so they stop skewing the proportional prior for real clusters. That fix stands alone and is small.
3. Consider whether PT9's \v N prefix offset (a constant 5 here, but \v 12 is 6) should be accounted for anywhere. Our anchoring only uses proportions, so this is a note rather than a defect — but the proportion is computed against PT9's prefixed string and our unprefixed baseline, which is a small systematic skew of its own.

Relations

• #317 — owns the formMismatch reason this misuses; its measured numbers include this drop.
• #140 — a drop with a misleading reason is the reporting problem in miniature.

Size: S for (2) alone; M-L if we decide to support heading analyses.
Priority: P1 for deciding and for (2); the loss is total for any project that glosses headings.

Start with HEADING_PARA_MARKERS in usjBookExtractor.ts:79-110 and the anchorVerseClusters and verseExtent logic in clusterAnchoring.ts:169-190. Reproduce the PHP 1:2 mini-project case, then determine whether heading analyses are supported or dropped with a distinct reason. Done means heading clusters no longer inflate verseExtent and the import report accurately reflects their handling.