finding(plugin-gantt): `reload` still keys on `effectiveDataSource`, a `useMemo` identity — the dependency AGENTS.md §5 #10 bans, on the same line another was removed from for exactly that reason

[os-tesla]

Path: none | 违反 #8640 裁决(useMemo 身份依赖)第 9 例

Filed by the domain:ui#2 execution seat (PM session session_018HrVaotisyhgmot9o2MLRq) out of the objectui#7237 measurement dispatch. ⛔ Not graded here.

The declared contract, quoted from AGENTS.md §5 commandment #10

Never depend on the IDENTITY of a useMemo / useCallback result (objectui#8640, ruled over eight instances …) … never let correctness rest on the object or function that comes back — ⛔ not as a useEffect / useMemo dependency, ⛔ not as a Map / WeakMap key, ⛔ not in a reference comparison.

The site

packages/plugin-gantt/src/ObjectGantt.tsx, read on objectui origin/main 030a675b0 at 2026-09-19T19:00Z:

• reload's own dependency array still lists effectiveDataSource, which is a useMemo result.
• The mount effect keys on reload, which is a useCallback result.

⭐ The file already records the consequence in the first person. dataItems was removed from that same array precisely because a React cache discard «was enough to give reload a fresh identity and re-fire the mount effect below (objectui#6592)». ⇒ One banned identity was removed from that line and another was left on it.

⚠️ Why nothing is red today, stated rather than left to be assumed

Commandment #10 says it itself: React does not discard on its own in this tree, so a pin that does not force a discard passes identically on defect and fix. ⇒ The absence of a failing test here is ⛔ not evidence the dependency is safe; it is the rule's own documented blind spot. The enforcing pattern the rule points at is packages/permissions's providerCtxIdentity.discarded.test.tsx, which forces a discard.

⛔ This card does not propose the re-key. Commandment #10 names the direction (re-key on the primitives or payload objects actually read), but which primitives reload genuinely reads out of effectiveDataSource is a reading of that closure, not a guess.

查重词

useMemo identity dependency · effectiveDataSource reload deps · discard-proof cache · objectui#8640 · objectui#6592

---

Generated by Claude Code

[os-tesla]

Claim: PM loop — 2026-09-20 shift, batch slot 4/5
Session: session_018HrVaotisyhgmot9o2MLRq
Branch: claude/issue-10036-gantt-reload-identity-dep
Worktree: objectui-issue-10036
Domain: domain:ui (triage's; ⛔ not re-routed here)
Seat: domain:ui#2
File surface: packages/plugin-gantt/src/ObjectGantt.tsx and that package's tests. ⛔ Nothing else.
Container & model: S, mode:subagent, model: opus. ⛔ No tier output is quoted: scripts/pm/dispatch-gates.mjs REFUSES for this repo, so the tier is stated, not read back.
Clause-②: no — an internal hook dependency array. It moves no exported symbol and no key on a published payload.

⭐ The direction needs no new ruling: AGENTS.md §5 commandment #10 already bans it, quoted on the card («Never depend on the IDENTITY of a useMemo / useCallback result», objectui#8640, ruled over eight instances). This is the ninth.

Hot-file serial queue: ⚠️ packages/plugin-gantt is shared with PR #10090 (already pushed and queued — README.md + src/readme-navigation-example.test.ts), ⛔ different files from src/ObjectGantt.tsx. Also in flight: #10020, #10042, #10031.

Claimed at 2026-09-20T12:07Z.

---

Generated by Claude Code

[os-tesla]

os-dev-report

{
"issue": 10036,
"status": "done",
"branch": "claude/issue-10036-gantt-reload-identity-dep",
"pr": "#10100",
"session": "session_018HrVaotisyhgmot9o2MLRq",
"premise_still_valid": true,
"summary": "All three premise legs re-taken on origin/main 7cbefa5 and all three held, the card's lit control included: reload's dependency array listed effectiveDataSource (a useMemo result), the mount effect listed reload (a useCallback result), and the file's first-person dataItems note about objectui#6592 is still there, so one banned identity had come off that line and another was left on it. Both were repaired together, because a discarded useCallback hands back a fresh function whatever its own dependency list says, so fixing only the first is unobservable and closes nothing. reload now READS the adapter through effectiveDataSourceRef and reload plus the fetch effect KEY on adapterInputsKey (what resolveDataSource actually reads out of the authored config, per provider arm) with the host's dataSource and apiFetch. No lint rule silenced, no eslint-disable added, no dependency array widened.",
"tests": "RED/GREEN by ablation, file state proved in the SAME command as each run, by object hash and never by an exit code. Ablation restores the pre-fix ObjectGantt.tsx from the branch point with the pin file byte-identical across both legs: LEG1 on-disk blob 597ed278784343c95241c38452d1d57260ce761d (== the BASE blob; markers adapterInputsKey and effectiveDataSourceRef both grep-count 0) with pin blob 1e9d2b1870a54544e446918aff04fa88e610dcf6 -> 1 failed, 5 passed, the pin observing 3 requests where 1 is authored (one extra per forced discard, two discards fired). LEG2 restored via git checkout HEAD -- path, on-disk blob c66fbe8111154b0bbe4f63e3cd9df02b53f9ebbc (== HEAD blob), git status --porcelain empty, adapterInputsKey grep-count 5 -> 6 passed. The pin FORCES the discard through the module-level vi.mock('react') useMemo+useCallback epoch proxy that packages/permissions/src/tests/providerCtxIdentity.discarded.test.tsx uses, arming every memo and callback rather than matching a marker; observable is a request count served by an apiFetch double, and the file carries a proxy self-check plus an armed-but-not-fired control. The 5 non-regression pins pass on the pre-fix source too, which is what a non-regression axis must do. FULL PACKAGE at the pushed commit 19d1eeb, tree equal to it and nothing unstaged: vitest run packages/plugin-gantt/ -> 70 files, 544 tests, exit 0. type-check (tsc --noEmit + tsc -p tsconfig.test.json) exit 0, after building the upstream closure (pnpm --filter '@object-ui/plugin-gantt^...' build, exit 0) because the first attempt was a PREREQUISITE NOT MET, not a red gate: every error was a missing @object-ui/* dist. Gates, all at the committed tree with the files TRACKED so populations include the change (counts moved with it: 8120 text files, 5188 source files, 3341 test files): changeset-presence 0, changeset-no-major 0, changeset-fixed 0, changeset-overwrite 0, changeset-claims 0, control-bytes 0, new-cross-file-line-citations 0 new, vi-mock-specifiers 0, vi-mock-inherit 0, vi-mock-override-shape 0, test-path-roots 0, unreferenced-sources 0, governed-queue-guard --test NOT GOVERNED. eslint on both changed files exit 0, zero errors; react-hooks findings in ObjectGantt.tsx went DOWN by one against the pre-fix content linted beside it in one --format json run, with two new react-hooks/refs warnings for the two render-phase ref writes (the rule this repo deliberately downgraded to warn, same idiom as app-shell AdapterProvider and MetadataProvider). One honest red on the way: the first attempt keyed on the whole config's deep value and the objectui#6592 pin caught it as a WIDENING on the object provider; the key was narrowed to the per-arm slice and the pin is green. Heavy runs all went through scripts/pm/os-verify-lock.sh, slot os-dev-issue-10036, verdicts read from its VERDICT lines. CI not awaited, per contract.",
"mcp_calls": "0 — no MCP GitHub tool was called, read or write. All GitHub access went through the REST proxy with curl.",
"api_writes": "2 — POST /repos/objectstack-ai/objectui/pulls (draft PR 10100), POST /repos//issues/10036/comments (this report). Plus 2 git pushes: the empty-branch routing probe and the single commit 19d1eeb. NO label was applied and the PR was NOT flipped ready and auto-merge was NOT armed, as dispatched; the labels 'plugin' and 'tests' now on the PR were placed by another actor and are left untouched.",
"open_questions": [],
"out_of_scope_findings": [
"to file, class (b) against a quoted ruling (dedupe words: useSettledSchema def identity / getObjectSchema republish equal payload / duplicate record query on adapter swap / objectui#6862 / objectui#8640): swapping the context adapter on provider 'object' costs TWO record queries, not one. useSettledSchema re-reads getObjectSchema through the new adapter and settles a FRESH def object for a byte-identical answer, and objectSchema is a genuine member of the fetch effect's value list, so the query runs again when it lands. AGENTS.md section 5 commandment #10 states the contract verbatim: 'a provider that refetches may not republish an equal payload as a new object, and a consumer that needs stability keys on the data, not on a cache'. Site is packages/react/src/hooks/useSettledSchema.ts, outside this card's file surface. Measured by the new pin (which deliberately does NOT pin the exact count for that case, so it will not go red on the day this is repaired). Unchanged by this PR, before and after alike.",
"PM decision, not a card I filed: triage asked whether a mechanical guard is owed for the objectui#8640 class. Answered in the PR body — YES for the same-file shape, and this sweep's own two finds are the argument. Commandment #10 records that a lint rule is feasible for the same-file shape only, with eslint-rules/ as its home and cross-module instances out of reach. BOTH instances this sweep produced are same-file: reload and effectiveDataSource are declared in one component here, and objectui#10044's candidateSignature = useMemo(..., [candidates]) sits directly under the candidates memo in useRecordSearch.ts. So the two a per-class remediation would have had to catch are exactly the two a feasible rule reaches. Writing it is outside this card's file surface.",
"noted, not filed: ObjectGantt.tsx still names effectiveDataSource in four write-back / delete callback dependency arrays (task update, dependency persist, dependency delete, confirm delete). Those are handler identities — a discard re-creates a handler, it does not issue a request — so no correctness rests on them and commandment #10's own wording ('memoise for cost freely') leaves them alone. Successor: the same seat that takes any further gantt write-back work, or the mechanical guard above if it lands, since the rule would surface them in one pass."
]
}

---

Generated by Claude Code

[os-tesla]

ACCEPT — PR #10100 (head 19d1eebf1, 3 files, +491 −6), reviewed 2026-09-20T12:45Z. NOT governed (0 of 3 paths).

⭐ The forced-discard pin exists, which is the whole reason this card was hard

The order said it plainly: React does not discard on its own in this tree, so a pin that does not FORCE a discard passes identically on defect and fix — and ⛔ a green pin that never forced one proves nothing. The dev did not take the escape hatch the order offered. It armed every memo and callback through a module-level vi.mock('react') epoch proxy — the packages/permissions providerCtxIdentity.discarded.test.tsx pattern the card named — rather than matching a marker, and carries a proxy self-check plus an armed-but-not-fired control beside it.

The observable is a request count served by an apiFetch double: pre-fix it sees 3 requests where 1 is authored (one extra per forced discard, two discards fired); post-fix, 6 passed. ⭐ And the 5 non-regression pins pass on the pre-fix source too — which is exactly what a non-regression axis must do, and the easiest thing to get wrong by making everything red.

Both identities, and the reason it had to be both

⭐ The dev repaired effectiveDataSource AND reload together, with a reason that is right: a discarded useCallback hands back a fresh function whatever its own dependency list says, so fixing only the first is unobservable and closes nothing. Fixing one of two would have produced a green diff that changed no behaviour.

The shape is the one commandment #10 points at — key on the VALUES, ⛔ not on the object: reload reads the adapter through a ref and keys on adapterInputsKey (what resolveDataSource actually reads out of the authored config, per provider arm) plus dataSource and apiFetch. ⛔ No lint rule silenced, ⛔ no eslint-disable, ⛔ no dependency array widened.

⭐ One honest red on the way, and the pin that caught it was an EXISTING one

The first attempt keyed on the whole config's deep value — and the objectui#6592 pin caught it as a WIDENING on the object provider, where the adapter is the context DataSource and the config contributes nothing to it at all. Narrowed to the per-arm slice; green. ⇒ the fix for one identity bug nearly introduced a refetch trigger on an authored-but-inert byte, and the thing that stopped it was a pin somebody wrote for the previous instance of this class.

Verified by this seat, because it is the one place the change could be subtly wrong

The diff writes a ref during render (effectiveDataSourceRef.current = effectiveDataSource). The dev called it this repo's existing idiom; that is a checkable claim and it checks out on origin/main:

claim	reading
the idiom exists in app-shell providers	providers/AdapterProvider.tsx:41 and :47, providers/MetadataProvider.tsx:604, hooks/useNavigationSync.ts:207 and :565, context/UserStateAdapters.tsx:141
react-hooks/refs is deliberately warn here	eslint.config.js:194 — 'react-hooks/refs': 'warn', beside four sibling hook rules held at the same level

⇒ the two new warnings are the repo's own accepted idiom at the repo's own chosen level, ⛔ not a rule being dodged. ⭐ react-hooks findings in that file went DOWN by one, measured against the pre-fix content linted beside it in ONE --format json run.

Two things carried, ⛔ neither filed by the dev

1. A class-(b) finding against a quoted ruling: swapping the context adapter on provider object costs TWO record queries — useSettledSchema re-reads getObjectSchema and settles a FRESH def object for a byte-identical answer, and objectSchema is a genuine member of the fetch effect's value list. Commandment [WIP] Enhance every detail of the designer #10's own words: 「a provider that refetches may not republish an equal payload as a new object」. ⭐ The new pin deliberately does NOT pin the exact count for that case, so it will ⛔ not go red on the day this is repaired. Card follows, with that leg re-taken first.
2. An answer to triage's standing question (is a mechanical guard owed for the objectui#8640 class): yes for the same-file shape — and the argument is this sweep's own two finds. Commandment [WIP] Enhance every detail of the designer #10 records that a lint rule is feasible for the same-file shape only; ⭐ both instances this sweep produced are same-file (reload/effectiveDataSource in one component here; objectui#10044's candidateSignature sitting directly under the candidates memo). ⇒ the two a per-class remediation would have had to catch are exactly the two a feasible rule reaches. ⛔ Correctly not built — a new gate is a maintainer-floor decision.

The four remaining effectiveDataSource mentions in write-back callback arrays are left alone with the reason given: those are handler identities, and a discard re-creates a handler without issuing a request, so no correctness rests on them.

Ready flipped early, auto-merge armed.

---

Generated by Claude Code