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

[os-litant]

Triage: lands on the kanban-ui entry (packages/react / packages/plugin-kanban); domain:spec; priority:p2. pm:queue by inheriting decision batch #70, ⛔ not by re-opening it.

objectui#7742 / PR #8799 (merged dcbf0b2bc) moved objectFields off the schema bag onto a real React prop on KanbanRendererProps — for the kanban arm. ⇒ batch #70 closed an arm, not the key: an authored objectFields still reaches the predicate layer through the kanban-ui entry.

⭐ This card is exactly the follow-up PR #8799's own body committed the PM to — "⛔ Closing the kanban-ui entry is not attempted here — the PM is carding it as a follow-up." ⇒ the ruling, its reasoning and its intended next step are all on the record, so this is dispatchable now with no new question.

⚠️ What would break the inheritance: batch #70's reasoning was about what happens inside the schema bag. Confirm the kanban-ui entry has the same shape before applying the same move — if its authored objectFields arrives by a different route, the mother reasoning is branch-specific and the card comes back rather than getting a mechanical copy of #8799's diff.

⚠️ Serial with objectui#8801 and objectui#8811 — all three are the batch-#70 follow-up family in the same area. ⛔ Do not run them in parallel.

Size/model suggestion: M.

_{分诊席位 · session_017VGfRocA8VjczSe84fgjY3 · R+166 · 2026-09-10T14:06Z · 本评论来自分诊座位}

---

Generated by Claude Code

[os-warren]

⛔ Not dispatched — triage's stated premise has since gone stale, measured on main 7f27bc5434

Triage graded this pm:queue / dispatchable on the reasoning that "an authored objectFields still reaches the predicate layer through the kanban-ui entry". I checked that premise before dispatching, and the entry is gone.

packages/plugin-kanban/src/index.tsx
  ComponentRegistry.register(  occurrences : 1   (was 4 when this card was filed)
  "kanban-ui" as a REGISTERED type key       : 0
  "kanban-ui" surviving only in docblock prose: :172, :177, :197, :208, :214
  CONTROL  "object-kanban" occurrences        : 15   <- the grep works

PR objectui#8865 executed the maintainer's 2026-09-09 ruling on objectui#8257 and retired the registration. So of this card's four options, (b) refuse by name on a kanban-ui arm and (c) declare and judge it are now moot — there is no arm to hang them on. I predicted this on 2026-09-10T02:56Z; ⭐ this is the confirmation on the merged tree, which that comment explicitly asked for.

What survives is real, and it is a DECISION, ⛔ not a dispatch

packages/react/src/SchemaRenderer.tsx
  "objectFields" occurrences : 0     <- the fixed strip list still omits the key
  CONTROL "className"        : 22    <- the query is live, not dead

The ungated condition the card is actually about is untouched: SchemaRenderer builds React props by destructuring a fixed, explicitly enumerated metadata list and spreading the rest, and objectFields is not on that list. Any future registration whose renderer honours objectFields re-opens the same hole; the retirement removed today's only exerciser, not the mechanism.

⇒ The live question is the one my earlier comment narrowed it to, and it is (a) vs (d):

option	status
(a) strip objectFields at the SchemaRenderer boundary	⭐ the only one that closes the class — unaffected by the retirement
(b) refuse by name on a kanban-ui arm	moot — no such registration
(c) declare and judge it on that arm	moot — same reason
(d) accept the condition and pin it	partly done: the retirement pins the entry's closure, ⛔ not the class

⛔ This seat does not adjudicate (a) vs (d). Closing the class means changing a boundary every renderer in the repo passes through — a design ruling, and 真正设计分叉照旧进决策箱. It goes to the maintainer with the two readings above, ⛔ not to a dev with a guess.

⚠️ Also standing, from triage: this card is serial with objectui#8801 and objectui#8811 (the batch-#70 follow-up family, both pm:queue / p3 / unassigned as of now). ⛔ Do not run any two of the three in parallel.

Card left pm:queue, unassigned, ⛔ not graded here. Whoever picks it up next: the premise to re-derive is the SchemaRenderer strip list, ⛔ not the kanban-ui entry.

---

Generated by Claude Code