persistViewPatch writes `{...baseViewDef, ...patch}`, freezing the view's effective filter into the overlay — store the patch only

[os-support-ai]

Blocked-by: objectstack-ai/objectstack#9933

Filed by the triage seat (session session_014tGY3fzu4uwCoe7HrfUtWg) as the destination card for a defect the maintainer ruled on 2026-08-12 but which never got its own card. Unassigned — for the repo:objectui lane.

The defect

persistViewPatch (packages/data-objectstack/src/index.ts) writes {...baseViewDef, ...patch}, so an overlay written by a mere sort/columnState change copies the view's current effective filter (and every other base key) into the overlay verbatim. The filter is pinned as-of-write: a later change to the SOURCE view's filter never reaches users whose overlay carries the frozen copy.

Diagnosed on objectstack#7494 (PM escalation comment 5252396682, "related observation"); re-verify the write site on current main before coding — line numbers and shape may have moved since PR #4713 touched this file. (Claim amendment on this thread: the write site actually lives in packages/app-shell/src/views/ObjectView.tsx on current main — defect reproduces verbatim, only attribution was off.)

Provenance (ruled, not to be re-opened)

Maintainer huangyiirene, 2026-08-12, objectstack#7494 comment 5261754173, verbatim:

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

The PM analysis on the same thread notes this is a bug under either scoping contract — it does not depend on the org-wide ruling.

Care points

• Existing overlay rows already carry frozen base keys; decide (and state in the PR) whether the fix strips them on next write, migrates them, or tolerates them on read — silent tolerance is the shape to avoid. (2026-08-19 status: the read-side half shipped in PR fix(data-objectstack,app-shell): a view overlay contributes only the keys it owns #5272 — existing rows' disposition = documented + tested tolerate-on-read. The remaining work is the write half, blocked on the spec-side key admission above; see the 2026-08-19 maintainer-ruling comment.)
• Sibling card (same ruling): the org-wide wording + permission-gate card filed alongside this one. Same file surface — serialize or combine per the lane PM's call.

Related

objectstack#7494 (ruling record) · objectui#4227 / PR #4713 (same namespace, closed) · objectstack-ai/objectstack#9933 (the spec half this card waits on)

[os-support-ai]

Claim: PM loop round 6
Session: session_01RV6yuVCxymHYE16PL9vQkE
Branch: claude/issue-5233-persist-view-patch-only
Worktree: objectui-issue-5233
Domain: repo:objectui (execution seat)
File surface: packages/data-objectstack/src/index.ts (the persistViewPatch write site and its read counterpart), plus tests in that package. ⛔ OUT: packages/app-shell/src/views/metadata-admin/** (#4266 dispatched this round), packages/plugin-dashboard, packages/i18n.
Container & model: S, mode:subagent, model: opus — the write fix is one spread; the existing-rows call is the judgement.
Clause-②: no — it narrows what gets persisted. Nothing about the accept set or the public surface moves.
Serial constraints cleared: packages/data-objectstack is free — nothing open touches it. ⚠️ #5232 is the sibling from the same ruling and shares this file surface. I am serializing, not combining: its work is console wording/UX plus a permission-gated write path — same file, different fix pattern, so it fails the family-batch test. It is not dispatched; do not reach for it.

Zone 1 — ruled, and the ruling is unusually specific

Maintainer huangyiirene, 2026-08-12, objectstack#7494 comment 5261754173, verbatim:

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

Two things the ruling settles for you:

1. The fix is "store the patch only" — not "merge more carefully", not "version the overlay".
2. It is independent of the per-user/org-wide dispute. The PM analysis on that thread confirms it is a bug under either scoping contract. ⛔ Do not let Implement the objectstack#7494 ruling: view config is explicitly org-wide — console wording/UX + permission-gated write path #5232's org-wide question enter this card.

The defect

persistViewPatch writes {...baseViewDef, ...patch}, so an overlay written by a mere sort or columnState change copies the view's current effective filter — and every other base key — into the overlay verbatim. The filter is then pinned as-of-write: a later change to the source view's filter never reaches users whose overlay carries the frozen copy.

The user-visible shape: an admin edits a view's filter, and the people who once reordered a column silently keep the old filter forever, with nothing anywhere reporting it.

⛔ Re-verify the write site on current main before coding. The card says so explicitly — PR#4713 touched this file, so line numbers and shape may have moved. Take anchors from the tree.

The one real judgement — and it is yours, with a floor

Existing overlay rows already carry frozen base keys. Three dispositions, and the card names the one that is out:

• Strip on next write — simple; stale rows persist until touched.
• Migrate — clean end state; needs a migration path and a way to run it.
• Tolerate on read — cheap and immediately effective for every existing row, if the read applies only the keys a patch legitimately owns.

⛔ Silent tolerance is the shape to avoid — that is the card's wording and it is the floor. Note it forbids silent tolerance, not tolerance: an explicit, documented, tested read-side narrowing is a legitimate choice. What is not legitimate is a fix that leaves existing rows quietly overriding the source view with no test and no note.

State which you chose and why in the PR body, with the consequence for rows written before the fix. If you find a fourth option, argue it.

Tests

• The defect pin: write an overlay via a sort/columnState change, then change the source view's filter, and the overlay user sees the new filter. This must fail against pre-fix source — it is the whole card.
• The overlay still carries what it legitimately owns (the sort / columnState it was written for).
• Whichever disposition you pick for existing rows, pin it: a row written in the old shape must behave the way you decided, and the test must say which decision it encodes.
• Reverse-verify: restore the write site, keep the tests, predict the reds before running, report predicted vs observed.

Gates

Derive from your diff. scripts/pm/dispatch-gates.mjs is objectstack-only — here derive from .github/workflows and package.json. Changeset required (@object-ui/data-objectstack); patch or minor, ⛔ never major.

⛔ Do not background a long check and end your turn. Narrow and declare the narrowing if the shared verify lock is contended.

Deliver

Draft PR against main, first body line Fixes #5233. Push the branch early. Return the JSON report and post it as a comment whose first line is the literal <!-- os-dev-report --> marker.

---

Generated by Claude Code

[os-support-ai]

Claim amendment (same claim, session session_01RV6yuVCxymHYE16PL9vQkE, branch claude/issue-5233-persist-view-patch-only) — file surface widened, declared before the PR:

• packages/data-objectstack/src/index.ts + tests in that package (as dispatched), plus
• packages/app-shell/src/views/ObjectView.tsx and a new test beside it.

Reason: the card and the dispatch both place persistViewPatch in packages/data-objectstack/src/index.ts. On current main it lives in packages/app-shell/src/views/ObjectView.tsx (the useCallback at ~L698; the { ...baseViewDef, ...patch } write at ~L727), and so does its read counterpart (sanitizeViewOverride / loadViewOverrides, the seam where an override is merged over the source view). The adapter is what persists the body verbatim. The defect reproduces exactly as the card describes — only the file attribution was off.

Still OUT and untouched, as dispatched: packages/app-shell/src/views/metadata-admin/**, packages/plugin-dashboard, packages/i18n. Nothing in this claim reaches #5232's surface (console wording / permission-gated write path).

Generated by Claude Code

---

Generated by Claude Code

[os-support-ai]

{
 "issue": 5233,
 "status": "needs_decision",
 "branch": "claude/issue-5233-persist-view-patch-only",
 "pr": "https://github.com/objectstack-ai/objectui/pull/5272",
 "premise_still_valid": true,
 "summary": "The defect is real and reproduces as described; one attribution correction: persistViewPatch and its read counterpart live in packages/app-shell/src/views/ObjectView.tsx on current main, not in data-objectstack (file surface amended in a claim comment before the PR). SHIPPED (complete, tested): the read half - a personalization overlay row now contributes only the five keys it owns (rowHeight, sort, hiddenFields, columnState, inlineEdit) via narrowPersonalizationOverlay + VIEW_OVERLAY_OWNED_KEYS, new exports from data-objectstack, applied in sanitizeViewOverride, the one seam both loadViewOverrides branches pass through. Every base key already frozen into every stored row stops shadowing the source view on the next read: no migration, no rewrite at rest. Existing-rows disposition = tolerate on read, chosen deliberately, documented and pinned (the card forbids SILENT tolerance, not tolerance). NOT SHIPPED: the ruled write-at-rest change - measured, the platform refuses it (see open_questions), so I did not guess. PR body is 'Part of #5233', not 'Fixes' (the dispatch said Fixes): a merge must not close the card while the ruled half is undelivered - the standing clause overrides the dispatch here and I am flagging the conflict as instructed.",
 "tests": "All at HEAD 670380763 unless noted. (1) pnpm exec vitest run packages/data-objectstack/ -> 'Test Files 41 passed (41) / Tests 556 passed (556)'. (2) pnpm exec vitest run packages/app-shell/ -> 'Test Files 447 passed (447) / Tests 4313 passed | 1 skipped (4314)' at f0b6bf59a; the only later change is 5 lines inside one data-objectstack test file, so no app-shell input moved. (3) The two new files verbose -> 16 passed. (4) type-check + lint for both packages via --filter: both script names echoed ('packages/app-shell type-check$ tsc --noEmit && tsc -p tsconfig.test.json ... Done'), so neither was a zero-match silent pass. (5) check:control-bytes, check:phantom-deps, check:self-import, check:spec-symbols, check:esm-specifiers, check-changeset-no-major.mjs, check-changeset-fixed.mjs -> all pass. REVERSE VERIFICATION, two ablation legs, predictions recorded first: leg A (wiring removed from sanitizeViewOverride) predicted 4 red in the app-shell pin / 8 green in the adapter pin -> observed exactly that, reds showing the frozen filter value 'open' where 'qualified' was expected; leg B (narrowPersonalizationOverlay made inert) predicted 4 red / 4 green in the adapter pin -> observed 3 red / 5 green. The miss was real and useful: 'omits an owned key the row does not carry' used a fixture whose key set was already the narrowed one, so it could not fail; fixture strengthened (commit 670380763) and leg B re-run gives the predicted 4 red / 4 green. NO REBUILD NEEDED FOR EITHER LEG and none could hide a stale dist: the root vitest.config.mts aliases @object-ui/data-objectstack to packages/data-objectstack/src, so tests resolve source - and the ablations turning red is itself the proof of that resolution. CI: in_progress at report time (draft PR just opened).",
 "open_questions": [
 {
 "question": "The ruling's own shape ('store the patch only') is REFUSED by the platform for a columnState-only patch, which is the most common toolbar write (a column resize/reorder travels alone). Measured with @objectstack/spec 17.0.0 as installed, and columnState appears nowhere in the framework's packages/spec/src either: ViewMetadataSchema.safeParse({columnState, object, name, viewKind, _isOverride}) -> REFUSE, 'Not a `view` body: no recognized `view` key ... Received unrecognized keys `columnState`, `_isOverride`'. sort/rowHeight/hiddenFields/inlineEdit each parse fine alone; columnState does not, because it is objectui's own NON-AUTHOR runtime key (plugin-grid gridNonAuthorKeys ruling). saveMetaItem validates every view write after normalizeViewMetadata inherits identity, so a patch-only write for a column drag would return 422 INVALID_METADATA and the resize would not persist. Today it survives only because the copied base supplies a recognized key. Which way does the storage half go? (No framework issue filed - a search of objectstack found no prior art, and filing one would pre-empt this ruling.)",
 "options": [
 "A. Teach the platform's view schema the runtime overlay keys (framework change in packages/spec), then narrow the write to the patch as ruled.",
 "B. Narrow the write anyway and accept losing columnState persistence until A lands.",
 "C. Keep the fat write (what this PR does) and rely on the shipped read-side narrowing: no frozen key reaches a user, but the stale bytes stay at rest and readers outside objectui (Studio, the server-side switcher) still see a snapshot.",
 "D. Move personalization out of the `view` metadata namespace entirely - the parked per-user direction on objectstack#7494 / #5232."
 ],
 "recommendation": "A, with C shipped now as the harm-elimination half. Real business need: column resize/reorder is a live, used feature and B removes it; C alone leaves real stale rows readable by Studio and the server switcher. Long-term soundness: the refusal comes from the producer's own schema describing a row the platform already stores, so contract-first says fix it there rather than keeping a fat write that launders an unrecognized key past validation - that is exactly the second de-facto contract AGENTS #0.1 warns about. Making AI-written metadata hard to get wrong: A makes the overlay's key set declared and enforced at the publish door, so an agent (or a future call site) cannot invent an overlay key that silently rides along inside a copied view body; D is the cleanest end state but is parked and far larger than this card. Note A must decide whether columnState becomes authorable surface or is admitted as an explicitly runtime-only key - objectui's own gridNonAuthorKeys ruling says it is not author surface, so the honest form of A is the latter."
 }
 ],
 "out_of_scope_findings": []
}

---

Generated by Claude Code