在功能规格或 QA 规划阶段需要系统梳理失败场景时用：提前编…

适用于在功能开发前或 QA 规划时，为整个功能枚举异常输入、边界条件、错误状态、并发问题和恢复路径。

适用场景

解决思路

1. 定义功能范围：清楚描述要分析的功能或流程；边缘情况依赖上下文，同一输入在不同功能中可能有效或无效。
2. 走查输入校验：考虑每个用户输入——为空？过长？格式错误？包含特殊字符？有效最小值和最大值分别是什么？
3. 探索边界条件：找出可接受范围的边缘；若字段接受 1-100，则测试 0、1、100、101；考虑分页边界、超时阈值和速率限制。
4. 映射错误状态：识别可能出错的情况——网络失败、权限拒绝、资源未找到、并发修改、会话过期；记录场景和期望行为。
5. 考虑并发问题：如果两个用户同时操作？用户双击？加载和保存之间数据变化？竞态条件常导致隐蔽 bug。
6. 定义恢复路径：对每个错误指定用户如何恢复；看到什么消息？能否重试？数据是否保留？好的错误处理能把挫败转为信心。
7. 按可能性和影响排优先级：并非所有边缘情况都需要相同关注；高可能性 + 高影响需稳健处理；罕见 + 低影响可仅优雅失败。
8. 使用 references/TEMPLATE.md 中的模板组织输出；完整边缘情况目录应填满所有模板章节：Feature Overview；Edge Case Categories；Error Messages；Recovery Paths；Test Scenarios。
9. 最终确认前检查：所有用户输入都有校验边缘情况记录。
10. 最终确认前检查：边界条件已明确列出。
11. 最终确认前检查：网络/系统故障场景已覆盖。
12. 最终确认前检查：每个错误状态都有定义的用户可见消息。
13. 最终确认前检查：恢复路径已指定，而不只是错误检测。
14. 最终确认前检查：边缘情况已按可能性和影响排优先级。

适用边界 · 注意事项

• 需要 story 级别的 Given/When/Then 交接检查时，使用 deliver-acceptance-criteria；本技能编目整个功能的失败面。
• 功能尚未定义到可枚举输入、状态和限制时，先用 deliver-prd。
• 若已发生生产事故要沉淀学习，使用 iterate-lessons-log 后再更新本目录；若需要发布就绪协调，使用 deliver-launch-checklist。