exception-handlinglisted

# Exception Handling 异常与失败处理 ## 目的与边界 为范围内每个功能定义可能出错之处与系统如何响应：可判定的触发条件、系统行为（拦截 / 降级 / 回滚 / 阻断）、带边界的恢复路径（重试 / 手动 / 自动 / 终止），以及面向用户的中文提示。每条 `EX-XXX` 行必须能被下游 `acceptance-criteria`（AC-XXX）作为可验证的失败用例消费。 **不得** 重新定义校验规则（→ `validation-rules`）、领域业务规则（→ `business-rules`）、状态转移（→ `state-machine`）、UI 呈现或交互反馈（→ `interaction-rules`）、可测的验收用例（→ `acceptance-criteria`），或实现级错误处理（try-catch、���常类型、超时毫秒数、消息队列、幂等键）。 ## 输入与输出 输入：按功能组织的 `feature-list.md`（FEA-XXX），含已确认的��态（`state-machine`）、业务拒绝分支（`business-rules`）、校验拒绝（`validation-rules`）、外部依赖清单与已确认的失败来源。输出：独立的 `exception-handling.md`，使用 `src/templates/resolver.py exception-handling.md` 解析出的模板。 分析前加载 `references/thinking-framework.md`（其引用 `src/framework/thinking-core.md` §1 强制透镜）。Draft 前加载 `references/output-contract.md`。交接前加载 `references/audit-checklist.md` 与 `references/reviewer-checklist.md`。Review 前运行 `scripts/validate_artifact.py <artifact> --json`。当失败来源稀疏时加载 `references/question-patterns.md`（主动向业务方采集失败场景）。 ## 思考提示（按阶段） ### 1. Preflight - "范围内有哪些 FEA-XXX？每个功能的风险密度如何（金钱、库存、数据、外部依赖）？" - 确认上游失败来源（state-machine、business-rules、validation-rules）存在，并识别失败来源负责人。 - **若不存在任何功能区块或已确认的失败来源**，返回 routing receipt 并 STOP——不要进入 Intake。 - 评估成熟度：L0（无失败信息）→ L1（单一稀疏失败提及）→ L2（部分失败分支）→ L3（充分明确）→ L4（上游已确认）。 ### 2. Intake - "对这个 FEA，上游实际说了什么会失败——而不是我认为可能失败什么？" - 先逐字提取失败声明再解读。将每条归类为 `FACT`、`DECISION`、`ASSUMPTION`、`AI_INFERENCE`、`UNKNOWN` 或 `CONFLICT`。 - 用 SRC-ID 登记来源。绝不从沉默中发明失败场景；缺失的失败分支是 `UNKNOWN`，而非不存在。 ### 3. Think (apply thinking-core.md §1 mandatory lenses +