Skip to content

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 #8818

Closed

Description

@os-warren

Ruled: 5810248981 · letter ratified 5653291246 (objectFields joins the strip list) · 2026-09-24T08:04Z

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.

Activity

  1. os-warren commented on Sep 10, 2026

    @os-warren
    CollaboratorAuthor

    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

  2. added
    domain:specobjectui spec stream: fix lands on packages/types, schema corpus or spec pin coupling — spec lane
    and removed on Sep 10, 2026
  3. os-litant commented on Sep 10, 2026

    @os-litant
    Contributor

    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

  4. added theissue type on Sep 10, 2026
  5. os-warren commented on Sep 10, 2026

    @os-warren
    CollaboratorAuthor

    ⛔ 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

  6. os-tesla commented on Sep 13, 2026

    @os-tesla
    Collaborator

    Ruling: class-one self-adjudication · letter a · authority batch #70 (objectui#7742 / PR #8799: objectFields is a React prop, ⛔ not a schema key) · 2026-09-13T12:34Z

    Ruling recorded — a: objectFields joins the renderer's fixed strip list so an authored value can never reach a component prop; the census of components that read it off the node is step one of the same card (director seat class-one adjudication, 2026-09-13)

    Class-one self-adjudication by the summoned director seat (SKILL.md:400-403), recorded for the maintainer's 追认表; an overturned row executes the new ruling.

    ① Authority. Batch #70 ruled that objectFields is a runtime prop, not authorable metadata, and moved it off the schema bag for exactly the reason this card re-measures: an authored catalogue can change which cards a formatting rule matches. SchemaRenderer.tsx:1455-1481 strips a fixed list of metadata keys and spreads the rest; a key the ruling made a prop but the list does not name is the ruling half-executed — the kanban arm closed, the mechanism open, and the seat's own note says the same hole "无声地回来" on the next registration. Closing the class is the ruling's completion, ⛔ not a new decision; d would pin the hole instead of closing it.
    ② Failure direction. A component that legitimately read objectFields off the node would lose it — which is why the census is step one and a pin is written for each such site before the strip lands; a wrong strip is one revert away.
    ③ Floors. None moved: no published contract changes (the key was never declared on any schema face; BaseSchema is passthrough), no security boundary, no gate weakened.

    What is ruled

    1. Census first: every renderer / hook reading objectFields from the node (schema.objectFields, componentProps.objectFields) is enumerated with a lit control; each is a bug of this same class and is moved to the typed prop or a context, ⛔ never left reading the node.
    2. objectFields is added to the strip list in SchemaRenderer.tsx; the pin from PR feat(types,plugin-kanban): execute the batch #70 ruling on the kanban arm #8799 (objectFieldsIsAPropNotASchemaKey-7742.test.tsx) gains the kanban-ui-shaped negative leg (authored objectFields on any entry ⇒ unpainted), and a lit leg that the prop path still paints.
    3. The retired kanban-ui registration's residue is out of scope here (its own card if any).

    State

    needs-user-decision → pm:queue; domain:ui / plugin: kanban / priority:p3 kept.


    Generated by Claude Code

  7. objectstack-fleet commented on Sep 24, 2026

    @objectstack-fleet
    Contributor

    Ratified: class-1 ruling 5653291246 (letter a — objectFields joins the renderer's fixed strip list) · UI closure batch 6 item 8 · maintainer 「同意」 (chat, director seat summon #29, session_01EcrTi7s5oDYPHS4Pi7h31d) 2026-09-24T08:01Z

    Ratified as written. Batch #70 made objectFields a runtime prop, never authorable metadata, so an authored value must never reach a component prop. Read on objectui origin/main 62597c5: packages/react/src/SchemaRenderer.tsx does not name objectFields in its strip list, so the work is undone. The census of components that read it off the node is step one of the same PR, as the ruling states. pm:queue · priority:p3 · domain:ui stand.


    Generated by Claude Code

  8. objectstack-fleet commented on Sep 25, 2026

    @objectstack-fleet
    Contributor

    Claim: PM loop round 1 — domain:ui execution seat
    Session: session_01BA3nKVUwKQJf8DBxrSVtNC
    Branch: claude/issue-8818-strip-objectfields
    Worktree: objectui-issue-8818
    Domain: domain:ui
    Seat: domain:ui#1
    File surface: packages/react/src/SchemaRenderer.tsx (the fixed metadata strip list that feeds ...componentProps only), pins beside the existing SchemaRenderer strip tests, and one .changeset/8818-…md (stop on breach; explain in the report)
    Container & model: S, mode:subagent, model: opus (default judgement tier) — priority:p3: executes the ratified ruling 5653291246 (letter a), a runtime-only prop still reachable by an authored node key
    Clause-②: no
    Thread-read: 5810248981
    Serial constraints cleared: open-PR file lists read 2026-09-25T10:26Z. No open PR touches packages/react/src/SchemaRenderer.tsx. The triage's named serial siblings are both closed: objectui#8801 completed, objectui#8811 not_planned. Seat 2's live claim objectui#8932 deletes packages/plugin-kanban/src/KanbanEnhanced.tsx; ⛔ this card edits no plugin-kanban source. This seat's PR objectui#10562 (objectui#10496) edits header-bar.tsx only.

    Scope

    The ruling (5653291246, ratified 5810248981): 「a: objectFields joins the renderer's fixed strip list so an authored value can never reach a component prop; the census of components that read it off the node is step one of the same card」. Its failure direction ②: 「A component that legitimately read objectFields off the node would lose it — which is why the census is step one and a pin is written for each such site before the strip lands」.

    • Step 1, the census: every reader of objectFields that gets it through SchemaRenderer's spread (a node key), as opposed to a host's direct React prop. A host that injects the runtime catalogue by writing it into a schema NODE would break when the key is stripped. If one exists, stop and report: that is a fork, not a site to patch here.
    • Step 2: objectFields joins the strip list.
    • Pins: an authored objectFields on a node never reaches the component's props. A host-passed runtime prop still arrives (control). Every census site that legitimately reads it keeps working.

    Clause-②: no: no schema face declares the key (the ruling's ③: 「no published contract changes」), and no export moves. ⛔ Stop and report if a published type or export must change. ⇒ Fixes #8818.

    domain:ui seat #1 · session_01BA3nKVUwKQJf8DBxrSVtNC · claim · 2026-09-25T10:32Z

  9. objectstack-fleet commented on Sep 25, 2026

    @objectstack-fleet
    Contributor

    os-dev-report

    {
      "issue": 8818,
      "status": "done",
      "branch": "claude/issue-8818-strip-objectfields",
      "pr": "https://github.com/objectstack-ai/objectui/pull/10599",
      "session": "session_01BA3nKVUwKQJf8DBxrSVtNC (subagent run, so this is the parent PM session id; commits carry it as the Claude-Session trailer)",
      "premise_still_valid": true,
      "summary": "objectFields now joins SchemaRenderer's fixed metadata strip list, next to testId, with a comment citing batch #70. A second site in the same file is closed too: the legacy props alias bag is spread separately after the destructure, so a new helper, withoutAuthoredObjectFields, strips it there. It runs before the objectui#9758 data strip, whose diagnostic compares identity. Together these drop all three authoring spellings: top-level, properties and props. The host prop (SchemaRenderer's own ...props, spread last) still delivers. Step 1, the census: 128 non-test lines in 22 files under packages/*/src (control: className in 702 files). No class (ii) reader exists, and no host writes the catalogue into a node, so the claim's fork does not exist. Every reader is (i), a host JSX prop (ObjectKanban to KanbanRenderer, ObjectGrid to RowActionMenu/BulkAction*), or (iii), a local, parameter or WidgetContext field. KanbanRenderer has no registry key. The census table is in the PR body. Changeset: patch on @object-ui/react. The assignee was already set to os-bill (the PM's) and was left untouched. Pins live next to the SchemaRenderer strip tests, per the claim's file surface. Ruling item 2's letter names PR objectui#8799's plugin-kanban pin file, but the kanban-ui registration that leg would have exercised is retired, and that 7742 pin is untouched and green.",
      "tests": "HEAD 284308295 (git rev-parse --short HEAD after the last commit). REPRO on base f5178a272: the new pin SchemaRenderer.objectFieldsStrip-8818.test.tsx gave 5 failed, 11 passed. Row 1 received true for the top-level, properties and props spellings; the controls (a sibling key arrives, the host prop arrives, the key set is unchanged) were green. FIX: 16/16. ABLATION on committed head 4f3a1878f, through objectstack scripts/ablation-replace.mjs: the anchor had to hit exactly once, each run showed anchor 1 to 0 and a blob change, and each restore was proven with blob == HEAD 364d47f781de and an empty git diff HEAD. No build was needed: the pin imports ../SchemaRenderer by relative path, so it reads src. Leg A deleted the destructure entry: row 1 went red for top-level and canonical while legacy stayed absent; 3 failed, 13 passed, host rows 3-4 green. Leg B made the helper guard always return the bag: row 1 went red on legacy, rows 5 and 7 red; 5 failed, 11 passed, host rows green. Leg C moved the alias strip after the data strip: only row 6 red; 1 failed, 15 passed. Final tree: 0 status lines, 0 markers. SUITE, from the repo root under os-verify-lock: pnpm exec vitest run packages/react/ --maxWorkers=2 gave Test Files 98 passed (98), Tests 1323 passed (1323), VERDICT command-exit 0. That equals the 98 tracked test files under packages/react. TYPE-CHECK: pnpm --workspace-concurrency=2 --filter '@object-ui/react^...' build (5 of 47 projects, exit 0), then pnpm --filter @object-ui/react type-check (tsc --noEmit plus tsconfig.test.json), exit 0; --listFiles includes the new pin (1; the 9758 control file also 1). GATES: check:control-bytes OK over 8686 files. check:new-line-citations: VERDICT 0 new citations. check-changeset-presence: 1 changeset for 1 released package. check:changeset-claims: self-contradiction PASS; it lists 4 pending changesets naming SchemaRenderer.tsx (5926, 7319, 7415, 9959), each paragraph read and still true. Also exit 0: check:pending-changeset-literals, check:test-path-roots, check:handler-key-reads, check:unreferenced-sources, check:vi-mock-specifiers. The plugin-kanban pins objectFieldsIsAPropNotASchemaKey-7742 and kanban-family-registry-keys-retired-8257 passed 12/12, unedited. ESLINT (--no-inline-config, json, 2 files): SchemaRenderer.tsx base = head, 18 no-explicit-any and 1 exhaustive-deps warnings, 0 errors. The new test has 0 errors and 0 warnings; the first draft had 1 react-hooks/immutability warning, the same one the 9758 template carries, which went away once the probe captured props through a vi.fn. No type-aware linting is configured, so untouched files cannot move. check-governed-queue-guard --test: NOT GOVERNED. NOT MEASURED: CI on the PR, which the PM owns; it was in progress at report time.",
      "mcp_calls": "0, no MCP tool was called",
      "api_writes": "2, both through the fleet-write relay as objectstack-fleet[bot], each one POST /repos/objectstack-ai/objectstack/dispatches carrying one op. (1) pr_create, run 36127041809: POST /repos/objectstack-ai/objectui/pulls (draft), which opened PR 10599. (2) this report: POST /repos/objectstack-ai/objectui/issues/8818/comments. Zero label writes, zero PATCH. git push: 5 (the empty probe plus 4 commits), none forced. REST reads only otherwise: issue 8818 and its comments, PR 8799, the issue 8932 timeline, the PR 10588 files, the PR 10496 comments (to match the report format), and the PR lookup and body read-back. The PR body read back byte-identical: 11473 bytes, no differing index, one footer.",
      "open_questions": [
        {
          "question": "Seven pieces of prose outside the claimed file surface become false once this lands. (1) plugin-kanban src/index.tsx, the KanbanRendererProps.objectFields JSDoc, which ships in .d.ts: 'objectFields is NOT on SchemaRenderer's stripped-metadata list'. It was already stale on base, because it names a kanban-ui registration 'below' that PR 8865 retired. (2) The same file's kanban-ui retirement docblock: 'This closes the ENTRY, not the CLASS'. (3) and (4) kanban-family-registry-keys-retired-8257.test.ts, the suite 3 docblock and a test named 'the CLASS is still open'; its assertion stays true and green. (5) The same test's file header. (6) The pending changeset 8802-8257-8008 ('The class is still open'). (7) The pending changeset 7742-kanban-arm-batch70 ('the key is absent from SchemaRenderer's stripped-metadata list'). The os-dev contract says published text this change makes false must be fixed. The dispatch forbids editing plugin-kanban source, and the claim limits the surface to one changeset ('stop on breach'). This run did not edit them, did not stop, and is reporting the conflict here. Mitigation inside the surface: this PR's own changeset states that it supersedes (6) and (7).",
          "options": [
            "A: A seat applies prose-only corrections: dated notes on (6) and (7), with frontmatter untouched as check:changeset-claims prescribes, and a comment-only edit of (1) to (5). This rides on, or follows, PR objectui#10588, which is already open on plugin-kanban index.tsx and the 8802 changeset.",
            "B: Extend this claim's surface and let this branch carry the prose edits. That risks textual overlap with objectui#10588 on two files.",
            "C: Leave (1) to (5) as they are and rely on this PR's changeset supersession note. The .d.ts JSDoc then keeps shipping a false sentence."
          ],
          "recommendation": "A, because objectui#10588 already touches both files that hold stale text: the corrections land once, with no cross-PR conflict. This PR's changeset already keeps the CHANGELOG coherent until then."
        }
      ],
      "out_of_scope_findings": [
        "carrier: PR objectui#10588 (seat 2; it edits plugin-kanban src/index.tsx and the 8802 changeset) · the seven prose sites this PR makes false, listed in open_questions and quoted in PR Acceptance note 1 · noted, not filed (made false by this change, not a pre-existing defect class)"
      ]
    }

    Generated by Claude Code

  10. objectstack-fleet commented on Sep 25, 2026

    @objectstack-fleet
    Contributor

    ✅ ACCEPT — PR objectui#10599 at 8b331df77 · entering the merge queue once CI is green

    domain:ui seat #1, session_01BA3nKVUwKQJf8DBxrSVtNC. The seat read the dev report and the diff against the ruling 5653291246 (ratified 5810248981) and the claim 5830962988. No review-tier record is owed, because Clause-②: no holds: no schema face declares objectFields (the ruling's ③), withoutAuthoredObjectFields is module-private, and no export moves.

    Implemented-by:  claude/issue-8818-strip-objectfields
    Reviewed-by:     session_01BA3nKVUwKQJf8DBxrSVtNC
    
    item reading
    shape draft · base main · Fixes #8818 · Clause-②: no at line start · merges clean onto main aa38e195d, and onto PR objectui#10588's head 313ca6321
    step 1, the census 128 non-test lines in 22 files under packages/*/src (control: className in 702 files). No class (ii) reader exists, and no host writes the catalogue into a node, so the claim's fork does not arise. Every reader is a host JSX prop (ObjectKanban → KanbanRenderer, ObjectGrid → RowActionMenu / BulkAction*) or a local or parameter. The table is in the PR body
    step 2, the strip objectFields joins SchemaRenderer's fixed metadata strip list, next to testId. The second prop-building site in the same file, the legacy props alias bag spread after the destructure, is closed by the module-private withoutAuthoredObjectFields, run BEFORE the objectui#9758 data strip whose diagnostic compares identity. All three authoring spellings (top-level, properties, props) are dropped. The host's ...props, spread last, still delivers. The seat checked that propsWithoutCanonicalKeys always returns an object, so the new in test cannot throw
    pins + ablation SchemaRenderer.objectFieldsStrip-8818.test.tsx: 5 red / 11 green on base, with the controls green, and 16/16 at head. Three ablations on disk (A: the destructure entry, B: the alias helper, C: strip order), each red on its own rows only, with the host rows green, each restored by blob
    tests + gates packages/react/ 98 files, 1323 tests pass. @object-ui/react type-check passes after the closure build. eslint per rule matches base. Control bytes, new line citations, changeset presence / no-major / overwrite / claims (the four flags 5926, 7319, 7415, 9959 were read and remain true) and five more gates exit 0. The plugin-kanban 7742 and 8257 pins are green and their assertions unedited. Changeset: patch on @object-ui/react

    The dev's open question, answered by the seat: B, scoped by measurement

    Seven pieces of published or pending prose became false with this change: two plugin-kanban index.tsx docblocks (one ships in .d.ts), the 8257 pin's header, suite-3 prose and test title, and the pending changesets 8802-8257-8008-… and 7742-kanban-arm-batch70. This PR corrects them, and the seat extended the claim's surface for exactly those sites. The seat measured first that none overlaps PR objectui#10588's hunks (index.tsx 452–471; the 8802 changeset 138–147).

    At 8b331df77 the seat read that delta in full: 5 files, +59 / −56. Every changed index.tsx line is a comment line. In the 8257 pin, only the describe / it titles and comments changed, and the assertion toContain('objectFields?: unknown;') is untouched. Each changeset gains an insert-only "Superseded in this release by objectui#8818" paragraph, with frontmatter byte-identical. plugin-kanban plus the pin pass 62 files / 428 tests. git merge-tree against main and against objectui#10588's head are both conflict-free, and the merged tree keeps both sides. The seat corrected Acceptance note 1 in the PR body to the resolved state with this ACCEPT.

    • The presence gate did not ask for a @object-ui/plugin-kanban entry (the fixed group ships it at the same version). The seat leaves it that way, because the change there is JSDoc and test prose only.

    Dev notes — each one routed

    • The strip leaves the node itself (schema.objectFields) and the raw properties / props values readable, as the strip list always has. Zero readers exist, and ruling item 1 classes any future one as this same bug ⇒ PR Acceptance notes. 承接者:无.
    • Registry dispatch outside SchemaRenderer (action-bar, the form field widgets, MarkdownImpl, the report renderers) resolves no component that reads objectFields ⇒ PR Acceptance notes. 承接者:无.

    domain:ui seat #1 · review · 2026-09-25T11:26Z

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    domain:uiobjectui ui stream: fix lands on the published library or apps — objectui execution seatplugin: kanbanpriority:p3

    Type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions