Measuring the same population against the v0.3.1 tag a consumer actually pins
(scratch venv, git+file://@v0.3.1, resolved version asserted) returned 99 of 185
(53.5%) against the current tree's 98 (53.0%). Chasing the one document that
moved corrected a published claim instead of confirming it.
docs-en-fullscreen.txt disposed QUARANTINE_REVIEW at 0.3.1 and WARN now, because
markdown:link-anchor-injection stopped matching 300 characters of ordinary prose
-- a match that opened at one construct's [ and closed at a different
construct's ](...), catching the word "execute" in between. The 0.3.3 ReDoS fix
excluded [ from the anchor class and ( from the target class, which telescopes
the runaway AND deletes that false-positive class.
0.3.3's "Known behaviour changes" said "None measured" and then named two
exceptions, both about a literal (. It missed the third: an anchor can no longer
span a [, so a match bridging two separate markdown constructs no longer forms.
The correction is in our favour, but it was a behaviour change presented as
none, and only a field sweep found it.
Also lands two things the measurement needed and did not have:
- The rate is now stated for the version consumers pin, not only for the tree
that produced it. A number measured on one tree must not be sent as if it
described another.
- This repository's own eight published documents are 8 of 8 fail-secure at the
upload door, reproducible from any clone with no private corpus. It is the
first bullet of LIMITATIONS at full strength, and explicitly NOT a fourth
population -- one eight-document corpus is an illustration, not a rate.
The population -> local-path mapping the public script deliberately omits is
recorded in docs/CONSUMER-MAP.local.md (gitignored, never reaches the mirror),
so the next session reproduces the numbers instead of re-choosing populations.
717 tests, matrix 128/128 with 6/6 gaps, LIMITATIONS still 33 items.
Kjell Tore Guttormsen
d3d0928c17