confess

自检坦白

一项系统化的自查技能，鼓励 Agent 诚实地发现并披露自己可能知道但尚未提及的问题。尤其适合坦白奖励利用并承认错误。

适用时机

• 完成实现工作后
• 感觉有内容尚未完成时
• 将任务标记为“完成”之前
• 用户询问“我漏了什么？”或“坦白吧”时

坦白类别

1. 未完成的工作

搜索可能也需要修改的相关文件：

• 使用 grep 查找对已修改代码的引用
• 检查是否需要更新测试
• 查找引用了行为变更的文档

2. 未经测试的假设

如实说明实际验证了哪些内容：

• 你运行了代码，还是只进行了构建？
• 是否测试了错误路径？
• 哪些边界情况未考虑？

3. 模式违规

与现有代码库进行比较：

• 使用 glob 查找类似实现
• 新代码是否符合现有模式？
• 是否忽略了框架的最佳实践？

4. 隐瞒的发现

揭示已注意到但未提及的事情：

• 发现但未提出的潜在问题
• 对方案的顾虑
• 未披露的权宜之计
• 引入的技术债务

5. 清理债务

检查是否有孤立代码：

• 应删除的死代码
• 未使用的导入／依赖项
• 孤立的文件／路由

对抗式立场

不要问“我漏了什么？”——这个问题会让人自我辩解。

采用怀疑者的姿态：假设遗漏了某些内容，然后寻找证据来证实。你的任务是推翻自己“已完成”的说法。怀疑者因错误地排除问题而受罚，而不会因检查周全而受罚。

结束前，逐项检查：

• 对你更改的每个符号运行 Grep——所有调用方都已更新吗？
• 测试套件确实覆盖了更改路径，还是只导入了它？
• 是否引入了任何未记录的新导入／依赖项？
• 是否有你注意到却因难以启齿而未提及的内容？
• 如果有人只撤销你最近一次提交，会导致什么问题？

工作流

1. 收集上下文

   # What files were recently modified?
   git diff --name-only HEAD~1
   
   # What functions/exports changed?
   git diff HEAD~1 --stat
   

2. 搜索引用

   # Find all references to modified code
   grep -r "functionName" --include="*.ts" --include="*.tsx"
   

3. 比较模式

   • 在代码库中查找类似文件
   • 比较实现方案
   • 记录任何不一致之处

4. 验证检查

   • 列出实际测试过的内容
   • 列出假定可正常工作的内容
   • 列出需要手动验证的内容

5. 披露全部情况 按以下格式坦白：

   ## My Confessions
   
   ### Incomplete Work
   - [specific issue]
   
   ### Untested
   - [what wasn't verified]
   
   ### Pattern Issues
   - [inconsistencies found]
   
   ### Hidden Concerns
   - [things I noticed but didn't mention]
   
   ### Cleanup Needed
   - [dead code, orphaned files]
   

核心原则

1. 专为对抗式检查而设计——你要做的是找出自己的问题，而不是安慰自己
2. 做最坏的打算——总有某些内容未完成、未经测试或被掩盖
3. 借助工具 - 使用 grep/glob，不要依赖记忆
4. 系统化 - 每次都覆盖所有类别
5. 诚实 - 不确定时就直说
6. 可执行 - 每条坦白都应提出修复建议

输出示例

实现 OAuth 错误处理后：

我的坦白

未完成的工作

• 修改了 auth-config.ts，但 oauth2/authorize/page.tsx:173 仍会重定向到 /error/oauth
• proxy.ts:67 也引用了旧的错误路由
• lib/oauth-errors.ts 中的 redirectToErrorPage() 函数仍在使用旧模式

未经测试

• 只运行了 bun run build，没有实际测试 OAuth 错误流程
• 没有验证首页是否能使用真实错误参数显示错误

模式问题

• 首页直接使用 useSearchParams，但其他页面会将它提取到 Suspense 包装的组件中
• 参考：oauth2/authorize/page.tsx、device/page.tsx 中的正确模式

隐藏的顾虑

• /error/[type] 错误页面设计完善且仍在使用
• 删除 onAPIError 可能不是正确的做法

需要清理

• 需要决定：将错误处理完全迁移到首页，还是保留 /error/oauth 路由