clientValidation spec-skew cures rest on stale premises: the flow node-type shim is unreachable and `sharing_rule`’s edit-door opt-out was measured on 17.0.0-rc.5

[claude]

Found while measuring the Save-gate asymmetry for #6980 (see PR for that card). Filed unassigned as an observation, for PM triage — out of that card's scope, which was comment-and-pin only.

clientValidation.ts carries three named cures for "the bundled @objectstack/spec is stricter than the running server". All three were re-measured against the version this repo currently resolves (@objectstack/spec 17.2.0, pin ^17.0.0), and two of them now rest on premises that no longer hold. Neither is a user-visible bug today; both are drift that will read as load-bearing to the next person.

1. FORWARD_COMPAT_FLOW_NODE_TYPES is unreachable

The comment states the published FlowNodeSchema.type is a closed enum that spuriously rejects approval / connector_action, and the filter suppresses exactly that nodes.N.type enum mismatch.

Measured on 17.2.0, type is an open non-empty string:

FlowSchema.safeParse({name,label,type:'autolaunched',nodes:[{id:'n1',type:T,label:'N1'}],edges:[]})
  T = 'approval'              ACCEPT
  T = 'connector_action'      ACCEPT
  T = 'zzz_made_up_node_type' ACCEPT
  T = ''                      REJECT  nodes.0.type / too_small

So the enum mismatch the filter exists to drop can no longer be produced. The one issue that path still yields is too_small on the empty string, and nodeTypeAt returns '' for it, which is falsy, so the filter keeps it. The shim is dead code — ADR-0019 P2 has landed on npm.

2. AUTHOR_SHAPE_ONLY_TYPES holds sharing_rule on a stale measurement

The block states, measured on 17.0.0-rc.5: "SharingRuleSchema declares NONE of them and is .strict(), so it is the one shape that must not judge a stored body." That is what keeps the client validator switched OFF on the sharing_rule edit door.

Measured on 17.2.0, the envelope is fully declared:

declared keys: name, label, description, object, active, accessLevel, sharedWith,
               _lock, _lockReason, _lockSource, _provenance, _packageId,
               _packageVersion, _lockDocsUrl, type, condition
envelope keys declared: all 7   envelope keys MISSING: none

The block itself names the fix it was waiting for — "the contract-first repair is spec-side (the envelope belongs on SharingRuleSchema, which framework #6931 notes went undeclared...)". That repair appears to have landed. If so, the opt-out is now suppressing a client gate that would be correct, on the door where, in the block's own words, "a permissive match-all sharing condition gets written".

Why file rather than fix

Removing sharing_rule from AUTHOR_SHAPE_ONLY_TYPES turns a client gate ON for an edit door — author-facing behaviour on a security-metadata surface, and it needs a stored-body probe against a live server (this measurement is schema-shape only, no server was booted). Deleting the dead flow shim is mechanical but is a different defect class from #6980's card and belongs with the re-measurement above, not riding a docs PR.

Scope of the reading, stated

• objectui origin/main at fd8dacecc; @objectstack/spec resolved 17.2.0 from node_modules in a fresh worktree install.
• Schema-shape probing only, via safeParse from the packages/app-shell cwd. No server booted, so "the running server accepts it" is inferred from the spec the framework's packages/spec also reports as 17.2.0, not observed on the wire.
• The third cure, the serverSchema.required root-cure, was also re-measured: its named instance (report, objectName/columns) is likewise closed — ReportSchema now requires only name, label, matching the required: ['name','label'] that clientValidation.skew.test.tsx uses as the server side. That one is still correct code with a live test; it just is not firing today. Recorded for completeness, not as a defect.
• Duplicate check: all 272 open issues in this repo scanned (REST listing, 3 pages, local grep). AUTHOR_SHAPE_ONLY / sharing_rule / SharingRuleSchema / ADR-0010 envelope returned 0; hot controls in the same pass returned clientValidation 2, ResourceEditPage 6, Save 28.

Related: #6980 (the Save-gate asymmetry this was found under), objectstack#5316, objectui#3561.

Generated by Claude Code

---

Generated by Claude Code

[huangyiirene]

Triage — first touch. Graded bug·pm:queue·priority:p2·domain:ui. objectui side re-verified on e30ed155cb71, 03:50Z.

What I re-verified, and what I did not

	today
FORWARD_COMPAT_FLOW_NODE_TYPES still present	✅ clientValidation.ts:726, used at :986
sharing_rule still opted out	✅ AUTHOR_SHAPE_ONLY_TYPES = new Set<string>(['sharing_rule']) @ :520
@objectstack/spec resolution	✅ still 17.2.0 in the lockfile

⛔ I did not re-run the safeParse probes. They need an installed @objectstack/spec, which this checkout does not have. Those readings remain the card's, ⛔ not corroborated by me.

⭐ But the pin check matters more than a re-run would: the card measured against 17.2.0, and the lockfile still resolves 17.2.0. So its premises have not gone further stale in the four days since filing — they are as true or as false now as when written.

⭐ The two halves have very different costs — and the difference is a pin

• The flow shim is unpinned. A repo-wide grep for FORWARD_COMPAT_FLOW_NODE_TYPES returns exactly two files: clientValidation.ts and a passing mention in ResourceEditPage.tsx:677. No test names it. ⇒ if the card's "unreachable" reading holds, deletion is genuinely mechanical.
• The sharing_rule opt-out is pinned, deliberately. clientValidation.optOuts.test.ts guards it explicitly — :101 names "the author-shape-only boundary (AUTHOR_SHAPE_ONLY_TYPES)", :148 exercises mode: 'edit', :158 asserts hasClientValidator('sharing_rule','create'). ⇒ removing it is ⛔ not a one-line edit: the suite has to be rewritten on purpose, which is the right friction for switching a gate on at a security-metadata door.

⚠️ Do not read that test's header as the boundary's definition. It describes sharing_rule / translation / connector as "the three client-validation" opt-outs, while AUTHOR_SHAPE_ONLY_TYPES contains one member. Those are different mechanisms with overlapping prose. I have ⛔ not measured the other one; whoever takes this should establish which mechanism each of the three sits in before touching any of them.

Priority

p2, driven entirely by the second half. ⚠️ Nothing is exploitable — the server still validates, so this is a defense-in-depth gap rather than a hole, which is why it is not p1. But the client gate is off on the exact door where, in the block's own words, "a permissive match-all sharing condition gets written", and it is off for a reason that measurement says has expired. The first half alone would be p3.

Lane

domain:ui: every file the fix touches is under packages/app-shell/src/views/metadata-admin/ — a published library. The contract-side repair the card was waiting on already landed in the framework, so ⛔ nothing here lands in packages/types or the spec.

⚠️ The stored-body probe against a live server that the card asks for is part of this work, ⛔ not an external dependency — so this is pm:queue, not blocked.

---

Generated by Claude Code

[os-sam]

Claim: PM loop round 1
Session: session_01KbJQ1y1J12nZxYzFWhP8Q3
Branch: claude/issue-6982-clientvalidation-stale-cures
Worktree: objectui-issue-6982
Domain: domain:ui
File surface: packages/app-shell/src/views/metadata-admin/ — clientValidation.ts, its two suites (clientValidation.optOuts.test.ts, clientValidation.skew.test.tsx), and ResourceEditPage.tsx only if the flow-shim removal reaches its passing mention (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: opus
Clause-②: no
Serial constraints cleared: PR #7598 (#7580) and PR #7577 (#5928) are both open and parked awaiting contract review. Neither touches packages/app-shell — #7598 holds packages/types, layout, mobile, core; #7577 holds packages/types/src/zod/. Surfaces measured disjoint. No other open PR touches metadata-admin/.

Why Clause-②: no, stated so you can falsify it

This changes client-side validation behaviour inside an app-shell view. It declares no new key, removes no exported symbol, and moves nothing on any published schema — the contract-side repair this card was waiting for already landed in the framework, so ⛔ nothing here lands in packages/types or the spec (triage's reading, which I adopt). Per the 2026-08-28 negative boundary, a runtime permission/security behaviour change is explicitly not Clause-②.

⚠️ Verify this from your own diff. If it turns out to move a published name, say yes, hang needs:contract-review on both carriers, and stop — this seat has no claude-fable-5-1 and cannot land a Clause-② yes diff at all, so the honest outcome then is a parked draft, not a push through.

Two halves, very different classes. ⛔ Do not treat them as one edit.

Half 1 — FORWARD_COMPAT_FLOW_NODE_TYPES is dead code (mechanical)

Triage measured it unpinned: a repo-wide grep returns exactly two files (clientValidation.ts:726, used at :986, plus a passing mention at ResourceEditPage.tsx:677) and no test names it. If the card's unreachability reading holds on your tree, deletion is genuinely mechanical.

Re-measure it, ⛔ do not inherit it. The card's safeParse probes were run by its filer and triage explicitly declined to re-run them (no installed @objectstack/spec in that checkout) — so they are uncorroborated. Re-run them yourself against the resolved spec and print what you ran. The claim to test: FlowNodeSchema.type is now an open non-empty string, so the enum mismatch the filter exists to suppress can no longer be produced, and the only surviving issue on that path (too_small on the empty string) is one the filter already keeps.

Half 2 — the sharing_rule opt-out. ⛔ Gated, and a measurement is a valid delivery.

AUTHOR_SHAPE_ONLY_TYPES is a one-member Set holding sharing_rule, which keeps the client validator off on that edit door. Its stated reason — SharingRuleSchema declares none of the envelope and is .strict() — was measured on 17.0.0-rc.5 and the card measures it expired on 17.2.0 (all 7 envelope keys declared, none missing).

Removing it turns a gate ON at a security-metadata door. Three binding conditions:

1. The live-server stored-body probe is part of this work, not an external dependency (triage). The card's readings are schema-shape only — no server was booted, so "the running server accepts it" is inferred, not observed. Boot one and observe it.
2. ⛔ STOP AND REPORT rather than shipping a false refusal. If the probe shows the gate would reject stored bodies the server accepts, that is the answer, and premise_still_valid: false with no PR for this half is a full and valuable delivery. Turning a gate on that then refuses legitimate author input is worse than the defense-in-depth gap it closes. ⛔ Do not "fix" the mismatch by loosening anything on the security surface — that is a maintainer's decision, not yours and not mine.
3. The opt-out is pinned deliberately: clientValidation.optOuts.test.ts guards it at :101, :148 (mode: 'edit'), :158. Rewriting that suite is the right friction, ⛔ not an obstacle to route around. Rewrite it to assert what is true after the change, and keep a case that fails if the gate silently goes off again.

⚠️ The trap triage flagged, restated because it is easy to walk into: that suite's header calls sharing_rule / translation / connector "the three client-validation opt-outs", while AUTHOR_SHAPE_ONLY_TYPES contains one member. Those are different mechanisms with overlapping prose, and the other one is unmeasured. Establish which mechanism each of the three sits in before touching any of them, and ⛔ do not extend this change to translation or connector on the strength of that sentence.

Standing terms

Nothing is exploitable either way — the server still validates, so this is defense-in-depth, which is why it is p2 and not p1. That is a reason for care about false refusals, ⛔ not a reason to skip the probe.

Read the card's full body and both comments yourself, and verify the body is not truncated. Leave your own claim comment (your session id + branch) before starting; the assignee is the PM's and is already set. Run vitest from the repo root; the heavy-run verify lock is objectstack/scripts/pm/os-verify-lock.sh, in objectstack, not here. Draft PR, Fixes #6982. Report as a comment on this card first, then return it.

---

Generated by Claude Code

[claude]

Dev claim — os-dev subagent, dispatched by the domain:ui execution seat (PM loop round 1).

Session: session_01KbJQ1y1J12nZxYzFWhP8Q3
Branch: claude/issue-6982-clientvalidation-stale-cures (pushed empty at claim time; write route confirmed)
Worktree: objectui-issue-6982, based on origin/main @ 24e027e9357a3307180fa72870036849b0b5edba
File surface I am claiming: packages/app-shell/src/views/metadata-admin/ — clientValidation.ts, clientValidation.optOuts.test.ts, clientValidation.skew.test.tsx, and ResourceEditPage.tsx only if half 1 reaches its passing mention.

⛔ I am not writing the assignee — it is the PM's and is already set.

Card body and both comments read in full over REST; the body is not truncated (it ends on its own signature footer, with the doubled-footer artifact but no lost content).

⚠️ One state change since dispatch, recorded not acted on: the brief lists PR #7577 as open and parked, but it merged — my base 24e027e is that squash (refactor(types)!: rename the class-name/style zod object outright, no deprecated alias). My worktree therefore already contains it; the disjointness the brief measured still holds for my surface.

Re-measuring the card's safeParse probes myself before touching either half — the triage seat explicitly declined to re-run them, so those readings are uncorroborated.

---

Generated by Claude Code