fix(data-objectstack,app-shell): a view overlay contributes only the keys it owns

[os-support-ai]

Part of #5233

Not Fixes — deliberately. This lands the half that is entirely ours (the read), and
escalates the half the ruling names (the write at rest) with the measurement that blocks
it. Details in "What does not ship" below; the issue should stay open on that decision.

The defect

persistViewPatch sends { ...baseViewDef, ...patch }, so an overlay written by a mere
column drag copies the view's current effective filter — and its columns, label,
type, isDefault — into the stored row. The display merge is { ...source, ...override }
(buildViewTabs / viewEntry), so that snapshot then outranks the source view
indefinitely: an admin edits the view's filter and everyone who once resized a column keeps
the old filter, with nothing anywhere reporting it.

Ruled by the maintainer on 2026-08-12 (objectstack#7494, comment 5261754173):

persistViewPatch 只存 patch,不存 merged base —— 独立小修,现在做:它把写入时的有效
filter 冻进 overlay,导致源视图后续的 filter 变更到不了带 overlay 的用户,这与 per-user
之争无关,是纯粹的存储形状错误。

Premise re-verified on main — one correction

The card attributes persistViewPatch to packages/data-objectstack/src/index.ts. On
current main the function — and the { ...baseViewDef, ...patch } spread — live in
packages/app-shell/src/views/ObjectView.tsx (the useCallback around line 698, the write
around line 727). The adapter's updateViewConfig is what persists that body verbatim.
The defect itself reproduces exactly as described; only the file attribution was off. The
declared file surface for this claim is amended accordingly (comment on the issue), and it
is why this PR touches app-shell as well as the adapter.

What ships: an overlay contributes only the keys it owns

@object-ui/data-objectstack gains two exports, because it is the package that owns the
overlay row's shape (it stamps the _isOverride marker that listViews() excludes rows by):

• VIEW_OVERLAY_OWNED_KEYS — rowHeight, sort, hiddenFields, columnState,
  inlineEdit: one per persistViewPatch call site, read off the tree.
• narrowPersonalizationOverlay(row) — reduces a personalization overlay row to
  identity plus those five. A saved view's own body is returned by reference, untouched;
  classification is the existing isPersonalizationOverlayRow, so a row cannot be an
  overlay for one reader and a saved view for another.

sanitizeViewOverride (app-shell) applies it. That is the one seam both branches of
loadViewOverrides pass through — already pinned as such by
ObjectView.overlayFilterRecovery.test.tsx — and it is where a row is read as a patch.

Deliberately not applied inside listViewOverrides / getView: both answer with the
stored document, their equality is itself pinned ("same key space, same document",
listViewOverrides.test.ts), and InterfaceListPage hydrates a hollow view out of it.
Narrowing the document read would have broken that pin and that hydration.

label is dropped from the overlay on purpose, even though the platform stamps it there:
viewIdentityPatch (@objectstack/metadata-protocol, #2555) inherits viewKind/object/
label from the registry entry an overlay shadows, so a stored label is a snapshot of the
source view's label — content, not identity. Same for isDefault, which the tab carries and
the fat write therefore froze.

The existing-rows decision: tolerate on read — explicitly, and pinned

Rows already stored carry the frozen body. Of the three dispositions the card names:

• Strip on next write — heals a row only if that view's user happens to touch it again,
  and leaves the frozen filter authoritative until then. It also cannot ship on its own
  right now (see below).
• Migrate — clean end state, but needs a runner over sys_metadata rows an operator may
  not know exist, and buys nothing the read-side narrowing does not already deliver.
• Tolerate on read — chosen. Every existing row stops shadowing its source on the next
  page load: no migration, no rewrite at rest, no user action.

The card forbids silent tolerance, not tolerance. This one is documented at the function,
declared here, and pinned by tests that say which decision they encode
(ObjectView.overlayPatchOnly.test.ts, "rows written BEFORE this fix (the disposition,
pinned)"), including the pre-marker legacy shape.

What does not ship, and why: the write at rest

The ruling's own words are "store the patch only". Measured against the platform's live
contract before writing any of it, that shape is refused for one of the five keys:

ViewMetadataSchema.safeParse({ columnState: {...}, object, name, viewKind, _isOverride })
REFUSE Not a `view` body: no recognized `view` key. Expected at least one of a container
slot (`list` / `form` / `listViews` / `formViews`), a ViewItem record (`viewKind`
+ `config`), or an inline view config (`type`, `columns`, `sections`, `filter`, …).
Received unrecognized keys `columnState`, `_isOverride` …

Measured with @objectstack/spec 17.0.0 as installed here; columnState appears nowhere in
the framework's packages/spec/src either. sort, rowHeight, hiddenFields and
inlineEdit all parse fine on their own — columnState does not, because it is objectui's
own non-author runtime key (plugin-grid/src/__tests__/gridNonAuthorKeys.test.tsx).
saveMetaItem validates every view write (after normalizeViewMetadata inherits identity
from the registry baseline), so a patch-only write for a column resize or reorder — the
most frequent toolbar toggle, and one that travels alone — would come back 422
INVALID_METADATA and the user's resize would not persist at all. Today it survives only
because the copied base rides along and supplies a recognized key.

So the storage-shape half needs a decision that is not this card's to take:

1. Teach the platform's view schema the runtime overlay keys, then narrow the write
   (contract-first: the refusal is the producer's, and the row is a real, already-persisted
   shape it declines to describe). Costs a framework change and a release.
2. Narrow the write anyway and lose columnState persistence until (1) lands. Cheapest to
   write, but it removes a working feature.
3. Keep the fat write, as this PR does, and rely on the read-side narrowing: no frozen key
   reaches a user, but the stale bytes stay at rest and any reader outside objectui (Studio,
   server-side switcher) still sees a snapshot.
4. Move personalization out of the view metadata namespace entirely — the parked per-user
   direction on objectstack#7494 / Implement the objectstack#7494 ruling: view config is explicitly org-wide — console wording/UX + permission-gated write path #5232.

Recommendation: (1) with (3) shipped now as the harm-elimination half. (2) trades a silent
staleness for a visible regression; (4) is parked and much larger.

Tests

• packages/app-shell/src/views/ObjectView.overlayPatchOnly.test.ts — the defect pin, round
  trip through the real adapter write + read and the real consumer merge
  (loadViewOverrides → buildViewTabs): a column drag writes the overlay, the admin then
  edits the source view's filter and columns, and the tab shows the new ones while keeping
  the columnState/sort/hiddenFields/rowHeight/inlineEdit the overlay was written
  for. Plus the disposition pins, the two "must NOT be narrowed" controls, and a ratchet
  that reads ObjectView.tsx and fails if persistViewPatch ever writes a key the overlay
  is not allowed to own (the drift that would otherwise silently drop a user's setting).
• packages/data-objectstack/src/viewOverlayPatchOnly.test.ts — the policy itself, and the
  document/patch boundary this PR deliberately keeps.

Reverse verification (predicted before running)

Two legs, both against committed code. No rebuild needed and none can hide a stale result:
the root vitest.config.mts aliases @object-ui/data-objectstack to
packages/data-objectstack/src, so tests resolve source, not dist — and the ablations
turning red is itself the proof of that resolution.

leg	predicted	observed
wiring removed from sanitizeViewOverride	4 red in the app-shell pin, 8 green in the adapter pin	exactly that — the reds report the frozen status: open where qualified was expected
narrowPersonalizationOverlay made inert	4 red / 4 green in the adapter pin, same 4 red in app-shell	3 red / 5 green in the adapter pin; app-shell as predicted

The miss is reported rather than smoothed over, and it found a real weakness: "omits an
owned key the row does not carry" used a fixture of identity plus one owned key, whose key
set is already the narrowed one — so it held against a narrowing that never ran. The
fixture now carries a base key (second commit) and the leg re-run gives 4 red / 4 green.

Gates

Run at 670380763, the tree this PR points at:

• pnpm exec vitest run packages/data-objectstack/ — 41 files, 556 tests, all pass.
• pnpm exec vitest run packages/app-shell/ — 447 files, 4313 pass, 1 skipped (run at
  f0b6bf59a; the only later change is five lines inside one data-objectstack test file,
  re-run green, so no app-shell input moved).
• pnpm --filter @object-ui/data-objectstack --filter @object-ui/app-shell type-check and
  lint — pass (app-shell's type-check covers the test tsconfig; both script names echoed
  in the output, so neither was a zero-match silent pass).
• pnpm check:control-bytes, check:phantom-deps (this PR adds a cross-package import),
  check:self-import, check:spec-symbols, check:esm-specifiers, plus
  check-changeset-no-major.mjs and check-changeset-fixed.mjs — all pass.

Changeset: patch for @object-ui/data-objectstack and @object-ui/app-shell.

Generated by Claude Code

---

Generated by Claude Code

[github-actions]

✅ Console Performance Budget

Metric	Value	Budget
Main entry (gzip)	25.3 KB	350 KB
Entry file	index-DWTn_iOc.js	—
Status	PASS	—

---

📦 Bundle Size Report

Package	Size	Gzipped
app-shell (index.js)	9.83KB	3.70KB
app-shell (runtime-config.js)	7.42KB	2.32KB
app-shell (types.js)	0.01KB	0.04KB
app-shell (urlParams.js)	8.92KB	3.41KB
auth (AuthContext.js)	0.31KB	0.24KB
auth (AuthGuard.js)	1.17KB	0.53KB
auth (AuthProvider.js)	29.33KB	7.05KB
auth (AuthShell.js)	3.49KB	1.40KB
auth (ForgotPasswordForm.js)	12.21KB	3.45KB
auth (LoginForm.js)	18.13KB	5.39KB
auth (PreviewBanner.js)	0.90KB	0.50KB
auth (RegisterForm.js)	6.64KB	2.21KB
auth (SocialSignInButtons.js)	9.60KB	3.89KB
auth (UserMenu.js)	3.40KB	1.22KB
auth (auth-gate-events.js)	1.29KB	0.66KB
auth (authStyles.js)	5.04KB	1.72KB
auth (createAuthClient.js)	40.21KB	10.79KB
auth (createAuthenticatedFetch.js)	6.34KB	2.43KB
auth (index.js)	2.71KB	1.22KB
auth (invitation-status.js)	1.22KB	0.70KB
auth (org-roles.js)	6.66KB	2.78KB
auth (phone-identifier.js)	1.11KB	0.66KB
auth (types.js)	0.59KB	0.35KB
auth (useAuth.js)	5.02KB	0.88KB
auth (useIsWorkspaceAdmin.js)	1.61KB	0.85KB
collaboration (CommentThread.js)	26.07KB	7.56KB
collaboration (LiveCursors.js)	3.17KB	1.27KB
collaboration (PresenceAvatars.js)	6.49KB	2.64KB
collaboration (PresenceProvider.js)	2.79KB	1.13KB
collaboration (index.js)	1.65KB	0.73KB
collaboration (useCollaborationTranslation.js)	6.05KB	2.52KB
collaboration (useCommentSearch.js)	1.98KB	0.88KB
collaboration (useConflictResolution.js)	7.75KB	1.86KB
collaboration (useMentionNotifications.js)	1.81KB	0.68KB
collaboration (usePresence.js)	6.33KB	1.84KB
collaboration (useRealtimeSubscription.js)	7.91KB	2.01KB
components (index.js)	506.17KB	113.33KB
core (index.js)	4.11KB	1.62KB
create-plugin (index.js)	10.08KB	3.26KB
data-objectstack (index.js)	159.80KB	44.34KB
fields (index.js)	237.07KB	59.46KB
i18n (LocalizationContext.js)	1.76KB	0.96KB
i18n (currency.js)	1.22KB	0.64KB
i18n (i18n.js)	4.28KB	1.75KB
i18n (index.js)	3.42KB	1.39KB
i18n (pickLocalized.js)	3.69KB	1.73KB
i18n (provider.js)	23.13KB	7.63KB
i18n (useDisplayLocale.js)	2.85KB	1.45KB
i18n (useObjectLabel.js)	29.43KB	7.15KB
i18n (useSafeTranslation.js)	7.77KB	3.13KB
layout (index.js)	39.16KB	10.97KB
mobile (MobileProvider.js)	0.92KB	0.49KB
mobile (ResponsiveContainer.js)	0.94KB	0.38KB
mobile (breakpoints.js)	1.51KB	0.70KB
mobile (createOfflineDataSource.js)	5.61KB	1.74KB
mobile (index.js)	1.50KB	0.62KB
mobile (offlineQueue.js)	3.91KB	1.35KB
mobile (pwa.js)	0.97KB	0.49KB
mobile (serviceWorker.js)	1.48KB	0.62KB
mobile (serviceWorkerSource.js)	3.41KB	1.48KB
mobile (useBreakpoint.js)	1.54KB	0.65KB
mobile (useGesture.js)	6.96KB	1.98KB
mobile (useOfflineSync.js)	1.99KB	0.72KB
mobile (usePullToRefresh.js)	2.53KB	0.85KB
mobile (useResponsive.js)	0.71KB	0.42KB
mobile (useResponsiveConfig.js)	1.36KB	0.63KB
mobile (useSpecGesture.js)	4.32KB	1.64KB
mobile (useTouchTarget.js)	1.01KB	0.54KB
permissions (MePermissionsProvider.js)	9.35KB	3.31KB
permissions (PermissionContext.js)	0.31KB	0.25KB
permissions (PermissionGuard.js)	0.89KB	0.45KB
permissions (PermissionProvider.js)	4.42KB	1.42KB
permissions (evaluator.js)	5.12KB	1.74KB
permissions (index.js)	0.91KB	0.41KB
permissions (store.js)	0.91KB	0.42KB
permissions (useFieldPermissions.js)	1.28KB	0.52KB
permissions (usePermissions.js)	1.81KB	0.83KB
plugin-ai (index.js)	15.75KB	3.80KB
plugin-calendar (index.js)	46.62KB	12.83KB
plugin-charts (index.js)	64.75KB	18.37KB
plugin-chatbot (index.js)	181.21KB	43.14KB
plugin-dashboard (index.js)	128.04KB	32.75KB
plugin-designer (index.js)	212.39KB	42.83KB
plugin-detail (index.js)	241.46KB	60.56KB
plugin-editor (index.js)	2.46KB	1.10KB
plugin-form (index.js)	123.77KB	30.07KB
plugin-gantt (index.js)	164.10KB	39.87KB
plugin-grid (index.js)	198.22KB	53.27KB
plugin-kanban (index.js)	52.93KB	14.60KB
plugin-list (index.js)	111.66KB	27.13KB
plugin-map (index.js)	19.96KB	6.56KB
plugin-markdown (index.js)	13.72KB	4.69KB
plugin-report (index.js)	42.84KB	11.77KB
plugin-timeline (index.js)	26.68KB	7.66KB
plugin-tree (index.js)	8.50KB	2.88KB
plugin-view (index.js)	84.08KB	20.59KB
providers (DataSourceProvider.js)	0.75KB	0.39KB
providers (MetadataProvider.js)	1.37KB	0.59KB
providers (ThemeProvider.js)	1.90KB	0.85KB
providers (UploadProvider.js)	11.66KB	3.50KB
providers (index.js)	0.44KB	0.22KB
providers (types.js)	0.01KB	0.04KB
react-runtime (index.js)	5.62KB	2.34KB
react (LazyPluginLoader.js)	3.77KB	1.33KB
react (SchemaRenderer.js)	31.56KB	10.70KB
react (data-invalidation.js)	5.05KB	2.08KB
react (index.js)	1.33KB	0.69KB
react (schema-input.js)	1.45KB	0.83KB
react (spec-input.js)	0.20KB	0.18KB
sdui-parser (codegen.js)	5.41KB	2.34KB
sdui-parser (index.js)	4.77KB	2.16KB
sdui-parser (input-type.js)	2.84KB	1.40KB
sdui-parser (parse.js)	10.76KB	3.17KB
sdui-parser (provenance.js)	3.66KB	1.82KB
sdui-parser (types.js)	0.29KB	0.24KB
sdui-parser (validate.js)	6.92KB	2.40KB
types (ai.js)	0.20KB	0.17KB
types (api-types.js)	0.20KB	0.18KB
types (app.js)	2.87KB	0.99KB
types (base.js)	0.20KB	0.18KB
types (blocks.js)	0.20KB	0.18KB
types (complex.js)	0.20KB	0.18KB
types (crud.js)	0.20KB	0.18KB
types (dashboard-filter-alias.js)	6.23KB	2.74KB
types (data-display.js)	0.20KB	0.18KB
types (data-protocol.js)	0.20KB	0.19KB
types (data.js)	0.20KB	0.18KB
types (designer.js)	1.87KB	0.85KB
types (disclosure.js)	0.20KB	0.18KB
types (error-code.js)	1.54KB	0.88KB
types (feedback.js)	0.20KB	0.18KB
types (field-types.js)	0.20KB	0.18KB
types (form.js)	0.20KB	0.18KB
types (http-retry.js)	4.32KB	2.02KB
types (index.js)	3.08KB	1.53KB
types (layout.js)	0.20KB	0.18KB
types (managed-by.js)	0.19KB	0.18KB
types (mobile.js)	2.59KB	1.31KB
types (navigation.js)	0.20KB	0.18KB
types (objectql.js)	0.20KB	0.18KB
types (overlay.js)	0.20KB	0.18KB
types (permissions.js)	0.20KB	0.18KB
types (plugin-scope.js)	0.20KB	0.18KB
types (record-components.js)	0.20KB	0.19KB
types (record-semantics.js)	1.28KB	0.67KB
types (registry.js)	0.20KB	0.18KB
types (reports.js)	0.20KB	0.18KB
types (spec-report.js)	5.05KB	1.93KB
types (system-fields.js)	3.33KB	1.54KB
types (theme.js)	0.20KB	0.18KB
types (ui-action.js)	3.40KB	1.71KB
types (views.js)	0.20KB	0.18KB
types (widget.js)	0.20KB	0.18KB

Size Limits

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