briefbound-bug-review

Briefbound Bug Review

目标

直接承接 bug 诊断与契约内修复：先用证据定位根因，再做最小修复和风险相称的验证。不要求展示固定阶段、长检查表或完整思维过程。

Briefbound task contract

• Context Boundary: 预期行为、实际症状、失败命令/日志、相关代码与测试、允许修改面和非目标。
• Output Contract: 根因状态、证据链、最小修复或下一 probe、影响范围、验证结果和剩余风险。
• Allowed Action: 用户要求修复且边界清楚时可直接读取、复现、修改和验证；只要求审查时保持只读。
• Success Evidence: 失败可复现或有等价证据，根因与修复存在因果联系，目标验证通过且未越界。
• Stop Condition: 缺少必要对象/权限、根因仍不稳定且写入会扩大误改、需要破坏性动作、需求冲突或风险越过当前授权。
• Route Out: 契约内修复、root-cause-tracing、briefbound-performance-engineering、briefbound-planning、briefbound-development-cleanup、briefbound-pr-review、briefbound-router 或 BLOCKED。

统一调用契约

• 只处理 Briefbound task contract 范围；不匹配时回 briefbound-router 或更具体 owner，复合任务不吞其他 owner。
• 用户可见内容默认中文，完成只报状态、产出、证据和剩余风险；代码、命令、路径、错误原文、API/协议、skill 名和枚举保留原样；Route Out 仅以 Briefbound task contract 为准，末行写 下一步建议: <一个具体动作>。

调试契约

1. 写清 Expected / Actual / Scope，先读本地可得的代码、日志、失败测试和近期 diff。
2. 优先复用现有失败测试或稳定复现；无法直接运行时，用调用链、状态变化或日志建立最窄证据链。
3. 定位 owning surface，沿数据流或控制流追到最早错误来源。来源藏在深层链路时才加载 root-cause-tracing。
4. 可直接确认的 N+1、循环 I/O、重复计算等明显低效留给当前 owner；已观察故障、正确性回归或根因不明才由本 skill 诊断；可测性能问题路由 briefbound-performance-engineering。
5. 标记根因：CONFIRMED / HYPOTHESIS / ENVIRONMENT / TEST_ISSUE / REQUIREMENT_MISMATCH。只有 CONFIRMED 才进入行为修复；其他状态继续低风险 probe 或路由正确 owner。
6. 用户已授权修复且根因、边界、回滚和验证清楚时，直接做最小修复；不为流程形式停下确认。
7. 运行能证明因果关系的窄验证，再按影响面决定是否扩展。区分实现失败、测试意图过期、环境失败和需求不一致。

Bug 测试锚点

Bug 修复不转交 TDD owner。已有失败测试或稳定复现直接作为 RED；若回归风险显著且没有自动化证据，在当前 owner 内补一个最小行为测试，确认它因目标缺陷失败后修复并得到 GREEN。局部、可逆且现有验证足够时直接修复，不为形式制造 RED。

测试只证明已确认的预期行为，不替代根因诊断。测试意图过期时标记 TEST_ISSUE，需求不一致时标记 REQUIREMENT_MISMATCH，不得为了 GREEN 固化旧约束。

流程重量

简单、局部、可逆问题直接修复并验证，不 planning、拆分或创建 worktree。只有真实设计分叉、跨系统迁移或边界不稳才进入 briefbound-planning；多文件或复杂调用链本身不升级流程。

输出

普通修复只需汇报：根因 / 修改 / 验证 / 剩余风险 / 下一步建议。只读审查或阻塞时再补：

Bug 判断:
- 根因状态:
- 关键证据:
- 影响范围:
- 建议动作:
- 停止条件:
下一步建议: <一个具体动作>

不得为了让测试通过而削弱正确行为，也不得在根因仍是猜测时堆叠补丁。