PR #17498 narrowed GroupingFieldSchema.field to refuse leading/trailing whitespace. The prose that ships with it — the .describe(), the generated doc page, and the ADR-0087 semantic entry — all say "whitespace", but the pattern's accept set is JavaScript's \S, which refuses considerably more than the space and tab a reader will picture.
Filed by the domain:spec execution seat, session session_01MkQhmuuJAVDjmeWNixwDDH, 2026-09-13T08:24Z, out of the at-tier post-hoc review of PR #17498. ⛔ No domain:* or priority:* applied — routing and grading are triage's. ⛔ Not a defect: the code is right, the description of it is incomplete.
The measurement
The at-tier round proved trim-equivalence by exhaustion — 14,641 four-character strings over an 11-symbol alphabet including U+00A0 (NBSP), U+3000 (ideographic space) and U+FEFF (BOM): 0 divergences from s === s.trim(). Lit control on the same harness (/^\S*$/): 150 divergences, so the harness discriminates.
⇒ the accept set is exactly trim-equivalence, Unicode included. A name with a leading NBSP or a trailing ideographic space is refused, by a rule whose published description mentions neither.
Why this is the failure mode worth fixing
These are precisely the characters an author does not know are in their string. A name pasted from a spreadsheet, a CJK editor, or a BOM-prefixed CSV export carries them invisibly. The author reads a refusal that says "whitespace", looks at a name with no visible space in it, and has no way to reconcile the two. The diagnostic already names the offending spelling — but a spelling whose difference is invisible is not a name the author can act on.
What is owed
Name the class in the three prose sites (.describe() on GroupingFieldSchema.field, the regenerated content/docs/references/ui/view.mdx row, and the ADR-0087 entry 18.ui-list-view-grouping-field-padded-refused): the rule is trim-equivalence under Unicode whitespace, not ASCII space. Worth considering alongside it: rendering the offending characters in the diagnostic as escapes ( ) rather than as themselves, so the message shows the author what they cannot see.
Previously raised as "Advisory 2" by an earlier review round on that PR and left unaddressed — filing it so it has a carrier this time rather than a mention.
Generated by Claude Code
PR #17498 narrowed
GroupingFieldSchema.fieldto refuse leading/trailing whitespace. The prose that ships with it — the.describe(), the generated doc page, and the ADR-0087 semantic entry — all say "whitespace", but the pattern's accept set is JavaScript's\S, which refuses considerably more than the space and tab a reader will picture.Filed by the
domain:specexecution seat, sessionsession_01MkQhmuuJAVDjmeWNixwDDH, 2026-09-13T08:24Z, out of the at-tier post-hoc review of PR #17498. ⛔ Nodomain:*orpriority:*applied — routing and grading are triage's. ⛔ Not a defect: the code is right, the description of it is incomplete.The measurement
The at-tier round proved trim-equivalence by exhaustion — 14,641 four-character strings over an 11-symbol alphabet including U+00A0 (NBSP), U+3000 (ideographic space) and U+FEFF (BOM): 0 divergences from
s === s.trim(). Lit control on the same harness (/^\S*$/): 150 divergences, so the harness discriminates.⇒ the accept set is exactly trim-equivalence, Unicode included. A name with a leading NBSP or a trailing ideographic space is refused, by a rule whose published description mentions neither.
Why this is the failure mode worth fixing
These are precisely the characters an author does not know are in their string. A name pasted from a spreadsheet, a CJK editor, or a BOM-prefixed CSV export carries them invisibly. The author reads a refusal that says "whitespace", looks at a name with no visible space in it, and has no way to reconcile the two. The diagnostic already names the offending spelling — but a spelling whose difference is invisible is not a name the author can act on.
What is owed
Name the class in the three prose sites (
.describe()onGroupingFieldSchema.field, the regeneratedcontent/docs/references/ui/view.mdxrow, and the ADR-0087 entry18.ui-list-view-grouping-field-padded-refused): the rule is trim-equivalence under Unicode whitespace, not ASCII space. Worth considering alongside it: rendering the offending characters in the diagnostic as escapes (Previously raised as "Advisory 2" by an earlier review round on that PR and left unaddressed — filing it so it has a carrier this time rather than a mention.
Generated by Claude Code