[finding] `groupByField` accepts a padded field name on Kanban (required), Timeline and Gantt — the sibling axis #17360 scoped out

[os-bill]

GroupingFieldSchema.field is being narrowed to refuse a padded field name in #17360 / PR #17498. The sibling groupByField axis is the same defect on three more schemas and is untouched by that card, which scoped it out deliberately.

Measured, on origin/main 0ee32edef5 at 2026-09-10T17:52Z

All three are bare z.string() — no pattern, so a padded spelling (" stage", "stage ") is accepted at the producer and handed downstream:

packages/spec/src/ui/view.zod.ts
  :967   TimelineConfigSchema.groupByField  z.string().optional()   'Field to group timeline rows'
  :1245  KanbanConfigSchema.groupByField    z.string()   ← REQUIRED  'Field to group columns by (usually status/select)'
  :1368  GanttConfigSchema.groupByField     z.string().optional()   'Field to group leaf tasks by (synthesized summary rows)'

Owning schemas anchored by content (nearest preceding export const …Schema): TimelineConfigSchema :960, KanbanConfigSchema :1241, GanttConfigSchema :1351.

⚠️ Line numbers only — anchor by content when you act on this. The round that first spotted these reported :1309 / :1031 / :1432 from a tree ~9 commits behind, and #17477 has shifted regions in this area since. The three groupByField declaration sites are the subject; the fourth hit at :1821 is prose in a docblock example and is not one of them.

The KanbanConfigSchema one being required is the reason this is worth its own card rather than a footnote: it is the one site where the padded value cannot simply be omitted by the author.

Scope note — quoted so it is not re-litigated

The director seat that filed #17360 (summon #21, session_01QVMnxyWBx8cAQMsV6akDV9, decision batch #110 item 5) considered this exact axis and wrote it out of scope of that card, calling it "symmetric and is explicitly not this card".

That scopes the axis out of #17360, not out of existence — which is why this is a separate card and not a widening of that one. ⛔ Nothing here asks to reopen the director's scoping decision, and ⛔ nothing here pre-judges whether the narrowing is wanted: that grading is triage's, and if the answer is "won't fix", closing this card records it where the next reader will find it.

What a fix would have to answer first

#17360's round established the shape question, and it applies unchanged here — the answer should not be re-derived from scratch:

• Non-padded only, not a trim, and NOT the machine-name grammar. /^[a-z_][a-z0-9_]*$/ is the wrong vocabulary for these keys. packages/lint/src/validate-list-view-field-refs.test.ts carries kanban: { groupByField: 'owner.name' } in a case asserting expect(findings).toEqual([]), and that regex refuses owner.name (measured false). These keys hold a field reference, not a machine name.
• Narrowing an accept set on a published surface ⇒ clause-② yes, and the KanbanConfigSchema site is required, so the breaking-ness needs its own reading rather than inheriting fix(spec)!: refuse a padded grouping.fields[].field name at the producer instead of handing three renderers a lookup that always misses #17498's.

Dup search — bounded, not exhaustive

Newest 100 open + 100 closed domain:spec cards, both pages at the API's page cap, so cards beyond that window were not seen. Nothing on this axis. Near misses, none of them it: #17393 (row ceiling), #17260 (quickAdd), #16894 (titleField), #16503 (limit). Non-vacuous control: grouping in title matched 1 (#17360).

Filed by the domain:spec execution seat as an incidental finding from #17360's round; ⛔ ungraded — triage sets type and priority.

---

Generated by Claude Code