finding(react,plugin-kanban): an AUTHORED `objectFields` still reaches the predicate layer on the `kanban-ui` entry — batch #70 closed the `kanban` arm, not the key

[os-warren]

Filed by the domain:spec @ objectui PM seat, session session_01Jmxdo7bmeqCQHLSfmLVX9w, as the follow-up PR #8799's own body commits the PM to:

⛔ Closing the kanban-ui entry is not attempted here — the PM is carding it as a follow-up.

⛔ No domain:* and no priority:* applied — routing and grading belong to triage, and this seat does not produce them.

What batch #70 actually closed

objectui#7742 / PR #8799 (merged dcbf0b2bc, 2026-09-09) moved objectFields off the schema bag onto a real React prop on KanbanRendererProps. The stated reason was that inside schema the key was reachable by an author: BaseSchema is .passthrough(), no schema face declares or judges the key, and the predicate layer uses it to decide how a conditional-formatting rule reads a field — so an authored catalogue can change which cards a rule matches.

That move closes the kanban arm. It does not close the key, and PR #8799 says so in three places. This card is the part it deliberately left open.

Measured on origin/main dcbf0b2bc by this seat — ⛔ not transcribed from the PR

The registration face

packages/plugin-kanban/src/index.tsx, every ComponentRegistry.register( call in the file:

line	type key	renderer
:252	kanban-ui	KanbanRenderer
:351	kanban-enhanced	inline ({ schema })
:579	object-kanban	ObjectKanbanRenderer
:589	kanban	ObjectKanbanRenderer

⚠️ Note for anyone carrying forward the objectui#8410 screen: that screen has this mapping inverted (it reads KanbanRenderer as serving kanban). PR #8799 corrected it and the table above is a fresh reading on the merged tree.

The renderer now takes the prop

packages/plugin-kanban/src/index.tsx:217:

export const KanbanRenderer: React.FC<KanbanRendererProps> = ({ schema, objectFields }) => {

The strip list does not name the key — and this is the whole mechanism

packages/react/src/SchemaRenderer.tsx builds its React props by destructuring a fixed, explicitly enumerated list of metadata keys off the node and spreading the rest:

packages/react/src/SchemaRenderer.tsx:1455-1481
    …
    dataSource: _dataSource,
    _hidden: __hidden,
    _disabled: __disabled,
    responsiveStyles: _responsiveStyles,
    ...componentProps            ← :1480
  } = evaluatedSchema;
…
:1576        ...componentProps,  // Spread non-metadata schema properties as props

objectFields in that file: grep exit 1, 0 occurrences.
Firing control on the same instrument, same file: className → 22 occurrences, exit 0.

⇒ The zero is a reading. objectFields is not stripped, so on a kanban-ui node an authored objectFields survives into ...componentProps and is spread as a React prop — landing on the very prop PR #8799 added, and reaching resolveConditionalFormatting exactly as it did before the move.

The behavioural evidence

⚠️ Attributed, not re-run here: PR #8799 measured this end-to-end through the real SchemaRenderer, with the positive leg asserted first as the firing control for the negative:

node	authored objectFields	outcome
kanban-ui	absent	unpainted
kanban-ui	present	painted rgb(255, 0, 0)
kanban	present	unpainted

The kanban row is the ruled arm genuinely closing: ObjectKanbanRenderer serves that key and discards its rest-spread (void _props;), so the value reaches nothing.

⚠️ Its pin — packages/plugin-kanban/src/__tests__/objectFieldsIsAPropNotASchemaKey-7742.test.tsx — renders KanbanRenderer directly and therefore never exercises SchemaRenderer. So the two kanban-ui rows above are measured but not pinned. That is the gap this card sits in: nothing in the repository will go red if the behaviour changes in either direction.

What is NOT claimed here

• ⛔ Not claimed that this is a vulnerability with a named exploit. kanban-ui is the schema-only entry: its data arrives whole from the same author who would write the catalogue. Whether an author fooling their own board is a defect or a non-event depends on who authors these documents in a deployment, and this seat does not know that.
• ⛔ Not claimed that stripping the key is free. objectFields is now a declared prop on a published component's props interface; a consumer rendering KanbanRenderer directly passes it legitimately. Any strip must land at the SchemaRenderer boundary or on a kanban-ui schema arm, ⛔ never by removing the prop.
• ⛔ Not claimed that countsAreWindowed is settled. PR feat(types,plugin-kanban): execute the batch #70 ruling on the kanban arm #8799 records it as the same shape and the same argument — internal, injected by ObjectKanban, absent from the registry inputs, still on the schema bag and author-reachable on kanban-ui. Batch Add cloud storage functionality with Vercel KV integration in studio #70 did not name it. objectui#8307 owns the key; whichever way this card is ruled should say whether that ruling reaches it.

The decision this card asks for — ⛔ none chosen here

Enforce-or-remove (ADR-0049) on an author-reachable channel that no face judges:

(a) Strip objectFields at the SchemaRenderer boundary — add it to the enumerated metadata list at :1455-1481. Closes every entry at once, including any future renderer. ⚠️ Cost: that list is a global strip; a component that legitimately wants an authored objectFields React prop from a node loses it silently. Nothing in the repo does today — that is a claim the implementer must measure, not inherit from this card.

(b) Refuse objectFields by name on a kanban-ui schema arm — a retirementTombstone, the mechanism PR #8799 used four times. Loud, local, and it tells the author what happened. ⚠️ Cost: kanban-ui would need an arm that declares it; check whether one exists before pricing this.

(c) Declare and judge it — make the catalogue an authorable, validated input. ⚠️ This is the direction batch #70 rejected for the kanban arm; taking it here would leave the two entries of one plugin disagreeing about the same key, which is the shape objectui#8801 and objectui#8802 are already open about.

(d) Accept it, and pin it as accepted — record that kanban-ui is an author-owned surface where the catalogue is the author's to supply, and add the SchemaRenderer-exercising pin the current one deliberately isn't, so the behaviour stops being merely measured.

This seat's recommendation: (a), with (d)'s pin regardless of which route wins. Reason: the key's only legitimate producer is ObjectKanban, which supplies it as a React prop and never through a node, so a strip at the boundary costs nothing measured and closes the class rather than one entry. But ⛔ (a) is the option that needs the "nothing legitimately authors it" measurement, and this seat has not taken it — that measurement is the first thing whoever implements owes.

⚠️ Whichever way this is ruled, the pin is not optional. Today both kanban-ui rows are measured and unpinned, so the next refactor can move this behaviour in silence in either direction — which is the same failure mode that let the original defect ship.

Refs: objectui#7742 (the ruled card) · PR #8799 (which measured this and scoped it out) · objectui#8801 (ObjectKanbanSchema.allowCollapse, one arm over) · objectui#8802 (the registry inputs divergence) · objectui#8307 (countsAreWindowed) · objectui#8410 (the screen whose registration mapping is inverted) · ADR-0049.

[os-warren]

This card's disposition changed — PR #8865 closes the kanban-ui ENTRY as a side effect, ⛔ not the class

domain:spec @ objectui PM seat, session session_01Jmxdo7bmeqCQHLSfmLVX9w.

⛔ I said on PR #8865's landing plan that this card was "being updated there" and then did not update it. The delta contract review caught the omission — "#8818 has no comment and its body is unchanged since creation; the verdict said 'verify before clearing'". This is that update, later than it should have been.

What changed under this card

Maintainer ruling (2026-09-09, recorded on objectui#8257): retire the kanban-enhanced and kanban-ui registrations — both measured as authored 0 times in the repository, JSON and TS. PR #8865 executes it.

This card is about the kanban-ui entry: an authored objectFields reaches the predicate layer there, because SchemaRenderer strips a fixed enumerated metadata list that does not include objectFields (0 occurrences in that file; firing control className → 22), and KanbanRenderer — registered for kanban-ui — declares objectFields as a real prop.

⇒ Retiring the registration closes this entry. With no kanban-ui registration, no authored node resolves to KanbanRenderer through the registry, so the schema-borne route this card describes has no entry point.

⛔ But it closes the ENTRY, not the CLASS — and that distinction is the whole reason this card should not just be closed

objectFields is still absent from SchemaRenderer's stripped-metadata list. PR #8865 says so in its changeset and pins it in kanban-family-registry-keys-retired-8257.test.ts. ⇒ if any renderer ever declares an objectFields prop again, the hole returns, with no gate to catch it.

That is precisely what this card's option (a) — strip objectFields at the SchemaRenderer boundary — would have closed. The retirement takes the cheaper route by removing the only entry that currently exercises it.

this card's option	status after PR #8865
(a) strip at the SchemaRenderer boundary	⭐ still the only one that closes the class — unaffected by the retirement
(b) refuse by name on a kanban-ui arm	moot — the registration is gone
(c) declare and judge it	moot for this entry
(d) accept and pin	partly done — the retirement pins the entry's closure, ⛔ not the class

⇒ What I am NOT doing

⛔ Not closing this card, and ⛔ not clearing it on PR #8865's merge. The verdict's own words on objectui#8257 were "verify before clearing". What survives is a real, measured, ungated condition: a fixed strip-list that omits a key the predicate layer honours.

⚠️ Whoever rules this card next should read it as narrowed, not answered: the question is no longer "should we close the kanban-ui entry" (done, by retirement) but "should the class be closed at the SchemaRenderer boundary, or is a pin enough?"

⚠️ And re-derive on the then-current main — PR #8865 is still in review at the time of writing, so none of the above is on main yet.

Refs: objectui#8257 (the ruling) · PR #8865 (the execution) · the REWORK verdict 5610751162 and its delta re-review · objectui#8802 · objectui#8008.

---

Generated by Claude Code