spec-probes

规格探查

验证器只会检查已有的断言；对于规格从未说明的边界情况，它会自信地判断错误。解决办法不是换一个更好的验证器，而是补全规格。在编写代码前，按以下顺序对每项需求进行这两轮检查。

第 1 轮：边界探查

对每项需求的数据形态进行分类：numeric-range、collection、text、stateful、io。然后，只提出与其形态相符的类别。纯文本需求绝不会被问及溢出问题。分类法有意保持封闭：作者能逐一排查的 8 个类别，胜过没人能全部完成的 30 个类别。

类别	形态	问题
边界值	numeric-range	在每个最小值、最大值或阈值处，以及其前后各一步，具体会发生什么？
邻接	collection	两个对象恰好相等或刚好接触时，它们会合并、冲突，还是保持分离？
空 / 退化情况	collection, text	输入为空、只有一个元素或为 null 时，结果是什么？
编码	text	长度和相等性依据谁的定义：字节、码点、字素簇，还是规范化形式？
顺序 / 稳定性	collection	元素比较结果相等时，是否规定输出顺序，且顺序是否稳定？
精度 / 溢出	numeric-range	哪些情况下可能发生舍入、平局处理、精度损失或溢出？具体契约是什么：四舍五入还是银行家舍入，向下取整还是截断？
幂等性	stateful	对同一输入运行两次会发生什么？
并发 / 效果顺序	stateful, io	如果操作被中断或并行运行，能保证什么？

有文字描述但没有匹配形态的需求，只添加一条宽泛的“未分类，手动审查”事项，不要保持沉默。

这种方法能发现的缺陷：“合并重叠区间”没有说明 [1,2] 和 [2,3] 这类仅仅接触的区间该如何处理。“四舍五入到最近值”没有说明 2.5 按银行家舍入取为 2。“截断为 N 个字符”没有说明字符指的是字节、代码单元、码点还是字素。

第 2 轮：禁止项探查

边界形态无法发现“提醒不得让用户感到羞愧”这类要求。针对每项需求，询问：这项功能可能悄然变成什么，而作者并不希望如此，却又未在规格中禁止？ 先广泛发散；每项需求提出 10 个原始候选项是预期之内。

然后进行一轮精炼：

• 删除常规工程事项：不得修改输入、空输入不得抛出异常、不得泄漏句柄。这些属于第 1 轮或代码审查。
• 保留涉及价值、公平、隐私、透明度和安全的事项：不得采用羞辱式措辞，不得以受保护属性作为代理变量，不得以明文存储原始 PII。
• 转交，不要新建， 专用工具已负责的事项（提示注入、路径遍历、数据保留法规、通用偏见准则）：在安全或合规步骤留一条线索，然后停止。

每项功能通常会筛出两三条专属事项。纯工具函数筛出零条也很正常，而且这就是正确答案；因此，非空列表总是有所提示。

解决所有提出的事项

每项事项最终必须处于以下一种状态：

• 已解决：验收标准明确说明了答案（explicit，由常规测试检查）；或有一项保留测试或基于属性的测试，用来覆盖你已知但无法完整写清的边界情况（backstop）；或对于需要人工判断而非测试的禁止项，标记为 judgment。
• 已驳回，并说明理由。“不适用，输入是有界枚举，不存在边界”是有效理由；保持沉默则不行。理由就是审计记录。
• 未解决：作为明确的缺口保留，并要求计划中呈现，绝不可悄然丢弃。

在规格本身写入 backstop 和 judgment 标签。之后的审查者会对这些事项弃权，而不是仅凭检查就判定通过；没有标签，审查者就无法识别自身的盲点。

回复： 按每项需求列出提出的事项及其状态；然后给出覆盖计数：适用项数、已解决项数、未解决项数，以及标记为 backstop 或 judgment 的项数。