TL;DR
pnpm dev（showcase）每次启动报 8 条「这些 flow 运行时会失败」，全是误报。校验在 ApprovalsServicePlugin 注册 approval 节点执行器之前 0.8 秒就跑完了。
告警措辞是断言式的，会直接把人送去查一个不存在的 bug（本 issue 的作者就被送去查了一轮）。
现场
WARN Flow 'showcase_expense_signoff' references node type(s) with no registered executor
or descriptor: approval. They will fail at execution time unless a plugin registers
them. Registered types: start, end, decision, assignment, loop, parallel, try_catch,
get_record, create_record, update_record, delete_record, screen, script, http,
connector_action, notify, wait, subflow, map
×8：showcase_expense_signoff、showcase_committee_quorum、showcase_budget_approval、showcase_invoice_signoff、showcase_one_task_signoff、showcase_closure_signoff、showcase_dynamic_approval、showcase_approver_bindings。
证据：是时序，不是缺失
用 --log-level info 跑一次：
| 事件 |
时刻 |
flow 校验告警 showcase_expense_signoff |
04:28:05.302 |
ApprovalsServicePlugin: service registered |
04:28:06.105 |
晚 0.8 秒。
而且 ApprovalsServicePlugin 的兜底日志 —— approvals-plugin.ts:283 的
} catch {
ctx.logger.info('ApprovalsServicePlugin: no automation engine — approval node not registered');
}—— 在整份 info 级日志里 一次都没出现（grep -c = 0）。说明 ctx.getService('automation') 拿到了引擎，registerApprovalNode(...) 确实跑了，approval 最终是注册上的，flow 运行时是好的。
相关代码：packages/plugins/plugin-approvals/src/approvals-plugin.ts:272-285、packages/plugins/plugin-approvals/src/approval-node.ts:92。
为什么值得修，而不是当噪音
- 措辞是断言不是猜测。"They will fail at execution time" 对一个恰好会在 0.8 秒后被注册的类型来说是假的。ADR-0018 明确允许插件在运行时通过
registerNodeExecutor(type) 扩展词汇表 —— 那么一个在扩展完成前拍板的校验器，就是在校验一个还没成型的世界。
- 它掩盖真问题。真正没人提供
approval 的部署（没装 approvals 插件）会得到一模一样的 8 条告警。现在这条信号的信噪比是 0，没人能用它区分两种情况。
- 它是 showcase 冷启 24 条告警里的 8 条，占三分之一。
修法（择一）
- 把校验推迟到所有插件
start() 完成之后（kernel:ready）—— 那时词汇表才是完整的。这是最贴合 ADR-0018 的做法。
- 保留早期校验但降级为 debug/info，在
kernel:ready 再跑一次权威校验，只有那一次才 warn。
倾向 1。另外顺带看一下 approvals-plugin.ts:283 那个 catch —— 它把"没有 automation 引擎导致 approval 节点没注册"记成 info，而 dev 默认日志级别是 warn，也就是真的降级发生时你反而看不见。这个 catch 至少该是 warn。
复现
rm -rf examples/app-showcase/.objectstack && pnpm dev
想看时序：objectstack dev --seed-admin --log-level info，对比 WARN Flow '...' 与 ApprovalsServicePlugin: service registered 的时间戳。
TL;DR
pnpm dev（showcase）每次启动报 8 条「这些 flow 运行时会失败」，全是误报。校验在ApprovalsServicePlugin注册approval节点执行器之前 0.8 秒就跑完了。告警措辞是断言式的，会直接把人送去查一个不存在的 bug（本 issue 的作者就被送去查了一轮）。
现场
×8：
showcase_expense_signoff、showcase_committee_quorum、showcase_budget_approval、showcase_invoice_signoff、showcase_one_task_signoff、showcase_closure_signoff、showcase_dynamic_approval、showcase_approver_bindings。证据：是时序，不是缺失
用
--log-level info跑一次：showcase_expense_signoff04:28:05.302ApprovalsServicePlugin: service registered04:28:06.105晚 0.8 秒。
而且
ApprovalsServicePlugin的兜底日志 ——approvals-plugin.ts:283的—— 在整份 info 级日志里 一次都没出现（
grep -c= 0）。说明ctx.getService('automation')拿到了引擎，registerApprovalNode(...)确实跑了，approval最终是注册上的，flow 运行时是好的。相关代码：
packages/plugins/plugin-approvals/src/approvals-plugin.ts:272-285、packages/plugins/plugin-approvals/src/approval-node.ts:92。为什么值得修，而不是当噪音
registerNodeExecutor(type)扩展词汇表 —— 那么一个在扩展完成前拍板的校验器，就是在校验一个还没成型的世界。approval的部署（没装 approvals 插件）会得到一模一样的 8 条告警。现在这条信号的信噪比是 0，没人能用它区分两种情况。修法（择一）
start()完成之后（kernel:ready）—— 那时词汇表才是完整的。这是最贴合 ADR-0018 的做法。kernel:ready再跑一次权威校验，只有那一次才 warn。倾向 1。另外顺带看一下
approvals-plugin.ts:283那个catch—— 它把"没有 automation 引擎导致 approval 节点没注册"记成info，而 dev 默认日志级别是warn，也就是真的降级发生时你反而看不见。这个 catch 至少该是warn。复现
rm -rf examples/app-showcase/.objectstack && pnpm dev想看时序：
objectstack dev --seed-admin --log-level info，对比WARN Flow '...'与ApprovalsServicePlugin: service registered的时间戳。