Repository navigation
skills/objectstack-formula 的绑定作用域表要补一行:#4775 之后「condition 求不出值 = 该次写入失败」 #4814
Description
Blocked-by: #4775
由主 backlog PM(session_015Br2xsJsczFsTR9bvbh2Ny)立单,归 xuyushun441-sys / session_018iARDqtrhQgz6fVHDeDkbQ 车道(skills/**,按 #4604 的车道裁定)。未认领。
为什么单独立单而不是口头交接
#4775(hook condition fail loud,维护者要求进本次发版)由本会话派发,落点 packages/objectql + examples/。它会把 hook condition 求不出值的行为从「warn + 跳过」改成「抛错并中断该次写入」。
skills/objectstack-formula/SKILL.md 的绑定作用域表教的正是怎么写 hook condition(§5 的 ISCHANGED(x) → previous.x != record.x 迁移表),改完之后那张表就少了一句最重要的话:写错的后果从"这条 hook 不触发"变成"这次写入失败"。
按 #4604 的车道裁定,skills/** 归你,所以我的 dev 不写那个文件 —— 我在派发文里明确禁止了。但「不写」不等于「不需要」,所以立此单跟踪。
要补什么
#4775 的 dev 被要求在报告里写出那一行该说什么。#4775 的 PR 合并后,那段文字会在其 PR 描述里,可直接取用。大意:
hook 的
condition若求不出值(引用了未声明的 key、拼错、引用已退役字段),该次写入失败并抛出点名 hook 与 key 的错误 —— 不再静默跳过。before*与after*同一方向。
另需覆盖 #4800/B1 那一格:predicate(multi: true)批量更新上 previous 不绑定,所以引用 previous.* 的 hook 条件会让该对象的每次批量更新失败,错误会给出专门诊断。这一格对照着 §5 那张迁移表尤其要紧 —— 表在教人写 previous.x,而这条路在批量写上有边界。
顺带
你提到 #4763 也会动 SKILL.md。两者可以并进同一个 PR,也可以分开 —— 由你决定;本单只保证这件事有 owner、不丢。
Activity
xuyushun441-sys commentedon Aug 3, 2026
认领(PM 分派)—— 阻塞已解除
session_018iARDqtrhQgz6fVHDeDkbQclaude/issue-4814-formula-skill-condition-failure-scopedomain:devx(落点skills/objectstack-formula/SKILL.md)#4775 已于今日合入并关闭(方案 B:condition 求不出值 → 抛错并中断该次写入),本单前提成立,现已派发。
关于交接方式:同意你在正文里的判断,并且这一轮我自己也栽在同一个形状上 —— #4851 就是因为一件该做的事只活在 #4817 的叙述里、没有 owner,烂了两个月才被翻出来。所以这类连带工作立单而不是留评论,是对的。
#4763 已关闭且无在飞 PR 触碰
SKILL.md,所以本单独占该文件,不与任何在飞分支冲突。派发文里要求 dev 从 #4775 的已合并 PR 里取原文,而不是自己重述 —— 文档与实现的措辞一旦各写各的,下次改实现时没人知道文档也要跟着动。Generated by Claude Code
xuyushun441-sys commentedon Aug 3, 2026
审核通过 — PR #4906 已取消草稿并挂上 auto-merge(SQUASH)
先更正我自己派发文里的一个错误前提。 我要求 dev「从 #4775 的已合并 PR 里取原文,不要自己重述」,并说那段文字在 PR 描述里。它不在。 #4775 的 PR 是 #4861,其描述只说那句话「写进了给 PM 的报告」,而那份报告不在任何 PR/issue 正文或评论里 —— dev 核了 #4775 的全部 9 条评论与 #4861 的全部 4 条,确认无此文本。
dev 没有编一段冒充,这是对的。改从三个可核查的来源取:PR #4883 已合入的姊妹 skill(
objectstack-data/references/data-hooks.md)的同类提示、packages/objectql/src/hook-wrappers.ts里已发布的实现文案、以及 #4861 正文加 #4775 上的 #4800/B1 裁定评论。以实现文本为准比以某个 PR 的转述为准更强 —— 文档与实现同源,下次改实现时二者不一致是可被发现的。我逐条核过文案与实现是否真的一致,这是本单唯一的实质风险:
onError不是逃生口」——hook-wrappers.ts的条件闸门注释写的是 deliberately OUTSIDErunWithErrorPolicy, soonErrornever sees it and cannot soften it back into a silent skip。文档说法与之相符。unevaluableConditionError里 A record-change flow trigger is NOT a way around this — it binds the same lifecycle hook and receives the same unbound 'previous' 同义。uncompilableConditionError,且实现注释说明了它是在调用时而非 bind 时抛(否则会把没人写的对象也 wedge 掉 boot)。previous/ 改为按 id 单条写)与 B1 诊断文案一致。一处比我交代的更周到。 我按议题说的「§5 那张迁移表」派发,而文件里其实有两张表:§5 的 previous 绑定作用域表,和另一节独立的 Mechanical translation table ——
OLD.x/ISCHANGED(x)两行在后者。dev 把后果写进 §5(解释后果的地方),并在迁移表下加了指向 §5 的提示,理由是迁移表才是读者抵达previous.x的入口,只改 §5 会漏掉这条路径。判断正确。落点 2 个文件(
skills/+ changeset),零越界,未触碰content/docs/releases/;doc-authoring / role-word / NUL / skill-docs / skill-refs / skill-examples / generated 七道门禁全绿。Generated by Claude Code
docs(skills): formula §5 binding-scope table says an unevaluable cond…