fix-findings

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Fix Review Session Findings

修复评审会话问题发现

Read findings from the active review session and apply fixes to the codebase, then update the resolution log.

读取当前评审会话中的问题发现，并对代码库应用修复，然后更新解决日志。

Step 1: Resolve the active session

步骤1：处理当前会话

Look for the current session:

Check
```
.chalk/reviews/.current-session
```
If not found, check for the most recent session directory under
```
.chalk/reviews/sessions/
```
If nothing found, stop and tell the user to run
```
/create-review
```
first to start a session

Store the session ID as

{session}

查找当前会话：

检查
```
.chalk/reviews/.current-session
```
如果未找到，检查
```
.chalk/reviews/sessions/
```
下的最新会话目录
如果仍未找到，停止操作并告知用户先运行
```
/create-review
```
来启动会话

将会话ID存储为

{session}

。

Step 2: Determine which findings to load

步骤2：确定要加载的问题文件

Based on

$ARGUMENTS

If a reviewer name is provided (e.g.
```
codex
```
,
```
gemini
```
,
```
gpt4
```
,
```
claude
```
), sanitize it to kebab-case and load only
```
.chalk/reviews/sessions/{session}/{reviewer}.findings.md
```
If
```
all
```
or no argument → load all
```
*.findings.md
```
files in the session directory

Discover available findings dynamically using the Glob tool:

.chalk/reviews/sessions/{session}/*.findings.md

Do NOT use shell

ls

for discovery — use the Glob tool to avoid command injection and handle special characters safely.

If a findings file doesn't exist or contains only template placeholder text, skip it and note that no findings are available from that reviewer.

If no findings are available from any reviewer, stop and tell the user to paste reviewer output into the findings files first. Show the expected path:

.chalk/reviews/sessions/{session}/{reviewer-name}.findings.md

根据

$ARGUMENTS

：

如果提供了评审人员名称（例如
```
codex
```
、
```
gemini
```
、
```
gpt4
```
、
```
claude
```
），将其转换为短横线分隔格式（kebab-case），仅加载
```
.chalk/reviews/sessions/{session}/{reviewer}.findings.md
```
如果参数为
```
all
```
或未提供参数 → 加载会话目录下所有
```
*.findings.md
```
文件

使用Glob工具动态查找可用的问题文件：

.chalk/reviews/sessions/{session}/*.findings.md

不要使用Shell的

ls

命令进行查找——使用Glob工具以避免命令注入，并安全处理特殊字符。

如果问题文件不存在或仅包含模板占位文本，跳过该文件并记录该评审人员无可用问题发现。

如果所有评审人员都没有可用的问题发现，停止操作并告知用户先将评审人员的输出粘贴到问题文件中。显示预期路径：

.chalk/reviews/sessions/{session}/{reviewer-name}.findings.md

Step 3: Parse findings

步骤3：解析问题发现

From each findings file, extract the findings table. Each row typically has:

ID — finding identifier (e.g.
```
F-001
```
,
```
G-001
```
, or any prefix)
Severity —
```
P0
```
,
```
P1
```
,
```
P2
```
,
```
P3
```
File:Line — source location (e.g.
```
src/main/auth.ts:172
```
)
Issue — description of the problem
Failure mode or Impact — what goes wrong
Recommended fix or Suggested fix — how to fix it
Confidence — reviewer confidence score (if present)

Sort all findings across all reviewers by severity: P0 > P1 > P2 > P3.

Deduplicate findings that target the same file and line (or overlapping line range) across reviewers. Two findings are duplicates if they reference the same file path AND the same line number (or lines within 5 of each other) AND describe a similar category of issue. When deduplicating, keep all IDs, use the more detailed description, and note both reviewers as sources.

从每个问题文件中提取问题表格。每行通常包含：

ID — 问题标识符（例如
```
F-001
```
、
```
G-001
```
或任何前缀）
Severity（优先级） —
```
P0
```
、
```
P1
```
、
```
P2
```
、
```
P3
```
File:Line（文件:行号） — 代码位置（例如
```
src/main/auth.ts:172
```
）
Issue（问题） — 问题描述
Failure mode（故障模式） 或 Impact（影响） — 会出现什么问题
Recommended fix（推荐修复方案） 或 Suggested fix（建议修复方案） — 修复方法
Confidence（置信度） — 评审人员的置信度分数（如果有）

将所有评审人员的问题发现按优先级排序：P0 > P1 > P2 > P3。

对针对同一文件和行（或重叠行范围）的重复问题发现进行去重。如果两个问题发现引用相同的文件路径 AND 相同行号（或行号相差不超过5行） AND 描述相似类别的问题，则视为重复。去重后，保留所有ID，使用更详细的描述，并记录所有相关评审人员作为来源。

Step 4: Present findings and get confirmation

步骤4：展示问题发现并获取确认

Before applying any fixes, present the user with a prioritized summary:

Priority	ID(s)	Source	File:Line	Issue (1-line)	Action
P0	G-001	gemini	src/main/auth.ts:31	Plaintext token storage	Fix
P1	F-001	codex	src/main/index.ts:182	Stale auth target	Fix
...	...	...	...	...	...

Ask the user which findings to fix. Options:

All — fix everything P0-P2 (skip P3 unless trivial)
Blocking only — fix P0 and P1 only
Let me choose — user picks specific finding IDs

在应用任何修复之前，向用户展示按优先级排序的摘要：

优先级	ID(s)	来源	文件:行号	问题（单行描述）	操作
P0	G-001	gemini	src/main/auth.ts:31	明文存储Token	修复
P1	F-001	codex	src/main/index.ts:182	过时的认证目标	修复
...	...	...	...	...	...

询问用户要修复哪些问题。选项：

全部 — 修复所有P0-P2级别的问题（除非是 trivial 问题，否则跳过P3）
仅阻塞性问题 — 仅修复P0和P1级别的问题
让我选择 — 用户选择特定的问题ID

Step 5: Apply fixes

步骤5：应用修复

For each finding to fix (in priority order):

Validate the file path — confirm the path is relative and within the repository root. Reject any absolute paths or paths containing
```
..
```
that escape the repo
Read the file at the specified path and line — read at least 30 lines of surrounding context (15 above, 15 below) to understand the code structure
Design the fix using the reviewer's suggested fix as guidance, but verify it makes sense in context
Show the proposed fix to the user and ask for explicit confirmation before applying it
Apply the fix using Edit tool
Verify the fix doesn't break surrounding code or introduce new issues

Rules:

Do NOT blindly copy suggested fixes — they're guidance, not exact patches
If a fix requires changes across multiple files, make all related changes together
If a fix is unclear or would require significant refactoring beyond the finding's scope, skip it and mark as
```
deferred
```
in the resolution log
For P3 findings: only fix if the change is a single-line or obvious one-liner (e.g. rename, add a null check, fix a typo). Otherwise skip
After fixing deduplicated findings, note all IDs as resolved

对每个要修复的问题（按优先级顺序）：

验证文件路径 — 确认路径是相对路径且在仓库根目录内。拒绝任何绝对路径或包含
```
..
```
以跳出仓库的路径
读取文件 — 读取指定路径和行号的文件，至少读取30行上下文（上下各15行）以理解代码结构
设计修复方案 — 以评审人员的建议修复方案为指导，但要验证其在当前上下文中是否合理
向用户展示拟议的修复方案，并在应用前获取明确确认
使用Edit工具应用修复
验证 — 修复不会破坏周边代码或引入新问题

规则：

不要盲目复制建议的修复方案——它们是指导，不是精确的补丁
如果修复需要跨多个文件修改，同时进行所有相关修改
如果修复方案不明确或需要超出问题范围的重大重构，跳过该问题并在解决日志中标记为
```
deferred（延期）
```
对于P3级别的问题：仅当修改是单行或明显的小改动（例如重命名、添加空值检查、修复拼写错误）时才修复。否则跳过
修复重复的问题后，标记所有相关ID为已解决

Step 6: Update the resolution log

步骤6：更新解决日志

Write or update

.chalk/reviews/sessions/{session}/resolution.md

If the file already exists, preserve any metadata comments at the top. Fill in:

markdown

undefined

写入或更新

.chalk/reviews/sessions/{session}/resolution.md

。

如果文件已存在，保留顶部的元数据注释。填充内容：

markdown

undefined

Finding Resolution Log

问题解决日志

Summary

摘要

Session: {session}
Item: {inferred from session name}
Reviewers: {list of reviewer sources found — e.g. codex, gemini}
Decision owner:

会话：{session}
项目：{从会话名称推断}
评审人员：{找到的评审人员来源列表 — 例如 codex, gemini}
决策负责人：

Findings

问题发现

ID	Severity	Source	File:Line	Decision	Notes
G-001	P0	gemini	src/main/auth.ts:31	fixed	Wrapped token persistence with safeStorage
F-001	P1	codex	src/main/index.ts:182	fixed	Rebind auth target in createWindow

Decision values:

fixed
accepted-risk
deferred
not-repro

ID	优先级	来源	文件:行号	决策	备注
G-001	P0	gemini	src/main/auth.ts:31	fixed（已修复）	使用safeStorage包装Token持久化逻辑
F-001	P1	codex	src/main/index.ts:182	fixed（已修复）	在createWindow中重新绑定认证目标

决策值：

fixed（已修复）
accepted-risk（接受风险）
deferred（延期）
not-repro（无法复现）

Follow-up Tasks

后续任务

{deferred work, test gaps, items needing manual verification}

{延期工作、测试缺口、需要手动验证的事项}

Final Gate

最终检查

Build:
Tests:
Ready to merge: yes/no

undefined

构建：
测试：
可合并：是/否

undefined

Step 7: Summary

步骤7：总结

After all fixes are applied, show:

A results table:

ID(s)	Severity	Source	Status	What was done
G-001	P0	gemini	Fixed	Wrapped token persistence with safeStorage
F-001	P1	codex	Fixed	Rebind auth target in createWindow
G-004	P3	gemini	Skipped	Trivial but not blocking

The resolution log path
Suggest next steps:
- Run build/tests to verify nothing broke
- Run
```
/commit
```
  to commit the fixes
- If all blocking findings are resolved, create or update the PR

应用所有修复后，展示：

结果表格：

ID(s)	优先级	来源	状态	操作内容
G-001	P0	gemini	已修复	使用safeStorage包装Token持久化逻辑
F-001	P1	codex	已修复	在createWindow中重新绑定认证目标
G-004	P3	gemini	已跳过	属于小问题但不阻塞

解决日志的路径
建议后续步骤：
- 运行构建/测试以验证未引入问题
- 运行
```
/commit
```
  提交修复
- 如果所有阻塞性问题都已解决，创建或更新PR

Rules

规则

ALWAYS validate that file paths from findings are relative and within the repository root — reject absolute paths or paths with
```
..
```
escaping the repo
ALWAYS read the file with surrounding context before applying any fix
Do NOT modify files that aren't referenced in findings
Do NOT fix things that aren't in the findings — stay scoped
If multiple reviewers suggest conflicting fixes for the same issue, present both suggestions to the user and let them choose which approach to take
Keep fixes minimal — address the finding, don't refactor surrounding code
If build or typecheck breaks after a fix, attempt to resolve but note it in the resolution log

始终验证问题发现中的文件路径是相对路径且在仓库根目录内——拒绝绝对路径或包含
```
..
```
以跳出仓库的路径
应用任何修复前，务必读取包含上下文的文件内容
不要修改未在问题发现中引用的文件
不要修复问题发现中未提及的内容——保持范围
如果多个评审人员对同一问题提出冲突的修复方案，向用户展示两种方案并让其选择采用哪种方法
保持修复最小化——仅解决问题发现中的问题，不要重构周边代码
如果修复后构建或类型检查失败，尝试解决并在解决日志中记录