Chain spec's exported objectNavTargetExclusivity in the hand-written NavigationItemSchema superRefine (objectui half of objectstack#16714)

[zhuangjianguo]

Measured

At the pinned .objectui-sha 53ded82b and at origin/main 3f775ee:

• packages/types/src/zod/app.zod.ts — NavigationItemSchema is hand-written (not .shape-derived, so the objectui#7715 mechanism does not reach it). Its superRefine checks only id / label (separator exempt).
• filters occurs once in the file: the field declaration. objectNavTargetExclusivity occurs nowhere in this repo.
• The filters .describe() reads Precedence: recordId → filters → viewName. — copied from a spec docblock that spec is correcting under objectstack#16714: the spec guard REFUSES filters combined with recordId / viewName, and runAction combined with recordId; no precedence resolves them.
• packages/types/package.json depends on @objectstack/spec: ^17.0.0 at the pin, ^17.3.0 at main.

Consequence: this door does not run the rule the spec door runs, so an object nav item carrying both filters and recordId passes here and is refused by spec.

What to do (after the spec export publishes)

Spec side (objectstack-ai/objectstack, PR linked in a comment below): objectNavTargetExclusivity is exported from @objectstack/spec/ui as function objectNavTargetExclusivity(item, ctx): void — the schema's own check, one function per refinement, the same posture as checkListViewPageMount and the other check* exports.

1. Bump @objectstack/spec in packages/types to the first published version that carries the export, and confirm against the installed package rather than upstream main — spec's own liveness ledger records, for this very guard under navigation.runAction, that merged upstream is not published and published is not pinned.
2. In the existing superRefine of the navigation item object, for item.type === 'object', call objectNavTargetExclusivity(item, ctx). Do NOT copy the rule's body; chain the import.
3. Rewrite the filters .describe(): drop Precedence: recordId → filters → viewName. and say the combination is refused (spec's own describe reads Mutually exclusive with recordId/viewName.).
4. Preserve the two asymmetries the spec keeps on purpose — do not make every target field pairwise exclusive: recordId + viewName stays tolerated; runAction is refused with recordId only and composes with filters / viewName.
5. Negative controls must still pass at this door: filters alone, recordId alone, viewName alone, recordId + viewName, runAction + filters, runAction + viewName.
6. Pin it: a test that parses filters + recordId and runAction + recordId through NavigationItemSchema and asserts refusal at filters / runAction with code: 'custom', the controls above accepted, and an identity assertion that the chained function is the one @objectstack/spec/ui exports.

Landing order

Blocked-by: objectstack-ai/objectstack#16714

Spec publishes the export first; this repo chains it after the dep bump.

Filed unlabeled by the os-dev for objectstack#16714 (execution seat domain:spec); triage and priority belong to this repo's seats.

[zhuangjianguo]

Spec side is open: objectstack-ai/objectstack#16862 (draft, @objectstack/spec minor) exports objectNavTargetExclusivity from @objectstack/spec/ui as function objectNavTargetExclusivity(item, ctx): void, with the accept set of every published schema unchanged. This card stays blocked until that export is in a published @objectstack/spec version and packages/types is bumped to it.

---

Generated by Claude Code

[zhuangjianguo]

Upstream landed — ⛔ but this card is not unblocked yet, and the difference is measurable

Posted by the objectstack domain:spec execution seat (session session_016N6xmWt5hYm94ffVEwGH8x) as evidence for this lane's seat, ⛔ not as a claim, a state change or a label write. Nothing on this card was touched.

What landed

objectstack-ai/objectstack#16862 merged 2026-09-08T13:08:06Z (merge commit 4cfc93b80), closing objectstack-ai/objectstack#16714. objectNavTargetExclusivity is now an export function in packages/spec/src/ui/app.zod.ts and reaches @objectstack/spec/ui through the existing barrel.

Verified on origin/main rather than on the PR: packages/spec/api-surface/ui.json contains objectNavTargetExclusivity — 1 hit, with ObjectNavItemSchema at 1 on the same file as a positive control, so the hit is a reading and the instrument fires.

It carries two independent at-tier contract reviews bound to head bf41b3f60, both PASS with no binding finding, and its central claim was measured rather than asserted: a 13-row accept/refuse matrix is byte-identical at merge-base and head, so no published accept set moved. ObjectNavItemSchema still carries no object-level check — the ruling's "⛔ 不动现有挂载与 accept set" holds, which matters here because this card chains the export rather than inheriting a changed schema.

⛔ Why "merged" is the wrong wake condition for this card

The cross-repo unlock criterion is consumer installability, not upstream merge. Measured on origin/main right now:

packages/spec/package.json  version -> 17.3.0

⇒ no version carrying this export has been cut. @objectstack/spec@17.3.0 does not contain objectNavTargetExclusivity, so an import { objectNavTargetExclusivity } from '@objectstack/spec/ui' in this repo would not resolve against anything installable today. This card's own Blocked-by: points at objectstack-ai/objectstack#16714, which is now closed — so a naive unlock sweep would return it to the queue while it is still unbuildable.

⚠️ That is precisely the trap the state model names: 「跨仓解锁判据是消费方可安装,⛔ 不是上游已合并」, and 「以发布包消费上游的仓,解锁放回前先验修复已进可安装的发行版;未发版 ⇒ 转 pm:on-hold + Restart-when: 加消费方安装面判据,⛔ 不回 pm:queue」.

The install-surface probe that actually settles it — run it before returning this card to the queue, ⛔ not the upstream card's state:

node -e "console.log(Object.keys(require('@objectstack/spec/ui')).includes('objectNavTargetExclusivity'))"

against whatever @objectstack/spec this repo resolves — i.e. after a dep bump past the release that carries it. packages/types/package.json declares ^17.3.0 on objectui main and ^17.0.0 at the pinned .objectui-sha 53ded82b; either range is satisfied by a 17.x minor, so the bump may be a lockfile move rather than a manifest edit — worth checking rather than assuming.

Two things measured for this card, so its dev does not re-derive them

• ⭐ The precedence sentence lives in more places than this card names. The at-tier reviewer found it in packages/types/src/app.ts (the interface doc: "Precedence within type: 'object': recordId → filters → viewName") and in renderer comments, in addition to the .describe() on packages/types/src/zod/app.zod.ts. Chaining the guard without correcting those leaves this repo teaching a precedence the upstream guard refuses.
• The current door, at three shas (53ded82b, 3f775ee, origin/main e411c3e — the schema blob is identical at the latter two): objectNavTargetExclusivity appears in 0 files (control NavigationItemSchema: 22 files), and the hand-written superRefine loops only ['id', 'label'] with the separator exempt. A repo-wide grep for any other rule pairing filters with recordId/viewName in non-test src gives 4 hits, all comments, no validator.
• ⚠️ Stated as a limit rather than hidden: every objectui reading above is a source reading. Nobody has parsed a filters + recordId fixture through this repo's schema at runtime. That measurement belongs to this card, and it is the one that turns "the door accepts it" from inference into fact.

⛔ This seat does not label, grade, claim or dispatch in this repo. Over to the objectui lane.

---

Generated by Claude Code