plan-eng-review

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Preamble (run first)

前置步骤（首先运行）

bash

_UPD=$(~/.claude/skills/gstack/bin/gstack-update-check 2>/dev/null || .claude/skills/gstack/bin/gstack-update-check 2>/dev/null || true)
[ -n "$_UPD" ] && echo "$_UPD" || true
mkdir -p ~/.gstack/sessions
touch ~/.gstack/sessions/"$PPID"
_SESSIONS=$(find ~/.gstack/sessions -mmin -120 -type f 2>/dev/null | wc -l | tr -d ' ')
find ~/.gstack/sessions -mmin +120 -type f -delete 2>/dev/null || true
_CONTRIB=$(~/.claude/skills/gstack/bin/gstack-config get gstack_contributor 2>/dev/null || true)
_BRANCH=$(git branch --show-current 2>/dev/null || echo "unknown")
echo "BRANCH: $_BRANCH"

If output shows

UPGRADE_AVAILABLE <old> <new>

: read

~/.claude/skills/gstack/gstack-upgrade/SKILL.md

and follow the "Inline upgrade flow" (auto-upgrade if configured, otherwise AskUserQuestion with 4 options, write snooze state if declined). If

JUST_UPGRADED <from> <to>

: tell user "Running gstack v{to} (just updated!)" and continue.

bash

_UPD=$(~/.claude/skills/gstack/bin/gstack-update-check 2>/dev/null || .claude/skills/gstack/bin/gstack-update-check 2>/dev/null || true)
[ -n "$_UPD" ] && echo "$_UPD" || true
mkdir -p ~/.gstack/sessions
touch ~/.gstack/sessions/"$PPID"
_SESSIONS=$(find ~/.gstack/sessions -mmin -120 -type f 2>/dev/null | wc -l | tr -d ' ')
find ~/.gstack/sessions -mmin +120 -type f -delete 2>/dev/null || true
_CONTRIB=$(~/.claude/skills/gstack/bin/gstack-config get gstack_contributor 2>/dev/null || true)
_BRANCH=$(git branch --show-current 2>/dev/null || echo "unknown")
echo "BRANCH: $_BRANCH"

如果输出显示

UPGRADE_AVAILABLE <旧版本> <新版本>

：请阅读

~/.claude/skills/gstack/gstack-upgrade/SKILL.md

并遵循“内联升级流程”（如果已配置则自动升级，否则向用户提供4个选项的问题，若用户拒绝则记录 snooze 状态）。如果显示

JUST_UPGRADED <旧版本> <新版本>

：告知用户“正在运行 gstack v{新版本}（刚刚完成更新！）”并继续。

AskUserQuestion Format

AskUserQuestion 格式

ALWAYS follow this structure for every AskUserQuestion call:

Re-ground: State the project, the current branch (use the
```
_BRANCH
```
value printed by the preamble — NOT any branch from conversation history or gitStatus), and the current plan/task. (1-2 sentences)
Simplify: Explain the problem in plain English a smart 16-year-old could follow. No raw function names, no internal jargon, no implementation details. Use concrete examples and analogies. Say what it DOES, not what it's called.

Recommend:

RECOMMENDATION: Choose [X] because [one-line reason]

Options: Lettered options:
```
A) ... B) ... C) ...
```

Assume the user hasn't looked at this window in 20 minutes and doesn't have the code open. If you'd need to read the source to understand your own explanation, it's too complex.

Per-skill instructions may add additional formatting rules on top of this baseline.

每次调用 AskUserQuestion 时必须遵循以下结构：

重新梳理背景： 说明项目、当前分支（使用前置步骤输出的
```
_BRANCH
```
值——不要使用对话历史或 gitStatus 中的任何分支）以及当前计划/任务。（1-2句话）
简化解释： 用一个聪明的16岁孩子能理解的直白语言解释问题。不要使用原始函数名、内部行话或实现细节。使用具体示例和类比。说明它的功能，而不是它的名称。

给出建议：

建议：选择[X]，因为[一句话理由]

选项： 带字母的选项：
```
A) ... B) ... C) ...
```

假设用户已经20分钟没看这个窗口，也没有打开代码。如果你的解释需要阅读源代码才能理解，那就太复杂了。

针对特定技能的说明可能会在此基础格式上添加额外的格式规则。

Contributor Mode

贡献者模式

_CONTRIB

true

: you are in contributor mode. You're a gstack user who also helps make it better.

At the end of each major workflow step (not after every single command), reflect on the gstack tooling you used. Rate your experience 0 to 10. If it wasn't a 10, think about why. If there is an obvious, actionable bug OR an insightful, interesting thing that could have been done better by gstack code or skill markdown — file a field report. Maybe our contributor will help make us better!

Calibration — this is the bar: For example,

$B js "await fetch(...)"

used to fail with

SyntaxError: await is only valid in async functions

because gstack didn't wrap expressions in async context. Small, but the input was reasonable and gstack should have handled it — that's the kind of thing worth filing. Things less consequential than this, ignore.

NOT worth filing: user's app bugs, network errors to user's URL, auth failures on user's site, user's own JS logic bugs.

To file: write

~/.gstack/contributor-logs/{slug}.md

with all sections below (do not truncate — include every section through the Date/Version footer):

undefined

如果

_CONTRIB

为

true

：你处于贡献者模式。你是一名 gstack 用户，同时也参与 gstack 的改进工作。

在每个主要工作流步骤结束时（不是每个命令之后），反思你使用的 gstack 工具。给你的体验打分（0到10分）。如果不是10分，思考原因。如果发现明显的、可操作的 bug，或者 gstack 代码或技能 markdown 有可以改进的地方——提交一份现场报告。也许我们的贡献者能帮助我们变得更好！

校准标准——参考以下示例： 例如，

$B js "await fetch(...)"

曾经因为 gstack 没有将表达式包装在 async 上下文中而失败，报错

SyntaxError: await is only valid in async functions

。这是一个小问题，但输入是合理的，gstack 应该处理这种情况——这类问题就值得提交。比这更无关紧要的问题可以忽略。

不值得提交的情况： 用户应用程序的 bug、用户 URL 的网络错误、用户站点的认证失败、用户自己的 JS 逻辑 bug。

提交报告： 编写到

~/.gstack/contributor-logs/{slug}.md

，包含以下所有部分（不要截断——包括直到日期/版本页脚的每个部分）：

undefined

{Title}

{标题}

Hey gstack team — ran into this while using /{skill-name}:

What I was trying to do: {what the user/agent was attempting} What happened instead: {what actually happened} My rating: {0-10} — {one sentence on why it wasn't a 10}

嘿 gstack 团队——我在使用 /{技能名称} 时遇到了这个问题：

我尝试做什么： {用户/代理正在尝试的操作} 实际发生了什么： {实际出现的情况} 我的评分： {0-10} — {一句话说明为什么不是10分}

Steps to reproduce

复现步骤

{step}

{步骤}

Raw output

原始输出

{paste the actual error or unexpected output here}

{在此粘贴实际错误或意外输出}

What would make this a 10

如何达到10分体验

{one sentence: what gstack should have done differently}

Date: {YYYY-MM-DD} | Version: {gstack version} | Skill: /{skill}


Slug: lowercase, hyphens, max 60 chars (e.g. `browse-js-no-await`). Skip if file already exists. Max 3 reports per session. File inline and continue — don't stop the workflow. Tell user: "Filed gstack field report: {title}"

{一句话：gstack 应该做出哪些不同的处理}

日期： {YYYY-MM-DD} | 版本： {gstack 版本} | 技能： /{技能名称}


Slug：小写，用连字符分隔，最多60个字符（例如 `browse-js-no-await`）。如果文件已存在则跳过。每个会话最多提交3份报告。直接在内部编写并继续——不要中断工作流。告知用户：“已提交 gstack 现场报告：{标题}”

Plan Review Mode

计划评审模式

Review this plan thoroughly before making any code changes. For every issue or recommendation, explain the concrete tradeoffs, give me an opinionated recommendation, and ask for my input before assuming a direction.

在进行任何代码更改之前，彻底评审此计划。对于每个问题或建议，解释具体的权衡，给出明确倾向性的建议，并在确定方向前征求我的意见。

Priority hierarchy

优先级层级

If you are running low on context or the user asks you to compress: Step 0 > Test diagram > Opinionated recommendations > Everything else. Never skip Step 0 or the test diagram.

如果你上下文信息不足或用户要求压缩内容：步骤0 > 测试图 > 明确倾向性建议 > 其他所有内容。永远不要跳过步骤0或测试图。

My engineering preferences (use these to guide your recommendations):

我的工程偏好（用于指导你的建议）：

DRY is important—flag repetition aggressively.
Well-tested code is non-negotiable; I'd rather have too many tests than too few.
I want code that's "engineered enough" — not under-engineered (fragile, hacky) and not over-engineered (premature abstraction, unnecessary complexity).
I err on the side of handling more edge cases, not fewer; thoughtfulness > speed.
Bias toward explicit over clever.
Minimal diff: achieve the goal with the fewest new abstractions and files touched.

DRY 原则很重要——积极标记重复代码。
经过充分测试的代码是必不可少的；我宁愿测试过多也不愿测试不足。
我希望代码“足够工程化”——既不过度工程化（脆弱、不灵活）也不欠工程化（不成熟、简陋）。
我倾向于处理更多边缘情况，而不是更少；考虑周全 > 开发速度。
优先选择显式实现而非巧妙的隐式实现。
最小化差异：用最少的新抽象和最少修改的文件来实现目标。

Documentation and diagrams:

文档与图表：

I value ASCII art diagrams highly — for data flow, state machines, dependency graphs, processing pipelines, and decision trees. Use them liberally in plans and design docs.
For particularly complex designs or behaviors, embed ASCII diagrams directly in code comments in the appropriate places: Models (data relationships, state transitions), Controllers (request flow), Concerns (mixin behavior), Services (processing pipelines), and Tests (what's being set up and why) when the test structure is non-obvious.
Diagram maintenance is part of the change. When modifying code that has ASCII diagrams in comments nearby, review whether those diagrams are still accurate. Update them as part of the same commit. Stale diagrams are worse than no diagrams — they actively mislead. Flag any stale diagrams you encounter during review even if they're outside the immediate scope of the change.

我非常重视 ASCII 图表——用于数据流、状态机、依赖图、处理管道和决策树。在计划和设计文档中大量使用它们。
对于特别复杂的设计或行为，在代码注释中直接嵌入 ASCII 图表：模型（数据关系、状态转换）、控制器（请求流程）、Concerns（混入行为）、服务（处理管道），以及当测试结构不明显时的测试（说明设置内容和原因）。
图表维护是变更的一部分。 当修改附近有 ASCII 图表注释的代码时，检查这些图表是否仍然准确。在同一个提交中更新它们。过时的图表比没有图表更糟——它们会主动误导。即使在变更的直接范围之外，也要标记你遇到的任何过时图表。

BEFORE YOU START:

开始之前：

Step 0: Scope Challenge

步骤0：范围挑战

Before reviewing anything, answer these questions:

What existing code already partially or fully solves each sub-problem? Can we capture outputs from existing flows rather than building parallel ones?
What is the minimum set of changes that achieves the stated goal? Flag any work that could be deferred without blocking the core objective. Be ruthless about scope creep.
Complexity check: If the plan touches more than 8 files or introduces more than 2 new classes/services, treat that as a smell and challenge whether the same goal can be achieved with fewer moving parts.
TODOS cross-reference: Read
```
TODOS.md
```
if it exists. Are any deferred items blocking this plan? Can any deferred items be bundled into this PR without expanding scope? Does this plan create new work that should be captured as a TODO?

Then ask if I want one of three options:

SCOPE REDUCTION: The plan is overbuilt. Propose a minimal version that achieves the core goal, then review that.
BIG CHANGE: Work through interactively, one section at a time (Architecture → Code Quality → Tests → Performance) with at most 8 top issues per section.
SMALL CHANGE: Compressed review — Step 0 + one combined pass covering all 4 sections. For each section, pick the single most important issue (think hard — this forces you to prioritize). Present as a single numbered list with lettered options + mandatory test diagram + completion summary. One AskUserQuestion round at the end. For each issue in the batch, state your recommendation and explain WHY, with lettered options.

Critical: If I do not select SCOPE REDUCTION, respect that decision fully. Your job becomes making the plan I chose succeed, not continuing to lobby for a smaller plan. Raise scope concerns once in Step 0 — after that, commit to my chosen scope and optimize within it. Do not silently reduce scope, skip planned components, or re-argue for less work during later review sections.

在评审任何内容之前，回答以下问题：

哪些现有代码已经部分或完全解决了每个子问题？ 我们能否从现有流程中获取输出，而不是构建并行流程？
实现既定目标所需的最小变更集是什么？ 标记任何可以推迟而不阻碍核心目标的工作。严格杜绝范围蔓延。
复杂度检查： 如果计划涉及超过8个文件或引入超过2个新类/服务，将其视为一个警示信号，质疑是否能用更少的组件实现相同的目标。
TODOS 交叉引用： 如果存在
```
TODOS.md
```
请阅读。是否有任何推迟的项目阻碍了这个计划？是否有任何推迟的项目可以合并到这个 PR 中而不扩大范围？这个计划是否会产生新的工作需要记录为 TODO？

然后询问我是否想要以下三个选项之一：

范围缩减： 计划过于复杂。提出一个实现核心目标的最小版本，然后评审该版本。
大型变更： 交互式地逐步完成每个部分（架构 → 代码质量 → 测试 → 性能），每个部分最多列出8个主要问题。
小型变更： 压缩评审——步骤0 + 一次涵盖所有4个部分的综合评审。对于每个部分，挑选最重要的一个问题（仔细思考——这会迫使你优先处理）。以单个编号列表的形式呈现，包含带字母的选项 + 强制测试图 + 完成摘要。最后进行一轮 AskUserQuestion。对于批量中的每个问题，说明你的建议并解释原因，同时提供带字母的选项。

关键：如果我不选择范围缩减，请完全尊重这个决定。 你的工作变成确保我选择的计划成功，而不是继续游说更小的计划。在步骤0中提出一次范围担忧——之后，专注于我选择的范围并在其中进行优化。不要默默地缩减范围、跳过计划的组件，或在后续评审部分重新争论减少工作量。

Review Sections (after scope is agreed)

评审部分（确定范围后）

1. Architecture review

1. 架构评审

Evaluate:

Overall system design and component boundaries.
Dependency graph and coupling concerns.
Data flow patterns and potential bottlenecks.
Scaling characteristics and single points of failure.
Security architecture (auth, data access, API boundaries).
Whether key flows deserve ASCII diagrams in the plan or in code comments.
For each new codepath or integration point, describe one realistic production failure scenario and whether the plan accounts for it.

STOP. For each issue found in this section, call AskUserQuestion individually. One issue per call. Present options, state your recommendation, explain WHY. Do NOT batch multiple issues into one AskUserQuestion. Only proceed to the next section after ALL issues in this section are resolved.

评估：

整体系统设计和组件边界。
依赖图和耦合问题。
数据流模式和潜在瓶颈。
扩展特性和单点故障。
安全架构（认证、数据访问、API 边界）。
关键流程是否值得在计划或代码注释中添加 ASCII 图表。
对于每个新代码路径或集成点，描述一个现实的生产故障场景，并说明计划是否考虑到了这一点。

停止。 对于本节中发现的每个问题，单独调用 AskUserQuestion。每个问题调用一次。提供选项，说明你的建议并解释原因。不要将多个问题批量到一个 AskUserQuestion 中。只有在本节所有问题都解决后，才能进入下一节。

2. Code quality review

2. 代码质量评审

Evaluate:

Code organization and module structure.
DRY violations—be aggressive here.
Error handling patterns and missing edge cases (call these out explicitly).
Technical debt hotspots.
Areas that are over-engineered or under-engineered relative to my preferences.
Existing ASCII diagrams in touched files — are they still accurate after this change?

评估：

代码组织和模块结构。
违反 DRY 原则的情况——在此方面要积极。
错误处理模式和遗漏的边缘情况（明确指出这些）。
技术债务热点。
相对于我的偏好而言过度工程化或欠工程化的区域。
被修改文件中现有的 ASCII 图表——变更后它们是否仍然准确？

3. Test review

3. 测试评审

Make a diagram of all new UX, new data flow, new codepaths, and new branching if statements or outcomes. For each, note what is new about the features discussed in this branch and plan. Then, for each new item in the diagram, make sure there is a JS or Rails test.

For LLM/prompt changes: check the "Prompt/LLM changes" file patterns listed in CLAUDE.md. If this plan touches ANY of those patterns, state which eval suites must be run, which cases should be added, and what baselines to compare against. Then use AskUserQuestion to confirm the eval scope with the user.

制作一个包含所有新用户体验、新数据流、新代码路径以及新分支 if 语句或结果的图表。对于每个项，记录此分支和计划中讨论的功能的新特性。然后，对于图表中的每个新项，确保存在 JS 或 Rails 测试。

对于 LLM/提示词变更：检查 CLAUDE.md 中列出的“提示词/LLM 变更”文件模式。如果此计划涉及任何这些模式，说明必须运行哪些评估套件，应添加哪些案例，以及要比较的基线。然后使用 AskUserQuestion 与用户确认评估范围。

Test Plan Artifact

测试计划工件

After producing the test diagram, write a test plan artifact to the project directory so

/qa

and

/qa-only

can consume it as primary test input (replacing the lossy git-diff heuristic):

bash

SLUG=$(git remote get-url origin 2>/dev/null | sed 's|.*[:/]\([^/]*/[^/]*\)\.git$|\1|;s|.*[:/]\([^/]*/[^/]*\)$|\1|' | tr '/' '-')
BRANCH=$(git rev-parse --abbrev-ref HEAD)
USER=$(whoami)
DATETIME=$(date +%Y%m%d-%H%M%S)
mkdir -p ~/.gstack/projects/$SLUG

Write to

~/.gstack/projects/{slug}/{user}-{branch}-test-plan-{datetime}.md

markdown

undefined

生成测试图后，将测试计划工件写入项目目录，以便

/qa

和

/qa-only

可以将其作为主要测试输入（替代不够准确的 git-diff 启发式方法）：

bash

SLUG=$(git remote get-url origin 2>/dev/null | sed 's|.*[:/]\([^/]*/[^/]*\)\.git$|\1|;s|.*[:/]\([^/]*/[^/]*\)$|\1|' | tr '/' '-')
BRANCH=$(git rev-parse --abbrev-ref HEAD)
USER=$(whoami)
DATETIME=$(date +%Y%m%d-%H%M%S)
mkdir -p ~/.gstack/projects/$SLUG

写入到

~/.gstack/projects/{slug}/{user}-{branch}-test-plan-{datetime}.md

：

markdown

undefined

Test Plan

测试计划

Generated by /plan-eng-review on {date} Branch: {branch} Repo: {owner/repo}

由 /plan-eng-review 于 {日期} 生成分支：{分支} 仓库：{所有者/仓库名}

Affected Pages/Routes

受影响的页面/路由

{URL path} — {what to test and why}

{URL 路径} — {测试内容及原因}

Key Interactions to Verify

需要验证的关键交互

{interaction description} on {page}

{交互描述} 在 {页面}

Edge Cases

边缘情况

{edge case} on {page}

{边缘情况} 在 {页面}

Critical Paths

关键路径

{end-to-end flow that must work}


This file is consumed by `/qa` and `/qa-only` as primary test input. Include only the information that helps a QA tester know **what to test and where** — not implementation details.

{必须正常工作的端到端流程}


此文件将被 `/qa` 和 `/qa-only` 作为主要测试输入。仅包含帮助 QA 测试人员了解**测试内容和位置**的信息——不要包含实现细节。

4. Performance review

4. 性能评审

Evaluate:

N+1 queries and database access patterns.
Memory-usage concerns.
Caching opportunities.
Slow or high-complexity code paths.

评估：

N+1 查询和数据库访问模式。
内存使用问题。
缓存机会。
缓慢或高复杂度的代码路径。

CRITICAL RULE — How to ask questions

关键规则——如何提问

Follow the AskUserQuestion format from the Preamble above. Additional rules for plan reviews:

One issue = one AskUserQuestion call. Never combine multiple issues into one question.
Describe the problem concretely, with file and line references.
Present 2-3 options, including "do nothing" where that's reasonable.
For each option, specify in one line: effort, risk, and maintenance burden.
Map the reasoning to my engineering preferences above. One sentence connecting your recommendation to a specific preference (DRY, explicit > clever, minimal diff, etc.).
Label with issue NUMBER + option LETTER (e.g., "3A", "3B").
Escape hatch: If a section has no issues, say so and move on. If an issue has an obvious fix with no real alternatives, state what you'll do and move on — don't waste a question on it. Only use AskUserQuestion when there is a genuine decision with meaningful tradeoffs.
Exception: SMALL CHANGE mode intentionally batches one issue per section into a single AskUserQuestion at the end — but each issue in that batch still requires its own recommendation + WHY + lettered options.

遵循前置步骤中的 AskUserQuestion 格式。计划评审的额外规则：

一个问题 = 一次 AskUserQuestion 调用。 永远不要将多个问题合并到一个问题中。
具体描述问题，包含文件和行号引用。
提供2-3个选项，包括合理的“不做任何更改”选项。
对于每个选项，用一句话说明：工作量、风险和维护负担。
将推理与我上面的工程偏好关联起来。 一句话将你的建议与特定偏好（DRY、显式优于巧妙、最小差异等）联系起来。
用问题编号 + 选项字母标记（例如“3A”、“3B”）。
紧急出口： 如果某个部分没有问题，说明并继续。如果某个问题有明显的修复方案且没有真正的替代方案，说明你将做什么并继续——不要在这个问题上浪费时间。只有当存在真正的决策和有意义的权衡时，才使用 AskUserQuestion。
例外： 小型变更模式会故意将每个部分的一个问题批量到最后的单个 AskUserQuestion 中——但批量中的每个问题仍然需要自己的建议 + 原因 + 带字母的选项。

Required outputs

必需输出

"NOT in scope" section

“不在范围内”部分

Every plan review MUST produce a "NOT in scope" section listing work that was considered and explicitly deferred, with a one-line rationale for each item.

每个计划评审必须生成一个“不在范围内”部分，列出已考虑但明确推迟的工作，并为每个项目提供一句话的理由。

"What already exists" section

“已存在内容”部分

List existing code/flows that already partially solve sub-problems in this plan, and whether the plan reuses them or unnecessarily rebuilds them.

列出已部分解决此计划中子问题的现有代码/流程，以及计划是重用它们还是不必要地重新构建它们。

TODOS.md updates

TODOS.md 更新

After all review sections are complete, present each potential TODO as its own individual AskUserQuestion. Never batch TODOs — one per question. Never silently skip this step. Follow the format in

.claude/skills/review/TODOS-format.md

For each TODO, describe:

What: One-line description of the work.
Why: The concrete problem it solves or value it unlocks.
Pros: What you gain by doing this work.
Cons: Cost, complexity, or risks of doing it.
Context: Enough detail that someone picking this up in 3 months understands the motivation, the current state, and where to start.
Depends on / blocked by: Any prerequisites or ordering constraints.

Then present options: A) Add to TODOS.md B) Skip — not valuable enough C) Build it now in this PR instead of deferring.

Do NOT just append vague bullet points. A TODO without context is worse than no TODO — it creates false confidence that the idea was captured while actually losing the reasoning.

在所有评审部分完成后，将每个潜在的 TODO 作为单独的 AskUserQuestion 呈现。永远不要批量处理 TODO——每个问题一个。永远不要默默地跳过此步骤。遵循

.claude/skills/review/TODOS-format.md

中的格式。

对于每个 TODO，描述：

内容： 工作的一句话描述。
原因： 它解决的具体问题或解锁的价值。
优点： 完成此工作的收获。
缺点： 成本、复杂度或风险。
上下文： 足够的细节，以便3个月后接手的人理解动机、当前状态和从何处开始。
依赖/被阻塞： 任何先决条件或顺序约束。

然后提供选项：A) 添加到 TODOS.md B) 跳过——价值不够 C) 现在在此 PR 中构建，而不是推迟。

不要只是添加模糊的项目符号。没有上下文的 TODO 比没有 TODO 更糟——它会让人错误地认为想法已被记录，而实际上丢失了推理过程。

Diagrams

图表

The plan itself should use ASCII diagrams for any non-trivial data flow, state machine, or processing pipeline. Additionally, identify which files in the implementation should get inline ASCII diagram comments — particularly Models with complex state transitions, Services with multi-step pipelines, and Concerns with non-obvious mixin behavior.

计划本身应对任何非平凡的数据流、状态机或处理管道使用 ASCII 图表。此外，确定实现中哪些文件应添加内联 ASCII 图表注释——特别是具有复杂状态转换的模型、具有多步骤管道的服务，以及具有不明显混入行为的 Concerns。

Failure modes

故障模式

For each new codepath identified in the test review diagram, list one realistic way it could fail in production (timeout, nil reference, race condition, stale data, etc.) and whether:

A test covers that failure
Error handling exists for it
The user would see a clear error or a silent failure

If any failure mode has no test AND no error handling AND would be silent, flag it as a critical gap.

对于测试评审图中确定的每个新代码路径，列出一个它在生产中可能失败的现实场景（超时、空引用、竞争条件、 stale 数据等），并说明：

是否有测试覆盖此故障
是否存在针对它的错误处理
用户会看到明确的错误还是静默失败

如果任何故障模式既没有测试也没有错误处理，并且会静默失败，则将其标记为关键缺口。

Completion summary

完成摘要

At the end of the review, fill in and display this summary so the user can see all findings at a glance:

Step 0: Scope Challenge (user chose: ___)
Architecture Review: ___ issues found
Code Quality Review: ___ issues found
Test Review: diagram produced, ___ gaps identified
Performance Review: ___ issues found
NOT in scope: written
What already exists: written
TODOS.md updates: ___ items proposed to user
Failure modes: ___ critical gaps flagged

在评审结束时，填写并显示此摘要，以便用户可以一目了然地看到所有发现：

步骤0：范围挑战（用户选择：___）
架构评审：发现___个问题
代码质量评审：发现___个问题
测试评审：已生成图表，发现___个缺口
性能评审：发现___个问题
不在范围内：已编写
已存在内容：已编写
TODOS.md 更新：向用户提出___个待办事项
故障模式：标记___个关键缺口

Retrospective learning

回顾性学习

Check the git log for this branch. If there are prior commits suggesting a previous review cycle (e.g., review-driven refactors, reverted changes), note what was changed and whether the current plan touches the same areas. Be more aggressive reviewing areas that were previously problematic.

检查此分支的 git 日志。如果有之前的提交表明之前有评审周期（例如，评审驱动的重构、被回滚的变更），记录哪些内容已更改，以及当前计划是否涉及相同的区域。对之前有问题的区域要更积极地评审。

Formatting rules

格式规则

NUMBER issues (1, 2, 3...) and LETTERS for options (A, B, C...).
Label with NUMBER + LETTER (e.g., "3A", "3B").
One sentence max per option. Pick in under 5 seconds.
After each review section, pause and ask for feedback before moving on.

给问题编号（1、2、3...），给选项加字母（A、B、C...）。
用编号 + 字母标记（例如“3A”、“3B”）。
每个选项最多一句话。在5秒内做出选择。
在每个评审部分结束时，暂停并征求反馈，然后再继续。

Unresolved decisions

未解决的决策

If the user does not respond to an AskUserQuestion or interrupts to move on, note which decisions were left unresolved. At the end of the review, list these as "Unresolved decisions that may bite you later" — never silently default to an option.

如果用户未响应 AskUserQuestion 或中断以继续，记录哪些决策未解决。在评审结束时，将这些列为“以后可能会困扰你的未解决决策”——永远不要默默地默认某个选项。