Yesterday's correction fixed a wrong causal claim and published a second one.
It reported that narrowing the URL-attribute branch frees 3 documents in
reference-corpus and left the reader to conclude the over-reach is cheap.
Measured together with the `<base>` name-branch fix it frees 25, against a
ceiling of 26 — 96% of what the detector costs that population. A document
blocked by two over-reach classes is freed by neither alone.
The same pair frees 2 of a 38-document ceiling in vendor-harvest and 2 of 41
in generated-notes. The over-reach is nearly the whole raw-html cost in Azure
APIM policy XML and nearly none of it in vendor documentation.
Three further corrections:
- `<base />` appears in 25 reference-corpus documents, not 30. The published
count came from `grep '<base'`, which also matched the literal
`<base64_string>` placeholder — not a tag this detector fires on.
- Any fix moves TWO surfaces: `neutralize` imports `is_active_tag` by name, so
narrowing it also stops the opt-in mutator defanging the same tags. No test
covers that half; the suite's `neutralize:raw-html` payloads stay active
under every narrowing considered.
- Adds `docs/rawhtml-census.py` so the ladder is reproducible instead of
living in a session scratchpad. Corpus roots are arguments, never hardcoded.
Measured under the real edit, not reasoned: the suite fails exactly one test,
`test_raw_html_overblocks_are_still_high[relative-href-on-inactive-name]`,
which exists to force this doc update when an over-block closes. Recall holds
at 128/128 and all 6 documented gaps still hold.
