Repository navigation
spec 自己的 flow fixture 教了三种跑不通的形状:CRUD 的 recordId、decision 的 condition、object（#4001 第一类发现的第七例） #4924
Description
Activity
认领:spec 车道第 2 批
会话:session_018fxLGQdatPbBUvCgiVxg6D
分支:claude/issue-4924-flow-fixture-shapes
Worktree:objectstack-issue-4924
域:domain:spec
文件面:packages/spec/src/automation/flow.test.ts(仅 fixture 四处 + 原地注释)。⛔ 按 issue 明示:不收紧FlowNodeSchema.config(ADR-0018 刻意开放)。注:#5393 刚给 delete/update_record 加了
multi键(PR #5485 落地中),:487的 delete fixture 改写成filter: { id: … }形状与其正交,无需等待。
Generated by Claude Code
验收(spec 车道 PM,
session_018fxLGQdatPbBUvCgiVxg6D):ACCEPT → PR #5502(draft;合并 main 后重程 CI 在跑,全绿后转 ready 入队;skip-changeset已按门禁 route 2 处理)。- 四处 fixture 按处方修正,另补两处 issue 未点名但执行期必需的键(
objectName缺失会被 executor 直接 refuseNode、outputVariable缺失导致下游谓词引用从未绑定)—— 属「让 fixture 真能跑」的题内延伸,批准;出边谓词改 bare CEL 避开 Record-change trigger plugin loads but flows never fire on data writes (7.4.1) #1491 的硬报错,依据正确。 - 三组 pin 各自独立先证红(CRUD 契约 safeParse / decision 无 config / 出边形状),互不遮蔽 —— 「会被照抄的教材」升级成「会红的测试」,正中 issue 的核心指控。
FlowNodeSchema.config未动(ADR-0018)✓;与 feat(spec,automation): flow 的 update_record / delete_record 可以声明批量意图multi#5485 的multi键正交性已核对 ✓。- 范围外五类缺陷立为 flow.test.ts 剩下的五类跑不通的 fixture 形状:
{节点id.字段}输出引用、assignment 无assignments包裹、legacy loop、字符串filter、brace-CEL 出边条件 #5500(已核实:五类各带机制分析、查重先行、finding+domain:spec在位)。其中第 4 类(字符串filter的可跑等价形状,$lt是否接受插值 ISO 串)内嵌一个契约拍板项 —— 进下一轮发现分诊,若晋级则拆出决策位,不在 finding 里静默拍。 - 操作情报追认:dev 实证
rerun_workflow_run重放原始 event payload、看不到新标签,必须新 labeled 事件才能让 Check Changeset 真正 skip —— 与 Operational notes 5「重跑复用原 ref」同族,记入车道经验。
Generated by Claude Code
- 四处 fixture 按处方修正,另补两处 issue 未点名但执行期必需的键(
发现于 #4001 批 9 的载荷普查,不在该批范围内,未修。
事实
packages/spec/src/automation/flow.test.ts的 fixture 里,示范用的 flow 节点写着这些 config 键:flow.test.ts:336get_record的config: { object: 'opportunity', recordId: '{opportunityId}' }GetRecordConfigSchema声明,executor 一个都不读。object有 ADR-0087 转换(flow-node-crud-object-alias)会在加载期改写;recordId什么都不是flow.test.ts:355update_record的config: { recordId: … }flow.test.ts:487delete_record的config: { recordId: '{loop_records.item.id}' }filter定位行,所以这是一个「唯一的约束条件根本不被读」的删除节点 —— 正是 #3810 要防的 match-everything,穿着一个读起来像约束的键flow.test.ts:346decision的config: { condition: '{opportunity.amount} > 100000' }config.condition只在start节点上被读(触发闸门),在其余 19 个内建节点类型上是惰性的 ——lint-flow-patterns的flow-inert-node-condition(#4414)就是专门报这件事的 advisory这些 fixture 断言的是
FlowSchema/FlowNodeSchema,而FlowNodeSchema.config是刻意开放的z.record(z.unknown()),所以它们全绿,而且批 9 收紧后依然全绿——收紧的是槽位里的每类型契约,不是槽位本身。这不是一个会红的测试,是一份会被照抄的教材。为什么这是一条发现而不是洁癖
#4001 的第一类发现（「六个把 strip 时代假象固化成预期的测试」）已经点名过同一形状五次,其中
page.route那条的原话是「一个从未存在的路由键,平台自己的测试套件养了多年」。这是第六、七例,而且更靠近作者:flow.test.ts是协议层最容易被当成范例读的文件,对 AI 作者尤其如此 —— 它读起来像「平台官方怎么写一个 flow」。recordId尤其值得记:批 9 因此给它写了 guidance（编辑距离够不到任何已声明的键,不给处方的话拒绝信息就只能报个键名),而那条 guidance 的经验依据,正是仓库自己的 fixture。建议
把这四处 fixture 改成能跑的形状,并在原地留一句注释说明为什么改（照 #4001 的惯例:「修测试,并记下原因,不要绕开」）:
object→objectNamerecordId: '{x}'→filter: { id: '{x}' }config.condition→ 挪到出边的condition,fallback 边标isDefault: true⛔ 不要顺手把
FlowNodeSchema.config收紧 —— 它按 ADR-0018 刻意开放（node.type对插件开放,插件 executor 自带configSchema),批 9 的台账行已就地记了这一条。相关
flow-inert-node-conditionadvisory —— 惰性config.condition){…}before the query engine sees it #3810（模板求值抹掉过滤条件 → 拒绝执行）parse()their config, and tighten the undeclared-key warning into an error #4277 / A designerconfigSchemaand the keys its executor actually reads are still unreconciled —notifyhonourscfg.source, which no schema declares #4045（registerFlow的描述符键闸门与 form↔Zod 对账)