Surfaced by the os-dev delivering #16894 (PR #18561) as an out_of_scope_findings entry. ⛔ Unlabelled for domain:* and ungraded — routing and grading are the triage seat's. The file was read-only by dispatch on that card, so it was reported and not edited.
⭐ Re-measured first-hand by the domain:spec seat 2 PM before filing (session_01JbZnqu8bt6YqfJsr9vaFb3, seat post #18549) — ⛔ this is not a relayed reading.
Class (c) — authorable metadata that nothing refuses and the runtime silently drops
POSITIONS in packages/lint/src/validate-list-view-field-refs.ts declares, per view face, which field-reference keys are walked and at what level. The kanban face is the only item-titled face with no titleField row.
Read off origin/main:
| face |
line |
titleField |
kanban |
:322 |
⛔ absent — scalars: { groupByField: 'error', summarizeField: 'warning' } |
calendar |
:332 |
'warning' |
gantt |
:340 |
'error' |
timeline |
:359 |
'error' |
| gallery / map block |
:366 |
'warning' |
Why this becomes reachable now
Until #16894 lands, KanbanConfigSchema refuses titleField by name (it is a strictObject), so the lint gap has no authorable surface behind it — the schema door catches everything. PR #18561 declares the key under director batch #87. From that release the key is authorable, and the walker still has no row for it.
⇒ A stale or misspelt kanban.titleField names nothing and is reported by nothing, while the byte-identical typo one block away on calendar or timeline is caught. The renderer falls back to the record display name (ADR-0079), so the author sees a board that renders correctly with a title that is not the one they asked for — a wrong value, not a visible failure.
Why it is class (c) and not a preference
The key is metadata: it is stored, and it is re-authored by someone other than whoever wrote it. The failure is silent at every door — schema accepts it (after #16894), lint does not walk it, the renderer substitutes a different value. That is the 「运行时静默丢弃」 shape, and it is the exact defect family #14107 created POSITIONS to close.
Not covered by any existing rule
⛔ No gate reconciles POSITIONS against the spec's own member lists. The only pin on that table — validate-list-view-field-refs.test.ts, 「#14107 — every other walked position」 — enumerates POSITIONS rows against each other, ⛔ not against the schema keys, so a face missing a row is invisible to it. (Checked, ⛔ not assumed.)
⚠️ This means the gap is structural, not a typo: nothing would have caught it, and nothing will catch the next one.
Suggested shape — ⛔ a proposal, not a prescription
Add a titleField row to POSITIONS.kanban. ⚠️ The level is a real choice and ⛔ this card does not make it: the siblings disagree with each other (calendar warns, gantt and timeline error), so whoever takes this decides which sibling kanban follows and says why.
⭐ The more durable half is the second one: whether POSITIONS should be reconciled against the spec member lists by a gate at all, rather than by hand each time a key is declared. ⛔ That is a separate, larger question and this card does not smuggle it in.
Sequencing
⚠️ Not actionable before PR #18561 lands — until then titleField is not authorable on kanban and the row would walk a key the schema refuses. Whoever takes this should confirm #16894 is closed first.
Dedupe words
validate-list-view-field-refs · POSITIONS.kanban · kanban titleField · list-view field ref · walked position table
Related: #14107 (created the table) · #14282 (the dotted-name follow-up) · #16894 / PR #18561 (makes the key authorable).
Generated by Claude Code
Surfaced by the
os-devdelivering #16894 (PR #18561) as anout_of_scope_findingsentry. ⛔ Unlabelled fordomain:*and ungraded — routing and grading are the triage seat's. The file was read-only by dispatch on that card, so it was reported and not edited.⭐ Re-measured first-hand by the
domain:specseat 2 PM before filing (session_01JbZnqu8bt6YqfJsr9vaFb3, seat post #18549) — ⛔ this is not a relayed reading.Class (c) — authorable metadata that nothing refuses and the runtime silently drops
POSITIONSinpackages/lint/src/validate-list-view-field-refs.tsdeclares, per view face, which field-reference keys are walked and at what level. Thekanbanface is the only item-titled face with notitleFieldrow.Read off
origin/main:titleFieldkanban:322scalars: { groupByField: 'error', summarizeField: 'warning' }calendar:332'warning'gantt:340'error'timeline:359'error':366'warning'Why this becomes reachable now
Until #16894 lands,
KanbanConfigSchemarefusestitleFieldby name (it is astrictObject), so the lint gap has no authorable surface behind it — the schema door catches everything. PR #18561 declares the key under director batch #87. From that release the key is authorable, and the walker still has no row for it.⇒ A stale or misspelt
kanban.titleFieldnames nothing and is reported by nothing, while the byte-identical typo one block away oncalendarortimelineis caught. The renderer falls back to the record display name (ADR-0079), so the author sees a board that renders correctly with a title that is not the one they asked for — a wrong value, not a visible failure.Why it is class (c) and not a preference
The key is metadata: it is stored, and it is re-authored by someone other than whoever wrote it. The failure is silent at every door — schema accepts it (after #16894), lint does not walk it, the renderer substitutes a different value. That is the 「运行时静默丢弃」 shape, and it is the exact defect family #14107 created
POSITIONSto close.Not covered by any existing rule
⛔ No gate reconciles
POSITIONSagainst the spec's own member lists. The only pin on that table —validate-list-view-field-refs.test.ts, 「#14107 — every other walked position」 — enumeratesPOSITIONSrows against each other, ⛔ not against the schema keys, so a face missing a row is invisible to it. (Checked, ⛔ not assumed.)Suggested shape — ⛔ a proposal, not a prescription
Add a⚠️ The level is a real choice and ⛔ this card does not make it: the siblings disagree with each other (
titleFieldrow toPOSITIONS.kanban.calendarwarns,ganttandtimelineerror), so whoever takes this decides which sibling kanban follows and says why.⭐ The more durable half is the second one: whether
POSITIONSshould be reconciled against the spec member lists by a gate at all, rather than by hand each time a key is declared. ⛔ That is a separate, larger question and this card does not smuggle it in.Sequencing
titleFieldis not authorable on kanban and the row would walk a key the schema refuses. Whoever takes this should confirm #16894 is closed first.Dedupe words
validate-list-view-field-refs·POSITIONS.kanban·kanban titleField·list-view field ref·walked position tableRelated: #14107 (created the table) · #14282 (the dotted-name follow-up) · #16894 / PR #18561 (makes the key authorable).
Generated by Claude Code