Filed by an os-dev seat while discharging objectstack#16577 (branch claude/issue-16577-listview-calendar-guard-coverage). Out of that card's scope: different door, different file, different ruling. ⛔ Not claimed, ⛔ no code.
The claim under test
packages/spec/src/kernel/functional-completeness.ts — VIEW_BINDING_BLOCKS's docblock states its calendar row as a MEASURED renderer fallback:
calendar → startDateField || 'start_date', endDateField || 'end_date'
and the same premise is the body of the warning checkViewCompleteness prints on that route (view/layout-without-binding):
A calendar view with no calendar block is bound to nothing: the renderer falls back to literal default field names, which works only if the object happens to declare them — on any other object the view renders empty while authoring reports success.
The docblock is explicit that the table was verified against a build: "read back verbatim from the built console 17.2.0".
The measurement
Read on objectui main at commit 3fbdd4a2d, both halves of the path a type: 'calendar' list view takes:
packages/plugin-list/src/ListView.tsx, the case 'calendar': props builder — the two literal floors are GONE, and the comment above them says so in its own words:
objectui#7029: only ever restate a binding the view actually DECLARED. These two keys used to be floored at 'start_date' / 'end_date' — field names no view had written and most objects do not carry.
The branch now spreads startDateField / endDateField / titleField only when each is declared.
packages/plugin-calendar/src/ObjectCalendar.tsx — getCalendarConfig(schema) returns null when there is neither a calendar block nor a flat startDateField / dateField, and the component's if (!calendarConfig) arm renders the refusal screen "Calendar configuration required. Please specify startDateField and titleField."
⇒ For calendar, today, there is no fallback to literal default field names, the view does not render empty, and authoring does not report success silently — the renderer names the two missing keys on screen. Both the table row and the warning's message describe objectui at 17.2.0, before objectui#7029 landed.
Why it is worth a card rather than a shrug
The fix: hint the same finding carries is still correct (calendar: { startDateField: ..., titleField: ... }), so an author is steered to the right edit. What is wrong is the WHY, and the why is load-bearing twice over:
- It is the stated evidence for the row's severity. ADR-0078 §1 assigns WARNING to what degrades and refusal to what renders nothing; the row justifies its warning by the fallback. With the fallback deleted, the severity is now resting on a premise that no longer holds — in either direction. objectstack#16577 is asking exactly which severity this route deserves, and it will be answered against this row.
- The docblock presents the row as measured and names the build it was measured on. That is the shape a later author reuses rather than re-measures — byte-exact at the commit it cites, describing code two refactors back.
⛔ This card does not rule what the row should say, and deliberately does not touch the five sibling rows (kanban / gantt / timeline / map / tree): only the calendar renderer was re-measured here, and the same docblock's standing instruction is that each entry is verified before it is asserted.
Dedup
REST list endpoints plus local grep over the bodies (the exit proxy declines /search/*). Two label-scoped listings, state=all — finding and domain:spec, 2 pages each, 374 distinct issues. Zero hits on layout-without-binding, VIEW_BINDING_BLOCKS, checkViewCompleteness, and on the literal startDateField || 'start_date'. Lit control functional-completeness read 2 (objectstack#16441, objectstack#16960 — both about line anchors elsewhere, neither this); dark control ZZQQ_dark_control_16577 read 0.
⚠️ Coverage bound, stated rather than implied: both listings' second pages came back full at 100, so this is not an exhaustive enumeration of either label — it is a bounded, controlled read, not a proof of absence.
Generated by Claude Code
Filed by an
os-devseat while discharging objectstack#16577 (branchclaude/issue-16577-listview-calendar-guard-coverage). Out of that card's scope: different door, different file, different ruling. ⛔ Not claimed, ⛔ no code.The claim under test
packages/spec/src/kernel/functional-completeness.ts—VIEW_BINDING_BLOCKS's docblock states its calendar row as a MEASURED renderer fallback:and the same premise is the body of the warning
checkViewCompletenessprints on that route (view/layout-without-binding):The docblock is explicit that the table was verified against a build: "read back verbatim from the built console 17.2.0".
The measurement
Read on objectui
mainat commit3fbdd4a2d, both halves of the path atype: 'calendar'list view takes:packages/plugin-list/src/ListView.tsx, thecase 'calendar':props builder — the two literal floors are GONE, and the comment above them says so in its own words:The branch now spreads
startDateField/endDateField/titleFieldonly when each is declared.packages/plugin-calendar/src/ObjectCalendar.tsx—getCalendarConfig(schema)returnsnullwhen there is neither acalendarblock nor a flatstartDateField/dateField, and the component'sif (!calendarConfig)arm renders the refusal screen "Calendar configuration required. Please specify startDateField and titleField."⇒ For
calendar, today, there is no fallback to literal default field names, the view does not render empty, and authoring does not report success silently — the renderer names the two missing keys on screen. Both the table row and the warning's message describe objectui at 17.2.0, before objectui#7029 landed.Why it is worth a card rather than a shrug
The
fix:hint the same finding carries is still correct (calendar: { startDateField: ..., titleField: ... }), so an author is steered to the right edit. What is wrong is the WHY, and the why is load-bearing twice over:⛔ This card does not rule what the row should say, and deliberately does not touch the five sibling rows (
kanban/gantt/timeline/map/tree): only thecalendarrenderer was re-measured here, and the same docblock's standing instruction is that each entry is verified before it is asserted.Dedup
REST list endpoints plus local grep over the bodies (the exit proxy declines
/search/*). Two label-scoped listings,state=all—findinganddomain:spec, 2 pages each, 374 distinct issues. Zero hits onlayout-without-binding,VIEW_BINDING_BLOCKS,checkViewCompleteness, and on the literalstartDateField || 'start_date'. Lit controlfunctional-completenessread 2 (objectstack#16441, objectstack#16960 — both about line anchors elsewhere, neither this); dark controlZZQQ_dark_control_16577read 0.Generated by Claude Code