`undoable: true` on an action without `operation` is accepted and silently un-anchored

[os-litant]

维护者速读

一个动作可以写 undoable: true(「做完给我一个撤销按钮」)。本仓的框架运行时只在动作同时写了 operation: 'update' 时才真的去拍快照;而我们自己钉住的控制台(.objectui-sha = 53ded82b)里有两个读者,只看 undoable、根本不读 operation —— 而且这两个读者就是本仓活性账本判 action/undoable = live 时引用的全部证据。

所以原卡那句「写了 undoable 却没有 operation ⇒ 什么都不会发生」不成立。真实情况是:有两拨读者,各自的锚不一样。

这就把一张本以为是「补个拒绝」的卡,变成一个契约形状问题:undoable 的合法集,该按哪一拨读者来定?

⛔ 本席没有让 dev 写任何代码,因为按原卡方向改会删掉今天活着的行为:

• 我们已发布的技能示例 ReassignLeadAction(skills/objectstack-ui/rules/actions.md,挂着 os:check)正是 type: 'api' + undoable: true + 没有 operation。defineAction 就是 ActionSchema.parse,所以原卡的拒绝会让我们自己发的示例在 import 时就抛错。
• 控制台里每一个 type: 'api' 的可撤销动作都会被拒。
• 本仓活性账本对 undoable 的 live 判定会当场失去它的依据。

四个选项,代价都已测量:

• A —— 原卡方向:undoable: true 必须配 operation: 'update'。☠️ 代价:上面三条全中,且必须连带改 objectui、抬 pin、重验活性、重写已发布示例,是一次跨仓破坏性落地,⛔ 不是本卡划的两文件面。
• B —— 让运行时在没有 operation 时也支持 undoable。☠️ 测到的反证:框架对 type: 'api' 根本没有服务端派发(action-execution.ts 自己的注释:UI-only types (url, modal, form) and api have no server dispatch here),所以在这些文档真正被编写的地方,加宽后的运行时没有东西可以锚。
• C —— 精准拒绝:只拒绝没有任何读者能锚的组合,即 operation !== 'update' 且 type !== 'api'。实测:拒掉 script 与 url 两种真正悬空的写法,api、operation: update、已发布示例全部照常通过。仍是收窄 ⇒ 仍要至档复核与 changeset,但删掉的活行为是零。⚠️ 代价我不能替您裁:它等于把「type: 'api' 是控制台能捕获的形状」这条控制台派发事实写进 spec。
• D —— 不改 schema,只改说明文字:undoable 的 .describe() 现在那句「An action with no operation declares no write set, so nothing anchors the capture there.」实测为假,连同活性账本条目一起改口径。最便宜也最准确,但对真正悬空的那一类(script / url / flow / modal / form)北极星第 4 条仍然没被满足。

我荐 C,并把 D 的文字改正并进同一个 PR。 请回一个字母:A / B / C / D。

os-decision-facets

• ① 项目长远合理性:北极星〈优先级〉4 要求「声明了的…在运行时兑现」。undoable 是被兑现的 —— 只是兑现它的是控制台而不是框架运行时。⇒ 真正的缺陷是契约没有说清楚谁来兑现,不是「没人兑现」。C 把合法集收到「至少有一个读者能锚」,是唯一让声明与现实对齐而不撤回能力的走法。⇒ 本棱指向 C。
• ② 实际业务拉动:⚠️ 本席测不到有多少人在写 type: 'api' + undoable,但测得到我们自己在已发布技能里教了这个写法。A 会让照着我们文档写的人在 import 时炸掉。⇒ 这一棱不是「未知」,是已知的负拉动,指向 ⛔ 不选 A。
• ③ 防 AI 犯错:现状对 script / url 上的 undoable 是静默放行 —— AI 作者写了,既不被拒也拿不到处方,正是北极星第 4 条禁止的形状。A、C 都终结这一类静默;D 不终结。⇒ 指向 A 或 C,而 ② 已排除 A。
• ④ 创业阶段不扩散:「remove 优于 declare-and-maintain」这一棱表面指向 A(撤掉这个键的一半用法)。⛔ 本席不据此翻字母:它管的是键,而 A 撤掉的是一个已发布、已教、已被活性账本判活的能力,那是撤能力不是撤键。C 新增的判定是一条 refine,不是一个新子系统。

自检行

只看①选 C;②③④ 是否翻转:否 —— ② 已知负拉动排除 A,③ 与①同向,④ 反向但它管的是键不是能力。

---

⚠️ 以下是原卡正文,保留不删 —— 其中被证伪的那一句已就地划掉并给出读数,因为本卡的整个框架是从它长出来的。

Path: P3 | 那条路第 3 步「验证响亮拒绝错的」 | undoable 缺 operation 被静默接受

What was measured

At objectstack-ai/objectstack head 889d9c7f22613e73d5a58d5eeacc22c9d907f4a7 (PR #19283, card #19148), an isolated at-tier contract review re-took the following on the tree:

• ActionSchema.undoable is a plain optional boolean. The refine chain in packages/spec/src/ui/action.zod.ts never reads it — the key's only two occurrences in that file are its docblock and the key itself.
• The undo envelope is built only inside executeDeclarativeUpdateAction (packages/runtime/src/action-execution.ts), which is reached only when operation is set.

So an action metadata document that sets undoable: true and declares no operation parses clean and produces no undo behaviour at runtime. The value is accepted and un-anchored.

⏹ FALSIFIED — verification read by this seat at 2026-09-20T20:12Z — measured on tip 488f4f54, and re-verified first-hand by the seat, ⛔ not taken from the dev's report. The document parses clean — that half stands. 「produces no undo behaviour」 does not: at the pinned console sha 53ded82b two readers build the undo envelope gated on action.undoable alone, with zero action.operation hits in either file — packages/app-shell/src/hooks/useConsoleActionRuntime.tsx:487 and packages/app-shell/src/views/RecordDetailView.tsx:831. Those same two files are the entire recorded evidence for this repo's own packages/spec/liveness/action.json verdict props/undoable: live. ⇒ the value is anchored, by a different reader than the one the card looked at.

Why PR #19283 does not close it

#19283 rewrites the undoable describe text so that it documents this state accurately. The reviewer's finding, verbatim:

The new sentence documents that undoable: true on an action with no operation is accepted and un-anchored. The dev records this as "resolved by this diff, no trap left". The prose is accurate, but accuracy is not enforcement: contract-first (Prime Directive #12) would refuse that pair at parse time, which narrows the accept set and is a separate contract card by 基本裁决原则 — not something this prose closes.

Direction is not settled here

Refusing the pair moves the accepted metadata set, so this is a contract-shape question, not a mechanical fix. It is filed for triage to grade and route; this seat chooses no direction.

Dedup words

undoable, un-anchored, ActionSchema, executeDeclarativeUpdateAction, undo envelope

Origin: at-tier contract review of PR #19283, comment 5749186061 (2026-09-20T10:18Z), boundary flag 1.
Filed-by: session_01LvwGppdonww4zGLWZo5rho (domain:spec execution seat 1) — filed as a finding, not graded or routed by this seat.

---

Generated by Claude Code

[os-sam]

Triage — domain:spec · priority:p2 · type Bug. finding leaves in the same write.

Triage seat (session_01KYzNJPin9Ar4oMMkSh4S9h), 2026-09-20T14:51Z. Card came in bare (finding only).

Lane — read from the body's named landing point, ⛔ not from the title

packages/spec/src/ui/action.zod.ts (the undoable declaration) with packages/runtime/src/action-execution.ts as the consuming side. The contract half is the spec's.

Grade — p2

An undoable: true written without operation is accepted and silently un-anchored — the author gets no refusal and no undo. That is 〈优先级〉4's named failure verbatim: 「错的必须被响亮拒绝并给处方,永不静默落库」. It is a class-(c) metadata trap: the key is stored, re-authored by someone else, and does nothing.

p2 and ⛔ not p1: the platform runs and the rest of the action works — what is wrong is one key's outcome. 「能跑但出错 ⇒ P2」.

Path: P3 | 那条路第 3 步「验证响亮拒绝错的」 | undoable 缺 operation 被静默接受

---

Generated by Claude Code

[os-sam]

Claim: PM loop round 21 from seat domain:spec#3
Session: session_01HnRAeVTLJevtQ5iCPX6JSm
Branch: claude/issue-19297-undoable-requires-operation
Seat: domain:spec seat 3 (seat post #18883)
Clause-②: yes (narrowing)
Thread-read: all 1 comment(s) on this card read in full before this write; 0 carried a Claim: or Release: line, so this claim opens the thread's claim pool.
Serial constraints cleared: see the measurement below — file surfaces disjoint against all 21 open PRs, 0 unreadable file lists, lit control fired.

Claimed at 2026-09-20T20:00Z.

Why this card, and why it is not barred by North Star rule 3

Rule 3 bars p2/p3 工具卡与契约卫生卡 while the product repo has open P0/P1 — and it does: 4 open P0, 43 open P1 at this reading. ⭐ This card is neither. Its own first line puts it on Path P3 —「验证响亮拒绝错的」, and the defect is product-visible authoring behaviour: an author writes undoable: true with no operation, the document parses clean, and nothing undoes anything. That is the North Star's 「错的必须被响亮拒绝并给处方,⛔ 永不静默落库」, ⛔ not ledger tidying and ⛔ not a gate repair.

⚠️ All three p1 cards in this lane were checked first and all three are genuinely held — ⛔ this is not a p2 taken in preference to available p1 work:

card	why not dispatched
#17667	PR #19373 holds packages/spec/src/api/package-api.zod.ts, its exact target file
#19365	the linked sibling of #17667 — 被链接或同父的两单永不同批, and it depends on the same retirement shape
#19289	region-held by PR #18319 on packages/lint/src/** (7 files). Re-measured and recorded at 5752285669

Serial constraint — measured at claim time, ⛔ not inherited

This card's surface is exactly two files, both named in its body:

packages/spec/src/ui/action.zod.ts
packages/runtime/src/action-execution.ts

All 21 open PRs read, GET /pulls/N/files per PR, intersected against that surface.

• EXACT-file holders: NONE.
• 0 unreadable file lists ⇒ ⛔ no false zero hiding behind a failed fetch.
• Lit control on the same run: packages/spec/src/api/package-api.zod.ts resolves to PR fix(spec,objectql): declare the inert-JSON artifact and registry-record package body stages, and stop the record under-reporting functions #19373, a hold this seat independently knows to be live. The instrument discriminates.

Three PRs share a directory with this surface and ⛔ none shares a file: #19090 (ui/bulk-action.*), #19398 (ui/component.*, ui/dataset.zod.ts, ui/view.zod.ts), #18319 (six packages/runtime/src/** test files). ⇒ Not a collision. The charter's test is stated in core-rules.md: 「同批独立性按文件面不相交判,⛔ 不按包」, and SKILL.md adds 「区域写不清就只能整文件串行」 — the fallback is file-level, and at file level these sets are disjoint. Residual overlap, if any appears, 「冲突交合并队列仲裁 ⛔ 不手排」.

⚠️ This reading decays. Anyone inheriting this card re-takes it before their own claim write, ⛔ never quotes this one.

Clause-② — yes (narrowing), declared before any commit

The repair makes ActionSchema refuse a combination it accepts today (undoable: true with no operation). An accept set that shrinks is a narrowing, and the ruling of record on that family is 5725370319 on #17852 — 「accept-set narrowing ⇒ Clause-②: yes；spec lane at-tier review」. ⇒ this PR carries needs:contract-review on both carriers and lands only on an at-tier PASS. ⛔ This seat is below CONTRACT_REVIEW_TIER and will ⛔ not review it itself.

Premise re-verified on today's tip, ⛔ not inherited from the card

The card's measurement was taken at 889d9c7f (PR #19283, card #19148). PR #19283 has since MERGED (2026-09-20T11:03:35Z), so the premise had to be re-read rather than carried: #19283 rewrote the undoable .describe() text and ⛔ did not add an enforcement, which is exactly what the card says it does not close. The two named files are on origin/main and no open PR holds either.

— domain:spec seat 3

---

Generated by Claude Code

[os-sam]

os-dev-report

{
"issue": 19297,
"status": "needs_decision",
"branch": "claude/issue-19297-undoable-requires-operation",
"pr": null,
"session": "session_01HnRAeVTLJevtQ5iCPX6JSm",
"premise_still_valid": false,
"summary": "Premise re-verified first-hand on today's tip 488f4f5 (not inherited from 889d9c7). Two halves hold, one is falsified. HOLDS: ActionSchema.undoable is still unread by the refine chain -- its only two occurrences in packages/spec/src/ui/action.zod.ts are prose at line 1116 and the key at line 1320, and the chain's last link is .superRefine(refuseDeclarativeUpdateContradictions) at line 1999, which reads type/operation/patch/params/locations and never undoable. HOLDS: the in-repo undo envelope is still produced only at packages/runtime/src/action-execution.ts:2007 (if (action?.undoable === true)) inside executeDeclarativeUpdateAction, reached only behind isDeclarativeUpdateAction (line 566: action?.operation === DECLARATIVE_UPDATE_OPERATION) at both doors (domains/actions.ts:687, action-execution.ts:2174); it is the only undoData producer under any packages/*/src. FALSIFIED: 'produces no undo behaviour' is false as an unqualified claim. At the pinned console sha (.objectui-sha = 53ded82bf7a494f54e344e19099dbf00854b8694, the objectui build this repo ships in packages/console) two readers build the undo envelope gated on action.undoable ALONE and never read action.operation at all -- app-shell useConsoleActionRuntime.tsx:487 and app-shell RecordDetailView.tsx:831; grepping action.operation in both of those files at that sha returns zero hits. Those two readers are verbatim the recorded evidence for this repo's own liveness verdict action/undoable = live (packages/spec/liveness/action.json, evidenceScope cross-repo). And skills/objectstack-ui/rules/actions.md ships an os:check-marked defineAction example (ReassignLeadAction) that is exactly type 'api' + params + undoable: true with NO operation, while defineAction (action.zod.ts:2132) IS ActionSchema.parse -- so the carded blanket refusal would throw on the published example at import time. I therefore did not pick a direction and wrote no code: the refusal direction as carded removes live, ledger-recorded behaviour rather than narrowing a dead combination. Branch pushed empty as the routing probe only; worktree kept for a follow-up round.",
"tests": "PARSE PROBE (throwaway, deleted; tree left clean): 6 documents through ActionSchema.safeParse on 488f4f5 via tsx against src. Baseline: A type 'api' + target + objectName + params + undoable, no operation -> PARSES CLEAN (the card's failing case, and the console-anchorable shape); B type 'script' + target + undoable, no operation -> PARSES CLEAN; C type 'url' + target + undoable, no operation -> PARSES CLEAN; D operation 'update' + patch + undoable -> PARSES CLEAN (control that must stay clean); E patch WITHOUT operation -> REFUSED, the LIT CONTROL proving the probe runs the refine chain (it quotes the existing 'patch only applies to operation: update' message); F the published skill example ReassignLeadAction verbatim (Precord.status == \"converted\" included) -> PARSES CLEAN. REFUSED_COUNT=1. DISCRIMINATING MEASUREMENT (prototype of the carded direction, not a delivered pin): the blanket refusal was injected into refuseDeclarativeUpdateContradictions with scripts/ablation-replace.mjs -- anchor hit x1 as declared, on-disk injected-count=1, blob moved 40c9ff6136e9ea1a216ad2e76356404b26c0e559 -> 52e7c5370407b7067184b44401a6114ea81da686. Under it: A REFUSED, B REFUSED, C REFUSED, D clean, E REFUSED (unchanged), F REFUSED. REFUSED_COUNT=5. So the carded refusal is measured -- not inferred -- to refuse the published skill's own example and every console-anchored type 'api' action, while correctly refusing exactly the two genuinely un-anchored shapes B and C. RESTORE: scripts/ablation-replace.mjs --restore under a trap; blob after restore 40c9ff6136e9ea1a216ad2e76356404b26c0e559 == blob at HEAD, git diff HEAD empty, git status --porcelain empty. GATE FAMILY: derived with node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack from the real changed set -- exit 2, 'this branch changes nothing against origin/main (merge base 488f4f5)', so the derived-for-this-branch family is EMPTY and nothing was run. For the PM's planning I also derived the hypothetical family for the two-file surface by passing the paths explicitly: 73 runnable commands (44 pnpm, 29 direct node), plus 50 artifact-roster families scored silent (7 of them with rosters under my paths), 11 declared-wide families, 6 pending-changeset families, 7 workflow-valued families and 5 path-scheduled CI jobs, all NOT MEASURED by construction. NOT MEASURED, all of it, and deliberately: with no diff there is nothing to gate. check:generated NOT MEASURED (no spec edit to regenerate for); affected-package test suites NOT MEASURED (no source change); repo-wide lint NOT MEASURED (same). pnpm install ran clean in the worktree (exit 0).",
"open_questions": [
{
"question": "undoable has TWO reader populations with DIFFERENT anchors -- the framework runtime anchors it on operation 'update', the pinned console anchors it on the action alone for type 'api'. Which accept set does the contract want?",
"options": [
"A -- the carded blanket refusal: undoable: true requires operation 'update'. MEASURED COST: refuses the published os:check skill example (which defineAction would then throw on), refuses every console-anchored type 'api' action, and contradicts this repo's own liveness verdict action/undoable = live whose sole evidence is those console readers. It would need an objectui-side change, a liveness re-verification, and a BREAKING changeset; per AGENTS.md Post-Task Checklist 4 it is a landing that cannot leave the pinned sibling untouched.",
"B -- teach packages/runtime to honour undoable without operation (the widening the dispatch flagged). MEASURED NOTE against it: the framework has no server dispatch for type 'api' at all (action-execution.ts, supported-type comment near line 573: 'UI-only types (url, modal, form) and api have no server dispatch here'), so for the very documents in question there is no server-side write for a widened runtime to capture. The widening would have nothing to anchor to where it is actually authored.",
"C -- targeted refusal: refuse undoable: true only where NO reader can anchor it, i.e. operation !== 'update' AND type !== 'api'. MEASURED accept-set delta from the probe above: refuses B (script) and C (url) -- the genuinely un-anchored shapes -- and keeps A, D and F. Still an accept-set narrowing, so still Clause-2: yes (narrowing) and still a changeset, but it removes zero live behaviour and the published example keeps parsing. COST I cannot rule on: it writes a console dispatch fact (type 'api' is the shape whose reader can capture) into the spec.",
"D -- no schema change: correct the describe text instead. Its current last sentence ('An action with no operation declares no write set, so nothing anchors the capture there.') is measured false against the pinned console, and re-scope the liveness entry accordingly. Cheapest and accurate, but leaves North Star 4 unserved for the genuinely un-anchored set (script/url/flow/modal/form)."
],
"recommendation": "C, with D's describe correction folded into the same PR. It is the only option that satisfies North Star 4 for the shapes that really are un-anchored while removing nothing the pinned console delivers today, and it needs no sibling-repo landing. I did NOT take it: choosing between C and A is a contract-shape decision about whether the spec may encode a console dispatch fact, and the card itself says the direction is not settled. If the seat prefers A, it should be dispatched as a cross-repo landing (spec + objectui + pin bump + liveness re-verification + published-skill example rewrite), not as the two-file surface this dispatch scoped."
}
],
"out_of_scope_findings": [
"noted, not filed: the undoable describe sentence landed by PR #19283 -- 'An action with no operation declares no write set, so nothing anchors the capture there.' -- is measured false against the pinned console readers and against the repo's own liveness evidence. Carrier: the PR that implements whichever direction this card takes edits that exact line, so it is not orphaned.",
"noted, not filed: skills/objectstack-ui/rules/actions.md line 22 attributes the undo snapshot to 'the runtime' ('the runtime snapshots prior values and restores them'); for that file's own example shape (type 'api', no operation) the snapshot is taken by the console, not by the framework runtime. Same carrier as above."
]
}

---

Generated by Claude Code