R-291 measured check-scenarios' tagsIn against this file's readers and found
them apart on three spellings. tagsIn was widened for case and spacing around
the colon; outcome-coverage's strict half still carried the case-sensitive
literal, so `[cus: Spot — x]` was READ by one guard and reported unparseable
by the other. The build failed, which is the safe direction, but it failed
saying the tag could not be read while another guard had just read it.
beatsIn and beatLikeIn now share one TAG pattern, widened to agree with
tagsIn. Measured across seven spellings: the five both strict readers accept
now agree in all three, and `[CUS Spot]` and `[CUS= Spot]` are still refused
by both and still named by the loose counter, so the canary keeps its teeth.
Verified on the real document that this is a spelling fix and nothing else —
beats 21, quoted 1, unparsed 0, stated 18/6/6, session figures unchanged, so
the baseline is untouched. A lowercase tag planted in the acts is now read by
check-outcomes, check-scenarios and check-rollable alike; the file was
restored byte-identical after the test. R-291's own assertion still passes.
Found by the peer session measuring my file rather than trusting it, which is
the fourth reader this session to be caught describing or reading its own
format wrongly.
npm run check: 19 guards pass.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
