跨对象状态机与异常路径

这一页说什么

这是 MYRILUM 的目标架构设计，不代表图中各项都已上线；某项能力现在能不能用，以《当前可用情况》为准。

一条业务链上的「成功」不能一概而论。本页只讲原则，实现细节不公开。

没有一个统称的「成功」

一条业务链上有多个对象，每个都有自己的状态。支付成功不代表成果合格，任务完成不代表用户已验收。界面和记录都要说明是哪一个对象到了哪一步。

每一次状态变化都有条件

状态只能由命令推动：先检查条件，再检查并发版本，然后正式提交并产生事件。计划要批准一个确定的版本才能执行；关键内容一变，就成了新版本，需要时重新批准。

中间状态不伪装成终态

等资料、等人工、暂停、外部结果不明、取消处理中，都是明确的中间状态，要能看到缺什么、下一步由谁负责。外部结果不明时先去查原来那次操作，不盲目再做一遍；恢复之前重新核对权限——能恢复不等于可以自动重做。

成果、核验、验收、支付是四个对象

成果提交后内容固定；核验写明用了什么方法、支持到什么范围、有哪些限制；验收由有权用户针对某一个成果版本作出；支付与结算依据资金回执和合同，不从成果状态去推断。它们通过规则事件相互关联，而不是共用一个状态字段。

修订产生新版本，历史不改写

修订会产生新的成果、计划或执行版本。已经验收的历史不会被悄悄改写。

出处

本页依据《MYRILUM 全架构图谱》v2.2 的 A25。按公开边界，这一页只公开原则，不放图。相关：《目标交付与合作操作系统》、《智能体运行时与故障恢复》、《命令、事件与一致性》。