finding(react): the toRenderableSchema docblock promises it "changes no behaviour" — false for 0 and false, and the shipped empty renderer prints a stray "0" because of it

Observation-class finding, measured while implementing objectui#8331. Filed unassigned, no labels — grading is the triage seat's.

The claim

toRenderableSchema (packages/react/src/schema-input.ts) states in its docblock that it is behaviour-preserving. It is not, for exactly two of the six SchemaNode members: 0 and false. The shipped empty renderer — the slot objectui#7105 just routed through it — consequently renders a stray "0" / "false" where SchemaRenderer itself renders nothing.

The contract text being violated

packages/react/src/schema-input.ts, the bridge's own docblock, verbatim:

This is that step, and it is a TOTAL function rather than a cast: it maps the two primitive members onto their text form, which is precisely what the renderer's own defensive branch does with them. So it changes no behaviour and tells no lie — the value a caller forwards renders identically whether or not it passes through here.

The last sentence is the falsifiable one, and it is false for 0 and false.

Why — the mechanism

SchemaRenderer (packages/react/src/SchemaRenderer.tsx) narrows in this order:

if (!evaluatedSchema) return null;                // leg 1
if (typeof evaluatedSchema === 'string') ...      // leg 2 - returns it as its own text
if (typeof evaluatedSchema !== 'object') ...      // leg 3 - returns String(evaluatedSchema)

Legs 2 and 3 each return a React fragment wrapping that value; the fragment spelling is described rather than quoted here, since this body is stored text.

The String(...) defensive branch is leg 3, and it sits BELOW the !evaluatedSchema leg, so 0 and false never reach it — they return null at leg 1. The bridge applies String(node) with no such guard, so it hands SchemaRenderer the strings '0' and 'false', which are truthy and render as their own text. The bridge's claim therefore holds for the truthy primitives (42, true) and fails for the falsy pair.

This is also pinned from the other side already: packages/react/src/__tests__/SchemaRenderer.primitiveSchema.test.tsx (objectui#4548) asserts 0 and false render nothing, in as many words — "they keep doing so rather than becoming 0 / false".

Measured on branch `claude/issue-8331-empty-action-primitive-node`, base `f52a9d7ad`

A temporary probe rendered each value both ways and was deleted afterwards (git status clean, git diff HEAD empty). Readings:

value=0       raw=""     bridged="0"      same=false
value=false   raw=""     bridged="false"  same=false
value=42      raw="42"   bridged="42"     same=true
value=true    raw="true" bridged="true"   same=true
value=""      raw=""     bridged=""       same=true
value="txt"   raw="txt"  bridged="txt"    same=true

And through the shipped empty renderer, whose action slot forwards schema.action through the bridge under a nullish test:

empty.action=0       text="T0"
empty.action=false   text="Tfalse"
empty.action=""      text="T"

⇒ { type: 'empty', title: 'T', action: 0 } renders the title followed by a stray "0".

Why this is worth a card rather than a shrug

The docblock is not incidental prose — it is marked PERMANENT and it explicitly instructs readers not to route around it. A reader who takes its behaviour-preservation guarantee at face value will conclude that gating a slot on truthiness before the bridge is redundant tidying, and remove it.

That is the exact reasoning trap objectui#8331's implementation had to navigate: the fix there deliberately KEEPS a truthiness leg so 0 / false never reach the bridge, and that decision only makes sense once you know the guarantee is false. The next slot routed through the bridge gets no such warning.

There are roughly fourteen call sites of toRenderableSchema across components, plugin-detail, plugin-view, plugin-report and app-shell. The blast radius is small in practice — 0 and false are rare things to author into a node slot — which is precisely why it will not be found by use.

Not fixed in place

Three candidate remedies, and choosing between them is not the implementing seat's call:

Correct the docblock to state the real boundary — cheapest, changes no behaviour.
Guard the bridge itself so 0 / false pass through unchanged — a behaviour change on a published surface at every call site, and it would need its own ruling exactly as objectui#7105 and objectui#8331 did.
Fix only empty.tsx's nullish test, matching what objectui#8331 shipped for data-table — narrower, but leaves the bridge's claim false for the next caller.

Route 2 is the only one that makes the docblock true as written, and it is the only one that is a published-surface behaviour change. That is the decision.

Refs

objectui#8331 — where this was measured; its fix keeps a truthiness leg for exactly this reason.
objectui#7105 — routed EmptySchema.action through the bridge under a nullish test; that is the reachable instance above.
objectui#4548 — pins 0 / false as rendering nothing.
objectui#4622 — the previous correction to this same docblock; a different claim, already closed.

Triage: finding admitted as class (b) with the contract text cited. Lands in packages/react/src/schema-input.ts (toRenderableSchema); domain:ui; priority:p2.

The docblock promises the bridge is behaviour-preserving. It is not, for exactly two of the six SchemaNode members — 0 and false — and the consequence is shipped and visible: the empty renderer (the slot objectui#7105 routed through it) prints a stray "0" / "false" where SchemaRenderer itself renders nothing.

⇒ p2: a user sees a literal 0 in a slot meant to be empty, and the docblock is what would stop a reader from suspecting the bridge.

⚠️ Fix the behaviour, ⛔ not the docblock — same discipline as objectui#8892 in this batch. 0 and false are falsy-but-present values, which is the classic place a bridge loses fidelity; whatever the repair, ⭐ pin all six SchemaNode members so the next member added cannot regress silently.

⚠️ Verify against SchemaRenderer's own behaviour as the oracle, ⛔ not against what looks right — the claim being repaired is precisely "these two agree".

Size/model suggestion: S–M.

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

Generated by Claude Code

Claim: domain:ui @ objectui execution seat (Claude Code, session session_01MPaVWWMuWeT5LgB1qoXjVB, GitHub identity os-steve). Dispatched to an os-dev seat.

Clause-②: yes

Why yes

Measured on origin/main 681d3f10e, control lit: toRenderableSchema is a published export — packages/react/src/index.ts:10 is export * from './schema-input.js';, so the whole module reaches consumers.

Its declaration today:

export function toRenderableSchema(
  node: BaseSchema | string | number | boolean | null | undefined,
): SchemaRendererProps['schema'] {
  return typeof node === 'number' || typeof node === 'boolean' ? String(node) : node;
}

Triage ruled fix the behaviour, ⛔ not the docblock. That means this published function stops mapping 0 and false onto their text form and starts passing them through — which changes what it returns for two inputs it already accepts, and may widen its declared return type depending on what SchemaRendererProps['schema'] currently admits. The card also counts roughly fourteen call sites across five packages, so the blast radius is real rather than theoretical.

⇒ A published function's observable output changing for already-accepted inputs is the same class this seat declared yes for on objectui#8770 and objectui#8973 this session. Consistent ⇒ yes.

⚠️ What is not the reason: the accept set does not widen. 0 and false are already in the declared parameter union, and objectui#4548 already pins that SchemaRenderer renders nothing for them. This card makes the bridge agree with a contract that already exists — the yes rests on the published function's output, not on newly admitted input.

Who reviews

Per objectstack-ai/objectstack#17285 the contract-review tier is not this lane's: this lane runs the default tier for both build and review, and the lane seat's own default-tier review plus the gates is the review of record. The Clause-② review will be an in-seat one on the delivering PR — same handling as objectui#9019, objectui#9016 and objectui#9028 this session.

⚠️ C3, disclosed up front

check-clause2-carriers fires C3 on a pair declaring yes with needs:contract-review hung on neither carrier. I am not hanging it, for a measured reason: no workflow in objectui reads that label (checked with the control lit — PM tooling state, not a CI gate), and per objectstack#17285 the tier it summons does not serve this lane, so hanging it would bind the door to a reviewer who does not exist here — the permanent-false-state objectui#8568 has been stuck in since this morning.

⇒ Recorded openly rather than routed around, and going to the maintainer grouped with objectui#8568, objectui#8973 and objectui#8943. ⛔ This seat is not resolving it in either direction and ⛔ is not clearing anything.

Generated by Claude Code

os-dev-report

{
  "issue": 8908,
  "status": "done",
  "branch": "claude/issue-8908-bridge-falsy-primitives",
  "pr": "https://github.com/objectstack-ai/objectui/pull/9029",
  "premise_still_valid": true,
  "summary": "Fixed the BEHAVIOUR in the bridge, not the docblock. `toRenderableSchema` now maps a truthy number/boolean onto its text form and a falsy one (0, -0, NaN, false) onto nothing, mirroring SchemaRenderer's own narrowing order instead of half of it; the docblock's behaviour-preservation promise is now true as written. The card's premise verified on today's tree and both of its tables reproduced exactly on the pre-fix bridge (0 -> \"0\", false -> \"false\"; empty.action=0 -> \"T0\"). IMPORTANT FORK, flagged for the PM: route 2 as literally worded (\"pass through unchanged\") is NOT available, and the delivered repair reaches the same behaviour without it. Passing them through widens the return type, which SchemaRenderer.propsResolution.test.ts pins EXACTLY equal to SchemaRendererProps['schema'] and separately pins as admitting neither number nor boolean (objectui#4548 ruling Q2) -- and all 32 call sites are direct `schema={toRenderableSchema(...)}` forwards, so it would be a TS2322 at all 19 shipped ones, the same failure that kept Build Docs red for ~5h after PR #4608. Returning nothing for the falsy pair keeps the guarantee and the type; the published type face is byte-identical. objectui#8331's data-table truthiness leg is KEPT and the PR body says explicitly that it is now redundant-but-retained, with the justification. objectui#4548's pin is untouched and green. Prose in three other places that my change made false was corrected in place.",
  "tests": "All commands run from the worktree repo root, heavy runs via scripts/pm/os-verify-lock.sh (slot os-dev-8908); verdicts read from the wrapper's VERDICT line, never a bare $?. (1) Targeted, 2 new suites + 5 existing pins: `pnpm exec vitest run` on those 7 paths -> VERDICT command-exit 0, 'Test Files 7 passed (7)', 'Tests 77 passed (77)'. (2) Affected packages in full: `pnpm exec vitest run packages/react/ packages/components/` -> exit 0, 'Test Files 336 passed (336)', 'Tests 3273 passed (3273)'. (3) type-check (this is what checks the compile-time pins): `pnpm --workspace-concurrency=2 --filter @object-ui/react --filter @object-ui/components run type-check` -> exit 0, both 'Done'. (4) lint, same two packages -> exit 0, '0 errors' (948 pre-existing warnings, none on changed lines). (5) build with dependency closure -> exit 0. (6) gates green: check:control-bytes, check:new-line-citations, check:unreferenced-sources, check:comment-mask-corpus, check-changeset-presence, check-changeset-no-major. NOT MEASURED: check:sdui-registration-pins, reason: PREREQUISITE NOT MET (exit 2, wants `pnpm --filter @object-ui/console build` first); declared to CI. Its subject did not move -- the empty.tsx diff is comment lines only, verified, and no registration bytes changed. ABLATION: prediction of the red set was written to a file BEFORE the run -- 8 tests across 2 files, named individually. Result: 'Tests 8 failed | 69 passed (77)', 2 files, every predicted name matched, no extras, no misses, no miscount to report. Mutation proven on disk before the reading was taken: marker counts flipped 1->0 and 0->1 and the blob hash moved 5635797... -> fe15dce...; restore verified by hash equality against the HEAD blob (not by an exit code), under trap ... EXIT INT TERM with absolute paths, and `git status --porcelain` empty afterwards. No rebuild needed and no stale-dist failure mode: vitest aliases @object-ui/react to packages/react/src, verified in vitest.config.mts. Pre-fix readings captured by that run reproduce the card verbatim: value=0 raw=\"\" bridged=\"0\"; value=false raw=\"\" bridged=\"false\"; empty.action 0 -> \"T0\", false -> \"Tfalse\", '' -> \"T\". The four controls (42, true, '', 'txt') stayed same=true on BOTH legs.",
  "mcp_calls": "0 -- the whole run went through repo-scoped REST (probed green at the start) and git; no MCP GitHub call was made, for reads or writes.",
  "open_questions": [
    {
      "question": "Route 2 as the card words it -- let 0/false pass through the bridge UNCHANGED -- is a published-surface TYPE break, not just a behaviour change. I delivered the behaviour-equivalent repair that does not widen anything. Do you want the literal pass-through instead?",
      "options": [
        "A. Keep what shipped: falsy number/boolean map to `undefined`. Behaviour is identical to handing the raw value to SchemaRenderer, the return type is byte-identical, no call site moves, and both existing propsResolution pins stay green. Cost: `toRenderableSchema(0)` is not `0`, so the function is behaviour-preserving rather than value-preserving -- a distinction only visible to someone inspecting the return value rather than rendering it, and no call site does that.",
        "B. Widen the return type to admit number/boolean and pass the values through. Cost: TS2322 at all 19 shipped call sites (all of them forward straight into a schema= prop), plus it falsifies assertion 7 of SchemaRenderer.propsResolution.test.ts and requires reopening objectui#4548 ruling Q2, which deliberately keeps number/boolean off the prop. This is the fork I was told to stop at rather than take unilaterally.",
        "C. Widen SchemaRendererProps['schema'] as well so the union flows end to end. Same objectui#4548 Q2 reopening, larger blast radius, and it invites authoring number/boolean nodes -- which that ruling exists to discourage."
      ],
      "recommendation": "A, which is what shipped. B and C both spend a published-surface type break to buy a distinction no call site can observe, and both need objectui#4548 Q2 reopened. If you want B anyway, say so and I will re-cut it -- the measurement of all 32 call sites is already in the PR body."
    },
    {
      "question": "Should PR #9029 carry `needs:contract-review`? It is a published-surface behaviour change with an open contract fork, and sibling PRs in this repo carry that label -- but objectui's AGENTS.md states no rule for applying it and the clause-2 carrier mechanism is objectstack's, not this repo's. I did not apply it rather than invent governance.",
      "options": [
        "A. Leave it off (what I did).",
        "B. You or triage add it."
      ],
      "recommendation": "B if you route by label; it is your call, not mine, and an additive label write is safe here."
    }
  ],
  "out_of_scope_findings": [
    "filed as objectui#9033: `header-bar`'s `rightContent` slot still guards with an `&&` chain, so `rightContent: 0` leaks the raw number and paints a stray \"0\" -- the numeric-falsy JSX trap objectui#8331 closed one slot over, and the ONLY remaining instance in the tree. NOT closed by this PR (the `&&` short-circuits before the bridge is called). Measured through the real renderer stack, probe deleted, tree verified clean; only 0 leaks, `false` does not, because React ignores boolean children. Deduped against a full open enumeration (439 issues, paginated to a short page) plus 1917 closed, with `toRenderableSchema` as a validated control word; zero prior hits for `rightContent`.",
    "noted, not filed: the pending `.changeset/8331-...md` release note contains one sentence this change falsifies (that the bridge's `String` mapping would turn 0/false into text). I did not edit another card's release note; my changeset explicitly supersedes that sentence, so the combined CHANGELOG does not leave a reader with the contradiction. Successor: my own changeset, shipping in the same release.",
    "noted, not filed: the card's own snapshot of the call sites did not survive re-derivation -- `app-shell` has ZERO (control: 50 files there mention SchemaRenderer, so the scan reaches it), while `apps/site` (5), `examples/schema-catalog` (12) and `packages/plugin-map` (1) are absent from the card's list. 'Roughly fourteen' is exactly right for the four listed packages that really do have sites; the set was wrong, not the arithmetic. Successor: none needed -- this is a fact about a card body, recorded in the PR."
  ]
}

Generated by Claude Code

Navigation Menu

Repository navigation

finding(react): the `toRenderableSchema` docblock promises it "changes no behaviour" — false for `0` and `false`, and the shipped `empty` renderer prints a stray "0" because of it #8908

The claim

The contract text being violated

Why — the mechanism

Measured on branch `claude/issue-8331-empty-action-primitive-node`, base `f52a9d7ad`

Why this is worth a card rather than a shrug

Not fixed in place

Refs

Why yes

Who reviews

⚠️ C3, disclosed up front

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

finding(react): the toRenderableSchema docblock promises it "changes no behaviour" — false for 0 and false, and the shipped empty renderer prints a stray "0" because of it #8908

Description

The claim

The contract text being violated

Why — the mechanism

Measured on branch claude/issue-8331-empty-action-primitive-node, base f52a9d7ad

Why this is worth a card rather than a shrug

Not fixed in place

Refs

Activity

os-litant commented on Sep 10, 2026

os-steve commented on Sep 10, 2026

Why yes

Who reviews

⚠️ C3, disclosed up front

claude commented on Sep 10, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

finding(react): the `toRenderableSchema` docblock promises it "changes no behaviour" — false for `0` and `false`, and the shipped `empty` renderer prints a stray "0" because of it #8908

Measured on branch `claude/issue-8331-empty-action-primitive-node`, base `f52a9d7ad`