业务规则与验证

沿正常、结束与异常情形形成可检查的业务规则，在产品文档维护依据，在逻辑原型中呈现关键条件与结果。

写清条件、动作与结果

简单规则用一句话，条件组合多时用表格，状态复杂时用状态图：

〔前置条件／角色状态〕→〔触发动作〕→〔预期业务结果〕

例如：“已有名称或 URL 包含 github 的书签；搜索 github；结果包含所有匹配书签并排除不匹配项。”按任务明确大小写、排序等会影响结果的规则。

重点检查数据变更成功的含义、角色对对象的权限、授权结束后的结果，以及失败或结果未知时的处理。性能承诺注明测试条件与依据。

按风险补齐情境

先走通正常任务，再按发生可能性、后果和可恢复性检查相关分支：

风险信号	需要决定的问题
网络依赖、长耗时、结果未知	中断后是什么状态？输入如何保留？如何核实结果？
重复触发、并发编辑	如何识别同一次操作？冲突怎样处理？
权限与不可信输入	谁可操作什么对象？无效输入如何处理？
放弃、删除、关联数据	未完成数据与关联对象怎样处理？是否允许恢复？

例如，保存前断网和请求发出后失联需要不同政策：前者可以保留输入并提示重试，后者需先核实是否已保存。取消操作则应明确取消编辑、停止等待还是停止远端执行，以及最终业务结果。

产品层确定结果，engineering-design 确定兑现这些结果的机制。建议政策经决定后写入规则，模板见业务规则写法。

选择验证并处理差异

规则讨论采用具体案例与逻辑原型走读，交互未知采用体验原型，状态与权限能力采用实际操作或自动化测试。支付、权限、数据丢失等高后果场景重点检查失败、重复和恢复。

差异分为规则含糊、实现偏离或原决定不再适用：分别修正规则、修复实现或重新讨论取舍。规则变化同步更新当前原型，重要目标或范围变化请用户确认。

记录检查条件、观察结果及证据覆盖范围；模拟行为、实际执行和待验证能力分别标明。