Skip to content

[finding] POSITIONS.kanban is the one item-titled face with no titleField row — from #16894 the key is authorable and a misspelt one is walked by nothing, while the identical typo on calendar/timeline errors #18565

Description

@os-bill

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 absentscalars: { 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

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions