state-machinelisted

# State Machine · 状态变化 ## 目的与边界 枚举范围内每个实体的每个合法状态，并为每个 状态 × 事件 组合定义目标状态及其守卫条件与副作用。转移表是生命周期行为的权威来源——而非流程图。 **不得** 设计展示状态的 UI（→ `interaction-rules` `IX-XXX`）、定义数据库 schema 或字段存储（→ `validation-rules` / 实现）、编写实现代码，或重复异常/恢复文案（→ `exception-handling`）。 ## 输入与输出 **输入**: 门控转移的已确认 `business-rules.md`（`BR-XXX`）、已确认的 `functional-flow.md` 流程，以及已确认的 `feature-list.md` 功能清单。**输出**: 独立的 `state-machine.md`，使用 `src/templates/resolver.py state-machine.md` 解析出的模板。 分析前加载 `references/thinking-framework.md`（其引用 `src/framework/thinking-core.md` §1 强制透镜 + §2 检查透镜）。Draft 前加载 `references/output-contract.md`。交接前加载 `references/audit-checklist.md` 与 `references/reviewer-checklist.md`。Review 前运行 `scripts/validate_artifact.py <artifact> --json`。 ## 思考提示（按阶段） ### 1. Preflight - "范围内哪些实体承载多个状态？门控它们的 BR-XXX 已确认吗？" - 枚举有状态实体及门控其转移的已确认 BR 规则。建模前，把任何没有门控 BR 的有状态 P0 实体标出来。 - **若不存在任何有状态实体或门控规则**，返回 routing receipt 并 STOP——不要进入 Intake。 ### 2. Intake - "已确认的故事/流程对生命周期实际说了什么——而不是我想象的流程？" - 列出来源提到的每个状态、暗示的每个事件、陈述的每条约束。按 `src/framework/contracts.md` 为每条标记 `FACT` / `DECISION` / `AI_INFERENCE` / `UNKNOWN` / `CONFLICT`。在每个候选上保留 BR-XXX / FEA-XXX 来源。 ### 3. Think (apply thinking-core.md §1 mandatory lenses) - **First Principles**: "哪些状态是真正独立存在的业务条件？哪些"状态"只是 UI 视图？" - **Systems Thinking**: "哪些其他实体、字段或流程会响应这次转移？什么不能被破坏？" - **Role Perspective**: "谁触发每个事件？谁���可以？副作用会通知谁？" - **Constraint Analysis**: "哪些 BR 规则门控每条转移？适用哪些硬约束（合规、时序）？" - **Adversarial**: "重复事件、回滚尝试、超时或并发触发时会发生什么？是否有被禁止的转移被静默跳过？" - **Reverse Validation**: "从每个