simplify

simplify - 质量门禁阶段

不变原则

• 仅审查任务范围和已更改的文件。
• 不得增加新的产品范围。
• 在测试前阻止重大偏差。
• 将需要长期留存的发现写入任务文档。
• 如果任务文档包含 Implementation Notes 一节，但 TASKS.md 中的任务行仍显示为 Planned 或 In Progress，则继续操作前将该行状态更新为 Testing——实现已运行，但遗漏了任务跟踪器的更新。如果没有 Implementation Notes，则不要更新状态；这表示实现实际上并未运行，应告知用户。

运行时适配器可以将此阶段呈现为斜杠命令、菜单操作或自然语言技能调用。可移植的阶段名称为 simplify。

工作流

1. 阅读 AGENTS.md。
2. 确定任务 ID，并阅读 docs/task/{ID}-{task-name}.md。
3. 根据 Implementation Notes 和 git diff --name-only 确定已更改的文件。
4. 仅阅读已更改的文件。
5. 检查编码标准和可维护性。
6. 对照需求、文件变更、范围外边界和验收标准检查实现。
7. 对偏差进行分类。
8. 将 Quality Gate Notes 追加到任务文档。
9. 返回 PASS 或 FAIL。

没有任务文档

对于用户直接提出的小改动，且没有 docs/task/ 文档（快速修复或润色）：

• 根据用户请求审查相对于基准分支的差异（git diff），而不是任务文档。
• 应用相同的标准检查清单和偏差等级。“范围”即用户提出的需求。
• 将结果（PASS/FAIL、发现和偏差）记录在拉取请求正文或提交消息中，而不是新建任务文档。
• 除非项目要求，否则不要为此创建 TASKS.md 任务行。

标准检查清单

在适用时检查：

• 没有未使用代码、死代码或注释掉的实现
• 项目有类型化替代方案时，不使用宽泛的 any 或无类型的逃逸机制
• 避免深层嵌套；如有必要，使用卫语句以提高可读性
• 函数和文件职责明确
• 名称能准确描述行为
• 重复逻辑会增加维护风险时，应提取复用
• 有意处理错误
• 生产路径中没有密钥、凭据或调试日志
• 有意更新断言旧行为或旧措辞的测试，并添加说明原因的注释，绝不可直接删除
• 新增或更改的测试应尽可能检查行为或输出；仅断言源文本或结构的测试应标记为证据薄弱
• 任务文档中的每项验收标准都必须有可能失败的检查；标记任何没有检查的标准
• 遵循 AGENTS.md、LEARNINGS.md 和任务文档中的项目约定

偏差分类

级别	含义	结果
Minor	满足范围要求的细微实现差异。	记录并继续。
Medium	应让用户知晓的实质性差异。	仅在风险可接受时记录并继续。
Major	违反需求、扩大范围，或未经批准更改架构。	FAIL 并停止。

在任务文档中的输出

## Quality Gate Notes

### Result
PASS | FAIL

### Standards Review
- {Finding or "No blocking issues"}

### Deviations
- {Deviation level and rationale}

### Required Fixes
- {Only if FAIL}

交接

PASS：

Quality gate passed for task {ID}
Next stage: test {ID}

FAIL：

Quality gate failed for task {ID}
Return to implementation with the required fixes listed in the task document.