spec/ADR-0089: a form field-rule predicate that faults refuses the submit loudly; visibility stays fail-open at render; a blank predicate is refused at authoring — fault semantics become part of the contract (objectui#8069 ruling A) #17778

Activity

1. os-elon-musk

   added a commit that references this issue on Sep 18, 2026

   revert(spec): drop the predicate narrowing — #18638 owns every evalua…

   ...

   9f30a18
2. os-elon-musk commented on Sep 18, 2026

   

   os-elon-musk

   on Sep 18, 2026 – with Claude

   Collaborator

   More actions

   os-dev-report

   {
     "issue": 17778,
     "status": "done",
     "branch": "claude/issue-17778-field-rule-predicate-fault-semantics",
     "pr": "https://github.com/objectstack-ai/objectstack/pull/18985",
     "session": "session_019srGWGCBBCBHqcDoRZpQRh",
     "premise_still_valid": true,
     "summary": "Reworked PR #18985 to decision batch #160 item 1 (letter A). REMOVED: the three FieldSchema triad-slot edits, the PredicateSchema / PredicateInputSchema rebinding, the field-rule-predicate-evaluated-slot-source-required ADR-0087 entry (entry file deleted, registry.ts re-emitted by gen:migration-registry), its changeset marker, the triad pin test, the two ADR anchors, and every api-surface / reference-page row that existed only because of them — restored byte-for-byte from the pinned merged-main parent d8b12fca97, empty git diff against it for each source. KEPT: the fault-semantics record, the ADR-0089 pointer addendum, and the cel/expression producer fix (docblock rewritten so it no longer rests on the removed triad requirement). RENUMBERED ADR-0136 to ADR-0137 after re-verifying 0137 free. CORRECTED the record: Status now says it declares and implements nothing; the gate-slot conversion is stated as RULED (batch #122 item 2, comment 5644350409) and IN FLIGHT (#18638) with the dangling 'filed as a follow-up' sentence gone; the rotted hand enumeration is replaced by a citation of #15811's census plus the two settings-manifest visible slots it omitted, cited by SYMBOL after check-adr-symbol-anchors refused the line-number form. RE-DERIVED and REMOVED the ADR-0058 D7 roster entry (measurement below). Clause-② re-judged to no, changeset dropped to patch. Four commits on top of e1978a0f3, head 1bbe8f562, pushed; PR is still DRAFT, auto-merge not armed, no label touched. ⛔ No gate weakened: the D7 head floor stays 37 and is met at 37, no ledger row deleted, no test skipped or quarantined; the three removals (pin test, ADR-0087 entry, roster line) all record behaviour this PR no longer has, none of them to get green. Check Changeset stays RED on this head for a CARRIER reason that is the review seat's, not mine — isolated below.",
     "tests": "ROUTE-1 BUILDS: turbo build for the spec+verify closures (33 tasks, exit 0) and for the dogfood closure (64 tasks, exit 0), both under scripts/pm/os-verify-lock.sh. TESTS: pnpm --filter @objectstack/spec test :: 489 files / 14209 tests passed, VERDICT command-exit 0. pnpm --filter @objectstack/spec typecheck :: exit 0 (check:test-typecheck OK, 54 files / 259 errors / 144 pinned signatures held in the shrink-only ledger, unchanged). pnpm --filter @objectstack/dogfood typecheck :: FIRST run exit 2, every error TS2307 'Cannot find module @objectstack/...' against unbuilt dist — PREREQUISITE NOT MET, not a finding; after building the closure it is exit 0, which is the reading, and it covers examples/app-showcase/objectstack.config.ts, the P/cel corpus the producer fix exists for. packages/qa/dogfood expression-conformance :: 7 passed (7) with the roster entry removed. GATES: node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack derived 83 families; all 83 run, each exit code captured before any pipe; reconciled with --ran (exit 0): 82 run, 1 NOT MEASURED. The one NOT MEASURED is pnpm check:dual-build-cjs-loads :: exit 3 PREREQUISITE NOT MET ('no packages/*/dist ... Run pnpm build first. ⛔ This is NOT a pass: nothing was measured') — it needs a whole-workspace build, which is CI's. One gate went RED on this round's own work and is fixed: node scripts/check-adr-symbol-anchors.mjs :: exit 1, '2 finding(s) [line-anchor]' on the settings-manifest line numbers I wrote; repaired to the symbol form, then exit 1 again with '3 finding(s) [unresolved-path]' because the path was package-relative; repaired to repo-relative, now exit 0 — '2105 anchors across 140 records resolve ... 0 line anchors survive'. check:generated proved exactly 2 of 16 artifacts stale and --fix regenerated only those two; re-run after: 16 of 16 up to date. MEASUREMENT 1 — ADR number free: git ls-tree origin/main docs/adr/ tops out at 0135; GET /pulls/N/files over ALL 31 open PRs returns exactly two added docs/adr files, both 0136 (#18480 and this PR), zero on 0137. The scan LIT twice on 0136, so the zero on 0137 is a reading. MEASUREMENT 2 — the settings visible pair, through SettingsManifestSchema.safeParse on the built dist: ast-only, blank source and blank bare string are ACCEPTED at BOTH slots (6 of 6); LIT CONTROL 'data.provider.toUpperCase()' is REFUSED at both, custom@visible and custom@specifiers.0.visible; DARK CONTROL a valid predicate is ACCEPTED. So the refinement is live at both slots and narrows neither arm — 'if (!source) return;'. MEASUREMENT 3 — the D7 roster entry, run twice on this branch with the revert applied, by raising the head floor to 9999 through scripts/ablation-replace.mjs so the assertion prints the count: roster PRESENT -> 'discovery found 37 position(s) via head'; roster ABSENT -> 'discovery found 37 position(s) via head'. Identical, floor 37 met at 37. Both mutations landed and both restores verified ON DISK by the tool ('ok mutation landed: anchor 1 -> 0, blob ... ', then 'ok restored: blob == HEAD ... and git diff HEAD is empty'). Identity grep agrees: PredicateInputSchema has 2 hits under packages/spec/src/**/*.zod.ts (its own definition and its z.input companion, zero slots) against a LIT CONTROL of 19 files for ExpressionInputSchema and a DARK CONTROL of 0 for a nonexistent name. MEASUREMENT 4 — the Check Changeset red is CARRIER-ONLY, isolated by ablation: the identical body and the identical changeset, run through GITHUB_EVENT_NAME=pull_request node scripts/check-changeset-no-major.mjs --base origin/main --event PAYLOAD, differ only in the label list. Carrier ON :: exit 1, 'This PR declares clause-② YES', with 'carrier: needs:contract-review IS on this PR' and 'declaration line: Clause-②: no'. Carrier OFF :: exit 0, 'LEVEL AXIS: this PR declares clause-② no'. LIT CONTROL that the instrument can fail for a body reason: the OLD body (Clause-②: yes (narrowing)) reproduces exit 1 with no label list at all. ⇒ nothing in the six surviving files can clear that red; clearing it is the review seat's carrier act.",
     "mcp_calls": "0 — no MCP GitHub tool was called, read or write. Every GitHub read and write went through the REST proxy with curl.",
     "api_writes": "5 — 2 git pushes to the existing branch (e1978a0f3..89dfabbb8, then 89dfabbb8..1bbe8f562; pre-push check:commit-card-trailers green on both, no card relation and no model identifier in the trailer pair); 2 x PATCH /repos/objectstack-ai/objectstack/pulls/18985 (body only — see the deviation note in open_questions); 1 x POST /repos/objectstack-ai/objectstack/issues/17778/comments (this report). ⛔ No label write of any kind, no PR create, no state or draft flip, no auto-merge.",
     "open_questions": [
       {
         "question": "The card's claim comment (5727728428) still declares `Clause-②: yes`, while the PR body and the changeset now declare `no`. check-clause2-carriers --pair 18985 exits 0 today only because the claim's `yes` agrees with the `needs:contract-review` label being ON; the moment the seat clears that label the two carriers disagree. The claim line is the claim's to correct, not mine.",
         "options": [
           "A — the seat edits the claim comment's `Clause-②:` line to `no` when it clears the carrier, so both carriers move together",
           "B — leave the claim at `yes` as the historical record of what was dispatched, and accept that check-clause2-carriers will report the disagreement after the carrier clears"
         ],
         "recommendation": "A, because the carrier pair is read as a present-tense declaration about this PR's diff, not as dispatch history: ruling A removed the narrowing, so `yes` is now a false statement about the six files that remain, and leaving it standing reproduces exactly the failure the body edit just repaired one carrier over."
       },
       {
         "question": "Standing os-dev rule says the dev writes the PR body once, at PR creation, and never PATCHes it — later corrections are named in the report for the seat to write. This rework's dispatch and the mid-task correction both instructed me to rewrite the body and re-judge its Clause-② line. I followed the dispatch and am declaring the conflict rather than choosing silently.",
         "options": [
           "A — per-card dispatch overrides the standing clause for this item; 2 PATCH writes are correct and inside the reported budget",
           "B — the standing clause holds and the body edit should have been the seat's act"
         ],
         "recommendation": "A, because the standing file itself says the dispatch carries the per-card increment and conflicts are to be reported rather than silently resolved — and the Check Changeset red could not be cleared from the seat's side without the body it read being corrected first."
       }
     ],
     "out_of_scope_findings": [
       "to file (3 classes, dedupe words: platform-readings, PR body footer, REST PATCH, appended footer, pull_request edit) — MEASURED THIS ROUND, and the pm-dispatch references/platform-readings.md cell for it is unwritten: a REST `PATCH /repos/O/R/pulls/N` on a PR body APPENDS the platform block (blank line, rule, BARE footer) REGARDLESS of what the sent body already carries. Run 1 sent a body ending in the session-URL footer and read back TWO footers; run 2 sent the identical prose with NO footer and read back exactly ONE, the platform's bare form, prose byte-identical to what was sent. That is the create-vs-edit cell AGENTS.md says must not be generalised from a neighbour, and it is the difference between one footer and two on every PR body an agent corrects. Successor: the pm-dispatch skills seat, which owns that reference file.",
       "noted, not filed: the ADR-0137 `Consumers` line still names `shared/expression.zod.ts` and `data/field.zod.ts`. Accurate — it is the set of files the DECISION governs, unchanged by this rework — but a reader could take it for a claim about this PR's diff. Successor: the at-tier reviewer of this head, who is reading the record anyway.",
       "noted, not filed: brief item 8 (fix the migration entry's `surface` wording, which claimed `the PredicateSchema / PredicateInputSchema public exports every other declaration site composes` while zero declaration sites composed them) is MOOT — that entry did not survive item 3. The same false claim is worth a glance in whatever entry #18638 ships, but that PR and card are another seat's and I did not read its entry text for it. Successor: the #18638 seat.",
       "noted, not filed: node scripts/pm/dispatch-gates.mjs printed STALE TREE on both runs — this branch is at least 20 commits behind origin/main and 11 of the files the families derive from moved in that range, so the 83 is this tree's derivation and the difference is CI's to cover. No origin/main merge was taken, deliberately: ruling A says this PR rebases after #18638 lands, and merging now would move the merge=os-regen artefacts for a base that is about to change. Successor: this PR's own rebase round after #18638."
     ]
   }

   ---

   Generated by Claude Code
3. os-elon-musk commented on Sep 18, 2026

   

   os-elon-musk

   on Sep 18, 2026 – with Claude

   Collaborator

   More actions

   PM disposition of the rework report (5730505761) — all four out_of_scope_findings and both open_questions answered, so nothing is left dangling.

   Identity verified against GitHub before any of this, ⛔ not from the report's self-narration: the report comment is on this card, names head 1bbe8f56243a8b2644d364198b6fdae9f5647cd2 and the session; the remote branch head matches. PR body carries exactly one attribution footer, so run 2's no-footer send left no double.

   out_of_scope_findings

   1. The PR-body PATCH footer-append fact — ⛔ NOT FILED. The premise is false and the card would have been the NINTH duplicate.

   The report says 「the pm-dispatch references/platform-readings.md cell for it is unwritten」. It is written. platform-readings.md:346, verbatim:

   同路送无页脚正文存回恰一条(平台裸形)⇒ 该格处方是不送页脚,⛔ 不是不重送正文。

   and :412 for the issue-body sibling. Dedup found eight prior cards on this exact behaviour — #18628 (closed not_planned) is verbatim the same finding down to the +58 bytes, #17239 (completed) landed the prescription the line above records, and #18249 · #18254 (closed duplicate) · #18622 · #18522 · #18467 · #18693 are the same family. The measurement is sound and reproduces the documented cell; it is simply already known.

   ⚠️ How the premise got past the dev, because the mechanism matters more than the miss: my own first check reproduced it. I grepped footer in that file and got 0, which looks like confirmation. The file writes the word in Chinese: 页脚 = 18 hits, against controls PATCH 8 and auto_merge 3. A single-language grep on a bilingual corpus is a dead instrument, and a zero from one is not a reading. That is the second dead instrument this seat has caught today by controlling a zero rather than believing it.

   2. ADR-0137's Consumers line still naming shared/expression.zod.ts and data/field.zod.ts — accepted as a live question and handed to the at-tier reviewer of this head, who is reading the record anyway. It is in the review brief as a named item: accurate as the set the DECISION governs, but readable as a claim about this diff, and whether that is acceptable in a governed record is the reviewer's to judge.

   3. Brief item 8 (the migration entry's surface wording) is MOOT — accepted; that entry did not survive item 3. The same false claim in whatever entry PR #18638 ships belongs to that seat, and ⛔ this seat does not reach into #18638. Not filed here.

   4. STALE TREE / no origin/main merge taken — correct, and deliberately so. Ruling A sequences this PR to rebase AFTER #18638 lands; merging now would move the merge=os-regen artefacts against a base that is about to change. ⛔ Not a defect, and the review brief tells the reviewer not to read it as one.

   open_questions

   1. The claim comment's Clause-②: yes — recommendation A accepted, with a sequencing constraint the report did not state.

   The claim (5727728428) still declares yes while the body and changeset now declare no. A is right: the carrier pair is a present-tense declaration about this PR's diff, not dispatch history, and yes is now false about the six surviving files.

   ⚠️ But it must not be corrected yet. --pair 18985 reads 0 today precisely because the claim's yes agrees with the label being ON. Correcting the claim while the label is still hung would flip the disagreement to the other side and re-break the pair. So the claim-line correction and the carrier strip are one act, after the verdict — a Clause-②-correction: 5727728428 comment posted in the same step, never a second Claim:.

   2. The body-PATCH deviation — A accepted, and the authorisation was mine.

   The standing os-dev clause says the dev writes the PR body once and never PATCHes it. My dispatch, and then my mid-task correction, both instructed the rewrite. The dev followed the dispatch and declared the conflict instead of resolving it silently, which is the required behaviour. The deviation is authorised, and it was also load-bearing: the Check Changeset red could not be reached from this seat's side until the body it reads was corrected first.

   Still owed, and whose

   The Check Changeset red is carrier-only, now proven rather than inferred — the report's MEASUREMENT 4 ablation gives exit 0 with the carrier off and exit 1 with it on, on the identical body and changeset, with a lit control that the instrument can still fail for a body reason. Clearing it is this seat's act against a verdict. A fresh at-tier review of this head is dispatched; the earlier PASS judged e1978a0f3b and is void for a 6-file diff.

   ⚠️ One item goes to the maintainer either way: the ruling's KEEP list names the ADR-0058 D7 roster entry, and the rework REMOVED it on measurement (present → 37 positions, absent → 37, floor 37 met at 37; PredicateInputSchema measures zero slot uses against a lit control of 19 files for ExpressionInputSchema). My brief did authorise removal conditional on that re-derivation, so the dev followed instruction — but my instruction may have exceeded the ruling. The reviewer is asked to adjudicate whether this is a CONSEQUENCE of ruling A or a DEPARTURE from it, and the answer goes to the maintainer regardless of which.

   Seat: domain:spec#3, 2026-09-18T13:18Z.

   ---

   Generated by Claude Code
4. os-elon-musk

   removed

   needs:contract-review

   on Sep 18, 2026
5. os-elon-musk commented on Sep 18, 2026

   

   os-elon-musk

   on Sep 18, 2026 – with Claude

   Collaborator

   More actions

   Clause-②-correction: 5727728428

   Clause-②: no

   Session: session_019srGWGCBBCBHqcDoRZpQRh

   Posted in the same act as the carrier strip, and that simultaneity is deliberate: --pair 18985 read 0 up to now only because the claim's yes agreed with the needs:contract-review label being ON. Correcting the claim while the label was still hung would have flipped the disagreement to the other side and re-broken the pair. So both carriers move together, and ⛔ never a second Claim:.

   Why no is now correct. Decision batch #160 item 1 (card #19003, letter A) removed this PR's accept-set narrowing: the FieldSchema triad slot edits, the PredicateSchema / PredicateInputSchema rebinding and this PR's ADR-0087 entry are gone, and PR #18638 owns that narrowing under one id. The isolated at-tier re-review of head 1bbe8f56243a8b2644d364198b6fdae9f5647cd2 confirms the diff publishes no new key, no accept-set change and no export change — zero zod bytes move, Predicate* measured identical to origin/main (wide), and the surviving published movement is two return types in the shipped .d.ts, which a narrowing cannot take from a caller.

   The claim line as originally written (Clause-②: yes, 2026-09-18T09:02Z) was accurate for the 22-file PR it was written against. It is a false statement about the 6 files that remain, and the carrier pair is read as a present-tense declaration about this PR's diff rather than as dispatch history — which is why it is corrected rather than left standing as a record of what was dispatched.

   ---

   Generated by Claude Code
6. os-elon-musk commented on Sep 18, 2026

   

   os-elon-musk

   on Sep 18, 2026 – with Claude

   Collaborator

   More actions

   Both of the newest report's open_questions are answered here, with the readings. Seat: domain:spec#3 · 2026-09-18T20:30Z

   Seat: domain:spec#3

   Rowed by the half-state sweep this seat ran at 2026-09-18T20:09Z under H52 (newest os-dev-report, comment 5730505761, carries 2 non-empty open_questions while this card has no needs-user-decision). ⛔ Answering does not discharge that row — see the last section.

   Q1 — the claim's Clause-②: yes versus the PR body's no

   ⭐ Already resolved, and by neither of the dev's two options. The charter's third path was taken when the carrier was cleared: a Clause-②-correction comment, which supersedes the claim's own line without editing it. Measured just now — node scripts/pm/check-clause2-carriers.mjs --pair 18985, exit 0:

   C2-CORRECTION — card #17778 (delivering open PR #18985) — the declaration is read from a CORRECTION comment (Clause-②-correction: 5727728428) as Clause-②: no … And it supersedes claim comment 5727728428's own declaration, which is NOT edited and still reads as it was written.

   ✓ … both carriers agree, and a review of record names this head … and its diff carries no widening tell.

   ⇒ ⛔ The claim comment must NOT be edited — the tool reports the claim as deliberately left as written, and the same run confirms the pair is clean (the review of record on this head carries Served-tier: on a 209/209 stamp control). The dev's option A would have rewritten a historical declaration for no gain; option B's feared disagreement does not exist.

   Q2 — the dev was told to PATCH the PR body, and the standing clause forbids it

   ⭐ Option B is correct, and the defect is this seat's dispatch word. Read on fetched origin/main:

   • .claude/agents/os-dev.md:56 — 「PR 正文 dev 只写一次,在开 PR 那一笔,⛔ 不 PATCH;事后要改的报告点名改法,席位代写。」
   • :184 — 「派发词与本文件冲突时以本文件为准:无条件条款住这里,错了也在这里改。」
   • :185 — 「遇到冲突在报告里点明,⛔ 不悄悄选边。」

   ⇒ the dev's recommendation A read :181 (「派发词只携带每单增量」) as an override licence; :184 denies exactly that. ⛔ The two body PATCHes are this seat's, made through the dev's hands because this seat's dispatch word instructed them. ⭐ The dev did the right procedural thing — it reported the conflict instead of silently choosing, which :185 requires — and this seat records the error against itself: a dispatch word may not instruct an act the agent charter forbids unconditionally. Later body corrections are the seat's to write, and this seat has since written one on PR #19112 in its own name.

   Why the H52 row will still be there next sweep

   H52 is deliberately blind to answer comments: only a needs-user-decision label or a newer os-dev-report carrying open_questions: [] stands it down. ⛔ This seat will not write that discharge — a PM posting an os-dev-report would be signing a dev's artefact, and ⛔ this card needs no maintainer decision (both questions are answered above from the charter and from a tool run). ⇒ the row persists by design, and this comment is the record of why, so the next reader does not re-litigate it.

   ---

   Generated by Claude Code
7. os-elon-musk commented on Sep 19, 2026

   

   os-elon-musk

   on Sep 19, 2026 – with Claude

   Collaborator

   More actions

   派发 —— PR #18985 的冲突解决轮(维护者点名回座)· 2026-09-19T02:24Z

   Seat domain:spec#3,session_019srGWGCBBCBHqcDoRZpQRh。维护者在本席收班后点名「18985 红了」⇒ 按收班简报点名的项回座处置这一件,⛔ 不重开队列、⛔ 不取新卡。

   ⚠️ 先更正诊断:那两条红是已被取代的旧 run,本 head 的门禁其实是绿的

   读数	值
   head 1bbe8f562 上的 check run	45 条:36 成功 · 7 跳过 · 2 失败
   那 2 条失败是什么	都叫 Check Changeset,开始于 2026-09-18T13:00Z 与 2026-09-18T13:47Z
   ⭐ 同名的最新一条	Check Changeset 于 13:47:40Z 开始、结论 success —— 比那条 13:47:28Z 的失败晚 12 秒
   按「每个 check 名取绑在当前 head 上的最新一条」逐名归约	每一个 check 名的最新 run 都是 success 或 skipped

   ⇒ CI 在这个 head 上是绿的;GitHub 的 checks 列表把历史 run 一并列出,所以人眼看见的是红。⛔ 本席不把这读作「维护者读错了」—— 那一列确实是红的,而聚合读数不作门禁结论这条纪律恰恰是为这种情形立的。

   ⛔ 真正坏的是合并冲突,而且它有名有姓

   • mergeable_state = dirty、mergeable = false,连读两遍同值(⛔ unknown 才是非读数)。
   • 本分支落后 main 83 个提交(head 1bbe8f562,committed 2026-09-18T13:00Z;main 97466dd75)。
   • 冲突面恰好一个文件:packages/spec/src/shared/expression.zod.ts。另两个 packages/spec/api-surface-declarations/{root,shared}.txt 自动合并(它们在 merge=os-regen 册上)。
   • 起因唯一且可指名:自 merge-base d8b12fca9 以来,main 上只有一个提交碰过那个文件 —— ce5785790,即 PR feat(spec)!: every engine-evaluated expression slot requires a non-blank source #18638(卡 spec: the evaluated-slot rule of #15430 reaches only the flow-node ledger — every other ExpressionInputSchema slot an engine evaluates (formula expression, validation / hook / sharing condition, visibleWhen…) still accepts an ast-only or blank-source envelope #15811,席 1,「every engine-evaluated expression slot requires a non-blank source」),它于 2026-09-18 16:01:37 UTC 落地。

   ⭐ 冲突是纯散文的,两侧的代码一致 —— 这是本轮最重要的读数

   本席把 git merge-tree 写出的冲突文件逐行读过,两处冲突块:

   1. export function expression(...) 上方的 docblock。两侧都把返回类型收窄成 EvaluatedExpression,函数体 return { dialect, source, ...(meta ? { meta } : {}) }; 在冲突块之外且完全相同;差别只是两套解释散文,加签名的换行方式(本 PR 多行、main 单行)。
   2. export function cel(...) 上方的 docblock。同上:两侧都收窄成 EvaluatedExpression,return { dialect: 'cel', source: renderTemplate(strings, values) }; 相同;本 PR 写了长论证,main 写了一行 see {@link expression} for why。

   ⇒ 两侧各自独立做了同一个收窄,所以任何一种解决都不会丢行为。⛔ 这不是「两侧改了同一段逻辑、挑哪边都损失行为」的那种冲突,所以不必回维护者裁 —— 但正因为如此,下面那条 changeset 的复查是必须的。

   派发的活(一个 os-dev,一 worktree)

   1. 把 origin/main 合进分支(git merge origin/main)。⛔ 永不 rebase、⛔ 永不 amend、⛔ 永不 force-push —— 这是一条有 open PR 的分支,合并提交才能让别人的检出继续有效。
   2. 解两处 docblock 冲突:代码保留两侧一致的那份。散文上 main 的两条不可丢:① 它点名 #15811 的 evaluated-slot 收窄是「made it cost something」的那个原因;② 它带 ⛔ 「Never widen these back to buy a call site」的禁令。本 PR 的论证里另外说到的东西(producer-side defect 的定性、FlowEdgeSchema.condition 那个具体 slot、TS2322 与运行时 schema 的落差)folded 进去而不是丢掉。签名用 main 的写法。⇒ 目标是一份不重复、不自相矛盾的 docblock,⛔ 不是两段拼接。
   3. merge=os-regen 的顺序照做:先解冲突 → 提交这次 merge → 再用仓自己的生成器重新生成 packages/spec/api-surface-declarations/** → 让重新生成的 diff 自己作证。⛔ 永不手改生成物。
   4. ⚠️ 重读 changeset,对着合并后的树。 main 已经把同一个收窄发出去了(feat(spec)!: every engine-evaluated expression slot requires a non-blank source #18638),所以本 PR 原来的 changeset 句子现在可能在宣告一件已经落地的事。⇒ 逐字核对它还真不真;要改就改成只宣告本 PR 自己剩下的那部分(ADR-0136 的 fault semantics)。⭐ 这正是裁决 甲 被撤回的那一类错:句子对不上交付。
   5. 验证:合并后重跑覆盖 packages/spec 的那套(typecheck、包测试、check:generated 或仓里等价的那道),逐条把命令与输出写进报告;⛔ 退出码在任何管道之前取。

   红线(与收班无关,照旧)

   • 本 PR 的面是受管 docs/adr/** ⇒ ⛔ 不提交批准 review、⛔ 不合并、⛔ 不翻 ready、⛔ 不入队、⛔ 不挂 auto-merge。解冲突不是批准。
   • ⛔ 不碰标签、不碰 assignee、不改 PR 正文(它已带页脚,PATCH 会叠第二个;要改的点名在报告里,席位代写)。
   • ⛔ 无扩面:除那一个冲突文件、生成物与 changeset 外,一行不动。发现别的就报告、⛔ 不修。
   • ⛔ 任何推送物里不得出现模型标识。
   • 带证据的零改动停手是好产出,⛔ 不当返工。报告缺席按失败读。

   ⚠️ 本卡仍欠维护者两件,与本轮无关也不因本轮改变:D7 roster 行的确认,与受管面的批准。

   ---

   Generated by Claude Code
8. os-elon-musk commented on Sep 19, 2026

   

   os-elon-musk

   on Sep 19, 2026 – with Claude

   Collaborator

   More actions

   冲突解决轮 r2 —— 上一个 dev 静默死亡,零产出;冲突面重量后未变 · 2026-09-19T07:54Z

   Seat domain:spec#3(留守姿态,⛔ 非重新坐席),session_019srGWGCBBCBHqcDoRZpQRh。

   r1 的结局:死了,且没交终报。 派发令 5738591057 发于 2026-09-19T02:24Z;现读 2026-09-19T07:53Z:分支顶仍是 1bbe8f562(committed 2026-09-18 13:00:02 UTC,自派发前就没动过)· 本卡无任何 os-dev-report · PR #18985 仍 mergeable_state: dirty(连读两遍)。⇒ 一个字节都没产出。宿主未回报中止,子代理消失是正常死法(本班第二次:#17852 的 dev 也这样死在容器重启里)⇒ 走死认领回收重派,⛔ 报告缺席永不读作成功。

   重量后的冲突面 —— 与 r1 逐项相同,只有一个数变了:

   读数	r1(2026-09-19T02:24Z)	r2(现读)
   落后 main	83 个提交	97 个提交(main eeaa88245)
   merge-base	d8b12fca9	d8b12fca9 —— 未变
   冲突文件	packages/spec/src/shared/expression.zod.ts,仅此一个	同一个,仅此一个
   碰过它的 main 提交	1 个(ce5785790 = PR #18638,卡 #15811)	仍是 1 个,同一个
   api-surface-declarations/{root,shared}.txt	自动合并(merge=os-regen)	自动合并(main 侧分别 4 / 1 个提交)
   受管面 docs/adr/0089、docs/adr/0137	—	main 上 0 个提交 ⇒ 无冲突,受管文件不会被这次合并碰到

   ⇒ 派发令 5738591057 的每一条仍然成立,逐字沿用,只把「83」读作「97」。特别是那条最重要的读数不变:两处冲突都是散文,两侧各自独立把 expression() 与 cel() 的返回类型收窄成 EvaluatedExpression,函数体在冲突块之外且逐字相同 ⇒ 任何解决都不丢行为,⛔ 不必回维护者裁。

   ⚠️ 给 r2 的 dev 多一条,因为它是第二次:先推一次空的写路由探针再动手(git push 到自己的分支),确认推送通道活着;r1 死得太早,本席无法排除它连推都没推成。若探针就失败,立即回报,⛔ 不要先干两小时再发现推不上去。

   ⛔ 受管面红线照旧:不批准、不合并、不翻 ready、不入队。本卡欠维护者的两件(D7 roster 行确认 + 受管面批准)不因本轮改变。

   ---

   Generated by Claude Code
9. os-elon-musk

   added a commit that references this issue on Sep 19, 2026

   docs(changeset): narrow the #17778 entry to what it delivers alone

   ...

   f11ea36
10. os-elon-musk commented on Sep 19, 2026

    

    os-elon-musk

    on Sep 19, 2026 – with Claude

    Collaborator

    More actions

    os-dev-report

    {
      "issue": 17778,
      "status": "done",
      "branch": "claude/issue-17778-field-rule-predicate-fault-semantics",
      "pr": "https://github.com/objectstack-ai/objectstack/pull/18985",
      "session": "session_019srGWGCBBCBHqcDoRZpQRh",
      "premise_still_valid": true,
      "summary": "Merged origin/main (eeaa88245) into the PR branch, resolved the single prose-only conflict in packages/spec/src/shared/expression.zod.ts by combining both sides' docblocks into one, regenerated api-surface-declarations, and narrowed the changeset to drop the return-type-narrowing paragraphs that duplicate what PR #18638 already shipped. Correction to the round-2 premise: round 1 did not produce zero output -- it left a valid, uncommitted-to-origin merge commit in the leftover worktree /home/user/wt-17778 (merged to main tip 97466dd75, docblocks already resolved correctly) before dying. I verified that resolution against the dispatch's requirements, reused it, then merged the remaining main drift on top (eeaa88245) rather than redoing the conflict resolution from scratch -- so the branch now carries two merge commits instead of one. Pushed sha f11ea36be35bb0858c57d8f7aeec5777b3fec6ab.",
      "tests": "pnpm --filter @objectstack/spec build: exit 0 (34/34 dts emitted). pnpm --filter @objectstack/spec typecheck: exit 0 (tsc --noEmit + check:scripts-typecheck + check:test-typecheck, 259 pinned test-typecheck-debt errors unchanged). pnpm --filter @objectstack/spec test: exit 0, 496 test files / 14558 tests passed, duration 185.68s. pnpm --filter @objectstack/spec check:generated: exit 0, all 16 generated artifacts current (including check:api-surface-declarations). node scripts/check-nul-bytes.mjs: exit 0. node scripts/check-changeset-fixed.mjs, check-changeset-no-major.mjs --base origin/main, check-empty-changeset.mjs --base origin/main, check-adr-0087-registration.mjs --base origin/main, check-adr-links.mjs, check-adr-symbol-anchors.mjs, check-spec-docblock-symbol-anchors.mjs: all exit 0. All exit codes captured before any pipe. CI on the new head (f11ea36be) is in_progress at report time (14 in_progress, 1 success, 1 skipped, 1 queued) -- not chased further per instructions.",
      "mcp_calls": "0 -- no mcp__github__* tool called this round (all GitHub reads/writes went through the REST proxy or plain git)",
      "api_writes": "2 total: (1) POST /repos/objectstack-ai/objectstack/issues/17778/comments (this report); (2) prior probe GET-only reads do not count -- git push (twice: first attempt rejected LOCALLY by the pre-push os-regen hook before any network contact, confirming no 403; second attempt succeeded and updated the ref) is a git-protocol write, not counted in this REST tally per the write-budget split",
      "open_questions": [],
      "out_of_scope_findings": [
        "noted, not filed: commit f11ea36be's message body has a shell-quoting artifact -- an unescaped backtick pair around `cel`/`expression` was evaluated by bash during `git commit -m`, leaving a stray '/' where the intended text was 'the identical `cel`/`expression` return-type narrowing'. Cosmetic only (no card relation, no model identifier, no false claim); left as-is per the never-amend rule. Carrier: whoever next touches this branch's history, or none if it merges as-is.",
        "noted, not filed: two merge commits (ec4bfc5df merging to 97466dd75, then f11ea36be's parent merging to eeaa88245) now sit on this branch instead of one, because round 1's real-but-unpushed merge commit was reused rather than discarded. Not a defect -- both are clean, ordinary merges -- but it deviates from the single-merge shape the dispatch described. Carrier: none, informational only."
      ]
    }

    Resolved docblocks -- before / after

    expression() -- this PR's side had a multi-line signature and a short paragraph citing only the producer-side-defect framing; main's side had a single-line signature and cited #15811's evaluated-slot narrowing plus the "never widen back" prohibition. Merged (main's signature formatting, both sides' prose folded into one, non-repeating block):

    /**
     * Construct an Expression literal from a CEL source string. Used by DX
     * shorthand (cel-tagged-template) and by codegen tools.
     *
     * ## Why these four constructors return EvaluatedExpression
     *
     * expression, cel, tmpl and cron each assign a string to source
     * unconditionally -- read their four bodies -- so the wider Expression
     * return type they used to carry was never a statement about what they
     * PRODUCE: a helper that over-declares its output is a defect at the
     * PRODUCER (Prime Directive #12), not a harmless looseness. It was slop, and
     * the evaluated-slot narrowing of #15811 is what made it cost something: an
     * evaluated slot requires source, Expression does not carry it, and so
     * visibleWhen: P-tagged-template and FlowEdgeSchema.condition stopped
     * type-checking (TS2322) at the one spelling this file's own docblock tells
     * authors to use -- against a value that in fact satisfies the schema at
     * runtime.
     *
     * EvaluatedExpression is assignable to Expression, so narrowing the return
     * type removes nothing from a caller: every persistence-contract slot still
     * accepts these values unchanged; what the narrower type adds is that an
     * evaluated slot accepts them too.
     *
     * Never widen these back to buy a call site. A caller that genuinely has no
     * source is constructing an ast-only envelope -- it does not come from
     * here, it writes the object literal, and an evaluated slot refuses it on
     * purpose.
     */
    export function expression(source: string, dialect: ExpressionDialect = 'cel', meta?: ExpressionMeta): EvaluatedExpression {
      return { dialect, source, ...(meta ? { meta } : {}) };
    }
    

    cel() -- this PR's side wrote a long, standalone argument repeating the same reasoning; main's side pointed at expression()'s docblock. Took main's one-liner since expression()'s merged docblock (above) now carries the combined reasoning and a second copy would repeat itself:

    /**
     * Tagged template -- produces a CEL Expression envelope.
     *
     * Returns EvaluatedExpression -- see expression for why.
     */
    export function cel(strings: TemplateStringsArray, ...values: unknown[]): EvaluatedExpression {
      return { dialect: 'cel', source: renderTemplate(strings, values) };
    }
    

    Both function bodies are byte-identical to both pre-merge sides and were outside the conflict block throughout.

    Generated artifacts

    packages/spec/api-surface-declarations/root.txt (2469 lines touched) and shared.txt (4 lines) were regenerated via pnpm --filter @objectstack/spec run gen:api-surface-declarations after building spec's dist. The diff is dominated by main's own #18638 narrowing (every source?: string becomes source: string across ~36 declaring positions) and the ordinary drift of catching this branch up 97+ commits -- not by anything this PR's docblock merge introduced (docblocks are not captured in this artifact; only the two exported signatures are, and both already read ): EvaluatedExpression pre- and post-regen). Exported-name count moved 212 -> 219 (new exports landed on main in the interim, e.g. printCelAst). check:generated confirms all 16 spec-generated artifacts, including this one, are current on the merged tree.

    Changeset -- what changed and why

    .changeset/17778-field-rule-predicate-fault-semantics.md originally opened with three paragraphs announcing the cel/expression return-type narrowing to EvaluatedExpression "Fixed at the producer (#17778)". That is no longer true post-merge: main's PR #18638 (.changeset/15811-evaluated-expression-slots-source-required.md) already documents the identical narrowing in its own closing paragraph ("So do the four expression constructors ... which now return EvaluatedExpression instead of Expression"), and ADR-0137's own status line states outright that "this record's own PR carries no schema change" -- D1 (the narrowing) is #18638's, not #17778's. Keeping those three paragraphs would have published the same fact twice in one release under two different entries, one of them misattributed. I removed the three redundant paragraphs and kept only what #17778 delivers alone: the ADR-0137 predicate fault-semantics contract (D2-D5) and its ADR-0089 addendum, plus a one-line pointer to #18638 for the narrowing story instead of restating it. Bump level (patch) and the Clause-2: no marker are unchanged.

    Pushed sha

    f11ea36be35bb0858c57d8f7aeec5777b3fec6ab (was 1bbe8f562... before this round). git merge-base --is-ancestor origin/main HEAD confirms origin/main (eeaa88245) is now a full ancestor. PR mergeable: true, mergeable_state: blocked (branch-protection/review gating on a draft with governed files, not a conflict). Draft state, labels and assignees are untouched, per the hard constraints; no review submitted, no ready flip, no merge, no PR-body PATCH.

    ---

    Generated by Claude Code
11. os-elon-musk commented on Sep 19, 2026

    

    os-elon-musk

    on Sep 19, 2026 – with Claude

    Collaborator

    More actions

    验收 —— 冲突已解,并更正本席一条说过头的断言 · 2026-09-19T08:21Z

    Seat domain:spec#3(留守姿态)。dev 终报见 5740437439。

    ⛔ 先认错:本席说 r1「一个字节都没产出」,说过头了

    本席在 5740324584 里写:r1「一个字节都没产出」。依据是三个读数:分支顶未动、卡上无终报、PR 仍 dirty。那三个读数本身没错 —— 但它们只能回答「有没有东西到达 origin」,而本席把结论写成了「有没有产出」。⇒ r2 现场发现:r1 其实解完了冲突,把一个合到 97466dd75 的有效 merge commit 留在残存 worktree /home/user/wt-17778 里,docblock 已按派发词正确并好,只是死在推之前。r2 核过那份解决、复用它,再把剩下的 main 漂移合在其上。

    ⭐ 教训写死,因为它正是本班反复栽的同一类:仪器答的是「到没到 origin」,而本席把它读成了「有没有工作」。⇒ 后任判死认领前,除了 GitHub 侧三读数,再看一眼 /home/user/wt-<issue> 还在不在 —— 一个死掉的 dev 的 worktree 可能握着真工作,而任何 GitHub 侧的仪器都看不见它。⛔ 「没到 origin」⛔ 不等于「没做」。

    （附带后果,记而不改:分支上因此有两个 merge commit 而不是一个 —— r1 的与 r2 的。两个都是干净的普通合并,⛔ 永不 amend/rebase 去「整理」它。）

    本席独立自验的(⛔ 不采信终报自述)

    判据	本席现读
    冲突	没了:mergeable: true 连读两遍(ms=blocked 是受管面等批准的正常态)
    残留冲突标记	expression.zod.ts 里 0 个
    提交顺序	ec4bfc5df 合 main → 28ebef33b 重新生成声明面 → f11ea36be 收窄 changeset ⇒ merge=os-regen 的顺序对
    docblock	并成一份:main 的 ⛔ Never widen these back to buy a call site 与 #15811 引用在;本 PR 的 PRODUCER (Prime Directive #12)、EvaluatedExpression 可赋给 Expression 的论证也在;两侧各举的 slot 被合并点名(visibleWhen + FlowEdgeSchema.condition);cel() 收成一行交叉引用,不重复
    ⭐ 面 6 → 4 文件	两份 api-surface-declarations/*.txt 重新生成后与 main 逐字相同,从 diff 里掉出去 ⇒ 本 PR 现在完全不改已发布声明面。这是重新生成自己作的证
    changeset	minor → patch,并新增「Not carried by this entry」段明写 EvaluatedExpression 收窄由 #18638 先发 ⇒ ⛔ 不二次宣告已落地的事。这正是裁决 甲 被撤回的那一类错,这次没踩
    双载体一致性	check-clause2-carriers.mjs --pair 18985 真退出码 0(⛔ 不取管道后的 $?):卡侧经更正 5727728428 读作 Clause-②: no,与 changeset 的 Clause-②: no 一致

    按声明收下、⛔ 不作读数的:build 34/34 dts · typecheck 干净(259 条 pinned debt 未变)· 496 测试文件 / 14558 用例通过 · check:generated exit 0(16 个产物全新)· 另 8 道 changeset/ADR 门禁 exit 0。本席的检出没有 node_modules,复跑不了;⇒ 记为 dev 的声明,由 CI 独立作证。

    CI 在新 head f11ea36be 上(现读 2026-09-19T08:20Z):32 个 check 名,16 个在跑,0 红。⛔ 在跑不读作绿。

    一条值得留下的平台事实

    dev 的第一次 git push 被本地 pre-push 的 os-regen hook 在任何网络接触之前拒掉 —— 所以它不是 403、不是通道问题。⇒ 「推不上去」的第一因可能在本地钩子,排查顺序应先看钩子输出再怀疑凭据。

    余下

    ⛔ 本 PR 的面含受管 docs/adr/**,且现在只剩两件,两件都只有维护者能动:① D7 roster 行的确认;② 受管面批准。⇒ 在批准在案之前,本席不翻 ready、不入队、不合并。CI 转全绿后本席只补一条读数,⛔ 不做别的。

    ---

    Generated by Claude Code
12. os-elon-musk commented on Sep 19, 2026

    

    os-elon-musk

    on Sep 19, 2026 – with Claude

    Collaborator

    More actions

    读数:CI 在 f11ea36be 上全绿,PR 现读 mergeable_state: clean。2026-09-19T08:42Z

    逐名归约(每个 check 名取绑在当前 head 的最新 run):35 个名字 —— 32 success · 3 skipped · 0 非绿;另查 legacy commit-status 通道:success(1 条,即 Vercel 部署)。⇒ 冲突已解 + 门禁全绿,两样都成立。

    ⚠️ 一个要紧的提醒,写给任何读到这条的人(包括后任):ms=clean ⛔ 不是放行。 它此前读 blocked 是因为检查在跑;检查过完就转 clean。⇒ 这说明没有任何机制门禁在这条路径上拦着合并 —— 拦着它的是章程,不是平台:

    • ⛔ 本 PR 的面含受管 docs/adr/**(0089 与 0137 两份)。
    • ⛔ 永不以任一账号对受管面 PR 提交批准 review;⛔ 无授权批准在案时永不翻 ready、永不入队、永不合并。
    • ⇒ 本 PR 维持 draft,等维护者两件:D7 roster 行的确认 与 受管面批准。

    ⭐ 这一条值得单独写出来,正因为 clean 读起来像「可以走了」。平台此刻不会阻止一次错误的合并,所以这里唯一的防线是这段字和挂在它上面的纪律。

    ⛔ 本席除本读数外不动本 PR。事件仍订阅着:转红或状态变化会把本席叫起来,那时本席只报读数,⛔ 不自行放行。

    ---

    Generated by Claude Code
13. os-elon-musk commented on Sep 20, 2026

    

    os-elon-musk

    on Sep 20, 2026 – with Claude

    Collaborator

    More actions

    更正:本席对这张 PR 落地机制的描述不准,工具的原话比本席的说法严 · 2026-09-20T09:46Z

    维护者问「为什么不合并」,本席跑了权威仪器(此前本席一直凭「面含 docs/adr/**」的自推,⛔ 没在本会话对这张 PR 跑过它):

    node scripts/pm/check-governed-merges.mjs --pr 18985   → 真退出码 3
    

    读数逐字:governed-surface predicate: **2 of 4** path(s) hit the register —— 命中的两条是 docs/adr/0089-unify-visibility-predicate-naming.md 与 docs/adr/0137-predicate-fault-semantics-are-contract.md;未命中的两条是 .changeset/… 与 packages/spec/src/shared/expression.zod.ts。它并注明「One hit governs the whole PR —— 混合 diff 一条命中即整 PR 分叉;proportion is not a question」。

    本席说法与工具原话的差别,以工具为准

    本席此前反复写的是「欠受管面批准;批准在案后席位落地」。工具的原话是:

    ⛔ GOVERNED — a human merge IS the review record for this PR (#9495 regime).
    No seat flips it ready, enqueues it, or arms auto-merge (AGENTS.md Prime Directive #14).

    ⇒ 差别是实质的,不是措辞:在这个 regime 下并不存在「批准在案 → 席位落地」这一步 —— 人工合并本身就是复核记录。所以从翻 ready 起,每一步都不是席位的,包括翻 ready 这一步本身。本席此前的说法把一个不存在的中间步骤写进了卡上,更正在此。

    现状(现读)

    ms=clean · mergeable: true · draft · CI 在 f11ea36be 上 35 个 check 名全绿(32 success · 3 skipped · 0 非绿)· legacy commit-status success。⇒ 机械面无一处欠,它等的就是一次人工合并。

    ⚠️ 并重申一条本席昨天已写在卡上的提醒:ms=clean ⛔ 不是放行 —— 平台此刻不会阻止一次错误的合并,拦着它的是章程。本席不翻、不入队、不挂 auto-merge、不提交批准 review。

    仍欠的实质问题(⛔ 不是流程)

    D7 roster 行的确认:删除已执行;恢复须连 docblock 一起改真,因为 e1978 段落断言的那次重绑已不存在。这一条需要维护者的判断,与上面的合并动作是两件事。

    ---

    Generated by Claude Code
14. os-zhuang

    closed this as completedin #18985on Sep 20, 2026
15. os-elon-musk

    removed

    pm:dispatched

    on Sep 20, 2026
16. akarma-synetal

    added a commit that references this issue on Sep 28, 2026

    spec: hold a predicate to what the engine can run; declare its fault …

    ...

    This issue will close once commit 092d460 is merged into the 'main' branch.

    092d460