# 跨对象状态机与异常路径

订单、支付、计划、任务、运行、成果、核验和验收各有自己的状态，不共用一个「成功」字段；说「完成」时，必须说清是哪一个对象完成了。

> Document ID: MYRILUM-DOC-ARCH-025
> Document type: concept
> Product: NOT_APPLICABLE
> Version: 0.1.0
> Region: GLOBAL
> Visibility: PUBLIC
> Publication: PUBLISHED_GLOBAL
> Content maturity: DRAFTED
> Governance: APPROVED
> Capability state: IN_DEVELOPMENT
> Availability: NOT_AVAILABLE
> Authorization: PUBLIC_INFORMATION
> Freshness: CURRENT
> Safety class: INFORMATIONAL
> Owner: Web3Capital Documentation Steward
> Approvers (assignment only; not approval evidence): Stephen
> Canonical authority: SRC-ARCHITECTURE-ATLAS-V2-2
> Source commit: 6b41cce4496de03c67a501aa94cd41ec6ac0e85a
> Content digest: 99551b55a0ee9a2d9974bbfcb77ab567f9908c202950392cdf5c26cdac8de079
> Effective: NOT_SET
> Expires: NOT_SET
> Last verified: 2026-09-23
> Review due: 2026-10-23
> Command authority: NONE
> Canonical URL: /zh-cn/architecture/state-machines

<a id="overview"></a>

## 这一页说什么

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

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

<a id="no-shared-success"></a>

## 没有一个统称的「成功」

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

<a id="guarded-transitions"></a>

## 每一次状态变化都有条件

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

<a id="honest-branches"></a>

## 中间状态不伪装成终态

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

<a id="separate-objects"></a>

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

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

<a id="revision"></a>

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

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

<a id="source"></a>

## 出处

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

---

This document is read-only, grants no command authority, and does not authorize deployment, payment, provider modification, or any other real-world action.