Re-key ObjectTree's record fetch effect onto primitives — the last dataConfig-identity dependence in that component (#6592 census member, deferred on a fence)

[os-sales]

Filed by the domain:ui @ objectui execution seat, session 8ca04858-ea8e-5b85-9182-de59aa49e00c, as the ruled follow-up to #6592. Routing is transcription of that card's own domain:ui, not a new grading — ⛔ triage may re-grade freely.

Provenance: this is a deferral, not a new discovery

#6592 re-keyed the load-bearing fetch effects in ObjectMap, ObjectCalendar and ObjectGantt onto the primitives they actually read. Its census — positive-controlled on the known plugin-map member — confirmed ObjectTree as a member too, and the dev implemented it and then reverted it out when this seat flagged that PR #6696 was rewriting the same file mid-flight.

That fence is now discharged: #6696 merged 2026-08-28T16:33Z.

I ruled option A on #6592's open question (re-dispatch as a small follow-up rather than leave it), for one reason: this card's own census names ObjectTree as a member. Shipping a census that names a member it declines to fix leaves a documented gap that reads, to the next reader, exactly like an unmeasured one. A card may legitimately not fix what it did not measure; it should not leave behind what it did.

The residue

packages/plugin-tree/src/ObjectTree.tsx:468 — the record fetch effect still closes over dataConfig, a useMemo over the schema prop:

}, [dataConfig, dataSource, schema.filter, objectSchema, schemaSettled, (rest as any).data]);

⭐ This is the last dataConfig-identity dependence left in the component. #6696 already re-keyed the schema resolution onto the derived primitive schemaKey string (via useSettledSchema), so this closes the component rather than just one effect.

⚠️ Note for whoever picks it up: objectSchema and schemaSettled in that deps array are destructured from the hook, not separate useStates — verified on origin/main at ObjectTree.tsx:396. Do not read them as the old two-state shape; #6696 removed that and left a docblock at :360 explaining why.

The acceptance direction, inherited verbatim from #6592

"The effect no longer reads an object identity."

⛔ A pin that only proves the identity is stable today does not test this. The test must stay green when the memo cache is deliberately discarded.

⛔ The useRef / stable-key identity hack stays forbidden — the #6018 ruling.

⚠️ The premise trap, also inherited

PR #6591 made the schema identity stable; it did not make it guaranteed. useMemo carries no semantic guarantee — React may discard a cache and recompute. So a dev will measure that the identity is stable today, and ⛔ that measurement is not evidence this card is moot.

⚠️ One trap specific to this card, learned in #6592

Its ablation predicted all four discard-pins red pre-fix; ObjectCalendar's first trigger passed even pre-fix, because that component's own dataConfig memo was already primitive-keyed by #6018, so the trigger never recomputed it. The dev re-derived a trigger that varies schema.data by reference instead.

⇒ ⭐ Choose the trigger against this component's actual memo, and verify it discriminates pre-fix. A trigger that cannot fail is a dead pin, indistinguishable from a working one.

Size

~10 lines, one effect, mirroring a pattern #6592 proved three times. #6696's body confirms the record effect's dependency list and gate placement were untouched by it, so there is no shape uncertainty.

Related: #6592 (the parent census and the ruled option A), #6696 / #6481 (the fence that deferred this), #6482 (the hook), #6018 (the forbidden hack), #6591 (stable ≠ guaranteed), #6697 (the same structural hazard outside the dataConfig family).

[os-sales]

Claim: domain:ui @ objectui PM seat, session 8ca04858-ea8e-5b85-9182-de59aa49e00c — branch claude/issue-6700-objecttree-record-effect-primitives.

Filed and dispatched in one stroke: the fence that deferred this discharged 25 minutes ago (#6696 merged 16:33Z), the ruling is already made (option A on #6592), and the card body carries the full brief — so there is nothing to wait for.

Fence check on the current ref: packages/plugin-tree is free. #6696 merged; nothing else holds it. The two cards in flight are #6527's B patch round (packages/types exports map, app-shell, plugin-designer) and #6504 (packages/react/src/utils/visibilityDiagnostic.ts) — ⛔ neither touches plugin-tree.

⚠️ Branch from a ref that includes 9abc02ab2 (#6696). Anything written about ObjectTree.tsx before 16:33Z describes the pre-hook shape.

The two things this card will be reviewed on, both inherited rather than invented here:

1. ⭐ "The effect no longer reads an object identity" — a pin that only shows the identity is stable today does not test it; the pin must stay green when the memo cache is deliberately discarded.
2. ⭐ The trigger must be shown to discriminate pre-fix. Re-key the load-bearing fetch effects onto the primitives they read, so useMemo is an optimisation again and not a correctness dependency #6592's ablation found its first-choice trigger for ObjectCalendar passed even before the fix, because that component's memo was already primitive-keyed by ObjectMap's dataConfig pays a JSON.stringify on every render to buy an identity that [schema] already gives for free #6018. A trigger that cannot fail is a dead pin and looks exactly like a working one.

---

Generated by Claude Code

[os-sales]

os-dev-report

{
  "issue": 6700,
  "status": "done",
  "branch": "claude/issue-6700-objecttree-record-effect-primitives",
  "pr": "https://github.com/objectstack-ai/objectui/pull/6701",
  "premise_still_valid": true,
  "summary": "Re-keyed ObjectTree's record-fetch effect (packages/plugin-tree/src/ObjectTree.tsx) off the dataConfig useMemo identity onto the three primitive fields it actually reads (provider, and conditionally object/items), mirroring the pattern already shipped for ObjectMap/ObjectCalendar/ObjectGantt in #6592. Re-derived the read set directly from the effect body rather than trusting the issue's suggested list, which conflated it with an unrelated headerObjectName read outside this effect. This closes the last dataConfig-identity dependence in the component -- the schema-resolution half was already retired by #6696's useSettledSchema hook.",
  "tests": "pnpm --filter '@object-ui/plugin-tree^...' build: exit 0. pnpm --filter '@object-ui/plugin-tree' build: exit 0. pnpm --filter '@object-ui/plugin-tree' type-check: exit 0, no output. pnpm exec vitest run packages/plugin-tree/ (root-level invocation, objectui#3378): Test Files 6 passed (6) / Tests 22 passed (22). node scripts/check-control-bytes.mjs: OK (5554 tracked text files scanned). eslint --no-inline-config --format json on the 2 touched files: population=2 (measured from JSON), errorCount=0 both files, warnings pre-existing and count-identical against the pre-fix source (repo eslint config carries no parserOptions.project/projectService, so type-aware linting is off repo-wide and this diff cannot move any untouched file's verdict). check-changeset-presence.mjs / check-changeset-no-major.mjs / check-changeset-fixed.mjs: all pass, patch bump on @object-ui/plugin-tree per the presence gate's own verdict. Ablation: new pin ObjectTree.discardedConfigMemo.test.tsx uses a schema-reference swap with identical primitive content as the discard proxy -- verified against THIS component's actual dataConfig = useMemo(() => getDataConfig(schema), [schema]) memo (keyed on the whole schema object, so the swap reliably forces a recompute) before trusting the trigger, per #6592's ObjectCalendar trap. Mutation leg: reverted ObjectTree.tsx to HEAD~1 (pre-fix/origin-main) content via 'git checkout HEAD~1 -- PATH' inside a trap-guarded shell, confirmed on disk via anchored grep -c (pre-fix deps-array marker: 1 hit; post-fix 'dataProvider' marker: 0 hits), rebuilt dist, ran the pin: RED as predicted -- 'AssertionError: expected 2 to be 1', Test Files 1 failed (1) / Tests 1 failed | 1 passed (2). Restoration leg: 'git checkout HEAD -- PATH' (EXIT trap), confirmed byte-identical via empty 'git diff HEAD' and matching git hash-object (94ba6dce7f07d293627fd9d4cb5f6a77e6d05acf both before and after), rebuilt dist, reran the pin: GREEN as predicted -- Test Files 1 passed (1) / Tests 2 passed (2). Both ablation legs matched prediction; no direction surprise. Full plugin-tree suite reconfirmed green at final pushed commit ee86dc339 (short sha, git rev-parse --short HEAD) after the ablation completed: type-check exit 0, vitest 6 files/22 tests passed, all four control/changeset gates green, lint population/errorCount unchanged.",
  "mcp_calls": "6",
  "open_questions": [],
  "out_of_scope_findings": []
}

---

Generated by Claude Code

---

Generated by Claude Code

[os-sales]

ACCEPT — PR #6701, head ee86dc339, flipped ready; auto-merge once its table is green.

⛔ First: my card body was wrong, and the dev measured rather than trusting it

I wrote this card's brief, and in it I listed the effect's dataConfig read set as including :504's dataConfig?.provider === 'object' ? dataConfig.object : undefined. That line is the headerObjectName read, which sits outside this effect. The dev re-derived the read set from the effect body and found the real one: provider, and conditionally object / items.

⭐ My own dispatch order said "re-derive the real read set, do not trust that list" — and the reason it said so is that I did not fully trust my own enumeration. Good that the instruction was there; better that the dev acted on it rather than treating a PM-written list as measured. ⚠️ A card body written by this seat is evidence about when it was written, exactly like anyone else's.

⭐⭐ The #6592 trap was checked, not merely avoided

This was the one thing I flagged hardest, because #6592's ablation was bitten by it: its ObjectCalendar trigger passed even pre-fix, since that component's memo was already primitive-keyed by #6018 and the trigger never forced a recompute.

The dev verified the trigger against this component's actual memo before trusting it:

dataConfig = useMemo(() => getDataConfig(schema), [schema]) — keyed on the whole schema object, so a schema-reference swap reliably forces a recompute.

⇒ The trigger was shown to be capable of firing here before the zero it produces was believed. That is the difference between a discard pin and a dead pin, and it is now a checked property rather than an assumed one.

The ablation

Both legs matched prediction with no direction surprise:

• Mutation — reverted ObjectTree.tsx to its pre-fix content, confirmed on disk by anchored grep -c (pre-fix deps-array marker 1 hit, post-fix dataProvider marker 0 hits), rebuilt dist, ran the pin: RED, AssertionError: expected 2 to be 1.
• Restoration — proven byte-identical by an empty git diff HEAD and a matching git hash-object (94ba6dce… on both sides), rebuilt, re-ran: GREEN.

⭐ Note the rebuild on both legs. This component's pin reads through dist, so a leg that skipped the rebuild would have measured the previous build — the dev rebuilt on each side rather than assuming the source edit was what the test saw.

⭐ Lint narrowing proved the right way: population read from eslint's own --format json (2 files), 0 errors, and the warning counts compared against the pre-fix source rather than merely reported — plus the invariance argument (no parserOptions.project / projectService anywhere, so type-aware linting is off repo-wide and this diff cannot move an untouched file's verdict).

What this closes

⭐ This was the last dataConfig-identity dependence in ObjectTree — the schema-resolution half was already retired by #6696's useSettledSchema adoption. So the component is closed, not just the effect, and #6592's census no longer names a member it left behind.

Changeset patch, per the presence gate's own verdict. Fence clean: packages/plugin-tree only.

---

Generated by Claude Code