deliver-edge-cases

边界情况

边界情况文档会系统地列举某项功能中不常见、处于边界以及错误场景。虽然正常流程通常有明确的规范，但边界情况往往要到生产环境中才会被发现，进而导致 Bug、糟糕的用户体验和额外的支持负担。提前记录边界情况，有助于确保工程团队有意识地处理这些情况，并让 QA 知道需要测试什么。

适用场景

• 需要列举故障模式、竞争条件、超时，以及边界或限制场景——也就是所有可能出错的情况——并为每种情况定义恢复路径时
• 工程工作开始前编写功能规范时
• 准备 QA 测试计划时
• 发现生产环境中的 Bug 后，为防止类似问题再次发生时
• 检查 PRD 或用户故事是否完整时
• 发布前确保错误状态已设计妥当时

不适用场景

• 需要针对用户故事编写用于交接的 Given/When/Then 检查项 -> 使用 deliver-acceptance-criteria；此技能用于梳理整个功能的故障范围
• 功能规范不够充分，无法列举输入、状态和限制 -> 先使用 deliver-prd
• 生产事故已经发生，并且想记录经验教训 -> 使用 iterate-lessons-log，然后将新情况补充到此目录中
• 需要为发布协调准备工作，而非分析故障 -> 使用 deliver-launch-checklist

说明

收到记录边界情况的请求时，请按以下步骤操作：

1. 定义功能范围 清楚描述你要分析的功能或流程。边界情况与具体上下文有关——相同的输入在某项功能中可能有效，在另一项功能中则可能无效。

2. 逐项检查输入验证 考虑每个用户输入：如果输入为空怎么办？过长怎么办？格式错误怎么办？包含特殊字符怎么办？有效值的最小值和最大值是多少？

3. 探索边界条件 找出可接受范围的边界。如果某个字段接受 1–100，请测试 0、1、100 和 101。还要考虑分页边界、超时阈值和速率限制。

4. 梳理错误状态 找出可能出错的情况：网络故障、权限被拒绝、资源不存在、并发修改、会话过期。记录场景和预期行为。

5. 考虑并发问题 如果两个用户同时操作会怎样？如果用户双击会怎样？如果数据在加载和保存之间发生变化会怎样？竞争条件经常会导致不易察觉的 Bug。

6. 定义恢复路径 针对每种错误，说明用户如何恢复。他们会看到什么消息？能否重试？数据会保留吗？良好的错误处理能化解挫败感，建立信心。

7. 按发生可能性和影响进行优先级排序 并非所有边界情况都需要同等关注。发生可能性高、影响大的情况需要稳健处理；罕见且影响小的情况可能只需优雅地失败。

输出格式

使用 references/TEMPLATE.md 中的模板来组织输出。完整的边界情况目录应填写模板中的每个部分：功能概述、边界情况类别、错误消息、恢复路径和测试场景。

质量检查清单

完成前，请确认：

• 已记录所有用户输入相关的验证边界情况
• 已明确列出边界条件
• 已涵盖网络／系统故障场景
• 每种错误状态都有面向用户的消息
• 已指定恢复路径（而非仅检测错误）
• 已按发生可能性和影响对边界情况进行优先级排序

示例

已完成的示例请参见 references/EXAMPLE.md。