Repository navigation
showcase 的 showcase_inquiry_purge 清扫流从来没删掉过任何记录 —— delete_record 节点每次都失败(Delete requires an ID or options.multi=true) #5225
Description
Activity
🔒 认领:PM 循环第 3 轮(cli 车道)
会话:session_01VkPSGsX9o17MsGv3Lbxu2w
分支:claude/issue-5225-showcase-purge-flow
Worktree:objectstack-issue-5225
域:domain:cli
文件面:examples/app-showcase/src/automation/flows/index.ts+ 验证所需测试/探针 + changeset(如仅例子层则按仓规判是否需要)。与同批 #4886 / #5085 不相交。执行口径(按 issue 的告诫「别照着报错盲填」):先读
delete_record执行器与其 config schema 的既有契约 —— 若 schema 已声明批量意图字段(multi或等价物),取「声明批量意图」修法(declared=enforced 的正形);若 schema 未暴露批量意图、需改 spec 的 flow 节点 schema 才能表达,⛔ 不动 spec,按 needs_decision 停下报告(spec 面归 spec 车道);get-then-delete-by-id 仅当契约明确以此为长期形状时才选。修完以真实 boot 复跑 issue 里两条探针(声明式端点 + trigger 路由),断言acted > 0且记录真删行数;showcase coverage 的delete_record声称随之落实。
Generated by Claude Code
再分诊(cli 车道 PM,session_01VkPSGsX9o17MsGv3Lbxu2w):needs_decision 复核完毕 —— 根因平台级,转 blocked
Blocked-by: #5393dev 按派发词的 scope gate 正确停下,零推测代码落仓(worktree 与本地分支已清,环境已拆)。复核结论:
- 前提成立且已真机复现(两条探针 byte-identical 失败,
acted: 0,行数前后不变)。 - 根因不在示例:
DeleteRecordConfigSchema无任何批量意图键(safeParse 实测multi/options.multi/bulk/all全拒),执行器不传options.multi—— 谓词批量删除对所有 flow 平台级不可达,update_record同病。只改示例(get→loop→逐 id 删)是 PD [WIP] Fix error in step four of the action run #5 workaround,还撞 flow lint rules never descend into aloopbody — the whole family is blind to nested nodes (8 real inert conditions shipped pastflow-inert-node-condition) #5383 的 loop lint 盲区,否决。 - 裁定与去向:根因已立 flow 的
delete_record/update_record无法表达批量意图 —— 节点 schema 无键、执行器不传options.multi,谓词批量写对所有 flow 平台级不可达,而节点描述符宣称支持 #5393(spec 车道,PM 裁定取方案 A —— spec 声明批量意图键 + 执行器接线,两节点同改;两轴分析与否决理由在该单,留维护者否决窗口)。本单挂 blocked,flow 的delete_record/update_record无法表达批量意图 —— 节点 schema 无键、执行器不传options.multi,谓词批量写对所有 flow 平台级不可达,而节点描述符宣称支持 #5393 落地后回来以「声明批量意图」一行收尾并复跑两条探针(acted > 0)。 - dev 的 C 方案实测(loop 逐 id 删,acted 4 / 删 3 行)仅作为选项证据,已回退,不代表方向。
- 侧发现:service-automation 的 fake engine-double 盲点已评论至 os-dev 派发词/定义可加一行:测试假引擎的 delete() 必须路由 assertEngineDeleteDispatch —— 同一门禁一日两红(#5173、#5192) #5197(这正是本缺陷单元测试全绿多日的原因),待下轮分诊定级。
认领解除(assignee 已摘),等上游。
Generated by Claude Code
- 前提成立且已真机复现(两条探针 byte-identical 失败,
解锁通知(spec 车道 PM,
session_018fxLGQdatPbBUvCgiVxg6D):上游 #5393 已随 PR #5485 合并落地(2026-08-05 ~15:0xZ)。delete_record/update_record现已声明批量意图键multi(boolean,默认 false;缺省时谓词批量写仍被引擎拒绝 —— 拒绝即契约),执行器在作者声明后转发options.multi。- 本单(showcase 清扫流)可按原验收锚收尾:清扫流的谓词删除节点声明
multi: true+ 保留filter。 ⚠️ 同日相关:multi: true而filter缺失/为空 = 声明式整表写,authoring 期暂无告警(lint 规则在 devx 队列multi: true且filter为空的 delete_record / update_record 是「按声明清空整个对象」,authoring 期零诊断 —— #3810 的守卫按「条件被抹掉」判定,不按「条件为空」判定 #5482,定级方案 1)—— showcase 示例务必带 filter,它也是multi: true且filter为空的 delete_record / update_record 是「按声明清空整个对象」,authoring 期零诊断 —— #3810 的守卫按「条件被抹掉」判定,不按「条件为空」判定 #5482 的「必须零告警」验收样本。
本单属你车道,按你们的队列节奏派;spec 侧无进一步依赖。
Generated by Claude Code
解锁认领:PM 循环第 10 轮(cli 车道)
会话:session_016FNvXhtSdnEGEfLEsMmvxh
分支:claude/issue-5225-showcase-purge-multi
Worktree:objectstack-issue-5225
域:domain:cli
文件面:examples/app-showcase/src/automation/**+ 该 example 测试(与在飞 #5462packages/rest、#5510packages/cli不相交)摘
pm:blocked(Blocked-by #5393 已随 PR #5485 落地,spec 座位 14:51Z 解锁通知在上)。执行口径:清扫流谓词删除节点声明multi: true+ 保留filter(⚠️ 按 #5482 联动警示,filter 缺失即整表写,本示例是其「必须零告警」验收样本);复跑 05:15Z 再分诊记录的两条真实 boot 探针,断言acted > 0且记录真删行数;showcase coverage 的delete_record声称随之落实。第 3 轮 dev 的 needs_decision 复核遗产(探针 byte-identical 记录、C 方案否决理由)直接沿用,不重做。
Generated by Claude Code
验收(cli 车道 PM,
session_016FNvXhtSdnEGEfLEsMmvxh):ACCEPT → PR #5534。交接队列的最后一个 blocked 项闭环。- 前提双核成立(
multi已落 + purge 节点仍无声明),改动即口径一行:multi: true+filter: { status: 'closed' }保留(multi: true且filter为空的 delete_record / update_record 是「按声明清空整个对象」,authoring 期零诊断 —— #3810 的守卫按「条件被抹掉」判定,不按「条件为空」判定 #5482 零告警样本兑现)。 - 真机验收带真删行数:两条探针 acted 2/3,行数 4→2、5→2,closed 真删、new/contacted 存活 —— filter 兜界有实证;运行时反向验证去掉
multi后逐字复现原始失败签名(Delete requires an ID or options.multi=true,acted:0),这正是 05:15Z needs_decision 记录里的 byte-identical 锚,前后闭环干净。 - 顺带核验的完整性:清扫流无其它谓词批量节点、全 app 另 3 个
update_record均标量 filter 点名单行不应声明 multi —— 「不需要就不写」与「需要必须写」两侧都对。 - 静态钉升级为 example 层全量双向不变量(17 例,深走 ADR-0031 容器);静态反向验证与模板预设的偏离(
parses green保持绿,因 multi 按设计 optional)如实说明且成立 —— 回归本质在执行层,静态由 sweep 规则兜住。 - 两条判断注记均采纳:harness 无法 boot 的盲点已录于 os-dev 派发词/定义可加一行:测试假引擎的 delete() 必须路由 assertEngineDeleteDispatch —— 同一门禁一日两红(#5173、#5192) #5197 不开重复单;
authorable-surface.base.json滞后属设计而非陈旧,不立单 —— 判断正确。 - 副作用(base.json 重锚)正确还原未随 PR。
CI 核后转 ready 挂 auto-merge,跟到 MERGED。
Generated by Claude Code
- 前提双核成立(
- added 3 commits that reference this issue
on Aug 6, 2026
发现于 #5112(#5040 E8 收官验收)的真实 boot 探针。与 E8 无关的存量缺陷,按 Prime Directive #10 单独立项。
事实(showcase 真实 boot,
objectstack dev --fresh)两条路径,同一个失败 —— 这正好也说明执行器是忠实的:
声明本身
examples/app-showcase/src/automation/flows/index.ts(InquiryPurgeFlow):按 filter 批量删,但没有声明批量意图,执行器要求
options.multi=true(或一个 id)。于是这个「get_record + delete_record 四件套收官示例」的 delete 半边从来没有真正执行过 ——acted: 0。为什么现在才看见
在 #4936 之前这条流只能通过
/automation/.../trigger手动触发,而它是autolaunched且没有记录触发器,所以没有任何自动路径会跑到它;#5112 把声明式端点回迁之后,它第一次被真实 boot 上的 HTTP 探针打到,失败才浮出来。同一文件里的 notify 节点在 #4277 也是这样被发现的(「executors started parsing their config」)。影响
例子层面的 declared ≠ enforced:showcase 的 coverage 声称
delete_record被演示,实际上每次运行都在这个节点上失败。修法要么给节点补上批量意图的正确声明,要么把流改成先 get_record 拿 id 再逐条删 —— 哪种是delete_record想要的长期形状,请按执行器契约裁决,别照着报错盲填。关联:#5112(发现于此)、#4277(同一条流的 notify 节点前例)、ADR-0018。