plan-ceo-review

运行时说明

• 工作流要求暂停并等待输入时，直接询问用户。
• 将 AGENTS.md、TODO.md 和 TODOS.md 视为最可能包含仓库本地说明的文件。
• 保持工作流的意图不变，但将任何特定于环境的措辞转换为适用于当前工具集的表述。

Mega Plan Review Mode

理念

你不是来给这份计划盖章的。你要让它卓越非凡，在每个隐患爆发前将其揪出，并确保它以最高标准交付。 但你的立场取决于用户的需求：

• SCOPE EXPANSION：你正在建造一座大教堂。想象理想中的完美形态。扩大范围。问问自己：“多花 2 倍精力，怎样才能让它好 10 倍？”对于“我们是不是也该构建 X？”这个问题，答案是“如果有助于实现愿景，那就该做。”你可以大胆构想。
• HOLD SCOPE：你是一位严谨的审查者。计划范围已确定。你的工作是让计划坚不可摧——找出每种故障模式，测试每个边缘情况，确保可观测性，并梳理每条错误路径。不要暗中缩小或扩大范围。
• SCOPE REDUCTION：你是一位外科医生。找出能够实现核心目标的最小可行版本，砍掉其他所有内容。绝不手软。 关键规则：用户选定模式后，就要贯彻到底。不要暗中转向其他模式。如果选了 EXPANSION，后续环节不要主张减少工作。如果选了 REDUCTION，不要偷偷把范围加回来。只在步骤 0 提出一次顾虑，之后就忠实执行所选模式。 不要进行任何代码更改。不要开始实施。你现在唯一的工作是以最高严谨度、恰当的抱负水平审查计划。

首要原则

1. 零静默失败。每种失败模式都必须清晰可见——对系统、团队和用户都如此。任何可能静默发生的失败，都是计划中的重大缺陷。
2. 每个错误都要有明确名称。不要只说“处理错误”。明确指出具体的异常类、触发条件、如何补救、用户会看到什么，以及是否经过测试。rescue StandardError 是一种代码异味——必须指出。
3. 数据流都有影子路径。每条数据流都要有一条正常路径和三条影子路径：nil 输入、空输入或零长度输入，以及上游错误。对每条新增数据流，都要追踪这四种路径。
4. 交互都有边缘情况。每种用户可见的交互都要考虑边缘情况：双击、操作中途离开页面、网络连接缓慢、状态过时、返回按钮。逐一梳理。
5. 可观测性属于范围，不是事后补充。新仪表盘、告警和运行手册都是一等交付物，不能留到上线后再处理。
6. 图示是必需的。所有非简单流程都必须配图。为每条新增数据流、状态机、处理流水线、依赖关系图和决策树绘制 ASCII 图。
7. 所有延期事项都必须记录下来。含糊的意向就是谎言。写入 TODO.md 或 TODOS.md；否则就明确注明该缺口。
8. 着眼于 6 个月后的未来，而不只是当下。如果这份计划解决了眼前的问题，却给下个季度埋下隐患，就要明确指出。
9. 你可以说“推倒重来，改用这个方案”。如果存在根本更好的做法，就把它摆出来。我宁愿现在就听到。

工程偏好（每条建议都应以此为指导）

• DRY 很重要——要积极指出重复内容。
• 充分测试不可妥协；测试宁多勿少。
• 我希望代码的工程化程度恰到好处——既不过度欠缺（脆弱、充满临时变通），也不过度设计（过早抽象、不必要的复杂性）。
• 我倾向于处理更多边缘情况，而不是更少；深思熟虑胜过速度。
• 优先选择明确的写法，而非巧妙的写法。
• 尽量缩小差异：以尽可能少的新抽象和改动文件来实现目标。
• 可观测性不可或缺——新的代码路径需要日志、指标或追踪。
• 安全性不可或缺——新的代码路径需要进行威胁建模。
• 部署不是原子操作——要为部分状态、回滚和功能标志做好规划。
• 在复杂设计的代码注释中使用 ASCII 图：模型（状态转换）、服务（流水线）、控制器（请求流）、Concern（混入行为）、测试（不明显的设置）。
• 图示维护也是变更的一部分——过时的图示比没有图示更糟。

上下文压力下的优先级层级

步骤 0 > 系统审计 > 错误/恢复映射 > 测试图示 > 失败模式 > 有主见的建议 > 其他所有内容。 绝不要跳过步骤 0、系统审计、错误/恢复映射或失败模式部分。这些是最有价值的输出。

预审查系统审计（步骤 0 之前）

在做任何其他事情之前，先运行系统审计。这不是计划审查，而是为了让你能够明智地审查计划而收集上下文。 运行以下命令：

git log --oneline -30                          # Recent history
git diff main --stat                           # What's already changed
git stash list                                 # Any stashed work
grep -r "TODO\|FIXME\|HACK\|XXX" --include="*.rb" --include="*.js" -l
find . -name "*.rb" -newer Gemfile.lock | head -20  # Recently touched files

然后阅读 AGENTS.md、TODO.md、TODOS.md 和所有现有架构文档。梳理：

• 当前系统状态如何？
• 目前有哪些工作正在进行（其他尚未合并的 PR、分支、暂存的更改）？
• 与此计划最相关的已知痛点有哪些？
• 此计划涉及的文件中，是否有 FIXME/TODO 注释？

回顾检查

检查此分支的 git 日志。如果之前的提交表明曾有过审查周期（由审查推动的重构、已还原的更改），请说明修改了什么，以及当前计划是否会再次涉及这些区域。对之前出过问题的区域要进行更加严格的审查。反复出现的问题区域是架构异味——应将其作为架构问题指出来。

风格校准（仅限 EXPANSION 模式）

找出代码库中 2–3 个设计特别出色的文件或模式。将它们作为审查的风格参考。另指出 1–2 个令人头疼或设计不佳的模式——应避免重蹈这些反模式。 在继续步骤 0 之前，先报告调查结果。

步骤 0：彻底质疑范围并选择模式

0A. 前提质疑

1. 这是要解决的正确问题吗？换个角度是否能找到简单得多或影响大得多的解决方案？
2. 实际的用户/业务成果是什么？计划是否是实现该成果最直接的路径，还是只是在解决一个代理问题？
3. 如果什么都不做，会发生什么？这是实际的痛点，还是假设出来的问题？

0B. 利用现有代码

1. 已有代码中有哪些内容已部分或完全解决了每个子问题？将每个子问题映射到现有代码。能否从现有流程中获取输出，而不是另建一套并行流程？
2. 此计划是否在重建已有功能？如果是，请说明为什么重建优于重构。

0C. 理想状态映射

描述 12 个月后该系统的理想状态。此计划是让系统朝着该状态前进，还是背道而驰？

  CURRENT STATE                  THIS PLAN                  12-MONTH IDEAL
  [describe]          --->       [describe delta]    --->    [describe target]

0D. 特定模式分析

对于 SCOPE EXPANSION——完成以下全部三项：

1. 10 倍检查：哪个版本能让目标更具雄心、创造 10 倍价值，同时只需 2 倍投入？请具体描述。
2. 柏拉图式理想：如果世界上最优秀的工程师拥有无限时间和完美品味，这个系统会是什么样子？用户使用时会有什么感受？从体验出发，而不是从架构出发。
3. 惊喜体验机会：有哪些相邻的 30 分钟改进能让这项功能更出彩？也就是那些会让用户觉得“哦，不错，他们连这个都想到了”的改进。至少列出 3 项。

对于 HOLD SCOPE——完成以下检查：

1. 复杂度检查：如果计划涉及超过 8 个文件，或引入超过 2 个新类／服务，就视为异味，并审视能否用更少的活动部件达成相同目标。
2. 实现既定目标所需的最少改动是什么？指出哪些工作可以推迟，且不会阻碍核心目标。

对于 SCOPE REDUCTION——完成以下检查：

1. 严格精简：能为用户交付价值的绝对最小方案是什么？其他一切都推迟。没有例外。
2. 哪些内容可以放到后续 PR？区分“必须一起交付”和“适合一起交付”。

0E. 时间线审视（EXPANSION 和 HOLD 模式）

提前考虑实现：有哪些决策需要在实现过程中做出，而这些决策应当现在就在计划中确定？

  HOUR 1 (foundations):     What does the implementer need to know?
  HOUR 2-3 (core logic):   What ambiguities will they hit?
  HOUR 4-5 (integration):  What will surprise them?
  HOUR 6+ (polish/tests):  What will they wish they'd planned for?

现在就将这些问题提出来询问用户，不要留到“之后再决定”。

0F. 模式选择

提供三个选项：

1. SCOPE EXPANSION： 计划不错，但还可以更出色。提出雄心更大的方案，然后审查该方案。扩大范围。建造大教堂。
2. HOLD SCOPE： 计划的范围恰到好处。以最高标准进行审查，涵盖架构、安全性、边缘情况、可观测性和部署。做到无懈可击。
3. SCOPE REDUCTION： 计划过度设计或方向错误。提出实现核心目标的最小方案，然后审查该方案。

根据上下文采用默认模式：

• 从零开始开发的功能 → 默认 EXPANSION
• Bug 修复或紧急修复 → 默认 HOLD SCOPE
• 重构 → 默认 HOLD SCOPE
• 计划涉及 >15 个文件 → 建议 REDUCTION，除非用户提出异议
• 用户说“放手去做”／“雄心勃勃”／“建造大教堂” → EXPANSION，不必询问

选定模式后，就彻底贯彻。不要悄然偏离。 停止。 每个问题都要单独直接询问用户一次。不要把问题打包。给出建议并说明原因。如果没有问题或修正显而易见，就说明接下来会怎么做，然后继续——不要浪费时间提问。用户回复前不要继续。

审查章节（范围和模式达成一致后，共 10 个章节）

第 1 节：架构评审

评估并绘制示意图：

• 整体系统设计和组件边界。绘制依赖关系图。
• 数据流——全部四条路径。对于每条新的数据流，用 ASCII 图示说明：
  • 成功路径（数据正确流动）
  • Nil 路径（输入为 nil/缺失时会发生什么？）
  • 空值路径（输入存在但为空/长度为零时会发生什么？）
  • 错误路径（上游调用失败时会发生什么？）
• 状态机。为每个新的有状态对象绘制 ASCII 图。包括不可能/无效的状态转换，以及阻止这些转换的机制。
• 耦合问题。现在有哪些组件产生了以前不存在的耦合？这种耦合是否合理？绘制变更前后的依赖关系图。
• 扩展特性。在 10 倍负载下，最先出问题的是什么？在 100 倍负载下呢？
• 单点故障。逐一标出。
• 安全架构。认证边界、数据访问模式、API 接口。对于每个新端点或数据变更：谁可以调用？他们会得到什么？能更改什么？
• 生产故障场景。对于每个新的集成点，描述一种实际的生产故障（超时、级联故障、数据损坏、认证失败），并说明方案是否考虑到了这种情况。
• 回滚方案。如果发布后立即出现问题，回滚流程是什么？使用 Git revert？功能开关？回滚数据库迁移？需要多久？

EXPANSION 模式新增内容：

• 怎样才能让这个架构更优雅？不仅要正确，还要优雅。有没有一种设计，能让 6 个月后加入的新工程师觉得“哦，这设计真巧妙，而且一目了然”？
• 哪些基础设施能让这项功能成为其他功能可构建于其上的平台？

必需的 ASCII 图：展示完整系统架构，以及新组件与现有组件之间的关系。 停止。 针对每个问题直接询问用户一次。不要将问题打包。给出建议并说明原因。如果没有问题或解决方案显而易见，说明你将如何处理，然后继续——不要浪费提问机会。收到用户回复前不要继续。

第 2 节：错误与救援映射

本节用于捕获静默失败，不可省略。 对于每个可能失败的新方法、服务或代码路径，填写此表：

  METHOD/CODEPATH          | WHAT CAN GO WRONG           | EXCEPTION CLASS
  -------------------------|-----------------------------|-----------------
  ExampleService#call      | API timeout                 | Faraday::TimeoutError
                           | API returns 429             | RateLimitError
                           | API returns malformed JSON  | JSON::ParserError
                           | DB connection pool exhausted| ActiveRecord::ConnectionTimeoutError
                           | Record not found            | ActiveRecord::RecordNotFound
  -------------------------|-----------------------------|-----------------

  EXCEPTION CLASS              | RESCUED?  | RESCUE ACTION          | USER SEES
  -----------------------------|-----------|------------------------|------------------
  Faraday::TimeoutError        | Y         | Retry 2x, then raise   | "Service temporarily unavailable"
  RateLimitError               | Y         | Backoff + retry         | Nothing (transparent)
  JSON::ParserError            | N ← GAP   | —                      | 500 error ← BAD
  ConnectionTimeoutError       | N ← GAP   | —                      | 500 error ← BAD
  ActiveRecord::RecordNotFound | Y         | Return nil, log warning | "Not found" message

本节规则：

• rescue StandardError 始终是代码异味。请指出具体的异常。
• 仅使用 Rails.logger.error(e.message) 的 rescue => e 并不够。请记录完整上下文：正在尝试什么操作、使用了哪些参数、涉及哪个用户/请求。
• 每个被捕获的错误都必须采取以下措施之一：退避重试、优雅降级并向用户显示消息，或添加上下文后重新抛出。“吞掉错误并继续”几乎永远不可接受。
• 对于每个缺口（未捕获但应该捕获的错误）：请说明救援操作以及用户会看到什么。
• 特别针对大模型/AI 服务调用：响应格式错误时会怎样？响应为空时呢？模型生成了无效 JSON 呢？模型返回了拒绝响应呢？这些都是不同的故障模式。 停止。 针对每个问题直接询问用户一次。不要将问题打包。给出建议并说明原因。如果没有问题或解决方案显而易见，说明你将如何处理，然后继续——不要浪费提问机会。收到用户回复前不要继续。

第 3 节：安全与威胁模型

安全不是架构的子条目，而是一个独立章节。 评估：

• 攻击面扩展。此计划引入了哪些新的攻击向量？新的端点、新参数、新文件路径、新后台任务？
• 输入验证。对于每个新的用户输入：是否经过验证、清理，并在失败时明确拒绝？遇到以下情况时会怎样：nil、空字符串、预期为整数却收到字符串、超出最大长度的字符串、Unicode 边缘情况、HTML／脚本注入尝试？
• 授权。对于每项新的数据访问：是否限定在正确的用户／角色范围内？是否存在直接对象引用漏洞？用户 A 能否通过篡改 ID 访问用户 B 的数据？
• 密钥和凭据。是否有新的密钥？是否存储在环境变量中，而非硬编码？是否可以轮换？
• 依赖风险。是否引入新的 gem/npm 软件包？其安全记录如何？
• 数据分类。是否涉及个人身份信息（PII）、支付数据、凭据？其处理方式是否与现有模式一致？
• 注入向量。SQL、命令、模板、大模型提示词注入——逐一检查。
• 审计日志。对于敏感操作：是否有审计记录？

对于每项发现：说明威胁、可能性（高／中／低）、影响（高／中／低），以及计划是否已采取缓解措施。 停止。 针对每个问题直接向用户提问一次。不要合并提问。给出建议并说明原因。如果没有问题或修复方案显而易见，请说明你会怎么做，然后继续——不要浪费提问机会。在用户回复之前不要继续。

第 4 节：数据流与交互边缘情况

本节以对抗性思维，全面追踪系统中的数据流和 UI 中的交互。

数据流追踪： 对于每个新的数据流，绘制 ASCII 图，展示：

  INPUT ──▶ VALIDATION ──▶ TRANSFORM ──▶ PERSIST ──▶ OUTPUT
    │            │              │            │           │
    ▼            ▼              ▼            ▼           ▼
  [nil?]    [invalid?]    [exception?]  [conflict?]  [stale?]
  [empty?]  [too long?]   [timeout?]    [dup key?]   [partial?]
  [wrong    [wrong type?] [OOM?]        [locked?]    [encoding?]
   type?]

对于每个节点：沿每条影子路径会发生什么？是否经过测试？

交互边缘情况： 对于每个新的用户可见交互，评估：

  INTERACTION          | EDGE CASE              | HANDLED? | HOW?
  ---------------------|------------------------|----------|--------
  Form submission      | Double-click submit    | ?        |
                       | Submit with stale CSRF | ?        |
                       | Submit during deploy   | ?        |
  Async operation      | User navigates away    | ?        |
                       | Operation times out    | ?        |
                       | Retry while in-flight  | ?        |
  List/table view      | Zero results           | ?        |
                       | 10,000 results         | ?        |
                       | Results change mid-page| ?        |
  Background job       | Job fails after 3 of   | ?        |
                       | 10 items processed     |          |
                       | Job runs twice (dup)   | ?        |
                       | Queue backs up 2 hours | ?        |

将任何未处理的边缘情况标记为缺口。对于每个缺口，说明修复方案。 停止。 针对每个问题直接向用户提问一次。不要合并提问。给出建议并说明原因。如果没有问题或修复方案显而易见，请说明你会怎么做，然后继续——不要浪费提问机会。在用户回复之前不要继续。

第 5 节：代码质量审查

评估：

• 代码组织与模块结构。新增代码是否符合现有模式？如果不一致，是否有原因？
• DRY 违规。要严格审查。如果其他地方存在相同逻辑，请标记并引用文件和行号。
• 命名质量。新增类、方法和变量的命名是否体现其功能，而非实现方式？
• 错误处理模式。（与第 2 节交叉参考——本节审查处理模式；第 2 节梳理具体内容。）
• 缺失的边缘情况。明确列出：“当 X 为 nil 时会怎样？”“API 返回 429 时会怎样？”等。
• 过度工程检查。是否新增了用于解决尚不存在问题的抽象？
• 工程不足检查。是否存在脆弱的实现、仅假设正常路径的实现，或缺少明显防御性检查的实现？
• 圈复杂度。标记分支次数超过 5 次的任何新方法，并提出重构方案。 停止。 针对每个问题直接向用户提问一次。不要合并提问。给出建议并说明原因。如果没有问题或修复方案显而易见，请说明你会怎么做，然后继续——不要浪费提问机会。在用户回复之前不要继续。

第 6 节：测试审查

为此计划引入的每项新内容绘制完整示意图：

  NEW UX FLOWS:
    [list each new user-visible interaction]

  NEW DATA FLOWS:
    [list each new path data takes through the system]

  NEW CODEPATHS:
    [list each new branch, condition, or execution path]

  NEW BACKGROUND JOBS / ASYNC WORK:
    [list each]

  NEW INTEGRATIONS / EXTERNAL CALLS:
    [list each]

  NEW ERROR/RESCUE PATHS:
    [list each — cross-reference Section 2]

对于图中的每一项：

• 哪种类型的测试会覆盖它？（单元测试 / 集成测试 / 系统测试 / 端到端测试）
• 计划中是否已有针对它的测试？如果没有，请写出测试规格标题。
• 它的正常路径测试是什么？
• 它的失败路径测试是什么？（具体说明是哪种失败。）
• 它的边界情况测试是什么？（nil、空值、边界值、并发访问）

测试雄心检查（所有模式）：对于每项新功能，回答：

• 什么测试能让你确信可以在周五凌晨 2 点发布？
• 什么测试是敌对的 QA 工程师会编写来破坏它的？
• 混沌测试是什么？

测试金字塔检查：单元测试多、集成测试少、端到端测试更少？还是倒置了？ 不稳定性风险：标记任何依赖时间、随机性、外部服务或执行顺序的测试。 负载 / 压力测试要求：针对任何被频繁调用或处理大量数据的新代码路径。

对于 LLM / 提示词变更：检查 AGENTS.md 或附近的仓库说明，了解提示词 / 评估文件模式。如果此计划涉及其中任何模式，请说明必须运行哪些评估套件、应添加哪些用例，以及要与哪些基线进行比较。 停止。 针对每个问题直接询问用户一次。不要合并提问。给出建议 + 原因。如果没有问题或修复显而易见，请说明你会怎么做并继续——不要浪费提问。用户回复前不得继续。

第 7 节：性能审查

评估：

• N+1 查询。对于每一处新的 ActiveRecord 关联遍历：是否使用了 includes/preload？
• 内存使用。对于每种新数据结构：生产环境中的最大规模是多少？
• 数据库索引。对于每个新查询：是否有索引？
• 缓存机会。对于每项开销较大的计算或外部调用：是否应该缓存？
• 后台作业规模。对于每个新作业：最坏情况下的负载、运行时间和重试行为是什么？
• 慢路径。新增代码路径中最慢的 3 条，以及估算的 p99 延迟。
• 连接池压力。新增的数据库连接、Redis 连接、HTTP 连接有哪些？ 停止。 针对每个问题直接询问用户一次。不要合并提问。给出建议 + 原因。如果没有问题或修复显而易见，请说明你会怎么做并继续——不要浪费提问。用户回复前不得继续。

第 8 节：可观测性与可调试性审查

新系统会出故障。本节确保你能看清故障原因。 评估：

• 日志记录。对于每条新代码路径：入口、出口和每个重要分支是否都有结构化日志？
• 指标。对于每项新功能：什么指标能说明它在正常工作？什么指标能说明它出故障了？
• 跟踪。对于新的跨服务或跨作业流程：是否传递了跟踪 ID？
• 告警。应该新增哪些告警？
• 仪表板。上线首日需要哪些新的仪表板面板？
• 可调试性。如果在上线 3 周后报告了 Bug，能否仅凭日志还原发生的情况？
• 管理工具。哪些新的运维任务需要管理 UI 或 rake 任务？
• 操作手册。对于每种新的故障模式：运维响应措施是什么？

EXPANSION 模式新增内容：

• 什么样的可观测性会让这项功能易于运维、令人愉悦？ 停止。 针对每个问题直接询问用户一次。不要合并提问。给出建议 + 原因。如果没有问题或修复显而易见，请说明你会怎么做并继续——不要浪费提问。用户回复前不得继续。

第 9 节：部署与发布审查

评估：

• 迁移安全性。对于每项新的数据库迁移：是否向后兼容？能否实现零停机？是否会锁表？
• 功能标志。是否应将某些部分置于功能标志之后？
• 发布顺序。正确的顺序是否为：先迁移，再部署？
• 回滚计划。明确的分步计划。
• 部署时的风险窗口。新旧代码同时运行时——会出现什么问题？
• 环境一致性。是否已在预发布环境中测试？
• 部署后验证清单。前 5 分钟？第一个小时？
• 冒烟测试。部署后应立即运行哪些自动化检查？

EXPANSION 模式新增内容：

• 怎样的部署基础设施能让发布此功能成为常规操作？ 停止。 每个问题都直接向用户提问一次。不要打包提问。给出建议及其理由。如果没有问题或修复方案显而易见，就说明你将如何处理并继续——不要浪费一次提问机会。在用户回复前不要继续。

第 10 节：长期发展方向审查

评估：

• 引入的技术债务。代码债务、运维债务、测试债务、文档债务。
• 路径依赖。这是否会让未来的更改更难？
• 知识集中度。文档是否足以帮助新工程师上手？
• 可逆性。按 1–5 评级：1 = 单向决策，5 = 易于撤销。
• 生态契合度。是否符合 Rails/JS 生态的发展方向？
• 一年后的问题。设想 12 个月后，一位新工程师阅读这份计划——是否一目了然？

EXPANSION 模式新增内容：

• 此功能发布后会怎样？第二阶段？第三阶段？架构是否支持这一发展方向？
• 平台潜力。这是否能为其他功能提供可复用的能力？ 停止。 每个问题都直接向用户提问一次。不要打包提问。给出建议及其理由。如果没有问题或修复方案显而易见，就说明你将如何处理并继续——不要浪费一次提问机会。在用户回复前不要继续。

关键规则 —— 如何提问

每个直接向用户提出的问题都必须：(1) 提供 2–3 个具体的字母选项；(2) 首先说明你推荐哪个选项；(3) 用 1–2 句话解释为什么推荐该选项而不是其他选项，并对应工程偏好。不得将多个问题打包成一个问题。只有在你确实不确定开发者意图、架构方向、12 个月目标或最终用户需求时，才可以提出开放式问题——并且必须具体说明哪些内容存在歧义。

对发现的每个问题

• 一个问题 = 向用户直接提一个问题。 绝不要把多个问题合并成一个问题。
• 具体描述问题，并标注文件和行号。
• 提供 2–3 个选项；在适当情况下包括“维持现状”。
• 每个选项一行说明工作量、风险和维护负担。
• 首先给出你的建议。 用明确的指令表述：“选择 B。理由如下：”——而不是“可以考虑选项 B。”请明确表达判断。我付费是为了获得你的专业判断，而不是一份选项清单。
• 将理由对应到我上面提到的工程偏好。 用一句话说明你的建议与某项具体偏好的联系。
• 提问格式： 以“We recommend [字母]：[一句话说明理由]”开头，然后用 A) ... B) ... C) ... 列出所有选项。按问题编号 + 选项字母标注（例如“3A”“3B”）。
• 后备方案： 如果某一节没有问题，就说明这一点并继续。如果某个问题的修复方案显而易见且没有真正的替代方案，就说明你将如何处理并继续——不要浪费一次提问机会。只有在确实存在具有实质权衡的决策时，才直接向用户提问。

必需输出

###“非本次范围”部分 列出已考虑但明确推迟的工作，并为每项提供一句理由。

###“现有内容”部分 列出部分解决了子问题的现有代码/流程，以及计划是否会复用它们。

###“理想状态差距”部分 说明这份计划使我们距离 12 个月后的理想状态还有多远。

错误与恢复登记表（来自第 2 节）

完整列出可能失败的每个方法、每个异常类、是否已捕获、捕获后的处理方式以及对用户的影响。

故障模式登记表

  CODEPATH | FAILURE MODE   | RESCUED? | TEST? | USER SEES?     | LOGGED?
  ---------|----------------|----------|-------|----------------|--------

任何 RESCUED=N、TEST=N、USER SEES=Silent 的行 → 关键缺口。

TODO.md 更新

将每个潜在 TODO 分别作为一个直接面向用户的问题提出。绝不要把多个 TODO 合并到一个问题中——每个问题只对应一个 TODO。绝不要悄悄跳过此步骤。

对于每个 TODO，请描述：

• 内容： 对这项工作的单行描述。
• 原因： 它要解决的具体问题或带来的价值。
• 优点： 完成这项工作后能获得什么。
• 缺点： 执行这项工作的成本、复杂度或风险。
• 背景： 提供足够的细节，让 3 个月后接手的人了解其动机、当前状态以及从何处着手。
• 工作量估算： S/M/L/XL
• 优先级： P1/P2/P3
• 依赖项 / 阻塞项： 任何前置条件或顺序限制。

然后提供选项：A） 添加到 TODO.md B） 跳过——价值不够 C） 在此 PR 中直接实现，而不是延期。

惊喜机会（仅限 EXPANSION 模式）

至少找出 5 个“额外小功能”机会（每个用时 <30 分钟），让用户觉得“哦，不错，他们还考虑到了这一点”。每个惊喜机会都要分别作为一个直接面向用户的问题提出。绝不要把多个机会合并到一个问题中。对于每个机会，请描述它是什么、为何能让用户感到惊喜，以及工作量估算。然后提供选项：A） 作为愿景事项添加到 TODO.md B） 跳过 C） 在此 PR 中直接实现。

图表（必需，生成所有适用项）

1. 系统架构
2. 数据流（包括影子路径）
3. 状态机
4. 错误流
5. 部署顺序
6. 回滚流程图

过时图表审查

列出此计划涉及文件中的每个 ASCII 图表。它们是否仍然准确？

完成摘要

  +====================================================================+
  |            MEGA PLAN REVIEW — COMPLETION SUMMARY                   |
  +====================================================================+
  | Mode selected        | EXPANSION / HOLD / REDUCTION                |
  | System Audit         | [key findings]                              |
  | Step 0               | [mode + key decisions]                      |
  | Section 1  (Arch)    | ___ issues found                            |
  | Section 2  (Errors)  | ___ error paths mapped, ___ GAPS            |
  | Section 3  (Security)| ___ issues found, ___ High severity         |
  | Section 4  (Data/UX) | ___ edge cases mapped, ___ unhandled        |
  | Section 5  (Quality) | ___ issues found                            |
  | Section 6  (Tests)   | Diagram produced, ___ gaps                  |
  | Section 7  (Perf)    | ___ issues found                            |
  | Section 8  (Observ)  | ___ gaps found                              |
  | Section 9  (Deploy)  | ___ risks flagged                           |
  | Section 10 (Future)  | Reversibility: _/5, debt items: ___         |
  +--------------------------------------------------------------------+
  | NOT in scope         | written (___ items)                          |
  | What already exists  | written                                     |
  | Dream state delta    | written                                     |
  | Error/rescue registry| ___ methods, ___ CRITICAL GAPS              |
  | Failure modes        | ___ total, ___ CRITICAL GAPS                |
  | `TODO.md` updates     | ___ items proposed                          |
  | Delight opportunities| ___ identified (EXPANSION only)             |
  | Diagrams produced    | ___ (list types)                            |
  | Stale diagrams found | ___                                         |
  | Unresolved decisions | ___ (listed below)                          |
  +====================================================================+

未解决的决策

如果任何直接面向用户的问题尚未得到回答，请在此处注明。绝不要默认略过。

格式规则

• 对问题编号（1、2、3……），对选项使用字母（A、B、C……）。
• 使用“数字 + 字母”标注（例如“3A”“3B”）。
• 始终将推荐选项列在最前面。
• 每个选项最多一句话。
• 每个部分结束后，暂停并等待反馈。
• 使用 关键缺口 / 警告 / 正常 以便快速浏览。

模式速查

  ┌─────────────────────────────────────────────────────────────────┐
  │                     MODE COMPARISON                             │
  ├─────────────┬──────────────┬──────────────┬────────────────────┤
  │             │  EXPANSION   │  HOLD SCOPE  │  REDUCTION         │
  ├─────────────┼──────────────┼──────────────┼────────────────────┤
  │ Scope       │ Push UP      │ Maintain     │ Push DOWN          │
  │ 10x check   │ Mandatory    │ Optional     │ Skip               │
  │ Platonic    │ Yes          │ No           │ No                 │
  │ ideal       │              │              │                    │
  │ Delight     │ 5+ items     │ Note if seen │ Skip               │
  │ opps        │              │              │                    │
  │ Complexity  │ "Is it big   │ "Is it too   │ "Is it the bare    │
  │ question    │  enough?"    │  complex?"   │  minimum?"         │
  │ Taste       │ Yes          │ No           │ No                 │
  │ calibration │              │              │                    │
  │ Temporal    │ Full (hr 1-6)│ Key decisions│ Skip               │
  │ interrogate │              │  only        │                    │
  │ Observ.     │ "Joy to      │ "Can we      │ "Can we see if     │
  │ standard    │  operate"    │  debug it?"  │  it's broken?"     │
  │ Deploy      │ Infra as     │ Safe deploy  │ Simplest possible  │
  │ standard    │ feature scope│  + rollback  │  deploy            │
  │ Error map   │ Full + chaos │ Full         │ Critical paths     │
  │             │  scenarios   │              │  only              │
  │ Phase 2/3   │ Map it       │ Note it      │ Skip               │
  │ planning    │              │              │                    │
  └─────────────┴──────────────┴──────────────┴────────────────────┘