DialectCatalogueSizeTest, modelled on ChapterProposalSizeTest and measured the
way the manager measures it -- the real encoding rather than an estimate.
Neither limit is checked anywhere a reviewer would see it: proposeSigningBatch
enforces both with a require, so the first sign of the catalogue outgrowing a
batch would be a wave that split in two, or one that threw. Somebody adding a
language has no reason to be thinking about FROST.
The third assertion changed shape while being written. "A wave is small rather
than just legal", as a fraction of MAX_PROPOSAL_BYTES, failed: the catalogue
encodes to 16,832 bytes and a quarter of the budget is 16,384. The quarter was a
guess. What actually wants guarding is the cost of one dialect -- 301 bytes,
bounded here at twice that -- because that is the number that would drift if a
dialect event grew something large, and unlike a fraction it does not move every
time a language is added.
The size test's failure message says not to trim the catalogue. The view model
already chunks by MAX_BATCH_SIZE, so a larger catalogue is two sessions rather
than a bug; what would be lost is a group adopting the whole list answering once,
and that is a decision rather than a repair.
Also records the plan as built, with a table of the seven places the build chose
differently, and indexes it in docs/README.md.
One of those entries is a finding rather than a choice: m3-touch-targets.py reads
comments as code, so a KDoc explaining that a row used a clickable Card "rather
than a Modifier.clickable" broke a zero budget and with it ./gradlew check. The
comment was reworded, which is the wrong fix. m3-audit.sh already solves this for
the colour check and says why, at NOT_A_COMMENT.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
dd405e90e5