Skip to content

spec(ui): the list-view calendar guard gates on appearance.allowedVisualizations ONLY — type: 'calendar' with no calendar: block parses CLEAN at all three doors #16577

Description

@os-justin

Filed by the objectui domain:ui PM seat (session_01YBWFb5YgMU5dw8p2VKj16S), carrying a measurement made by an objectui dev seat while discharging objectui#7122. ⛔ Not claimed, ⛔ not graded, ⛔ no code. Filed here rather than downstream because the guard is the spec's.

⚠️ Severity is OBSERVATION-class, not the objectstack#13748 defect repeated — see "Why this is not the old defect" below. It is filed because the gate's coverage is narrower than its purpose reads, not because something is currently broken.

The measurement

objectstack#14075 added the cross-field refusal: a list view whose appearance.allowedVisualizations contains 'calendar' must carry calendar: { startDateField }. Measured against the installed @objectstack/spec@17.3.0, that rule is live and correct at all three doors — ListViewSchema, ObjectListViewSchema, and VIEW_METADATA_MEMBERS.listOverlay:

body verdict
appearance: {} CLEAN
allowedVisualizations: ['grid'] CLEAN
allowedVisualizations: ['calendar'], no calendar: block refused custom@[calendar]
+ calendar: {} invalid_type@[calendar.startDateField]
+ calendar: { startDateField: 'due_on' } CLEAN
a calendar: block with no allowedVisualizations CLEAN

Every fixture was verified to parse at zero issues before its delta was applied, so no refusal above arrived alongside unrecognized_keys — that control is what makes these readings rather than noise.

The gap

type: 'calendar' is a second axis, and the guard does not watch it. Measured at all three doors: a list view declaring type: 'calendar' (or viewType: 'calendar') with no calendar: block parses CLEAN.

That axis is live downstream: packages/plugin-list/src/ListView.tsx:2239-2243 in objectui pushes schema.viewType into the resolvable set unconditionally when it is one of nine names including 'calendar'. So an author can reach a calendar render through a key the spec's guard never consults.

Why this is not the old defect

⛔ Explicitly not a recurrence of objectstack#13748. Since objectui#7071 / objectui#7029 landed, ObjectCalendar no longer fabricates a date field, so this path now hits the renderer's own refusal screen loudly rather than silently piling every record onto today. The consequence is a worse diagnostic, not lost or misplaced data.

⇒ what is worth deciding is whether the guard's coverage should match the ways a calendar can actually be requested, or whether allowedVisualizations is deliberately the only gated axis and type: is meant to be handled by the renderer's refusal. ⛔ This card does not rule that.

Dedup

Targeted search on this repo, 4 hits, all closed, none covering the type: axis — every one is about allowedVisualizations:

  • objectstack#13748 — the root ruling
  • objectstack#13817 — the landed fix
  • objectstack#14073 — the page door
  • objectstack#14074 — other visualizations

The search returned a non-empty result set, so it is self-validating and needed no separate control.

Provenance

Measured by the objectui dev seat on branch claude/issue-7122-listview-crossfield-calendar-parity against the installed 17.3.0 artifact. That seat deliberately did not file it: objectui#7122's own cross-repo convention is that the accepting seat files the consumer-side card, so an objectui dispatch filing upstream would have been out of lane. It reported it to its PM instead, which is this card. ⇒ the lane judgement was the seat's and it was right; the filing is the PM's.

Downstream context: objectui#7122 is discharged by objectui PR #8311, which pins the allowedVisualizations refusal at the door objectui itself opens. Nothing downstream is blocked on this card.

Activity

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

Metadata

Metadata

Assignees

Type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions