…for the gantt and calendar record-source ladder
The gantt and calendar zod describes and TS docs attributed the three-rung
record-source ladder to a `getDataConfig` their renderers no longer hold
(removed by objectui#7632; the calendar never had one). Name the shared
`resolveRecordSourceConfig` instead; the map text stays, since
`ObjectMap.tsx` keeps a local `getDataConfig` wrapper. The ladder order is
unchanged. `record-source.ts` now says its quotation is the map faces' text.
Adds a pin that gantt/calendar faces never name `getDataConfig`, with the map
faces as control.
Co-Authored-By: Claude <noreply@anthropic.com>
Fixes #9618
Clause-②: no
What changed
Text only: no schema shape, accept-set or export moves. The ladder ORDER (
data, thenstaticData, thenobjectName) is unchanged everywhere.The gantt and calendar record-source text named a
getDataConfigthat their renderers do not contain. objectui#7632 (commitce2aaefe1) took it out ofObjectGantt.tsx, andObjectCalendar.tsxhas none either. Both renderers call the sharedresolveRecordSourceConfigfrom@object-ui/core. This PR rewrites only the false mentions so they name that function. The map text stays as it is, becauseObjectMap.tsxstill has its localfunction getDataConfig(wrapper, which delegates to the shared ladder.Census: every
getDataConfigmention in the two types files onorigin/main(c2c4372)The renderer check greps each renderer file. The control reads
ObjectMap.tsx: it hasfunction getDataConfig(and 7 mentions, whileObjectGantt.tsxandObjectCalendar.tsxhave 0 each. Positions are given by the owning symbol, not by line.getDataConfig?zod/objectql.zod.tsrequireRecordSourcedocblock (the refinement shared by map, gantt and calendar), 2 mentionsresolveRecordSourceConfigand says the map reaches it through its local wrapperzod/objectql.zod.tsObjectMapSchemadocblock +objectName/data/staticDatadescribes, 4 mentionszod/objectql.zod.tsObjectGanttSchemadocblock +objectName/data/staticDatadescribes, 4 mentionszod/objectql.zod.tsObjectCalendarSchemaobjectName/staticDatadescribes, 2 mentionsobjectql.tsObjectMapSchema.objectName/.dataJSDoc, 2 mentionsobjectql.tsObjectGanttSchema.objectName/.data/.staticDataJSDoc, 3 mentions.datadoc quoted the codeif (schema.data) return schema.data;, which the shared ladder no longer contains (rung 1 is judged by arm), so that quote is replaced with a descriptionobjectql.tsObjectCalendarSchema.objectName/.staticDataJSDoc, 2 mentionsAfter the change, 5 mentions remain in the zod file and 2 in
objectql.ts. All of them are on map text, plus the new wording that names the map's local wrapper.Second site,
packages/core/src/utils/record-source.ts. Two docblocks quoted the describes as the ruled contract and attributed that text to the map and gantt twins. Both now say that the quoted text is the map faces' text, and that the gantt (and calendar) faces nameresolveRecordSourceConfig. TheresolveRecordSourceObjectNamedocblock said callers pass "theirgetDataConfig(schema)output". It now says they pass theirresolveRecordSourceConfigoutput, directly or through a local wrapper. This stays clear of the regions that objectui#10540 edits in the same file.Test header. The
objectql-record-source-refinement-6939.test.tsheader made the same attribution, and it is corrected in the same way. That file also holds the new pin.Pin and reverse verification
A new
describeblock,objectui#9618 — the record-source text names the function each renderer actually has, inpackages/types/src/__tests__/objectql-record-source-refinement-6939.test.ts:ObjectGanttSchemaandObjectCalendarSchema, no zod member describe containsgetDataConfig. TheobjectNameandstaticDatadescribes nameresolveRecordSourceConfig, and the TSexport interfaceblock contains nogetDataConfig.getDataConfig, andObjectMap.tsxstill declaresfunction getDataConfig(.Reverse verification ran from the committed fix (
a709aab8f), with restore fromHEADunder an EXIT/INT/TERM trap. The mutation putgetDataConfigback into the ganttobjectNamedescribe. On disk the marker count went from 1 to 0 and thegetDataConfigcount from 5 to 6. Vitest then reportedTests 1 failed | 19 passed (20), and the failure wasObjectGanttSchema: no zod describe and no TS doc names getDataConfig. After the restore,git diff HEADwas 0 bytes and the file hash matched theHEADblob.Local verification (head
27ac561f0, after mergingorigin/main)pnpm exec vitest run packages/types/ packages/core/src/utils/gaveTest Files 324 passed (324)andTests 6923 passed (6923). This covers the zod mirror parity suites inpackages/types.pnpm --filter '@object-ui/core^...' run build, thenpnpm --filter @object-ui/types --filter @object-ui/core run type-check: both printedDone, exit 0.--format json, 4 files): 0 errors. The warnings are existingno-explicit-anyhits on untouched lines.eslint.config.jssets noparserOptionsor type-aware config, so this diff cannot change the verdict on any untouched file. The repo-widepnpm lintis left to CI.check-changeset-presencepassed with 1 changeset for 4 source files in 2 released packages.check-changeset-no-major,check:new-line-citations(0 new citation(s)),check:control-bytesandcheck:test-path-rootsall exited 0.check-governed-queue-guard --testreports NOT GOVERNED.Acceptance notes (not in this PR)
packages/plugin-gantt/src/index.tsxstill has 3 comment mentions that sayObjectGanttreads throughgetDataConfig. They have the same false attribution, but the file is outside this card's claimed surface and the text is comment-only. Carrier: none..changeset/*.mdbodies namegetDataConfigfor the renderers of their time. They are release records of those changes and are left alone.Generated by Claude Code