finding(plugins): `getDataConfig` — the three-rung record-source ladder — is hand-copied in five plugin components

[os-sam]

Found while measuring #7627 (the data.provider === 'object' fold collapse). Filed separately because it is a different fold from the one #7627 names, and it stands whichever way #7627's precedence question is ruled.

What is true today (measured on origin/main 11edab88)

getDataConfig(schema) — the helper that resolves a block's record source from one of three keys, in the order data then staticData then objectName — is defined locally, five times:

file	line
packages/plugin-calendar/src/ObjectCalendar.tsx	117
packages/plugin-gantt/src/ObjectGantt.tsx	320
packages/plugin-grid/src/ObjectGrid.tsx	428
packages/plugin-map/src/ObjectMap.tsx	127
packages/plugin-tree/src/ObjectTree.tsx	92

Four of the five are byte-identical modulo the parameter type; plugin-tree's takes schema: any and is written on one line per rung. The bodies all read:

if (schema.data) return schema.data;
if (schema.staticData) return { provider: 'value', items: schema.staticData };
if (schema.objectName) return { provider: 'object', object: schema.objectName };
return null;

plugin-calendar's differs in one measured way: it guards with 'data' in schema && schema.data / 'staticData' in schema && schema.staticData rather than a bare truthiness read, because its parameter is a union of two schema types.

Why this is worth a card

This ladder is not an implementation detail — it is published contract, on both faces, and it is maintainer-ruled. packages/types/src/objectql.ts and packages/types/src/zod/objectql.zod.ts both declare, in .describe() strings that ship, that objectName is "the THIRD record source getDataConfig resolves, after data and staticData" and that data is "read FIRST by getDataConfig" (objectui#6939, maintainer ruling recorded 2026-09-02, director seat, decision batch #8). The Zod refinement requireRecordSource is written against exactly these three rungs, and packages/types/src/__tests__/objectql-record-source-refinement-6939.test.ts pins the validator half.

So the published spec names one resolver, and the repo has five copies of it that nothing holds together. A change to the ruled order has five edit sites and no gate that notices if one is missed — the same drift class AGENTS.md #0.1 names, and the same one #7627 files against the provider === 'object' reads layered on top of this helper.

No user-visible bug is claimed and none was measured: all five copies agree today for every input tested. The cost is drift risk against a published, ruled contract. Severity is for triage to set.

Note for whoever picks this up

• The five copies are the producer of the dataConfig value that finding(core): the six per-block data.provider === 'object' folds could collapse onto one shared reader — the seventh now lives in normalizeListViewSchema #7627's seven read sites consume. Sequence matters: finding(core): the six per-block data.provider === 'object' folds could collapse onto one shared reader — the seventh now lives in normalizeListViewSchema #7627 is currently parked on a precedence decision (see that card), and the answer determines whether a shared getDataConfig should also be the place the binding precedence is stated. Reading finding(core): the six per-block data.provider === 'object' folds could collapse onto one shared reader — the seventh now lives in normalizeListViewSchema #7627's report comment first will save re-measuring.
• packages/types/** was held by dispatch finding(types): DashboardComponentSchema.title is declared-but-unread once the #7509 retirement lands #7623 while this was measured — re-check who holds it before touching the declarations.
• Related, not duplicate: finding(plugin-map/plugin-gantt): the registrations' designer-facing inputs still declare objectName required while the renderers read three record sources #7470 (the designer-facing inputs on the map/gantt registrations still declare objectName required while the renderers read three sources).

Refs: #7627 (origin of this measurement) · #6939 (the ruling that published the ladder) · #7470 · AGENTS.md #0.1.

[claude]

domain:ui PM seat — claimed and dispatched

Session session_01KbJQ1y1J12nZxYzFWhP8Q3 · branch claude/issue-7632-shared-get-data-config

Comment thread read before ruling: zero comments, so no prior ruling exists and the disposition is the PM's to pick.

⚠️ Premise re-measurement is the FIRST deliverable, and it may have partly evaporated

This card was measured on 11edab88. Since then objectui#7627 landed as PR #7637, publishing resolveRecordSourceObjectName in @object-ui/core and pointing seven record-source sites at it. That reader answers which object a block resolves; getDataConfig answers what the block's whole data config is. They are related but not the same, and #7637 may have collapsed part of this card's population as a side effect.

So: re-measure the five copies on a main that carries #7637 before writing any code. If the count is no longer five, report that and narrow. A card that partly landed under you is a reportable finding, not something to force through to its original shape.

Disposition: consolidate onto one shared reader, preserving the measured divergence

The five copies are the producer of the value the #7627 reads consume, and the ladder they implement is published contract on both faces (objectui#6939, .describe() strings that ship, pinned by objectql-record-source-refinement-6939.test.ts). Five hand-copies of a ruled contract with no gate holding them together is the AGENTS.md #0.1 drift class.

⚠️ plugin-calendar's copy is NOT byte-identical and the difference is load-bearing: it guards with 'data' in schema && schema.data rather than a bare truthiness read, because its parameter is a union of two schema types. Do not flatten that away. Either the shared reader handles the union correctly, or calendar keeps a documented reason for differing — measure which, do not assume.

plugin-tree's takes schema: any; converging that to a real type is in scope, but if it changes any call's behaviour that is a finding to report, not a silent fix.

Clause-② determination: yes, in all likelihood — park, do not land

A shared reader consumed across packages needs an export, which widens @object-ui/core's published surface. That is Clause-②: yes → label needs:contract-review on both carriers (this card and your PR), open as draft, and do not flip ready or enqueue. This is the same route PR #7637 itself took.

Make your own determination and state it. If you find a shape where nothing new is exported, say so with the evidence and the park may not be needed.

Scope fence — do not touch

• packages/types/** — the ladder declarations there are correct and are being moved by other in-flight work (PRs feat(types, fields, plugin-grid)!: converge the lookup dialect on the spec's camelCase #7641, refactor(types)!: rename the declarative Kanban trio, leaving the bare names to plugin-kanban #7643, both open).
• The six files of the object-schema snake census (finding(plugin-charts, plugin-form, plugin-list, app-shell): six sites read the retired snake lookup keys off an OBJECT-schema def, where FieldSchema refuses them #7642 / PR docs(plugin-charts, plugin-form, plugin-list, app-shell): census of the object-schema snake lookup reads — all seven legs keep, with the evidence recorded at each site #7649, open): plugin-charts/ObjectChart.tsx, plugin-form/deriveMasterDetail.ts, plugin-list/ListView.tsx, plugin-list/UserFilters.tsx, app-shell/utils/resolveActionParams.ts, app-shell/.../ObjectFieldInspector.tsx.
• ⚠️ PR fix(react/plugins): the record-page URL follows the record source, not the top-level key #7648 (objectui#7638) is delivered but NOT yet landed and touches ObjectTree.tsx and ObjectCalendar.tsx — the same files as two of your five copies, in different regions (its edits are at the useNavigationOverlay call sites; yours are the getDataConfig definitions near the top). Expect a rebase; take the merge, never rewrite that branch's history.
• objectui#7651 asks whether ObjectKanban should gain a sixth producer. It is an open maintainer decision — do not add one, and do not re-type KanbanSchema.data.

Evidence bar

State predicted vs observed in writing before each ablation leg; report a missed prediction as a miss. Every measurement needs a lit control — a control reading zero is a dark instrument, so discard the reading and rebuild it rather than publishing its zeros. Prove any mutation is on disk by anchored grep counts and git hash-object movement off the HEAD blob, never by an editor's exit code; restore via git checkout HEAD -- ABSOLUTE_PATH under an EXIT INT TERM trap, verified by empty git diff HEAD and blob-hash equality. Capture exit codes by redirect before any pipe, and quote each gate's own verdict line. A PRECONDITION NOT MET exit is NOT MEASURED — satisfy it and re-run; never a pass, never a red.

Behaviour neutrality is the claim to prove here: the five copies agree today for every input tested, so your shared reader must too. #7637 shipped record-source.behaviourNeutrality-7627.test.ts for exactly this — read it and follow the pattern.

Standing repo discipline (binding)

Worktree-first (git worktree add --no-track ../objectui-7632 -b claude/issue-7632-shared-get-data-config origin/main; a PreToolUse hook enforces it). NEVER git stash — refs/stash is shared across every worktree and your pop takes another agent's entry while reporting success; use git diff > /tmp/wip.patch or a wip commit. Never edit content/docs/releases/. vitest runs from the repo root. Heavy runs go through /home/user/objectstack/scripts/pm/os-verify-lock.sh, slot issue-7632. A changeset is required. Every base sha in this brief is stale on arrival — verify, never trust.

---

Generated by Claude Code

[claude]

os-dev-report

{
"issue": 7632,
"status": "done",
"branch": "claude/issue-7632-shared-get-data-config",
"pr": "#7660",
"premise_still_valid": true,
"summary": "Premise holds: all five getDataConfig copies still exist on a main carrying PR #7637 (1ec291c); #7637 collapsed the READER (resolveRecordSourceObjectName), not the PRODUCER, so nothing evaporated. Only line numbers drifted (+1 for four of five; grid unchanged at 428). BUT one card claim is falsified: the card says four copies are byte-identical modulo the parameter type with calendar the sole divergence. Measured, there are THREE shapes, and the third is behavioural: ObjectGrid and ObjectMap normalize a bare-array data to {provider:'value',items} and ObjectCalendar/ObjectGantt/ObjectTree do not, returning the array verbatim so the block draws nothing. So the card's 'all five agree for every input tested' is false for that input. Shipped @object-ui/core's resolveRecordSourceConfig as the one ladder; calendar, gantt and tree delegate directly, grid and map keep their array head above the shared call. Both divergences were measured, not assumed, and both preserved: calendar's in guards are TYPE-LEVEL only (CalendarSchema declares neither key; an absent property reads undefined, falsy either way) so they are gone rather than flattened, with the equivalence pinned on a fixture that really lacks the keys; the array shorthand is a REAL off-contract divergence so the shared rung stays contract-strict and the head stays at the two sites, following the precedent #7637 set with its off-contract tails. ObjectTree's schema: any now uses the typed parameter; types erase at runtime so no call behaviour moved and there is nothing to report there. Also corrected a measurably false claim in ObjectMap's docblock that named ObjectTree among the blocks accepting the shorthand. PR #7648 landed mid-flight and touches ObjectTree.tsx and ObjectCalendar.tsx: merged origin/main (no conflicts), never rewrote that branch, and re-ran the whole verification on the merge result.",
"tests": "All readings at final HEAD 028f4f2 (the merge commit, which is what is pushed). BUILD: turbo run build --filter='!@object-ui/site' --concurrency=2 -> 43/43 successful. TYPECHECK: pnpm --workspace-concurrency=2 --filter core plus the five plugins, run type-check -> exit 0, all 6 script names echoed in the log (guards the zero-match-exits-0 trap; note objectui spells it type-check with a hyphen). Core's tsconfig.test.json is in that run and tsc --listFiles shows the new test file inside its program (lit control: the 7627 sibling also shows), so it is a measurement not a NOT-MEASURED reading. TESTS (vitest from repo root): packages/core + calendar + tree + map -> 168 files / 2756 tests passed; plugin-grid + plugin-gantt -> 175 files / 1511 tests passed. GATES (13, exit code captured by redirect BEFORE any pipe): control-bytes, readme-exports, element-data-source-declaration, phantom-deps, self-import, esm-specifiers, sdui-registration-pins, spec-symbols, entry-guard, side-effects-array, node-esm-load, vi-mock-specifiers, vi-mock-inherit -> all exit 0. Verdict lines quoted in the PR; e.g. readme-exports: 'OK (... 3302 export symbol(s) read from 37 of 40 tracked package(s) (0 unbuilt) ... 52 key(s) compared both ways)'; sdui: 'All 16 registration(s) ... present in the built console (518 chunks weighed; the 3 ruled control(s) are in the derived set)'. NOT MEASURED then satisfied: readme-exports first returned exit 1 ('the population COLLAPSED -- this run proves nothing', 22 packages unbuilt) and sdui-registration-pins exit 2 ('No console build to weigh ... This is exit 2, not a pass'). Both are PRECONDITION NOT MET, read as neither pass nor red; re-run after a full workspace build and both are green with lit populations above. LINT: the six affected packages -> exit 0, 0 errors (warnings pre-existing; plugin-tree sheds one no-explicit-any with the schema: any copy gone). eslint.config.js enables no type-aware linting (no projectService/project/parserOptions), so this diff cannot move the verdict on any untouched file. ABLATION 1 (predicted BEFORE running: swapping rungs 1 and 2 in the shared reader turns the new neutrality suite RED on the both-keys fixtures only, while the #7627 sibling stays GREEN because it carries its own transcribed ladder). OBSERVED: PREDICTION MET -- 6 failed / 185 passed; exactly the five site rows on 'all-three' plus the gantt/tree/calendar arm of 'array-shorthand+staticData'; sibling file green. REBUILD: none needed and that was CHECKED not assumed -- the test imports '../record-source.js' from inside core so vitest resolves it to src, which the red proves. MUTATION PROVED ON DISK: anchored count 'if (schema.data) {' 1 before, injected marker 0 -> 1 after, and git hash-object moved e6baa3f6 -> 7e027498 off the HEAD blob (empty hash treated as FAILURE, not 'nothing to compare'). RESTORE under an EXIT INT TERM trap calling a restore function with absolute paths from git rev-parse --show-toplevel, via git checkout HEAD -- ABSOLUTE_PATH (never a bare checkout): on-disk blob back to e6baa3f6 == HEAD blob, 0 marker residue, git diff HEAD empty. ABLATION 2 (predicted BEFORE running: deleting the array head from ObjectMap turns ObjectMap.schemaDataShorthand.test.tsx RED; a GREEN would mean the head is decorative and my whole preservation argument is wrong, which I would report as a miss). OBSERVED: PREDICTION MET -- 3 failed / 2 passed. This is what makes the preservation measured rather than stylistic. Mutation proved on disk: 'Array.isArray(authored)' 1 -> 0, marker 0 -> 1, blob 2ba40d38 -> 9ef25d7a; restored to 2ba40d38 == HEAD blob, 0 residue, empty git diff HEAD. SEARCH CONTROL: the GitHub search endpoint is blocked for this session (403 'sessions are bound to their configured repositories'), and its zeros read as 'total: None' -- a DARK instrument, discarded rather than published. Rebuilt on the repo-scoped REST list endpoint + local grep over 381 open issues, with a lit control (#7632 and #7651 both found).",
"mcp_calls": "1 - a single mcp__github__create_pull_request. Everything else (card body, full comment thread, issue listing for the dedup search, label writes, label read-back, PR body read-back, filing #7661) went through repo-scoped REST, which I probed first and which returned HTTP 200.",
"open_questions": [],
"out_of_scope_findings": [
"filed as #7661: a bare-array data renders EMPTY in ObjectTree, ObjectGantt and ObjectCalendar while six siblings (grid, map, ListView, ObjectChart, ObjectDataTable, calendar-view-renderer) normalize it to {provider:'value',items} - no error, no warning. Found because ObjectMap's docblock names ObjectTree among the blocks that accept it and that is measurably false (plugin-tree has no Array.isArray on schema.data at all; lit control - the same grep finds its five other Array.isArray uses). PR #7660 corrects the comment and deliberately leaves the behaviour alone, because closing the divergence is a behaviour change in three renderers and is likely blocked on #6207 (the two spec authorities disagreeing on whether object-grid.data is an array or a discriminated union). Filed unassigned and unlabelled for triage; dedup searched over 381 open issues with a lit control, nearest neighbours #6207, #7651, #7313 all related but distinct."
]
}

---

Generated by Claude Code