Skip to content

refactor(types,app-shell,plugin-designer): one tombstone registry for the designer seam's retired field keys - #6627

Draft
os-sales wants to merge 1 commit into
mainfrom
claude/issue-6527-retired-key-tombstone-registry
Draft

refactor(types,app-shell,plugin-designer): one tombstone registry for the designer seam's retired field keys#6627
os-sales wants to merge 1 commit into
mainfrom
claude/issue-6527-retired-key-tombstone-registry

Conversation

@os-sales

Copy link
Copy Markdown
Collaborator

Fixes#6527

Session: session_01CRJge11jso9TpXRWFt1Z49 (durable copy of the attribution, since PATCH edits demote the footer).

What this is

The designer seam carried three independently maintained RETIRED_FIELD_KEYS literals — the metadata-admin read door (packages/app-shell/src/views/metadata-admin/previews/object-fields-io.ts), MetadataService's carryOver and MetadataFieldsPage's carryOver — and they had drifted. They now derive from a single tombstone registry in @object-ui/types:

  • RETIRED_FIELD_KEY_TOMBSTONES — each retired key, the card that retired it (retiredBy), the accepted spelling the concept lives under today (specEquivalent, documentation and never a migration instruction), a defensive flag, and PER-SITE applicability booleans.
  • retiredFieldKeysFor(site) — the only supported way for a site to obtain its strip list; the return type is the literal union derived from the same data, so a site's list and its type cannot drift apart.

All three lists were re-taken on the merged ref (fa1348fe, which includes PR #6624) before writing anything, as the dispatch required — contents matched the card's table.

Deliberately NOT a union — per-site behaviour is unchanged and pinned

keyread door (object-fields-io)MetadataService carryOverMetadataFieldsPage carryOver
indexed (objectui#4644)stripstripstrip
referenceTo (objectui#6041)stripstripstrip
formula (objectui#6043)carry through — RULEDstripstrip
isSystem (objectui#6044)stripstripstrip
sortOrder (objectui#6045)carry throughstrip — recorded DEFENSIVEcarry through
  • formula at the read door: ruled on objectui#6526 (option B, director seat 2026-08-27) — the ObjectFieldInspector migration path (objectui#6043) stands; the linting CEL editor seeds from the legacy key and the first edit migrates it, and the 422 diagnostic points at that editor (PR fix(app-shell): name the field and the Formula (CEL) editor in the retired formula 422 diagnostic #6624). The registry records the false with the ruling, and retired-field-key-tombstones.test.ts pins it mechanically — flipping it also turns the read door's own pins and the inspector's migration pin red (measured below).
  • sortOrder verdict (recorded, not silently unioned): re-measured on this ref — FieldSchema 17.2.0 refuses it by name (probe with positive control), no emit site on this tree writes a field-level one, and DesignerFieldDefinition deliberately declares none (objectui#6045: "the key never reached the wire"). Chosen arm: keep the MetadataService strip as the registry's one explicitly-defensive entry, with the measurement cited on the tombstone. Keeping preserves exact per-site parity and protects any document a non-designer client may have stored while an older server accepted the key; dropping would turn such a document into an un-clearable 422. The other two sites do not gain it — widening them would be the naive union this card exists to prevent.

The per-key evidence that lived in three file-local comment blocks moved onto the tombstones; each site keeps only its own mechanics (strip-on-load contract, carry-over bounds, this writer's history).

Verification

Union re-run at the final commit ec93ccfa on a clean tree, under the shared verify lock (VERDICT command-exit 0): 62 test files / 716 tests passed (registry pins, the full previews and services suites, ObjectFieldInspector.test.tsx, six MetadataFieldsPage suites); type-check green for all three packages; check-changeset-presence / check-designer-field-key-parity / check-control-bytes green; package-scoped lint green for the three touched packages (turbo, 4 tasks — one pre-existing no-explicit-any warning in MetadataService.ts is on origin/main at the same line). Repo-wide pnpm lint is CI's run. tsc -p tsconfig.test.json --listFiles lists both new files, so the type-check verdict covers them.

Every new pin shown red (mutation committed-first; mutation proven on disk by a unique anchored replacement, before/after grep counts and a blob-hash difference vs HEAD; restore proven by empty git diff HEAD AND hash match, never by exit code; each leg's script carried a trap restore):

  • Leg A — flip formula's read-door flag to true: 5 red — the registry's asymmetry pin, its read-door parity pin, the read door's "names exactly the three keys" and "carries a legacy formula through", and ObjectFieldInspector's "commits edits to expression and migrates the legacy formula key" (the editor renders the empty string — the objectui#6519-measured destruction signature).
  • Leg B — flip sortOrder's MetadataService flag to false: 5 red — verdict pin, MetadataService parity pin, no-dead-entries pin, and both wire-bytes strip cases in MetadataService.fieldKeyCarryOver.test.ts (diagnostics increase: the key rides out onto the PUT body).
  • Leg C — erase defensive: true: exactly the 2 verdict pins red, 12 green.
  • Leg D — smuggle in an ACCEPTED key (sortable): 5 red — the membership-criterion pin, MetadataService parity pin, and three wire-bytes cases proving the hazard the criterion exists for (authored sortable deleted from the PUT body).

Cross-package negative type check: retiredFieldKeysFor('notASite') in app-shell turns tsc red with TS2345 naming the exact three-literal union from the rebuilt .d.ts, then restored. Mutation legs run against source directly (root vitest aliases @object-ui/types to packages/types/srcvitest.config.mts:261), so no stale-dist hazard applies to them.

Changeset: @object-ui/types minor (new public exports), @object-ui/app-shell / @object-ui/plugin-designer patch.

Cross-lane follow-up (deliberately NOT in this PR)

scripts/check-designer-field-key-parity.mjs still reads the declared payload shapes and does not know this registry. Triage's unlock shape includes pinning the registry as that gate's single source — that half is real and worth doing, but gate-class scripts/ is domain:devx, another lane. It needs its own card: without a gate pinning it, the registry is a convention, and conventions drift, which is exactly how three lists happened. This PR's registry test carries the interim line (parity pins per site + membership criterion).

#6526 is not addressed here (it landed as PR #6624); #6519, #6488, #6045, #6043, #6044, #6041, #4644 are context and all remain as they were.


Generated by Claude Code

… the designer seam's retired field keys
Three independently maintained RETIRED_FIELD_KEYS literals on the designer
seam (the metadata-admin read door in object-fields-io.ts, MetadataService's
carryOver, MetadataFieldsPage's carryOver) become derivations from a single
tombstone registry in @object-ui/types: RETIRED_FIELD_KEY_TOMBSTONES names
each retired key, the card that retired it, and its PER-SITE applicability,
and retiredFieldKeysFor(site) is the only supported way for a site to obtain
its strip list.
Deliberately NOT a union of the three lists — per-site behaviour is unchanged
and pinned per site:
- `formula` stays stripped by the two write-side carry-overs and is NOT
applicable at the read door, per the objectui#6526 option B ruling
(ObjectFieldInspector's linting CEL editor migrates the legacy key;
stripping on read destroys authored expression text). The registry test
makes that ruling mechanical.
- `sortOrder` stays a single-site strip at MetadataService's carry-over and is
now recorded as the registry's one DEFENSIVE entry, with the objectui#6045
measurement (no shipped writer ever populated a field-level one) cited on
the tombstone instead of the entry reading like a measurement.
The per-key evidence that used to live in three file-local comment blocks
moves onto the tombstones; each site keeps only its own mechanics (read-door
strip-on-load contract, carry-over bounds, this-writer history).
Not touched here: scripts/check-designer-field-key-parity.mjs still reads the
declared payload shapes, not this registry; pinning the registry as that
gate's single source is a cross-lane follow-up (gate-class scripts/ is
domain:devx), named in the PR body.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CRJge11jso9TpXRWFt1Z49
@github-actions

Copy link
Copy Markdown
Contributor

✅ Console Performance Budget

MetricValueBudget
Eager closure (gzip, 52 chunks)3237.6 KB3266.6 KB
Main entry chunk (gzip)157.3 KB350 KB
Entry fileindex-m1p4pqti.js
StatusPASS

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

PackageSizeGzipped
app-shell (consoleActionDispatch.js)0.20KB0.19KB
app-shell (index.js)11.89KB4.50KB
app-shell (runtime-config.js)20.61KB7.35KB
app-shell (types.js)0.01KB0.04KB
app-shell (urlParams.js)10.06KB3.86KB
auth (ActiveOrganizationStorage.js)25.05KB9.16KB
auth (AuthContext.js)0.31KB0.24KB
auth (AuthGuard.js)2.07KB1.00KB
auth (AuthProvider.js)40.18KB10.59KB
auth (AuthShell.js)3.49KB1.40KB
auth (ForgotPasswordForm.js)12.21KB3.45KB
auth (LoginForm.js)18.15KB5.39KB
auth (PreviewBanner.js)0.90KB0.50KB
auth (RegisterForm.js)6.65KB2.22KB
auth (SocialSignInButtons.js)9.61KB3.89KB
auth (UserMenu.js)3.41KB1.23KB
auth (auth-gate-events.js)1.29KB0.66KB
auth (authStyles.js)5.04KB1.72KB
auth (createAuthClient.js)40.21KB10.80KB
auth (createAuthenticatedFetch.js)8.46KB3.43KB
auth (index.js)3.19KB1.44KB
auth (invitation-status.js)1.22KB0.70KB
auth (org-roles.js)6.66KB2.78KB
auth (phone-identifier.js)1.11KB0.66KB
auth (types.js)0.59KB0.35KB
auth (useAuth.js)5.30KB1.02KB
auth (useWorkspaceAdminStatus.js)5.13KB2.35KB
collaboration (CommentThread.js)26.08KB7.56KB
collaboration (LiveCursors.js)3.17KB1.27KB
collaboration (PresenceAvatars.js)6.49KB2.64KB
collaboration (PresenceProvider.js)2.79KB1.13KB
collaboration (index.js)1.68KB0.73KB
collaboration (useCollaborationTranslation.js)6.05KB2.52KB
collaboration (useCommentSearch.js)1.98KB0.88KB
collaboration (useConflictResolution.js)7.75KB1.86KB
collaboration (useMentionNotifications.js)1.81KB0.68KB
collaboration (usePresence.js)6.33KB1.84KB
collaboration (useRealtimeSubscription.js)7.91KB2.01KB
components (index.js)507.69KB114.99KB
core (index.js)5.30KB2.13KB
create-plugin (index.js)10.08KB3.26KB
data-objectstack (index.js)173.10KB47.96KB
fields (index.js)238.89KB60.02KB
i18n (LocalizationContext.js)1.76KB0.96KB
i18n (currency.js)1.22KB0.64KB
i18n (fallbackInterpolation.js)6.25KB2.77KB
i18n (i18n.js)4.28KB1.75KB
i18n (index.js)3.44KB1.39KB
i18n (pickLocalized.js)7.62KB3.26KB
i18n (provider.js)26.89KB9.04KB
i18n (useDisplayLocale.js)2.85KB1.45KB
i18n (useObjectLabel.js)33.40KB8.71KB
i18n (useSafeTranslation.js)5.60KB2.33KB
layout (index.js)38.95KB10.97KB
mobile (MobileProvider.js)0.92KB0.49KB
mobile (ResponsiveContainer.js)0.94KB0.38KB
mobile (breakpoints.js)1.51KB0.70KB
mobile (createOfflineDataSource.js)5.61KB1.75KB
mobile (index.js)1.55KB0.62KB
mobile (offlineQueue.js)3.91KB1.35KB
mobile (pwa.js)0.97KB0.49KB
mobile (serviceWorker.js)1.48KB0.62KB
mobile (serviceWorkerSource.js)3.41KB1.48KB
mobile (useBreakpoint.js)1.54KB0.65KB
mobile (useGesture.js)6.96KB1.98KB
mobile (useOfflineSync.js)1.99KB0.72KB
mobile (usePullToRefresh.js)2.53KB0.85KB
mobile (useResponsive.js)0.72KB0.42KB
mobile (useResponsiveConfig.js)1.37KB0.63KB
mobile (useSpecGesture.js)4.32KB1.64KB
mobile (useTouchTarget.js)1.01KB0.54KB
permissions (MePermissionsProvider.js)9.53KB3.38KB
permissions (PermissionContext.js)0.31KB0.25KB
permissions (PermissionGuard.js)0.89KB0.45KB
permissions (PermissionProvider.js)4.64KB1.50KB
permissions (evaluator.js)5.12KB1.74KB
permissions (index.js)0.93KB0.41KB
permissions (store.js)0.91KB0.42KB
permissions (useFieldPermissions.js)1.28KB0.53KB
permissions (usePermissions.js)1.93KB0.88KB
plugin-ai (index.js)15.75KB3.80KB
plugin-calendar (index.js)46.85KB12.89KB
plugin-charts (index.js)64.66KB18.32KB
plugin-chatbot (index.js)190.33KB45.10KB
plugin-dashboard (index.js)133.46KB34.48KB
plugin-designer (index.js)212.80KB43.17KB
plugin-detail (index.js)245.29KB62.39KB
plugin-editor (index.js)2.46KB1.10KB
plugin-form (index.js)132.01KB32.23KB
plugin-gantt (index.js)165.16KB40.33KB
plugin-grid (index.js)201.66KB54.57KB
plugin-kanban (index.js)53.11KB14.62KB
plugin-list (index.js)112.86KB27.54KB
plugin-map (index.js)20.09KB6.62KB
plugin-markdown (index.js)13.72KB4.69KB
plugin-report (index.js)43.51KB11.94KB
plugin-timeline (index.js)26.72KB7.71KB
plugin-tree (index.js)9.26KB3.13KB
plugin-view (index.js)85.87KB21.12KB
providers (DataSourceProvider.js)0.75KB0.39KB
providers (MetadataProvider.js)1.37KB0.59KB
providers (ThemeProvider.js)1.90KB0.85KB
providers (UploadProvider.js)11.66KB3.50KB
providers (index.js)0.45KB0.23KB
providers (types.js)0.01KB0.04KB
react-runtime (index.js)5.62KB2.34KB
react (LazyPluginLoader.js)4.47KB1.63KB
react (SchemaRenderer.js)65.97KB21.98KB
react (data-invalidation.js)5.05KB2.08KB
react (index.js)2.44KB1.21KB
react (schema-input.js)2.32KB1.24KB
react (spec-input.js)0.20KB0.18KB
sdui-parser (codegen.js)5.41KB2.34KB
sdui-parser (dashboard-widget-options.js)3.08KB1.30KB
sdui-parser (index.js)4.93KB2.24KB
sdui-parser (input-type.js)2.84KB1.40KB
sdui-parser (parse.js)12.13KB3.65KB
sdui-parser (provenance.js)3.66KB1.82KB
sdui-parser (types.js)0.28KB0.23KB
sdui-parser (validate.js)9.30KB3.22KB
types (ai.js)0.20KB0.17KB
types (api-types.js)0.20KB0.18KB
types (app.js)2.87KB0.99KB
types (base.js)0.20KB0.18KB
types (blocks.js)0.20KB0.18KB
types (complex.js)2.74KB1.41KB
types (crud.js)0.20KB0.18KB
types (dashboard-filter-alias.js)6.23KB2.74KB
types (data-display.js)3.75KB1.85KB
types (data-protocol.js)0.20KB0.19KB
types (data.js)0.20KB0.18KB
types (designer.js)1.85KB0.85KB
types (disclosure.js)0.20KB0.18KB
types (error-code.js)1.54KB0.88KB
types (feedback.js)0.20KB0.18KB
types (field-types.js)0.20KB0.18KB
types (form.js)0.20KB0.18KB
types (http-inflight.js)8.87KB3.73KB
types (http-retry.js)4.32KB2.02KB
types (icon-key-migration.js)4.26KB1.63KB
types (index.js)4.83KB2.29KB
types (layout.js)0.20KB0.18KB
types (managed-by.js)0.19KB0.18KB
types (mobile.js)2.59KB1.31KB
types (navigation.js)0.20KB0.18KB
types (objectql.js)0.20KB0.18KB
types (overlay.js)0.20KB0.18KB
types (permissions.js)0.20KB0.18KB
types (plugin-scope.js)0.20KB0.18KB
types (record-components.js)0.20KB0.19KB
types (record-semantics.js)1.28KB0.67KB
types (registry.js)0.20KB0.18KB
types (reports.js)0.20KB0.18KB
types (retired-field-keys.js)11.20KB4.11KB
types (spec-report.js)5.05KB1.93KB
types (spec-ui-namespace.js)0.20KB0.19KB
types (system-fields.js)3.33KB1.54KB
types (theme.js)6.28KB2.87KB
types (ui-action.js)3.40KB1.71KB
types (views.js)0.20KB0.18KB
types (widget.js)0.20KB0.18KB

Size Limits

  • ✅ Core packages should be < 50KB gzipped
  • ✅ Component packages should be < 100KB gzipped
  • ⚠️ Plugin packages should be < 150KB gzipped

@os-salesClaude

Copy link
Copy Markdown
CollaboratorAuthor

Placement-topology measurements for the ruling on objectui#6527 (taken read-only on this branch at ec93ccfa, requested by the PM 2026-08-27; recorded here for whoever implements the ruling):

1. Yes — it is on the package's public entry, and only there

packages/types/src/index.ts on the branch, lines 688–701, verbatim:

// Retired-field-key tombstone registry — the single source for the designer// seam's per-site strip lists (objectui#6527).exporttype{RetiredFieldKeySite,RetiredFieldKeyTombstone,RetiredFieldKey,RetiredFieldKeysAt,}from'./retired-field-keys.js';export{RETIRED_FIELD_KEY_SITES,RETIRED_FIELD_KEY_TOMBSTONES,retiredFieldKeysFor,}from'./retired-field-keys.js';

So: three value exports + four type exports re-exported from the index barrel. The exports map publishes "." plus exactly ten named subpaths (./base, ./layout, ./form, ./data-display, ./feedback, ./overlay, ./navigation, ./complex, ./data, ./zod) — there is no./retired-field-keys subpath and no wildcard, and files publishes only dist. Because an exports map is present, undeclared subpaths do not resolve at all: the registry is reachable only through the main barrel. Package is not private.

2. Changeset frontmatter, verbatim

---
'@object-ui/types': minor
'@object-ui/app-shell': patch
'@object-ui/plugin-designer': patch
---

@object-ui/types is declared minor — the level a new public export requires — with patch on the two consumers.

3. Non-published placement: structurally not available; the real options with measured costs

The binding constraint, measured on the branch:

  • app-shellbuild: "tsc" — its dist preserves bare imports; nothing is inlined.
  • plugin-designerbuild: "vite build" with external: (id) => !/^[./]/.test(id) (vite.config.ts:52) — every bare specifier is externalized; imports preserved.
  • Both packages are published (neither private; both in the 40-package fixed group).

Therefore whatever module both consumers import must be resolvable at their consumers' runtime through some published package's exports map. A genuinely non-published single-source placement does not exist in this topology. The options:

  • A (current) — index barrel of @object-ui/types. Fully public, discoverable, permanent. Cost: a permanent maintenance obligation. Mitigation available without moving anything: JSDoc @internal-style prose on the exports (convention, not mechanism — stripInternal is NOT an option, it would blind the consumers' own typecheck).
  • B — dedicated subpath off the barrel: remove the index re-exports, add one exports entry (e.g. ./internal/retired-field-keys), consumers import the subpath. Still published API by the letter — an exports subpath is surface — but it leaves the main barrel untouched, signposts non-public intent in the path name, and a later withdrawal is one clearly-scoped subpath instead of barrel members. Cost: ~3-line exports-map change + 3 import-line changes + re-run of the pin suite; the barrel-wiring pin in retired-field-key-tombstones.test.ts would pin the subpath instead.
  • C — move into plugin-designer (app-shell already depends on it): relocates the same published surface onto a widget package's single "." barrel — strictly worse home, no surface saved. Not recommended.
  • D — duplication + equality pin: the only truly zero-new-surface shape, and it is the card's named failure mode (two lists again, held together by convention).
  • E — cross-package relative source import: blocked mechanically — app-shell's tsc rootDir excludes it, the emitted dist would carry a phantom path, and check:phantom-deps exists to catch exactly this class. Not viable.
  • F — private shared workspace package: no runtime precedent in this repo — the only private workspace lib (@object-ui/test-support) is consumed exclusively as a devDependency (measured across all seven dependents); a published package with a runtime dep on a private package is unresolvable for npm consumers. Not viable.

Plain answer: a non-published placement is not genuinely available. The choice is between A (public on the Protocol barrel, status quo, minor already declared) and B (published but fenced to a signposted subpath). Either way the placement adds published surface, which is why this sits with the maintainer; B is the smaller permanent obligation if the maintainer wants one at all.


Generated by Claude Code

@os-salesClaude

Copy link
Copy Markdown
CollaboratorAuthor

Test (shard 1/4) red at ec93ccfa — diagnosed, and it is NOT a flake. ⛔ No re-run: the cause is deterministic and is a direct consequence of the placement question this PR is held on.

ui execution seat, session_01CRJge11jso9TpXRWFt1Z49. This is the one comment the drive-to-green posture requires: what is failing, and what blocks fixing it.

The failure

FAIL packages/app-shell/src/views/metadata-admin/clientValidation.skew.test.tsx
Error: [vitest] No "ReportChartSchema" export is defined on the "@objectstack/spec/ui" mock.
❯ packages/types/src/spec-report.ts:104:38
❯ packages/types/src/index.ts:805:1

1 failed / 532 passed (533 files); 7174 tests passed. ⚠️ Note the shape: a failed SUITE, not a failed assertion — nothing about the registry's behaviour is wrong. The module graph changed.

⭐⭐ Why this is the placement decision showing up as a test failure

The registry is exported from @object-ui/types's main barrel (index.ts:688–701). To consume it, object-fields-io.ts must import from the barrel — and importing a barrel eagerly evaluates everything else in it, including spec-report.ts:104, which reads ReportChartSchema off @objectstack/spec/ui. That test installs a partialvi.mock of @objectstack/spec/ui which does not define that symbol, so evaluation throws before any test body runs.

⭐ The generalisable finding, worth more than the fix: adding one export to a barrel widens what every consumer of that barrel must be able to evaluate. A partial mock that was complete enough yesterday is not complete enough today, and nothing in the diff touches the failing test or the module it mocks. This is the same class as the lesson from PR #6626 earlier today — an enforcement or an assumption resting on a module's shape rather than on its behaviour, silently invalidated by a declaration landing elsewhere.

⛔ Why I am not fixing it

There are exactly two fixes, and choosing between them is the decision this PR is held on (see #6527):

  • Under option A (registry on the barrel, current): patch the test's mock to define ReportChartSchema. That fixes the symptom and accepts that every future barrel consumer with a partial spec mock inherits the same fragility.
  • Under option B (dedicated signposted subpath): the failure disappears at the root — a subpath import never pulls the barrel in, and no test's mock needs touching.

Pushing the mock patch would silently pre-commit the repo to A while a decision on A-vs-B is open. ⛔ Not mine to make.

What this changes about the decision

It moves a cost from theoretical to measured. My filing on #6527 argued B on governance grounds — smaller permanent obligation, more withdrawable. This adds a concrete technical cost to A that was not in that analysis: barrel placement makes every consumer's module graph wider, and the first thing it broke was an unrelated test in a package that merely imports the barrel. Recorded on the card as new evidence rather than left here.

⚠️ Also worth stating plainly: this failure did not appear in the dev's local union because that union covered the registry suite plus the directly-affected suites. CI shards run the whole repo, which is why they caught it and a scoped union could not. That is the sharding earning its keep, not a verification lapse.

Status: PR stays draft, held on #6527's ruling. Once ruled, the fix follows from the ruling and I will resume the same dev on this same claim.


Generated by Claude Code

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

refactor(app-shell,plugin-designer): unify the three retired-field-key lists on the designer seam into one tombstone registry

2 participants

@os-sales@claude