Observation recorded while fixing #12590 (duplicate ### Nested Shape: anchors). Filing rather than fixing: it is a much larger population with a different decision behind it, and #12590's card explicitly scoped itself to the per-key qualified headings.
What was measured
Counting duplicate heading TEXTS per emitted page under content/docs/references/**, on the tree regenerated with #12590's fix applied (214 pages):
excess=1316 pages=162 distinct heading texts=6
Broken down by heading text (excess occurrences summed across pages):
| excess | heading |
|---|
| 1133 | ### Properties |
| 145 | ### Allowed Values |
| 12 | ### Union Options |
| 12 | #### Option 1 |
| 12 | #### Option 2 |
| 2 | #### Option 3 |
The worst single page is content/docs/references/ui/view.mdx with 44 occurrences of ### Properties; api/protocol.mdx has 124.
Why this is a separate question from #12590
Two different kinds of heading live on these pages, and only one of them was ever qualified:
So this is not the same defect one level up; it is the open question of whether the section grammar should be addressable at all.
What is NOT claimed here
- Nothing in the repo is known to link to these anchors.
check:doc-anchors checks that links resolve, never that anchors are unique, and it is green. - Whether the docs site's slugger de-duplicates repeated headings (appending
-1, -2) was not measured. If it does, the harm is a reader/AI-author addressing problem rather than a broken link, and the counts above are still the honest measure of how many headings are not independently addressable.
Triage should decide between: qualify the section grammar the way the per-key headings are qualified; demote these to a non-heading rendering so they mint no anchor; or accept them and say so in the renderer so the next reader of the Schema.key qualifier does not read the inconsistency as a bug.
Reproduce with any per-file duplicate-heading count over content/docs/references/**, e.g. counting identical lines matching ^#{1,6}\s within each page and summing count - 1.
Observation recorded while fixing #12590 (duplicate
### Nested Shape:anchors). Filing rather than fixing: it is a much larger population with a different decision behind it, and #12590's card explicitly scoped itself to the per-key qualified headings.What was measured
Counting duplicate heading TEXTS per emitted page under
content/docs/references/**, on the tree regenerated with #12590's fix applied (214 pages):Broken down by heading text (excess occurrences summed across pages):
### Properties### Allowed Values### Union Options#### Option 1#### Option 2#### Option 3The worst single page is
content/docs/references/ui/view.mdxwith 44 occurrences of### Properties;api/protocol.mdxhas 124.Why this is a separate question from #12590
Two different kinds of heading live on these pages, and only one of them was ever qualified:
### Nested Shape: \Schema.key`and### Allowed Values: `Schema.key`. These exist to be uniquely addressable; theSchema.key` qualifier is there precisely so one page cannot mint the same anchor twice. [finding] 12 duplicate### Nested Shape:anchors on 4 reference pages — a union-variant table qualifies its heading by schema+key, and sibling variants share both #12590 fixed the case where two sibling union variants shared both halves of that qualifier (12 excess / 4 pages), and the qualified population is now zero.### Properties,### Allowed Values,### Union Options,#### Option N. These are structural labels emitted once per schema section (or once per union variant), and they carry no qualifier by construction. One page carries many schema sections, so they repeat by design.So this is not the same defect one level up; it is the open question of whether the section grammar should be addressable at all.
What is NOT claimed here
check:doc-anchorschecks that links resolve, never that anchors are unique, and it is green.-1,-2) was not measured. If it does, the harm is a reader/AI-author addressing problem rather than a broken link, and the counts above are still the honest measure of how many headings are not independently addressable.Triage should decide between: qualify the section grammar the way the per-key headings are qualified; demote these to a non-heading rendering so they mint no anchor; or accept them and say so in the renderer so the next reader of the
Schema.keyqualifier does not read the inconsistency as a bug.Reproduce with any per-file duplicate-heading count over
content/docs/references/**, e.g. counting identical lines matching^#{1,6}\swithin each page and summingcount - 1.