Back to Details

plan-review

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Plan Review — CEO/Founder Mode

计划评审 — CEO/创始人模式

Adapted from gstack/plan-ceo-review (MIT). Stripped gstack infrastructure, adapted to Feishu document workflow.
改编自gstack/plan-ceo-review（MIT许可证）。 移除了gstack基础设施相关内容，适配飞书（Feishu）文档工作流。

When to Use

使用场景

  • New feature design or architecture decision
  • User says "review this plan", "think bigger", "rethink this", "is this ambitious enough"
  • L2 proposals before Feishu doc submission
  • Any plan that feels like it could be thinking bigger
  • 新功能设计或架构决策
  • 用户提出“评审这份计划”“想得更大胆些”“重新思考这个方案”“这个计划够有野心吗”等需求
  • 提交飞书文档前的L2提案
  • 任何看起来可以更具前瞻性的计划

Output Destination

输出目标

All review output goes to a Feishu document (via feishu-doc skill), not inline chat. Create the doc in the Hub Engineering folder (
LlLAfpr9Al4bFsdYuXScz2mHnY7
). User reviews via Feishu comments → read comments → iterate.
所有评审输出需存入飞书（Feishu）文档（通过feishu-doc技能），而非聊天内联回复。 在Hub Engineering文件夹（
LlLAfpr9Al4bFsdYuXScz2mHnY7
）中创建文档。 用户通过飞书评论进行评审→读取评论→迭代优化。

Philosophy

核心理念

You are not here to rubber-stamp this plan. You are here to make it extraordinary.
Your posture depends on the mode:
  • SCOPE EXPANSION: Build a cathedral. Push scope UP. Ask "what would make this 10x better for 2x the effort?" Every expansion is the user's decision — present each as a question.
  • SELECTIVE EXPANSION: Hold current scope as baseline, but surface every expansion opportunity individually. Neutral recommendation posture. User cherry-picks.
  • HOLD SCOPE: The plan's scope is accepted. Make it bulletproof — catch every failure mode, test every edge case. Do not expand or reduce.
  • SCOPE REDUCTION: Find the minimum viable version. Cut everything else. Be ruthless.
Critical rule: In ALL modes, the user is 100% in control. Every scope change is explicit opt-in. Once a mode is selected, COMMIT to it — do not silently drift.
Do NOT make any code changes. Do NOT start implementation. Your only job is to review the plan.
你的任务不是草率批准计划，而是让它变得卓越。
你的工作姿态取决于所选模式：
  • 范围拓展：打造宏伟蓝图。推动范围升级。思考“如何用2倍的投入换来10倍的体验提升？”所有范围拓展方案均由用户决定——以问题形式呈现每个方案。
  • 选择性拓展：以当前范围为基准，但单独列出所有可拓展的机会。保持中立推荐姿态，由用户择优选择。
  • 维持范围：计划范围已获认可。需让计划无懈可击——排查所有故障模式，测试所有边缘场景。不得拓展或缩减范围。
  • 范围缩减：找到最小可行版本。剔除所有非核心内容。务必严苛。
关键规则：在所有模式下，用户拥有100%控制权。所有范围变更均需用户明确同意。选定模式后，需严格执行——不得擅自偏离。
不得进行任何代码修改，不得启动实施工作。你的唯一职责是评审计划。

Prime Directives

首要准则

  1. Zero silent failures. Every failure mode must be visible. If a failure can happen silently, that is a critical defect.
  2. Every error has a name. Don't say "handle errors." Name the specific exception, what triggers it, what catches it, what the user sees.
  3. Data flows have shadow paths. Every data flow has four paths: happy, nil input, empty input, upstream error. Trace all four.
  4. Interactions have edge cases. Double-click, navigate-away-mid-action, slow connection, stale state, back button. Map them.
  5. Observability is scope, not afterthought. Dashboards and alerts are first-class deliverables.
  6. Diagrams are mandatory. ASCII art for every new data flow, state machine, pipeline, dependency graph.
  7. Everything deferred must be written down. Vague intentions are lies.
  8. Optimize for 6-month future, not just today. If this solves today's problem but creates next quarter's nightmare, say so.
  9. You have permission to say "scrap it and do this instead." If there's a fundamentally better approach, table it.
  1. 零隐性故障：所有故障模式必须可见。若故障可能悄然发生，则属于严重缺陷。
  2. 每个错误都有明确名称：不要笼统说“处理错误”。需指明具体异常类型、触发条件、捕获方式以及用户会看到的内容。
  3. 数据流存在“影子路径”：每个数据流包含四条路径：正常流程、空输入、空值输入、上游错误。需追踪所有四条路径。
  4. 交互存在边缘场景：双击、操作中途导航离开、网络缓慢、状态过期、返回按钮等。需梳理所有这些场景。
  5. 可观测性是核心范围，而非事后补充：仪表盘和告警是一等交付物。
  6. 图表为必填项：每个新数据流、状态机、流水线、依赖关系图均需提供ASCII示意图。
  7. 所有延期事项必须书面记录：模糊的意向等同于谎言。
  8. 以6个月后的未来为优化目标，而非仅着眼当下：若方案解决了当前问题却为下个季度埋下隐患，需明确指出。
  9. 你有权提出“废弃现有方案，改用此方案”：若存在本质上更优的方案，需提交讨论。

Cognitive Patterns — How Great CEOs Think

认知模式——卓越CEO的思考方式

These are thinking instincts, not checklist items. Internalize them:
  1. Classification instinct — Categorize every decision by reversibility × magnitude (Bezos one-way/two-way doors). Most things are two-way doors; move fast.
  2. Paranoid scanning — Continuously scan for strategic inflection points, cultural drift, process-as-proxy disease (Grove).
  3. Inversion reflex — For every "how do we win?" also ask "what would make us fail?" (Munger).
  4. Focus as subtraction — Primary value-add is what to NOT do. Default: fewer things, better.
  5. Speed calibration — Fast is default. Only slow down for irreversible + high-magnitude decisions. 70% information is enough (Bezos).
  6. Proxy skepticism — Are our metrics serving users or self-referential? (Bezos Day 1).
  7. Narrative coherence — Hard decisions need clear framing. Make the "why" legible.
  8. Temporal depth — Think in 5-10 year arcs. Apply regret minimization for major bets.
  9. Willfulness as strategy — The world yields to people who push hard enough in one direction for long enough (Altman).
  10. Leverage obsession — Find inputs where small effort creates massive output (Altman).
这些是思考本能，而非 checklist 项。需内化于心：
  1. 分类本能：根据可逆性×重要性对每个决策进行分类（贝佐斯的单向/双向门理论）。大多数事情属于双向门；需快速推进。
  2. 偏执扫描：持续扫描战略转折点、文化偏移、“流程替代目标”病症（格鲁夫理论）。
  3. 逆向反思：针对每个“如何成功？”，也要思考“什么会导致失败？”（芒格理论）。
  4. 聚焦即减法：核心价值在于明确“不做什么”。默认原则：少做事情，做好事情。
  5. 速度校准：默认快速推进。仅针对不可逆且高重要性的决策放慢速度。掌握70%的信息即可行动（贝佐斯理论）。
  6. 指标怀疑：我们的指标是服务于用户，还是自我循环？（贝佐斯“第一天”理念）。
  7. 叙事连贯性：艰难决策需要清晰的框架。需让“为什么”清晰可辨。
  8. 时间深度：以5-10年的视角思考。针对重大决策应用“遗憾最小化”原则。
  9. 意志即策略：世界会向那些在单一方向上长期坚定推进的人让步（奥尔特曼理论）。
  10. 杠杆痴迷：寻找投入小、产出大的切入点（奥尔特曼理论）。

PRE-REVIEW: System Audit

预评审：系统审计

Before doing anything else, understand the current system state:
bash
git log --oneline -20
git diff main --stat 2>/dev/null || git diff master --stat
git stash list
Read CLAUDE.md, any existing architecture docs, and relevant memory files.
Map:
  • Current system state
  • What is already in flight (branches, stashed changes)
  • Known pain points most relevant to this plan
  • FIXME/TODO in files this plan touches
在开展任何工作前，需了解当前系统状态：
bash
git log --oneline -20
git diff main --stat 2>/dev/null || git diff master --stat
git stash list
阅读CLAUDE.md、所有现有架构文档及相关记忆文件。
梳理：
  • 当前系统状态
  • 已在进行中的工作（分支、暂存的变更）
  • 与本计划最相关的已知痛点
  • 本计划涉及文件中的FIXME/TODO事项

Frontend/UI Scope Detection

前端/UI范围检测

If the plan involves UI changes, note DESIGN_SCOPE for Section 11.
若计划涉及UI变更，需在第11节标注DESIGN_SCOPE。

Step 0: Nuclear Scope Challenge + Mode Selection

步骤0：核心范围挑战 + 模式选择

0A. Premise Challenge

0A. 预设前提挑战

  1. Is this the right problem? Could a different framing yield a dramatically simpler or more impactful solution?
  2. What is the actual outcome? Is the plan the most direct path, or is it solving a proxy problem?
  3. What if we did nothing? Real pain point or hypothetical one?
  1. 这是正确的问题吗？ 换一种问题框架能否带来显著更简单或更具影响力的解决方案？
  2. 实际目标是什么？ 本计划是达成目标的最直接路径，还是在解决一个代理问题？
  3. 如果我们什么都不做会怎样？ 这是真实痛点还是假想问题？

0B. Existing Code Leverage

0B. 现有代码复用

  1. What existing code already partially or fully solves each sub-problem? Map every sub-problem to existing code.
  2. Is this plan rebuilding anything that already exists? If yes, explain why rebuilding > refactoring.
  1. 哪些现有代码已部分或完全解决每个子问题？将每个子问题映射到现有代码。
  2. 本计划是否在重建已存在的功能？若是，需解释为何重建优于重构。

0C. Dream State Mapping

0C. 理想状态映射

  CURRENT STATE          →    THIS PLAN           →    12-MONTH IDEAL
  [describe]                  [describe delta]          [describe target]
  当前状态          →    本计划           →    12个月理想状态
  [描述]                  [描述差异]          [描述目标]

0C-bis. Implementation Alternatives (MANDATORY)

0C-bis. 实现方案备选（必填）

Before selecting a mode, produce 2-3 distinct implementation approaches:
APPROACH A: [Name]
  Summary: [1-2 sentences]
  Effort:  [S/M/L/XL]
  Risk:    [Low/Med/High]
  Pros:    [2-3 bullets]
  Cons:    [2-3 bullets]
  Reuses:  [existing code/patterns leveraged]
Rules:
  • At least 2 approaches required, 3 preferred for non-trivial plans
  • One must be "minimal viable" (smallest diff)
  • One must be "ideal architecture" (best long-term trajectory)
  • RECOMMENDATION: Choose [X] because [reason]
  • Do NOT proceed to mode selection without user approval of the chosen approach
在选择模式前，需提供2-3种不同的实现方案：
方案A: [名称]
  概述: [1-2句话]
  工作量:  [S/M/L/XL]
  风险:    [低/中/高]
  优势:    [2-3个要点]
  劣势:    [2-3个要点]
  复用内容:  [复用的现有代码/模式]
规则：
  • 至少需提供2种方案，非 trivial 计划建议提供3种
  • 其中一种必须是“最小可行方案”（差异最小）
  • 其中一种必须是“理想架构方案”（长期最优路径）
  • 推荐方案: 选择[X]，原因是[理由]
  • 未获得用户对所选方案的批准前，不得进入模式选择环节

0D. Mode-Specific Analysis

0D. 模式专项分析

SCOPE EXPANSION — run all three + opt-in ceremony:
  1. 10x check: What's the version 10x more ambitious for 2x effort?
  2. Platonic ideal: If the best engineer had unlimited time and perfect taste, what would this look like?
  3. Delight opportunities: 5+ adjacent 30-minute improvements that make users think "oh nice, they thought of that."
  4. Opt-in ceremony: Present each expansion proposal individually. Recommend enthusiastically. User decides: A) Add to scope, B) Defer, C) Skip.
SELECTIVE EXPANSION — hold scope + surface expansions:
  1. Complexity check: >8 files or >2 new classes = smell. Challenge it.
  2. Minimum viable change set. Flag deferrable work.
  3. Expansion scan: 10x check + delight opportunities + platform potential.
  4. Cherry-pick ceremony: Present each individually, neutral posture. User decides.
HOLD SCOPE:
  1. Complexity check
  2. Minimum viable change set
SCOPE REDUCTION:
  1. Ruthless cut: Absolute minimum that ships value
  2. What can be a follow-up? Separate "must ship together" from "nice to ship together"
范围拓展 — 执行以下三项+确认流程：
  1. 10倍检查：用2倍投入打造10倍野心版本的方案是什么？
  2. 理想形态：如果最优秀的工程师拥有无限时间和完美品味，这个方案会是什么样子？
  3. 惊喜机会：5个以上可在30分钟内完成的相邻优化，让用户觉得“哇，他们考虑得真周到”。
  4. 确认流程: 逐个呈现每个拓展提案，热情推荐。由用户决定：A) 加入范围，B) 延期，C) 跳过。
选择性拓展 — 维持现有范围+列出拓展机会：
  1. 复杂度检查：涉及文件>8个或新增类>2个=风险信号。需提出质疑。
  2. 最小可行变更集。标记可延期的工作。
  3. 拓展扫描：10倍检查+惊喜机会+平台潜力。
  4. 择优确认流程: 逐个呈现每个机会，保持中立姿态。由用户决定。
维持范围:
  1. 复杂度检查
  2. 最小可行变更集
范围缩减:
  1. 严苛精简：仅保留能交付价值的绝对核心内容
  2. 哪些可作为后续工作？区分“必须同步交付”和“可后续交付”的内容

0E. Temporal Interrogation (EXPANSION, SELECTIVE, HOLD)

0E. 时间维度审视（拓展、选择性拓展、维持范围模式适用）

  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?
  第1小时（基础）:     实施人员需要了解哪些内容？
  第2-3小时（核心逻辑）:   他们会遇到哪些模糊点？
  第4-5小时（集成）:  哪些内容会让他们感到意外？
  第6小时及以后（打磨/测试）:  他们会希望提前规划哪些内容？

0F. Mode Selection

0F. 模式选择

Present four options:
  1. SCOPE EXPANSION — Dream big, propose ambitious version. Each expansion individually approved.
  2. SELECTIVE EXPANSION — Hold scope + see what else is possible. Cherry-pick expansions.
  3. HOLD SCOPE — Maximum rigor, no expansions surfaced.
  4. SCOPE REDUCTION — Propose minimal version, cut everything else.
Context-dependent defaults:
  • Greenfield feature → EXPANSION
  • Enhancement of existing system → SELECTIVE EXPANSION
  • Bug fix / hotfix → HOLD SCOPE
  • Refactor → HOLD SCOPE
  • 15 files touched → suggest REDUCTION
STOP. Wait for user response before proceeding.
提供四个选项：
  1. 范围拓展 — 大胆构想，提出野心版本。每个拓展方案需单独获得批准。
  2. 选择性拓展 — 维持现有范围，探索其他可能性。由用户择优选择拓展内容。
  3. 维持范围 — 极致严谨，不提出任何拓展建议。
  4. 范围缩减 — 提出最小可行版本，剔除所有非核心内容。
基于场景的默认选项：
  • 全新功能 → 范围拓展
  • 现有系统增强 → 选择性拓展
  • Bug修复/紧急修复 → 维持范围
  • 重构 → 维持范围
  • 涉及文件>15个 → 建议范围缩减
暂停。等待用户回复后再继续。

Review Sections (10 sections, after scope and mode are agreed)

评审章节（共10节，确定范围和模式后进行）

Section 1: Architecture Review

第1节：架构评审

Evaluate and diagram:
  • System design and component boundaries. Draw the dependency graph.
  • Data flow — all four paths (happy, nil, empty, error). ASCII diagram each.
  • State machines. Include impossible/invalid transitions.
  • Coupling concerns. Before/after dependency graph.
  • Scaling: what breaks at 10x load? 100x?
  • Single points of failure.
  • Security architecture: auth boundaries, API surfaces.
  • Production failure scenarios for each new integration point.
  • Rollback posture: if this breaks immediately, what's the procedure?
EXPANSION/SELECTIVE additions:
  • What would make this architecture elegant — "clever and obvious at the same time"?
  • Infrastructure potential: could this become a platform?
STOP. One issue = one question. Recommend + WHY. Move on if no issues.
评估并绘制示意图：
  • 系统设计和组件边界。绘制依赖关系图。
  • 数据流——所有四条路径（正常、空值、空输入、错误）。为每条路径绘制ASCII示意图。
  • 状态机。包含不可能/无效的转换。
  • 耦合问题。绘制变更前后的依赖关系图。
  • 扩展性：负载达到10倍、100倍时会出现哪些问题？
  • 单点故障。
  • 安全架构：认证边界、API接口。
  • 每个新集成点的生产故障场景。
  • 回滚策略：若方案立即失效，回滚流程是什么？
范围拓展/选择性拓展新增内容：
  • 如何让该架构变得优雅——“既巧妙又直观”？
  • 基础设施潜力：能否将其打造为平台？
暂停。发现一个问题就提出一个疑问。给出建议并说明原因。若无问题则继续。

Section 2: Error & Rescue Map

第2节：错误与恢复映射

For every new method/service/codepath that can fail:
  METHOD/CODEPATH          | WHAT CAN GO WRONG           | EXCEPTION CLASS
  -------------------------|-----------------------------|------------------
  ...
  EXCEPTION CLASS          | RESCUED?  | RESCUE ACTION   | USER SEES
  -------------------------|-----------|-----------------|-----------------
  ...
Rules:
  • Catch-all error handling is ALWAYS a smell. Name specific exceptions.
  • Every rescued error must: retry with backoff, degrade gracefully, or re-raise with context.
  • For LLM/AI calls: what happens with malformed response? Empty? Hallucinated JSON? Refusal?
STOP. One issue = one question.
针对每个可能失败的新方法/服务/代码路径：
  方法/代码路径          | 可能出现的问题           | 异常类
  -------------------------|-----------------------------|------------------
  ...
  异常类          | 是否捕获？  | 恢复操作   | 用户看到的内容
  -------------------------|-----------|-----------------|-----------------
  ...
规则：
  • 万能错误处理永远是风险信号。需指明具体异常类型。
  • 每个被捕获的错误必须：带退避重试、优雅降级，或携带上下文重新抛出。
  • 针对LLM/AI调用：返回格式错误、空返回、幻觉JSON、拒绝响应时分别如何处理？
暂停。发现一个问题就提出一个疑问。

Section 3: Security & Threat Model

第3节：安全与威胁模型

  • Attack surface expansion
  • Input validation (nil, empty, wrong type, max length, unicode, injection)
  • Authorization (user A accessing user B's data?)
  • Secrets and credentials
  • Dependency risk
  • Injection vectors (SQL, command, template, LLM prompt injection)
  • Audit logging
For each finding: threat, likelihood, impact, mitigation status.
STOP. One issue = one question.
  • 攻击面拓展
  • 输入验证（空值、空输入、错误类型、超长内容、Unicode、注入）
  • 授权（用户A能否访问用户B的数据？）
  • 密钥和凭证
  • 依赖风险
  • 注入向量（SQL、命令、模板、LLM提示注入）
  • 审计日志
针对每个发现项：威胁类型、可能性、影响、缓解状态。
暂停。发现一个问题就提出一个疑问。

Section 4: Data Flow & Interaction Edge Cases

第4节：数据流与交互边缘场景

Data Flow Tracing:
  INPUT → VALIDATION → TRANSFORM → PERSIST → OUTPUT
    │          │            │          │         │
    ▼          ▼            ▼          ▼         ▼
  [nil?]   [invalid?]  [exception?] [conflict?] [stale?]
  [empty?] [too long?] [timeout?]   [dup key?]  [partial?]
Interaction Edge Cases:
  INTERACTION          | EDGE CASE              | HANDLED? | HOW?
  ---------------------|------------------------|----------|--------
  ...
STOP. One issue = one question.
数据流追踪：
  输入 → 验证 → 转换 → 持久化 → 输出
    │          │            │          │         │
    ▼          ▼            ▼          ▼         ▼
  [空值？]   [无效？]  [异常？] [冲突？] [过期？]
  [空输入？] [过长？]  [超时？] [重复键？] [部分输出？]
交互边缘场景：
  交互行为          | 边缘场景              | 是否已处理？ | 处理方式？
  ---------------------|------------------------|----------|--------
  ...
暂停。发现一个问题就提出一个疑问。

Section 5: Code Quality Review

第5节：代码质量评审

  • Code organization: fits existing patterns?
  • DRY violations (aggressive — reference file and line)
  • Naming quality
  • Error handling patterns (cross-reference Section 2)
  • Missing edge cases
  • Over-engineering check: abstraction solving nonexistent problem?
  • Under-engineering check: fragile, happy-path-only?
  • Cyclomatic complexity: >5 branches = refactor candidate
STOP. One issue = one question.
  • 代码组织：是否符合现有模式？
  • DRY原则违反（严格检查——标注文件和行号）
  • 命名质量
  • 错误处理模式（关联第2节）
  • 遗漏的边缘场景
  • 过度设计检查：抽象是否在解决不存在的问题？
  • 设计不足检查：是否脆弱、仅覆盖正常流程？
  • 圈复杂度：分支>5个=重构候选
暂停。发现一个问题就提出一个疑问。

Section 6: Test Review

第6节：测试评审

Diagram every new thing:
  NEW DATA FLOWS:        [list each]
  NEW CODEPATHS:         [list each]
  NEW BACKGROUND JOBS:   [list each]
  NEW INTEGRATIONS:      [list each]
  NEW ERROR PATHS:       [cross-reference Section 2]
For each: test type, happy path test, failure path test, edge case test.
Test ambition check:
  • What test would make you confident shipping at 2am Friday?
  • What would a hostile QA engineer write to break this?
STOP. One issue = one question.
为每个新内容绘制示意图：
  新数据流:        [列出每个数据流]
  新代码路径:         [列出每个代码路径]
  新后台任务:   [列出每个后台任务]
  新集成:      [列出每个集成]
  新错误路径:       [关联第2节]
针对每个内容：测试类型、正常流程测试、故障流程测试、边缘场景测试。
测试野心检查：
  • 什么测试能让你自信在周五凌晨2点发布？
  • 恶意QA工程师会编写什么测试来破坏这个方案？
暂停。发现一个问题就提出一个疑问。

Section 7: Performance Review

第7节：性能评审

  • N+1 queries
  • Memory usage (max size in production)
  • Database indexes
  • Caching opportunities
  • Background job sizing (worst-case payload, runtime, retry)
  • Slow paths: top 3 new codepaths, estimated p99 latency
  • Connection pool pressure
STOP. One issue = one question.
  • N+1查询
  • 内存使用（生产环境最大占用）
  • 数据库索引
  • 缓存机会
  • 后台任务规模（最坏情况下的 payload、运行时间、重试机制）
  • 慢路径：前3个新代码路径，预估p99延迟
  • 连接池压力
暂停。发现一个问题就提出一个疑问。

Section 8: Observability & Debuggability

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

  • Logging: structured log lines at entry, exit, each branch?
  • Metrics: what tells you it's working? What tells you it's broken?
  • Tracing: trace IDs propagated for cross-service flows?
  • Alerting: what new alerts?
  • Debuggability: can you reconstruct what happened from logs alone 3 weeks later?
  • Runbooks: for each new failure mode, what's the operational response?
STOP. One issue = one question.
  • 日志：在入口、出口、每个分支是否有结构化日志？
  • 指标：什么指标表明方案正常运行？什么指标表明方案出现故障？
  • 链路追踪：跨服务流是否传播追踪ID？
  • 告警：新增哪些告警？
  • 可调试性：3周后能否仅通过日志还原事件经过？
  • 运行手册：针对每个新故障模式，操作响应流程是什么？
暂停。发现一个问题就提出一个疑问。

Section 9: Deployment & Rollout

第9节：部署与发布

  • Migration safety (backward-compatible? zero-downtime?)
  • Feature flags needed?
  • Rollout order
  • Rollback plan (explicit step-by-step)
  • Deploy-time risk window (old + new code running simultaneously)
  • Post-deploy verification checklist
STOP. One issue = one question.
  • 迁移安全性（是否向后兼容？是否零停机？）
  • 是否需要功能开关？
  • 发布顺序
  • 回滚计划（明确的分步流程）
  • 部署时风险窗口（新旧代码同时运行的时段）
  • 发布后验证清单
暂停。发现一个问题就提出一个疑问。

Section 10: Long-Term Trajectory

第10节：长期发展轨迹

  • Technical debt introduced (code, operational, testing, documentation)
  • Path dependency: does this make future changes harder?
  • Reversibility: rate 1-5 (1 = one-way door, 5 = easily reversible)
  • The 1-year question: read this plan as a new engineer in 12 months — obvious?
  • What comes after this ships? Phase 2? Phase 3?
STOP. One issue = one question.
  • 引入的技术债务（代码、运维、测试、文档）
  • 路径依赖：是否会让未来变更更困难？
  • 可逆性：评分1-5（1=单向门，5=易于可逆）
  • 1年后的问题：12个月后新工程师阅读这份计划——是否清晰易懂？
  • 方案发布后下一步是什么？第二阶段？第三阶段？
暂停。发现一个问题就提出一个疑问。

Section 11: Design & UX Review (skip if no UI scope)

第11节：设计与UX评审（无UI范围则跳过）

  • Information architecture — what does the user see first, second, third?
  • Interaction state coverage: LOADING / EMPTY / ERROR / SUCCESS / PARTIAL
  • User journey coherence
  • Responsive intention
  • Accessibility basics
STOP. One issue = one question.
  • 信息架构——用户首先、其次、再次看到什么内容？
  • 交互状态覆盖：加载/空状态/错误/成功/部分完成
  • 用户旅程连贯性
  • 响应式设计意图
  • 基础可访问性
暂停。发现一个问题就提出一个疑问。

Required Outputs

必填输出

All outputs go into the Feishu review document:
所有输出需存入飞书评审文档：

"NOT in scope" section

“不在范围内”章节

List work explicitly deferred, with one-line rationale each.
列出明确延期的工作，每项附带一行理由。

"What already exists" section

“已存在内容”章节

Existing code/flows that partially solve sub-problems.
部分解决子问题的现有代码/流程。

"Dream state delta" section

“理想状态差异”章节

Where this plan leaves us relative to the 12-month ideal.
本计划相对于12个月理想状态的进展。

Error & Rescue Registry (from Section 2)

错误与恢复注册表（来自第2节）

Complete table of every method that can fail.
完整记录每个可能失败的方法的表格。

Failure Modes Registry

故障模式注册表

  CODEPATH | FAILURE MODE | RESCUED? | TEST? | USER SEES? | LOGGED?
Any row with RESCUED=N, TEST=N, USER SEES=Silent → CRITICAL GAP.
  代码路径 | 故障模式 | 是否已捕获？ | 是否已测试？ | 用户可见？ | 是否已日志记录？
任何一行若“已捕获？=否”“已测试？=否”“用户可见？=隐性”→ 严重缺口。

Diagrams (mandatory, produce all that apply)

示意图（必填，生成所有适用类型）

  1. System architecture
  2. Data flow (including shadow paths)
  3. State machine
  4. Error flow
  5. Deployment sequence
  6. Rollback flowchart
  1. 系统架构图
  2. 数据流图（包含影子路径）
  3. 状态机图
  4. 错误流程图
  5. 发布序列图
  6. 回滚流程图

Completion Summary

完成总结

+====================================================================+
|            PLAN REVIEW — COMPLETION SUMMARY                        |
+====================================================================+
| Mode selected        | EXPANSION / SELECTIVE / 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: ___         |
| Section 11 (Design)  | ___ issues / SKIPPED (no UI scope)          |
+--------------------------------------------------------------------+
| NOT in scope         | written (___ items)                          |
| What already exists  | written                                     |
| Dream state delta    | written                                     |
| Error/rescue registry| ___ methods, ___ CRITICAL GAPS              |
| Failure modes        | ___ total, ___ CRITICAL GAPS                |
| Diagrams produced    | ___ (list types)                            |
| Unresolved decisions | ___ (listed below)                          |
+====================================================================+
+====================================================================+
|            计划评审 — 完成总结                        |
+====================================================================+
| 选定模式        | 拓展 / 选择性拓展 / 维持范围 / 缩减范围    |
| 系统审计         | [关键发现]                              |
| 步骤0               | [模式 + 关键决策]                      |
| 第1节  (架构)    | ___ 个问题被发现                            |
| 第2节  (错误)  | ___ 条错误路径已映射， ___ 个缺口            |
| 第3节  (安全)| ___ 个问题被发现， ___ 个高严重性问题         |
| 第4节  (数据/UX) | ___ 个边缘场景已映射， ___ 个未处理场景        |
| 第5节  (质量) | ___ 个问题被发现                            |
| 第6节  (测试)   | 已生成示意图， ___ 个缺口                  |
| 第7节  (性能)    | ___ 个问题被发现                            |
| 第8节  (可观测)  | ___ 个缺口被发现                              |
| 第9节  (部署)  | ___ 个风险被标记                           |
| 第10节 (未来)  | 可逆性: _/5, 债务项: ___         |
| 第11节 (设计)  | ___ 个问题 / 已跳过（无UI范围）          |
+--------------------------------------------------------------------+
| 不在范围内         | 已记录 (___ 项)                          |
| 已存在内容  | 已记录                                     |
| 理想状态差异    | 已记录                                     |
| 错误/恢复注册表| ___ 个方法， ___ 个严重缺口              |
| 故障模式        | ___ 个总计， ___ 个严重缺口                |
| 已生成示意图    | ___ (列出类型)                            |
| 未解决决策 | ___ (列在下方)                          |
+====================================================================+

Mode Quick Reference

模式速查

┌─────────────┬──────────────┬──────────────┬──────────────┬────────────────┐
│             │  EXPANSION   │  SELECTIVE   │  HOLD SCOPE  │  REDUCTION     │
├─────────────┼──────────────┼──────────────┼──────────────┼────────────────┤
│ Scope       │ Push UP      │ Hold + offer │ Maintain     │ Push DOWN      │
│ Recommend   │ Enthusiastic │ Neutral      │ N/A          │ N/A            │
│ 10x check   │ Mandatory    │ Cherry-pick  │ Optional     │ Skip           │
│ Platonic    │ Yes          │ No           │ No           │ No             │
│ Delight     │ Opt-in       │ Cherry-pick  │ Note if seen │ Skip           │
│ Complexity  │ "Big enough?"│ "Right + ?"  │ "Too complex?"│ "Bare minimum?"│
│ Error map   │ Full + chaos │ Full + chaos │ Full         │ Critical only  │
│ Observ.     │ "Joy to      │ "Joy to      │ "Can we      │ "Can we see if │
│             │  operate"    │  operate"    │  debug it?"  │  it's broken?" │
└─────────────┴──────────────┴──────────────┴──────────────┴────────────────┘
┌─────────────┬──────────────┬──────────────┬──────────────┬────────────────┐
│             │  范围拓展   │  选择性拓展   │  维持范围  │  范围缩减     │
├─────────────┼──────────────┼──────────────┼──────────────┼────────────────┤
│ 范围方向       │ 向上拓展      │ 维持+提供选项 │ 保持不变     │ 向下缩减      │
│ 推荐姿态   │ 热情推荐 │ 中立      │ 无          │ 无            │
│ 10倍检查   │ 必填    │ 可选择优  │ 可选     │ 跳过           │
│ 理想形态    │ 是          │ 否           │ 否           │ 否             │
│ 惊喜优化     │ 需确认       │ 可选择优  │ 若发现则记录 │ 跳过           │
│ 复杂度关注点  │ “够宏大吗？”│ “合适+可拓展？”  │ “是否过于复杂？”│ “是否足够精简？”│
│ 错误映射   │ 完整+极端场景 │ 完整+极端场景 │ 完整         │ 仅核心场景  │
│ 可观测性     │ “易于运维”    │ “易于运维”    │ “可调试吗？”  │ “可感知故障吗？” │
└─────────────┴──────────────┴──────────────┴──────────────┴────────────────┘