总装：一个全自动系统

四个闭环怎样接起来

前四课各自完整，可在工厂里它们碰的是同一批对象。接起来的第一步，是写清楚每个闭环读什么、写什么。

按单写手规则，每个可改的属性只有一个写手。workOrder.status 由人下达、由质量闭环暂停，订单闭环不去碰它；否则「暂停、下达、再暂停」会来回打架。一张订单从确认到发运，事件这样接力：

「到货再检查一次」需要第二个入口：它监听 material，复用同一套 Action，不复制逻辑。同一件事有两个入口时，写两个工作流，共用 Action。

链式、冷却与配额

• 每条变化只触发一次，工作流自己写出的变化不会回头触发自己；写出的数据可以再触发别的工作流，最多 3 层。
• 冷却按对象（主键）算：同一个对象两次运行至少隔这么久，冷却期内的变化只推进游标。
• 配额按应用算：四个闭环若有六个工作流应用，就有六份计算分钟和通知额度。一条通知发给多人、多个通道，仍只占一条额度。计算分钟用完后，数据变化与定时停止，下月恢复；期间错过的变化不补跑。通知额度每天重置。

设计时要数层数：从一次数据变化出发，画出每个工作流写了什么、谁在监听它，链不能超过 3 层。超过了，就合并步骤，或者把中间那一步改成人。靠 3 层上限截断两个互相监听的工作流，是事故，不是设计。

运行手册：卡住了先查什么

1. 有没有运行？

   没有：应用是不是「已上线」，when 为不为真，是不是在冷却里，本月计算分钟是不是用完，是不是它自己的写入。

2. 运行失败或中断？

   看每一步的输出。心跳超过 5 分钟未更新时，运行状态为 failed，错误信息提示「运行被中断」，可以重跑。运行记录保留 180 天。

3. 运行成功，对象没变？

   先核对运行状态和通道，再看是否为预演，以及写入步骤是否被 when 跳过。提交条件失败会使对应步骤和运行失败。最后查改动历史。

4. 对象的值不对？

   看 overridden（语义层盖住了数据源的值）、sourceGone（数据源里已没有这一行，别据此行动）和 rev。

5. 数据没来？

   看数据绑定的状态和落后几批，再看发布端是否在线、是否「连不上数据源」。

aidc semantic automate runs order-release --limit 20
aidc semantic automate status order-release <运行 id>
aidc app usage order-release
aidc semantic object workOrder WO-2609-031
aidc semantic edits-history workOrder --pk WO-2609-031
aidc semantic datasource list
aidc semantic streams status erp-orders

失败模式与紧急停止

• 悄悄变旧：数据不来，就没有变化可触发。对策是自动化⑥的看门狗，按 hoursSince 判断，每小时一次会收到高频告警，那是有意为之的代价。
• 风暴：一次盘点改了几十个对象。change.input 留空的工作流，同一批变化只开一次运行；写入类的要靠冷却和汇总，别让每个对象各发一封邮件。

先说没有的：目前还没有一键暂停全部自动化的总开关，也没有按组织的总闸。真正存在的停止办法有三个：

还有两个办法不在这三张卡里。让提供方应用发布一个不再登记那个 Action 的版本，工作流跑到写入步骤就会失败。或者自己设计一个软开关对象，每个工作流第一步读它；那是你的设计，不是平台功能，见无人值守的治理那一课。

aidc app rollback order-release --version 1.0.0 --notes "紧急停用：回到只有手动触发的版本"
aidc app status order-release
aidc semantic datasource remove <对象类型> --stream <流>
aidc semantic streams revoke erp-orders --prefix aidc-pk-…