[objectstack-fleet]

domain:spec#3 · os-support-ai · session_01WGufzj2PNcHjESYvrviQf7

Requested by Yibo Wang · project thread

Fixes #27643

Part of #27482 (layer 1 of 2, the producer; the Studio reader, layer 2, stays on #27482).

Clause-②: no
Metadata-protocol: none

Both declarations are the claim's, measured and kept: no accept set moves (every body that saved or published before does so now, every refusal still refuses with the same rule, where and message); only the locator of an existing refusal changes, and no metadata key or value is touched. They match what PR #26999 (#26858, the flow-edge precedent) declared for the same kind of change: Clause-②: no, Metadata-protocol: none, one @objectstack/lint patch changeset. @objectstack/metadata-protocol publishes nothing new here (its diff is one test file), so it has no changeset line.

维护者速读

• 改了什么：对象校验规则（validations[]）表达式被拒时，发现项的 path 从描述文字（object 'X' · validation rule 'R'）改为键路径（objects[0].validations[1].condition）；草稿读取的 _diagnostics[].path 因此变成 validations.1.condition，发布 422 的 issues[].path 变成 objects.X.validations[1].condition。where 文字不变。
• 为什么改：Studio 按字段路径对号显示服务端结论；流程连线条件已经这样做（Studio: an expression field that says "Valid CEL" should read the draft's server verdict at its own path (RLS predicate, flow edge condition) #26858），校验规则此前只有描述文字，界面对不上号，无法据此暂停自动保存（Studio: an expression the engine refuses (RLS USING on a formula field, a null-unsafe validation predicate) keeps autosaving — the server verdict is shown on the field but never holds the save #27482 第 2 层要用）。
• 风险与回滚：拒绝与放行完全不变，只换定位字段；直接读 path 文字的调用方会看到新拼写（仓内已查遍，见 Acceptance notes）。回滚即还原本 PR。
• 先看：packages/lint/src/validate-expressions.ts（对象校验规则循环里的 atSlot），packages/metadata-protocol/src/protocol.runtime-authoring-gate.test.ts（finding(lint): the object save door gives no build verdict on validation conditions, field-rule slots (requiredWhen etc.), option visibleWhen or action predicates; os build refuses them, a metadata save stores them (#22019's sibling) #22032 块新增的草稿读取断言），packages/lint/src/validate-expressions.validation-rule-path.test.ts。
• 两分钟验证：pnpm --filter @objectstack/lint exec vitest run src/validate-expressions.validation-rule-path.test.ts，应 9/9 全绿。
• 需要你做的：无，席位落地（契约复核后）。

What changes

Measured first, on origin/main b761968d

A draft of an object whose amount field is nullable, with three rules (ok_rule clean; amount_rule record.amount > 100; a conditional cond_rule with when: record.amount > 5 and then → inner record.amount < 1000), saved through the real saveMetaItem (draft), read with getMetaItem({ state: 'draft' }), then published:

Before (_diagnostics.errors[], then the publish 422 issues[] path / where):

{ path: "object 'rule_probe' · validation rule 'amount_rule'",                 code: "expression-invalid" }
{ path: "object 'rule_probe' · validation rule 'cond_rule' when-predicate",    code: "expression-invalid" }
{ path: "object 'rule_probe' · validation rule 'cond_rule' then → 'inner'",    code: "expression-invalid" }
422 path = where = "object 'rule_probe' · validation rule 'amount_rule'"   (and likewise for the other two)

The flow-edge precedent on the same harness (the #26707 edge_cel flow, edge e2 condition record.name ==):

{ path: "edges.1.condition", code: "expression-invalid" }
422 path = "flows[0].edges[1].condition", where = "flow 'edge_cel' · edge 'e2' (decide→end) condition"

After, at this PR's head (same probe):

{ path: "validations.1.condition",      code: "expression-invalid" }
{ path: "validations.2.when",           code: "expression-invalid" }
{ path: "validations.2.then.condition", code: "expression-invalid" }
422 path = "objects.rule_probe.validations[1].condition",      where = "object 'rule_probe' · validation rule 'amount_rule'"
422 path = "objects.rule_probe.validations[2].when",           where = "object 'rule_probe' · validation rule 'cond_rule' when-predicate"
422 path = "objects.rule_probe.validations[2].then.condition", where = "object 'rule_probe' · validation rule 'cond_rule' then → 'inner'"

Messages are byte-identical before and after.

The producer (packages/lint/src/validate-expressions.ts)

• The object validation-rule loop computes the rule's key path over the lists as authored (objects[I].validations[N], indexOf on the raw arrays, the Studio: an expression field that says "Valid CEL" should read the draft's server verdict at its own path (RLS predicate, flow edge condition) #26858 spelling), and stamps ${rulePath}.${slot} onto every issue each slot's call pushes. That covers all three verdicts the pass gives: check() (syntax, bare refs, unknown fields, hop checks), the parent root verdict (lint: a validations[] rule whose condition reads parent passes os validate, but no validations[] rule binds parent, so every write under it is refused as unevaluable #24720) and checkNullGuards (has(x) reads as a null guard and is not one — a publish-time lint should reject un-guarded nullable comparisons in CEL predicates #4763).
• The expression slots a rule has, measured from rulePredicates and the loop: condition and when on the rule itself, and the same two on every conditional rule nested under then / otherwise, at any depth. RulePredicate gains key (condition, when, then.condition, otherwise.then.when, …). The nested slots are included: they are slots of the same top-level rule and have an unambiguous key path (validations.0.then.condition); a flow's nested region edge was left out in Studio: an expression field that says "Valid CEL" should read the draft's server verdict at its own path (RLS predicate, flow edge condition) #26858 only because it has none.
• A map-form objects collection has no index to spell, so its findings keep where alone, as a map-form flows collection's do.
• No new member: ExprIssue.path (from Studio: an expression field that says "Valid CEL" should read the draft's server verdict at its own path (RLS predicate, flow edge condition) #26858) carries it, and authoring-rules.ts's path: i.path ?? i.where needs no change. The publish rule is not copied anywhere.
• The runtime gate is untouched: its differential compares the raw positional paths (siblings sit at the same index in every snapshot), nameKeyFindingPath re-spells objects[I] as objects.NAME after it, and withPublishVerdict's itemRelativeIssuePath strips that prefix for _diagnostics.

Tests

• New packages/lint/src/validate-expressions.validation-rule-path.test.ts (9 cases), one per slot and verdict, each asserting the key path AND the unchanged where: the null-guard gate on condition; check() on condition; check() and the null-guard gate on when; nested then.condition, otherwise.when, otherwise.then.condition; the parent root verdict; raw-list indexing past null members (object and rule); map-form objects keeps no path; a field formula finding gains none; and the publish gate's by-name spelling objects.rule_probe.validations[1].condition.
• packages/metadata-protocol/src/protocol.runtime-authoring-gate.test.ts: the finding(lint): the object save door gives no build verdict on validation conditions, field-rule slots (requiredWhen etc.), option visibleWhen or action predicates; os build refuses them, a metadata save stores them (#22019's sibling) #22032 block's pin moves from the prose to objects.fx_rule.validations[0].condition (the 422 on save and on promotion), with where still asserted as the prose; a new case pins the draft read's _diagnostics[].path at validations.0.condition for both refused bodies; (d) door-vs-build parity keeps rule/where/message/hint exact and compares path once the door's by-name top-level spelling is applied. The lint: a conditional validation rule's nested then / otherwise predicate is never validated, so os build passes and the object save door stores a predicate the top-level rule would refuse #22042 (nested) and lint 18.x: validationRuleParentIssue moves from warning to error, so a validations[] rule that reads parent is refused at os build and the object save door (the refusal half of #24720) #24957 (parent) blocks of the same file pinned the same prose path and move the same way. Nothing is skipped.
• Lint suites that pinned path: where for a validation-rule finding move the same way: runtime-gate.object-validation-writes.test.ts (8 cases; a local asAtDoor applies the door's by-name spelling for the door-vs-build toEquals), validate-expressions.validation-rule-parent.test.ts (2), runtime-gate.object-field-existence-spellings.test.ts (the validation condition slot's door path).
• validate-expressions.test.ts's validate-expressions / validate-security-posture 也有同形的 spec 不声明键的 ?? 别名读法(#5009 建议 3 的核对结果) #5017 receiver meta-test reads the new index through the tabled obj receiver (obj.validations.indexOf), so no excuse is added.

Ablation (path stamping removed)

At head 7363e13f (the fix and the moved pins committed; the later changeset commit touches no code), through scripts/ablation-replace.mjs with a trap restore, under the lock:

• Mutation: if (!rulePath) return; → if (!rulePath || 'ablated-27643') return; in atSlot (no finding gains a path). Landed: anchor 1 → 0, blob a4aad9da → fbc41d77. pnpm --filter @objectstack/lint build exit 0; ablation-dist-preflight.mjs @objectstack/lint 'ablated-27643': marker present in 4 built files, exit 0.
• Red: validate-expressions.validation-rule-path.test.ts 7 failed / 2 passed (the map-form and off-rule controls stay green, as they should); protocol.runtime-authoring-gate.test.ts -t '22032|22042|24957' 11 failed / 30 passed (the draft-read _diagnostics[].path pin among them).
• Restore: blob back to a4aad9da = HEAD, git diff HEAD empty, rebuild exit 0, preflight --absent exit 0 (marker absent from all 20 built files, tree clean). Green again: 9/9 and 41/41.
• A first attempt used a comment marker (/* ablated-27643 */), which the bundler strips: the preflight answered "marker ABSENT from dist/" (exit 1), so that run's reading is void even though the same suites went red; it was redone with the string marker above.

Acceptance notes

Readers that match on a validation-rule finding's path, grepped repo-wide at this head (git grep for · validation ', · validation rule ' and .path beside them):

• packages/lint tests: the four files above, updated. Every other lint test matches on where, which is unchanged.
• packages/metadata-protocol: the finding(lint): the object save door gives no build verdict on validation conditions, field-rule slots (requiredWhen etc.), option visibleWhen or action predicates; os build refuses them, a metadata save stores them (#22019's sibling) #22032, lint: a conditional validation rule's nested then / otherwise predicate is never validated, so os build passes and the object save door stores a predicate the top-level rule would refuse #22042 and lint 18.x: validationRuleParentIssue moves from warning to error, so a validations[] rule that reads parent is refused at os build and the object save door (the refusal half of #24720) #24957 blocks, updated. withPublishVerdict needs no change (it already strips an objects.NAME prefix).
• packages/cli: os lint prints at ${issue.path} (authoringFindingToLintIssue), so for these findings it now prints the key path where it printed the where text a second time; the message still leads with where. artifact-packages.ts's findingKey normalises the top-level index (objects[3] → objects[]), so its per-package dedupe is unaffected. os validate / os build / doctor print where.
• packages/qa/dogfood/test/rule-hop-undeclared-related-field.dogfood.test.ts matches [rule, where], unchanged.
• ui/packages/app-shell/src/views/metadata-admin/draftVerdict.ts: serverErrorsAt matches a path by equality, and no Studio field asks for validations.N.condition yet, so nothing changes on screen until layer 2 (Studio: an expression the engine refuses (RLS USING on a formula field, a null-unsafe validation predicate) keeps autosaving — the server verdict is shown on the field but never holds the save #27482). withServerOnlyErrors dedupes a client error and a server error with the same path and message; with the prose path no client error ever matched, with the key path a client error raised at validations.N.condition with the same message is shown once, which is the intended direction.
• objectql's runtime refusal text (validation rule 'X' on OBJ could not be evaluated) is a different message on a different surface and is untouched.

In-flight intersection (open PRs at the time of the claim, files listed per PR): only #27592 (head e2368298) touches protocol.runtime-authoring-gate.test.ts, in the #27069 related-list block near the end of the file (an added it and a changed fixture); no hunk overlaps the #22032 / #22042 / #24957 blocks. No open PR touches validate-expressions.ts or authoring-rules.ts.

Verification

All at head 9d9987f5 (the PR head), under scripts/pm/os-verify-lock.sh on the shared box:

Suites: lint and metadata-protocol test + typecheck, all exit 0

• pnpm --filter @objectstack/lint test: exit 0, Test Files 178 passed (178), Tests 7613 passed (7613).
• pnpm --filter @objectstack/lint typecheck: exit 0.
• pnpm --filter @objectstack/metadata-protocol test: exit 0, Test Files 279 passed, 4 skipped (283), Tests 21782 passed, 26 skipped (21808).
• pnpm --filter @objectstack/metadata-protocol typecheck: exit 0.
• Lock VERDICT command-exit 0 (5m23s).

Derived gates: 59 derived, 59 run, all exit 0

• node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack: 59 families derived at 9d9987f5.
• Serial pass: 56 exit 0 and 3 exit 3 (prerequisites, nothing measured): check-plugin-teardown-shape --self-test (shallow clone), check:dual-build-cjs-loads and check:lean-entry-closure (no full build).
• After git fetch origin 621a4876 and a full turbo run build --concurrency=2 (exit 0, lock VERDICT command-exit 0): all three rerun exit 0.
• dispatch-gates --ran: 59 derived, 59 run, 0 NOT-MEASURED, 0 UNRUN, exit 0.
• Dogfood: not run (no ! in the title and no (narrowing) arm).

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

4 anchor(s) derived from 1 changed package(s); no hand-written page names any of them, so this run has nothing to list — not a clean bill of health. This check sees only pages that NAME a derived anchor: one that documents this change in prose, or enumerates it in an authoring dialect, names none and stays invisible to it on every run.

What this run could not see

• the SDK route bridge reached 58 of 210 client-bound route-ledger rows — the other 152 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 152: 0 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 55 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 97 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.
• a key NAME is not a key, so the hand re-read the line above prescribes can land on the wrong schema. The same spelling is authorable on one governed type and a [REMOVED] tombstone on another for each of active, aria, joins, objects, template, tools and version (censused on [finding] tools is a key on BOTH AgentSchema (tombstoned, dead) and SkillSchema (live, cloud-attested), so a name-based search attributes skill examples to the agent key — it produced a false stop-the-line alarm on PR #19059 #19093 over the liveness ledger's governed types, top-level keys); nothing in a search result distinguishes the two, so a grep hit on a LIVE example reads as evidence about the DEAD key. Measured on fix(spec): the agent.tools liveness row says dead — it claimed live on a key the schema tombstoned #19059: content/docs/ai/agents.mdx was reported as contradicting the agent.tools tombstone over its tools: example at :161, which is inside the defineSkill({ block opened at :155 — the page was already correct. Settle ownership by PARSING the value against both schemas, never by the name: that literal PASSES SkillSchema, and as an AgentSchema it FAILS at tools with the tombstone prescription. ⛔ These names are not the whole class — a key retired through a .strict() guidance map leaves no tombstone in the walked shape and none of them here (tool.category, live as AIToolDefinition.category).

Coarse fallback — 4 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 33ab543913125b53feec6c116f13d616261a908c → packageMentionDocs.

Which tree this was computed on

This run read content/docs from b76e7d0ff08e90d96c9368cc885f77d08121ed05 — the merge of head 9d9987f555e1a52d3b52bc8670e20376cd5c61af into base 33ab543913125b53feec6c116f13d616261a908c, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin b76e7d0ff08e90d96c9368cc885f77d08121ed05 && git checkout b76e7d0ff08e90d96c9368cc885f77d08121ed05
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 33ab543913125b53feec6c116f13d616261a908c 9d9987f555e1a52d3b52bc8670e20376cd5c61af && git checkout -B drift-repro 33ab543913125b53feec6c116f13d616261a908c && git merge --no-ff 9d9987f555e1a52d3b52bc8670e20376cd5c61af

node scripts/docs-audit/affected-docs.mjs --json 33ab543913125b53feec6c116f13d616261a908c

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

[objectstack-fleet]

triage#1 · os-sales · session_01L6bhgV4fMGJHSdSdx3u9mK

Contract-review-claim: session_01L6bhgV4fMGJHSdSdx3u9mK · head 9d9987f · 2026-10-29T17:40Z

---

Generated by Claude Code

[objectstack-fleet]

triage#1 · os-sales · session_01L6bhgV4fMGJHSdSdx3u9mK

Contract review

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: 9d9987f555e1a52d3b52bc8670e20376cd5c61af
Local-runs: none
Scope: packages/lint/src/runtime-gate.object-field-existence-spellings.test.ts, packages/lint/src/runtime-gate.object-validation-writes.test.ts, packages/lint/src/validate-expressions.ts, packages/lint/src/validate-expressions.validation-rule-parent.test.ts, packages/lint/src/validate-expressions.validation-rule-path.test.ts, packages/metadata-protocol/src/protocol.runtime-authoring-gate.test.ts + packages/lint/src/authoring-rules.ts, packages/lint/src/runtime-gate.ts, packages/lint/src/object-graph.ts, packages/metadata-protocol/src/metadata-diagnostics.ts, packages/spec/src/data/object.zod.ts, packages/cli/src/commands/lint.ts, packages/cli/src/utils/artifact-packages.ts, ui/packages/app-shell/src/views/metadata-admin/draftVerdict.ts

Inputs read: card #27643 (body, 3 comments: triage, claim, dev report), parent card #27482 (body, 8 comments), PR #27675 (body, 7-file list, net diff from the files endpoint, 2 comments), the 55 check-runs on the head. The rest of the diff — .changeset/27643-validation-rule-finding-path.md — is the lane seat's ACCEPT at TIER_DEFAULT; it is read here only for ②.

① Derived judgments

• Accept set unchanged — right. The only producer hunk is in runStackExpressionPasses (packages/lint/src/validate-expressions.ts 2967–3053 at head). atSlot rewrites issues[k] in place as { ...issues[k], path } over the half-open range each slot's call pushed; it pushes nothing and drops nothing, and every push site it covers (check() 2384–2386 and its hop refusals 2147/2197, the parent root verdict 3043, checkNullGuards 2303) still pushes the same where, message, source, severity. Clause-②: no is the right declaration: nothing saves, publishes or refuses differently.
• ExprIssue.path set on validation-rule findings — right, no new member. path?: string has existed since Studio: an expression field that says "Valid CEL" should read the draft's server verdict at its own path (RLS predicate, flow edge condition) #26858; only its docblock and its population change. RulePredicate.key is on a non-exported interface. authoring-rules.ts:797 (path: i.path ?? i.where) needs no edit and gets none, so runAuthoringRules findings for this rule now carry the key path as the flow-edge findings already do.
• The runtime gate needs no change — right, read in runtime-gate.ts. buildRuntimeWriteSnapshotSet (675–735) appends the written item LAST and keeps siblings at the same index in baseline, candidate and stored; fingerprint (604) keys on the raw positional path, so a sibling's objects[I].validations[N].x cancels across passes exactly as its prose path did. isLocatedOnAnotherEntry (768–797) reads the new path through its positional branch (objects[k], k vs writtenSlot) with the same answer the prose branch (object 'NAME') gave before. nameKeyFindingPath (959–968) runs AFTER the differential and re-spells objects[S] as objects.NAME because objects is a name-keyed context key — which is why the 422 path reads objects.rule_probe.validations[1].condition while a flow's keeps flows[0].edges[1].condition (flows are not a context collection). Consistent with the existing wire shape, not a new one.
• _diagnostics[].path item-relative spelling — right. itemRelativeIssuePath (metadata-diagnostics.ts 388–400) strips the objects.NAME prefix and dots every [n], so the draft read serves validations.1.condition / validations.2.when / validations.2.then.condition, the shape serverErrorsAt (draftVerdict.ts 99–106, equality match) resolves and the shape Studio: the Validations tab holds the autosave on a served CEL verdict at the rule's own path, as the RLS arm does (#27482 layer 2 of 2) #27644 will ask for. Metadata-protocol: none is right: no metadata key or value changes; the envelope member is the one Studio: an expression field that says "Valid CEL" should read the draft's server verdict at its own path (RLS predicate, flow edge condition) #26858 already populates for flows.
• Indexing over the authored lists — right. recordsOf (object-graph.ts 215–221) returns the array's own members filtered, so stack.objects.indexOf(obj) / obj.validations.indexOf(rule) give raw indices, and a null member before the entry does not renumber it (pinned). validations is z.array(ValidationRuleSchema) in the spec (object.zod.ts 3018, 4482), so there is no map-form validations to leave behind; the map-form objects collection keeps where alone, as map-form flows do.
• Downstream readers — right as listed. os lint (cli/src/commands/lint.ts 790–798, 1146) prints at ${f.path}: positional at the CLI (objects[0].validations[1].condition), as it already prints a flow edge's; findingKey (artifact-packages.ts 104–105) strips the top-level index, so the per-package dedupe is unaffected. withServerOnlyErrors (draftVerdict.ts 72–79) can now dedupe a client error raised at the same key path — the intended direction for layer 2.
• In-flight intersection — holds. Open PR feat(spec,lint,app-shell)!: a field group's relatedList names body tables only #27592 (now at head f8ed3f6c) touches protocol.runtime-authoring-gate.test.ts in the related-list block; no open PR touches validate-expressions.ts or authoring-rules.ts.

② Semver level

.changeset/27643-validation-rule-finding-path.md: @objectstack/lint: patch — matches what the diff publishes. One package's source changes (packages/lint); the metadata-protocol diff is one test file and publishes nothing, so it rightly has no changeset line. The level is the one PR #26999 (#26858) set for the same kind of change — a locator value moving from prose to the key path, type shape and accept set unchanged, prose where still served. The Clause-②: no and Metadata-protocol: none lines are present and identical on the PR body and the changeset; no (narrowing) arm. Check Changeset, PR-body guards and Governed Surface Queue Guard are all success on the head.

Clause-②: no — judged right.

③ Boundary flags

• Is the needs:contract-review label right? By path, no face: reviewFace over the 7 paths returns no schema hit and no governed-path hit, and the changeset's Clause-②: no carries no narrowing arm, so the tool reads the declaration face. The review is owed by the card's own constraint instead: lint: a validation rule's expression finding carries the key path validations.N.condition, not prose, so the draft read can address it (#27482 layer 1 of 2) #27643's body rules that the served _diagnostics[].path value changes and "a contract review is owed before approval", granted with the cross-domain exception by triage (6501867418). The label is right as a card-ruled review; no path or declaration in the committed tree makes a contract face on its own. Served at CONTRACT_REVIEW_TIER as the brief directs, scope widened to every non-prose path of the diff.
• Dev flag 1 — nested then / otherwise slots also carry a key path. Answered: within the card's "the analogous key for the other expression slots of a rule"; each nested slot has an unambiguous key path (validations.0.then.condition), unlike a flow's region edge, which Studio: an expression field that says "Valid CEL" should read the draft's server verdict at its own path (RLS predicate, flow edge condition) #26858 left out for lack of one. Pinned in the new test and the lint: a conditional validation rule's nested then / otherwise predicate is never validated, so os build passes and the object save door stores a predicate the top-level rule would refuse #22042 block. Accepted.
• Dev flag 2 — the lint: a conditional validation rule's nested then / otherwise predicate is never validated, so os build passes and the object save door stores a predicate the top-level rule would refuse #22042 and lint 18.x: validationRuleParentIssue moves from warning to error, so a validations[] rule that reads parent is refused at os build and the object save door (the refusal half of #24720) #24957 blocks of the gate test and four lint test files moved too. Answered: the claim's file surface names the whole gate test file and "tests beside"; every moved pin asserts the new path AND the unchanged where; nothing is skipped (the diff adds 50 lines there, removes 10, no .skip). Accepted.
• Dev flag 3 — door-vs-build parity compares path after by-name re-spelling. Answered: the loops drop path from the exact-key list but immediately assert the build's positional path exactly and the door's as that string with ^objects[0] re-spelled by name — still an exact, two-dialect pin. Accepted.
• Dev flag 4 — a probe test committed in 7363e13f and deleted in 9d9987f5. Verified against the files endpoint: the net diff is 7 files and carries no zz-probe file. Accepted.
• Dev flags 5 and 6 (no assignee / review request at open; worktree kept) are process notes for the seat, not contract matters.
• open_questions: [] — none to answer or escalate. premise_still_valid: true — consistent with the measured-before block on b761968d.
• Check-runs on the head: every completed run that measured is success (Test Core and its 8 shards, TypeScript Type Check, Lint & Repo Gates, the scoped Lint and Type Check families, Test UI, Type Check UI, Build & E2E UI, Live E2E UI, Dogfood Regression Gate, Check Changeset ×2, Check PR Size, PR-body guards, Governed Surface Queue Guard); the skipped rows are opt-in or matrix placeholders. No gate verdict stands against the head.

④ Design judgment

• packages/lint/src/validate-expressions.ts — holds. Judged against the gate that consumes it (runtime-gate.ts) and the flow-edge precedent in the same file (2925–2939). Break attempts: (a) a sibling object's finding newly carrying a positional path could be charged to the write — no, siblings sit at the same index in every snapshot and the fingerprint cancels; (b) the stored self's finding could cancel the item's own — no, isLocatedOnAnotherEntry reads objects[writtenSlot] as the item; (c) atSlot could stamp an issue located elsewhere — no, every push inside check() / checkNullGuards / the hop refusals uses the slot's own where, and the hook pass's splice-and-dedupe (3560–3584) is outside this loop; (d) a null list member could renumber — no, raw indexOf; (e) the two spellings of one slot (check() and the null-guard gate on when) could disagree — no, rulePredicates yields key: 'when' at depth 0 and the explicit call stamps the same when (pinned). One inherited limit, not this PR's: an object whose name fails PATH_SAFE_NAME keeps objects[S] at the door and itemRelativeIssuePath strips only objects[0], so with siblings its path stays absolute — the same holds for every collection-resident finding today and for the flow precedent, and the spec's machine-name shape rules it out. No finding.
• packages/lint/src/validate-expressions.validation-rule-path.test.ts — holds. Nine cases, one per slot × verdict, each asserting the key path AND the unchanged where; two negative controls (map-form objects, a formula-field finding) keep the "nothing else gains a path" claim honest; the last case crosses the door and pins the by-name spelling. The ablation in the dev report (7 red / 2 green with the controls staying green) matches what the cases claim. No finding.
• packages/lint/src/runtime-gate.object-validation-writes.test.ts — holds. asAtDoor re-spells ^objects[0] by fx_rule because gateObject passes context: { objects: [] } (42–43), so the item is the sole object at index 0 — the anchor is right. The lint: a conditional validation rule's nested then / otherwise predicate is never validated, so os build passes and the object save door stores a predicate the top-level rule would refuse #22042 nested cases now pin the nested key paths explicitly where they pinned path: f.where. No finding.
• packages/lint/src/validate-expressions.validation-rule-parent.test.ts — holds. With a header object in context the item lands at objects[1] at the build and objects.fx_line at the door — exactly the append-last design; the pin reads it correctly. No finding.
• packages/lint/src/runtime-gate.object-field-existence-spellings.test.ts — holds. DOOR_PATH moves only the validation condition slot; the two field slots keep where as their path, which is the live behaviour (a field-formula finding gains no path, pinned in the new suite). No finding.
• packages/metadata-protocol/src/protocol.runtime-authoring-gate.test.ts — holds. This is the one cross-domain pin the card's exception grants. The finding(lint): the object save door gives no build verdict on validation conditions, field-rule slots (requiredWhen etc.), option visibleWhen or action predicates; os build refuses them, a metadata save stores them (#22019's sibling) #22032 block pins the 422 path on save and on promotion as objects.fx_rule.validations[0].condition with where still the prose, and the new case pins the draft read's _diagnostics[].path at validations.0.condition for both refused bodies through the real saveMetaItem / getMetaItem — the exact value Studio: the Validations tab holds the autosave on a served CEL verdict at the rule's own path, as the RLS arm does (#27482 layer 2 of 2) #27644 will consume, which is the scenario this PR is accepted against. The lint: a conditional validation rule's nested then / otherwise predicate is never validated, so os build passes and the object save door stores a predicate the top-level rule would refuse #22042 and lint 18.x: validationRuleParentIssue moves from warning to error, so a validations[] rule that reads parent is refused at os build and the object save door (the refusal half of #24720) #24957 blocks move the same way. The pin is moved, not weakened; nothing is skipped. No finding.

Must-fix: none. Should-fix: none.

Implemented-by: claude/project-thread-kkb2g0
Reviewed-by: session_01L6bhgV4fMGJHSdSdx3u9mK

VERDICT: PASS

---

Generated by Claude Code

[objectstack-fleet]

domain:spec#3 · os-support-ai · session_01WGufzgbJhFoXYsLSe5WSPP

维护者速读 (席位终稿)

• 改了什么：对象校验规则（validations[]）表达式被拒时，发现项的 path 从描述文字（object 'X' · validation rule 'R'）改为键路径（objects[0].validations[1].condition）；草稿读取的 _diagnostics[].path 因此变成 validations.1.condition，发布 422 的 issues[].path 变成 objects.X.validations[1].condition。where 文字不变。
• 为什么改：Studio 按字段路径对号显示服务端结论；流程连线条件已经这样做（Studio: an expression field that says "Valid CEL" should read the draft's server verdict at its own path (RLS predicate, flow edge condition) #26858），校验规则此前只有描述文字，界面对不上号，无法据此暂停自动保存（Studio: an expression the engine refuses (RLS USING on a formula field, a null-unsafe validation predicate) keeps autosaving — the server verdict is shown on the field but never holds the save #27482 第 2 层要用）。
• 风险与回滚：拒绝与放行完全不变，只换定位字段；直接读 path 文字的调用方会看到新拼写（仓内已查遍，见 Acceptance notes）。回滚即还原本 PR。
• 先看：packages/lint/src/validate-expressions.ts（对象校验规则循环里的 atSlot），packages/metadata-protocol/src/protocol.runtime-authoring-gate.test.ts（finding(lint): the object save door gives no build verdict on validation conditions, field-rule slots (requiredWhen etc.), option visibleWhen or action predicates; os build refuses them, a metadata save stores them (#22019's sibling) #22032 块新增的草稿读取断言），packages/lint/src/validate-expressions.validation-rule-path.test.ts。
• 两分钟验证：pnpm --filter @objectstack/lint exec vitest run src/validate-expressions.validation-rule-path.test.ts，应 9/9 全绿。
• 需要你做的：无，席位落地。

席位意见：接受。分诊契约复核 PASS（6504243774，就在当前 head 上），没有 must-fix，也没有 should-fix。

席位核对 · ACCEPT · domain:spec seat 3 · os-support-ai · session session_01WGufzgbJhFoXYsLSe5WSPP · 2026-10-29T20:21Z

Head: 9d9987f555e1a52d3b52bc8670e20376cd5c61af · card #27643 · claim 6502420877

1. 形态: a draft PR to main carrying Fixes #27643 and Part of #27482 (layer 1, the producer): 7 paths (+300 / −26), inside the claim's surface. Each validation-rule expression finding that validate-expressions.ts pushes now carries the judged slot's key path (validations.N.condition, .when, .then.condition, and the nested then/otherwise slots) in the flow-edge spelling of Studio: an expression field that says "Valid CEL" should read the draft's server verdict at its own path (RLS predicate, flow edge condition) #26858; where and every message are byte-identical. Clause-②: no / Metadata-protocol: none, @objectstack/lint patch, matching fix(app-shell): an expression field shows the draft's server verdict at its own path #26999. check-governed-merges reports NOT governed, so the ordinary queue landing applies.
2. 前提实测: before and after are measured in the body: on main the draft read's _diagnostics[].path for a rule is prose; on the head it is the key path, and the publish 422 path is objects.NAME.validations[N].condition. The contract review (6504243774, PASS, this head) confirmed that the metadata-protocol pin (finding(lint): the object save door gives no build verdict on validation conditions, field-rule slots (requiredWhen etc.), option visibleWhen or action predicates; os build refuses them, a metadata save stores them (#22019's sibling) #22032, plus the lint: a conditional validation rule's nested then / otherwise predicate is never validated, so os build passes and the object save door stores a predicate the top-level rule would refuse #22042 and lint 18.x: validationRuleParentIssue moves from warning to error, so a validations[] rule that reads parent is refused at os build and the object save door (the refusal half of #24720) #24957 blocks in the same file) is moved, not weakened, and that the value is the one layer 2 consumes.
3. 门禁 check-runs (on this head): 56 runs: 40 success, 16 skipped, none red or pending. Dev-side: lint and metadata-protocol test and typecheck exit 0, dispatch-gates --ran 59/59, ablation recorded.
4. 接受的偏差: a probe test committed in 7363e13f and deleted in 9d9987f5; the net diff is clean, and the squash merge carries none of it.
5. 范围外去向: layer 2 (the Studio reader) stays on Studio: an expression the engine refuses (RLS USING on a formula field, a null-unsafe validation predicate) keeps autosaving — the server verdict is shown on the field but never holds the save #27482. Skills-docs: no skill teaches a validation-rule finding's path.
6. 落地条款: the seat checked the prose faces against the diff on this head: the PR body (r0) and the changeset. The seat readies the PR and arms auto-merge in this act, follows it to MERGED, and lands lint: a validation rule's expression finding carries the key path validations.N.condition, not prose, so the draft read can address it (#27482 layer 1 of 2) #27643.