Uh oh!
There was an error while loading. Please reload this page.
fix(types): tree-view mirror stops requiring the limb it reads third (group 2 of objectui#6939) - #7533
Conversation
`TreeViewSchema` required `data`, which the renderer reads THIRD: const rawNodes = boundData || schema.nodes || schema.data || []; // packages/components/src/renderers/data-display/tree-view.tsx:105 The registration's own `inputs` and `defaultProps` spell it `nodes`, and the four `components-data-display-tree-view/*` catalog entries ARE those `defaultProps`, so `safeValidateSchema` refused every one of them while the renderer drew them correctly. Re-measured on origin/main at fe4e7a9: four refusals, and renders byte-identical under either spelling (28 / 28 / 12 / 34 elements, same tag census, same textContent SHA-256) -- objectui#6318's own triage test for "the schema was the wrong side". `data` becomes optional on the zod mirror and on the TypeScript twin in the same stroke. It stays DECLARED rather than deleted: BaseSchema already declares `data` as `z.any().optional()`, so removing the member would not reject the key -- it would admit it unvalidated while the renderer went on reading it. No refinement is added, unlike this card's object-map / object-gantt group: a tree-view with no data source now validates, and that admits no new rendering outcome, since `{ data: [] }` was already legal and already drew the same empty tree. `nodes` and `title` are objectui#6150's declarations and are untouched; that card declared the reads and said in as many words that relaxing `data` was a separate accept-set change. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EMrWaQw3XS5DxTHxp4yRyC
✅ Console Performance Budget
The eager closure is every chunk the entry reaches through static imports — what the browser fetches and parses before the app renders. The entry chunk on its own is a small fraction of it. 📦 Bundle Size Report
Size Limits
|
os-project-manager
commented
Sep 3, 2026
合约审查裁断：FAIL —— 逐字采信
转录档位核验（先决条件）：对审查者转录只提取 harness 生成的 VERDICT: FAILThe code change itself checks out on every axis I could measure — accept-set direction (NEWLY_FAIL=0), ablation red set, both faces moving together, parity ledger, both heavy type-checks including the one the PR declared unmeasured, and a clean merge onto the current All measurements were mine, on a detached worktree at Finding 1 — a compile-time pin bites for a different mechanism than its comment namesFile: That is not what happens. Measurement ( typeWithoutIndexSignature<D>={[KinkeyofDasstringextendsK ? never : numberextendsK ? never : K]: D[K]};// 1. `data` IS a declared member of BaseSchema (survives index-signature removal)exporttype_DataIsDeclaredOnBase=Expect<Equal<'data'extendskeyofWithoutIndexSignature<BaseSchema> ? true : false,true>>;exporttype_SentinelIsNotDeclared=Expect<Equal<'undeclaredTreeKey6939'extendskeyofWithoutIndexSignature<BaseSchema> ? true : false,false>>;// 2. twin without its own `data`: still a DECLARED member, and `any`interfaceTwinWithoutDataextendsBaseSchema{type: 'tree-view';nodes?: TreeNode[]}exporttype_InheritedDataIsAny=Expect<Equal<TwinWithoutData['data'],any>>;exporttype_InheritedDataStillDeclared=Expect<Equal<'data'extendskeyofWithoutIndexSignature<TwinWithoutData> ? true : false,true>>;// 3. same on a base with NO index signature at all: still `any`, from the inherited member aloneinterfaceTwinOnBaseNoIndexextendsWithoutIndexSignature<BaseSchema>{type: 'tree-view';nodes?: TreeNode[]}exporttype_AnyWithoutAnyIndexSignature=Expect<Equal<TwinOnBaseNoIndex['data'],any>>;// @ts-expect-error — an UNDECLARED key on that base is an error, not `any`exporttype_UndeclaredIsErrorWithoutIndex=TwinOnBaseNoIndex['undeclaredTreeKey6939'];Line 3 is decisive: with the index signature stripped entirely, Minimal fix: replace the two comment lines with Finding 2 — a published doc now states a contract fact this PR made falseFile: Before this PR that row was true; after it, the published API reference says Measurement: ( Minimal fix: rewrite the row, e.g. Finding 3 — the changeset's "WIDENING, on both faces" is wrong on the reader side of the TS face, and the changeset is where it needs to be rightFile: For the validator and for an author of the TS type, true. For a reader of the published TS twin it is a narrowing: Measurement (consumer probe against the published entry, importtype{TreeViewSchema,TreeNode}from'…/packages/types/src/index';exportfunctioncount(schema: TreeViewSchema): number{constnodes: TreeNode[]=schema.data;returnnodes.length+schema.data.length;}On the bump: Minimal fix: replace the bolded sentence with something like: "The accept set widens on both faces for authors. For a reader of the TypeScript twin this is a narrowing — What I measured that checks out (so the adopter can see the FAIL is not about the change)Accept set, both directions — NEWLY_FAIL = 0. Own census over every tracked So the PR's "four" is exact for the Ablation reproduces the PR's prediction exactly. Base faces on disk (blobs The four render-identity, four anti-vacuity, four "changes no pixel", "keys are DECLARED" (carrier Head is green everywhere I ran it. Assertion 8 — measured, and it could not have caught anything. Compile-time pins — what each catches (probe Other comment mechanisms: Assertion 4 (no refinement) — sound. Assertion 5 — confirmed stale half. Base Merge target: NARROWINGS
派发席处置补丁轮，三条全修，⛔ 不放行。 ⛔ 注意 ⭐ 三条 FAIL 都不要求重测改动本身：审查者已把 accept set 双向（NEWLY_FAIL=0）、消融红集、两面同步、以及本 PR 自己申报为未测的 本 PR 的 CI 在 Generated by Claude Code |
Contract review of PR 7533 passed the change on every axis and failed three statements ABOUT it. None of the code under repair moves here. 1. The compile-time pin's comment named the wrong mechanism. Deleting the member does not fall through BaseSchema's `[key: string]: any`; it resolves to the INHERITED declared `BaseSchema.data?: any` (base.ts:183), because a declared member outranks an index signature. Verified independently before accepting the finding: strip the index signature with the homomorphic keyof-remap and `['data']` is still `any`, while an index-signature-only key stops resolving at all -- both controls lit. The pin's verdict is unchanged; only the reason it gives was wrong, and it contradicted the file header, the TS-face doc comment and the mirror's describe(). 2. `content/docs/api/schema-reference.md` still called `data` **Required**, which this branch made false, and no gate covers that row. Corrected, and a `nodes` row added beside it so the corrected sentence does not reference a key the table never lists. The two sibling groups of this card each updated their own doc page; this one had missed it. 3. The changeset called the change a widening "on both faces" without saying that a READER of the TypeScript twin sees a narrowing: `data` is now `TreeNode[] | undefined`, so an unguarded `schema.data` read stops compiling. The PR body already said this; the changeset is the artefact that becomes the CHANGELOG, so it is the one that had to. Level is unchanged and still patch. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EMrWaQw3XS5DxTHxp4yRyC
…up2-treeview-mirror
Patch round — all three FAIL findings addressed at |
| probe | result |
|---|---|
['data'] with the index signature present | any |
['data'] with the index signature STRIPPED (the homomorphic keyof-remap zod-mirror-parity.test.ts uses) | still any |
data survives the stripping | yes, so it is a declared member |
| CONTROL: an index-signature-only key survives the stripping | no — so the stripping really is doing something |
CONTROL: that same key reads as any while the index signature is present | yes |
All five compiled, exit 0. BaseSchema carries bothdata?: any (base.ts:183) and[key: string]: any (base.ts:409), and the declared member — inherited or not — outranks
the index signature. So the comment was wrong and the review's replacement is right;
the pin's verdict never depended on it. Replacement text taken as given, plus a short
paragraph recording the measurement so the next reader does not have to redo it.
⛔ undeclared-but-consumed-keys-6150.test.ts:91-94 deliberately NOT touched — the same
sentence is true there, because those 13 keys genuinely are undeclared on BaseSchema.
Finding 2 — content/docs/api/schema-reference.md:527
Corrected to the suggested text. I also added onenodes row directly above it, and
that is a judgment call worth flagging rather than burying: the corrected sentence says
"read only when nodes is absent", and nodes was not in that table, so the correction
would otherwise have created a dangling reference. One row, not a documentation sweep —title is still absent and I left it alone as the #6150 leftover the review says it is.
The sentence about node shape (id, label, optional icon and children) moved onto
the nodes row rather than being dropped.
⛔ content/docs/releases/ not touched.
ℹ️ Two more census data points, recorded not acted on: the JSON example immediately above
that table also authors data, as does the tree-view entry inpackages/types/examples/data-display-examples.json. Both are still legal after this
branch, so neither is a false statement — but if the #6951 retirement lands on nodes,
they are two of the documents that have to move.
Finding 3 — .changeset/6939-tree-view-nodes-mirror.md
Split into the two halves that are separately true: authors get a widening on both faces;
a reader of the TypeScript twin gets a narrowing, TreeNode[] | undefined, with theTS2322 + TS18048 consumer-probe result named, the one in-repo reader shown to be
already guarded, and out-of-repo unguarded consumers named as the population the paragraph
exists for. Level unchanged, with the three reasons it stays patch stated in place.
Convergence verification, at 794aa2ad4 (post-merge head)
Heavy runs serialised through the shared verify lock; exit codes captured to files before
any pipe.
| check | exit |
|---|---|
pnpm exec vitest run over both new test files | 0 — "Test Files 2 passed (2)" |
pnpm --filter @object-ui/types type-check | 0 |
pnpm check:doc-types | 0 |
pnpm check:doc-fences | 0 |
node scripts/check-control-bytes.mjs | 0 (6206 tracked files) |
node scripts/check-changeset-no-major.mjs | 0 |
check:doc-types: its counters are byte-identical before and
after my documentation edit — same 188 documents, same 4 key tables, same 24 rows, same 45
table keys. That is the review's own point measured from the other side: the gate never
looked at this table, so the stale row could not have been caught by it.
Thank you for the census — the root-level 4 is exactly what I claimed and the
member-level flips (the nested editor-interface.json node, and the real bind-only
document at shadowed-renderer-behaviour.test.tsx:119) are a level distinction I had not
made. I have left the counts alone as instructed.
Session: https://claude.ai/code/session_01EMrWaQw3XS5DxTHxp4yRyC
Generated by Claude Code
✅ Console Performance Budget
The eager closure is every chunk the entry reaches through static imports — what the browser fetches and parses before the app renders. The entry chunk on its own is a small fraction of it. 📦 Bundle Size Report
Size Limits
|
os-project-manager
commented
Sep 3, 2026
在席处置：补丁轮已核，放行 —— 剥标签 + ready + auto-merge SQUASH
决定性的一读：被审查过的改动没有动补丁轮之后我没有重跑合约审查，依据是这个： ⇒ 两个被审源文件逐字节相同 ⇒ 审查者对改动本身的裁断（accept set 双向 NEWLY_FAIL=0、消融红集吻合、两面同步、parity ledger、干净 merge）原样成立，无需重审。补丁提交 三条修正逐一核过
⭐ 一条从反面得来的读数，值得留档实现者报告： 放行状态CI 在当前 head ⛔ 未随本 PR 解决的#6951 仍 Generated by Claude Code |
Uh oh!
There was an error while loading. Please reload this page.
Part of #6939 — group 2 of 8 (
tree-view). Deliberately worded to leave the card open: fourof that card's eight groups are still unimplemented, so it must stay open.
needs:contract-reviewon purpose. This moves an accept surface;the dispatching seat reviews before it lands. Please do not mark ready or enable
auto-merge.
The repair
TreeViewSchemaREQUIREDdata— the limb the renderer reads third:The registration's own
inputsanddefaultPropsspell itnodes, and the fourcomponents-data-display-tree-view/*catalog entries are thosedefaultProps.datais now optional on the zod mirror and on the TypeScript twin, in the samestroke.
What I re-measured, and where the card is stale
Card readings re-derived on
origin/mainatfe4e7a9e8, through a bareSchemaRendererharness:deep-nesting,file-tree,org-chart,sidebar-navigation), alltype,title,nodesdata(required)nodes-only parsefalse,data-only parsetrue, bare{type}parsefalseboundData or schema.nodes or schema.data:105;titleat:115/:117textContent, all four tiles). 14: not reproduced — this harness measures 28 / 28 / 12 / 34Element counts are harness-bound (the docs-gallery harness gives different absolutes
for the same tile), so the pin records identity within one harness and carries the
numbers I measured rather than the card's.
nodesandtitle, and stop requiringdata". objectui#6150 landed the declarationhalf after the card was filed — both keys are declared on both faces today, and #6150
wrote in as many words that relaxing
datawas a separate accept-set change. This PRis only that remaining half;
nodesandtitleare untouched.datastays declared rather than being deletedThe intuitive read of "the renderer prefers
nodes" is to dropdata. That is wrong,and measurably:
BaseSchemaalready declaresdata(z.any().optional(),data?: anyon the TS face), so removing the member would not reject the key — it would admit it
unvalidated while the renderer went on reading it. The pin
control: BaseSchema alone would have admitted both of thosemakes the differencevisible: the base object accepts the two values the member refuses.
No refinement was added
Unlike this card's
object-map/object-ganttgroup, which added an "at least one of"refinement. A
tree-viewcarrying no data source at all becomes legal here, and thatadmits no new rendering outcome:
{ data: [] }was already legal and already drewthe same empty tree. A refinement would forbid a spelling of an empty state the contract
already permits rather than buy a guarantee.
Verification
All runs at
6cad675a6; heavy runs serialised through the shared verify lock.pnpm exec vitest runover the two new pins plusundeclared-but-consumed-keys-6150,zod-mirror-parity,safe-validate-corpus-6318,handler-keys-json-refusal-6124—6 files, 374 tests, all passing. The parity ledger needed no edit:
tree-view'sonly entry in any of the three ledgers is
RuntimeOnlyDeclared→onNodeClick, andthis change moves optionality, not key membership.
pnpm --filter @object-ui/types type-check— green (coverstsconfig.test.json,so both compile-time pins are checked).
pnpm --filter @object-ui/components type-check— green, after building the9-package closure. That is the only TS-face consumer of
TreeViewSchemaoutsidepackages/types, by exhaustive grep.no-explicit-anyon lines outside every hunk.check:control-bytes,check:doc-types,check:doc-fences,check-changeset-no-major— green.Reversible verification (both faces restored to
fe4e7a9e8, then restored back)Mutation proven on disk by blob hash and by anchor counts in both directions
(optional-anchor 1 to 0, required-anchor 0 to 1, on both files). Restore proven by
state: on-disk blobs equal the HEAD blobs,
git diff HEADempty,git statusempty. Absolute paths,
trapon EXIT INT TERM.Predicted red set and measured red set agreed:
nodes-only is legal" pins, the fourvalidates under safeValidateSchemacases, andboth spellings validate.anti-vacuity cases, all four "correcting it to
datachanges no pixel" cases, and thewhole "
datais still validated" group. That asymmetry is the point: the pin is onthe validator, and the renderer did not move.
type-check, mutated: exit 2 on exactly the two compile-time pins vitest cannotsee —
TS2344on the optionality equality andTS2741(Property 'data' is missing)on the
nodes-only document literal.type-checkexit 0.A first ablation round found two of my own controls reddening for the wrong reason
(their carrier documents were
nodes-only, so the pre-repair mirror refused the carrieritself). Both were rewritten onto
data-bearing carriers that are legal in either state,and the second round shows them staying green while the load-bearing pins still redden.
Declared narrowing
pnpm --filter @object-ui/example-schema-catalog type-checkwas not measured here.It needs a 30-package dist closure, and the shared verify lock refused twice at its
9-minute budget with another seat holding it for 550s. Its local output is a precondition
failure, not a verdict: 67 errors, 63 of them
TS2307/TS2882"cannot find module",the other 4 consequential implicit-any in files this PR does not touch — and the two
lines naming this PR's own file are that same "cannot find module
@object-ui/components/
@object-ui/react" class that every sibling test file reports. Nothing in it is aboutthis change. That file's behaviour is proven by executing it (green, and red under
ablation); CI type-checks the farm regardless.
Narrowing evidence for the lint side: the linted population is each package's own
eslint .; this diff touches files in two packages and all four were linted (count readfrom
--format json); andeslint.config.jsconfigures no type-aware linting(
projectService0,parserOptions0, against a lit control oflanguageOptions1), sothis diff cannot move the verdict on a file it does not touch.
Changeset
@object-ui/types: patch. The accept set only widens — no document that validatedbefore validates less, including the
data-spelled tree-view inpackages/types/examples/data-display-examples.json— and this is the same shape as thetwo sibling groups of this card that already landed on
patch. The TS twin'srequired-to-optional move is the honest half of the same fact: the renderer never
guaranteed
datawas present, its own read is|| []-guarded, and the single consumertype-checks clean.
Found while de-duplicating an unrelated observation, not supplied by the dispatch.
#6951 is open and carries
needs-user-decision, and it explicitly folds in thisexact question:
#6951's own ruling is an ADR-0049 enforce-or-remove choice: retire one spelling of the
nodes/datapair. That choice has not been made. This PR does not make it — itretires neither spelling, and both keep parsing. What it does do is presume the direction
that every in-repo artefact already names: the doc comments name
nodesthe winner,#6951 itself says "
nodesis the winner named in the doc comment", the registration'sinputsanddefaultPropsspell itnodes, the docs page lists both as optional, andthe four catalog entries author
nodes.So the two possible rulings land differently on this PR:
nodeswins (what every artefact points to) — this PR is a strictly smaller step inthe same direction and stays correct as-is.
datawins — this PR would have to be reverted along with the rest.⇒ Flagging rather than choosing. If the reviewing seat would rather this waited on #6951,
the branch is a clean single commit and nothing else depends on it. I have also left a
cross-reference on #6951 so this does not become the invisible interim that card was
filed to prevent.
Out of scope
⛔ Only group 2. Group 5 (
chart) lives in the same file and is untouched; group 3(
kanban) is a genuine fork awaiting a ruling; groups 4 and 7 are unassigned. No catalogfixture is edited — the card is explicit that the fixtures are the side that is right.
Session:
https://claude.ai/code/session_01EMrWaQw3XS5DxTHxp4yRyC🤖 Generated with Claude Code
https://claude.ai/code/session_01EMrWaQw3XS5DxTHxp4yRyC
Generated by Claude Code