Development record
the grounds substance floor counts runes not letters so twenty zero-width spaces satisfy the promoted refusal
the grounds substance floor counts runes not letters so twenty zero-width spaces satisfy the promoted refusal
Found by the round-2 adversarial security review of build/itd-179.
abcd intent ready itd-N --grounds "pursued:<20 x U+200B>" is accepted and
written. Fold leaves the zero-width runes (TrimSpace trims NBSP but not
ZWSP); ValidateText passes the rune-length check; wordRe finds zero
letter-runs, and onlyDegenerate := len(words) > 0 at
internal/core/grounds/grounds.go:163 short-circuits to false. The reader
groundsCheck applies the same floor, so the record renders as an entry with
nothing visible in it and the seventh readiness check reports OK. Twenty dots
and twenty digits pass identically.
This matters because the check is the one this intent PROMOTED from a report to
a refusal. A refusal answerable with twenty zero-width spaces is not a floor.
The type doc at lines 58-63 claims it "refuses the degenerate texts", and
commands/intent.md tells the host that - pursued: yes is not an entry,
which is true while twenty dots is.
Same shape as the defect c2dfd9ad already fixed (the check claimed a floor the reader did not enforce); the floor now exists, and a zero-letter text walks through it.
Remedy: ValidateText requires a minimum count of wordRe matches and refuses
len(words) == 0, rather than counting runes. Both the writer and
ParseGrounds inherit it from the one place.
Grounds
- pursued: we expect a floor stated in characters to be answerable with characters that render as nothing, and a text of twenty zero-width spaces clearing the promoted refusal is what showed it
Frontmatter
| id | iss-2608301206034359 |
|---|---|
| type | issue |
| lifecycle | resolved |
| severity | major |
.abcd/work/issues/resolved/iss-2608301206034359-the-grounds-substance-floor-counts-runes.md
open on GitHub ↗ · commit history ↗
mentions3
- dcn-26083000000000142026-08-30 — itd-179 round-4: the grounds floor's unit is a WORD where the script separates words and a LETTER where it does not (`textUnits` + a named, deliberately partial `scriptioContinua` set: Han, Hiragana, Katakana, Thai, Lao, Khmer, Myanmar, Tibetan, Javanese), and `MinTextWords = 3` is unchanged. The letter test is load-bearing, not tidy: a Unicode SCRIPT table carries its script's digits, punctuation and combining marks too, so counting table members would have made twenty Thai digits — or twenty Tibetan tsheg, which are twenty dots — a twenty-unit text and reopened iss-2608301206034359 once per script. Rejected: the review-converged shape of "contains a scriptio-continua rune → skip the run count and apply the rune floor", because `supercalifragilistic 中` then clears a 20-rune floor on one word; the shipped counting refuses it at two units, though the closure is one ideograph deep (`supercalifragilistic 中中` passes, as `supercalifragilistic 中 中` already did before this change). Rejected: Hangul in the set — Korean is spaced, and counting its syllables would let two Korean words clear a three-word floor. Limit stated in the doc comment: a scriptio-continua script not named in the set still counts as one word and is still refused, and the set is where that is fixed, one script at a time.
- iss-2608301206073609hidden runes reach committed records verbatim because termsafe.EncodeHiddenRunes is not applied at the record-write boundary
- itd-179The reasoning behind what was pursued no longer evaporates at the gate — readiness and triage record grounds for the conjecture, not only the decision