spec-probes

仕様のプローブ

検証ツールが確認するのは、存在するアサーションだけです。仕様に記載のない境界ケースについては、確信を持って誤った判断を下します。解決策は、より優れた検証ツールではなく、仕様の完全性です。コードを書く前に、各要件に対して次の2つのパスをこの順序で実行してください。

パス 1：境界プローブ

各要件のデータ形状を numeric-range、collection、text、stateful、io に分類します。その形状と交差するカテゴリだけを取り上げます。純粋なテキスト要件に、オーバーフローについて尋ねることはありません。分類体系を意図的に限定しています。著者が確認しきれる8つのカテゴリのほうが、誰も最後まで確認できない30のカテゴリより優れています。

カテゴリ	形状	確認事項
境界値	numeric-range	各最小値、最大値、しきい値ちょうど、およびその前後1ステップでは、どうなりますか？
隣接	collection	2つの要素が完全に等しい、またはちょうど接しているとき、それらはマージされますか、衝突しますか、それとも別々のままですか？
空／退化ケース	collection, text	空、単一要素、または null の入力に対する結果は何ですか？
エンコーディング	text	長さと等価性は、バイト、コードポイント、書記素クラスター、正規化形式のどれに基づいて判定しますか？
順序／安定性	collection	要素が等しいと判定された場合、出力順序は仕様で定められ、安定していますか？
精度／オーバーフロー	numeric-range	丸め、タイブレーク、精度損失、オーバーフローはどこで発生する可能性があり、正確な契約は何ですか？ half-up と half-even、floor と truncate のどちらですか？
冪等性	stateful	同じ入力に対してこれを2回実行した場合、どうなりますか？
並行性／効果の順序	stateful, io	中断された場合や並列実行された場合、何が保証されますか？

該当する形状がない文章上の要件には、項目を何も出さないのではなく、「未分類、手動で確認」というソフトな項目を1つ出します。

これによって検出できる欠陥の例：「重複する区間をマージする」だけでは、重なるのではなく接している [1,2] と [2,3] の扱いは決まりません。「最も近い整数に四捨五入する」だけでは、2.5 を2に丸める half-even の扱いが明示されません。「N文字に切り詰める」だけでは、文字がバイト、コードユニット、コードポイント、書記素のどれを指すのかが定まりません。

パス 2：禁止事項プローブ

境界形状からは、「リマインダーでユーザーを責めてはならない」といった事項を見つけられません。要件ごとに、**この機能が、著者の望まない形に気づかれないまま変質するとしたら、何が起こり得ますか？ それを仕様は禁じていますか？**と問いかけます。まずは幅広く洗い出してください。要件ごとに候補を10個挙げるのが目安です。

次に、精度を高めるためのパスを1回行います。

• 除外する：一般的なエンジニアリング上の事項。入力を変更してはならない、空入力で例外を投げてはならない、ハンドルをリークしてはならない、など。これらはパス1またはコードレビューで扱います。
• 残す：価値観、公平性、プライバシー、透明性、安全性に関する事項。責めるような表現を使ってはならない、保護対象の属性を代理変数として使ってはならない、生の PII を平文で保存してはならない、など。
• 独自に追加せず、参照する：専用ツールがすでに担当している事項（インジェクション、パストラバーサル、データ保持法、一般的なバイアスの原則など）。セキュリティまたはコンプライアンスの手順への手掛かりを1つ記したら、それ以上は続けません。

機能ごとの独自項目は2～3個が通常の成果です。純粋なユーティリティでは0個となり、それが適切な答えです。したがって、空でないリストには必ず意味のある情報が含まれます。

挙げた項目をすべて解決する

各項目は、次のいずれか1つの状態で終わらせます。

• 解決済み：受け入れ基準に答えが記載されている（explicit。通常のテストで確認する）。または、完全には記述できないと分かっている境界ケースの代わりとして、保留テストもしくはプロパティベーステストを用意する（backstop）。または、テストではなく人間の判断が必要な禁止事項に対して judgment を付ける。
• 却下：理由を付けます。「該当なし。入力は有界な列挙型であり、境界は存在しない」は有効ですが、何も記さずに済ませることはできません。その理由が監査証跡になります。
• 未解決：明示的なギャップとして引き継ぎ、計画で必ず明らかにします。黙って破棄してはなりません。

backstop と judgment のタグは、仕様自体に記載してください。後でレビューする人は、それらの項目を目視確認で通過させず、判断を保留します。タグがなければ、レビューする人には自分の見落としに気づけません。

回答：要件ごとに、挙げた項目とその状態を示してください。続いて、適用可能、解決済み、未解決の件数、および backstop または judgment が付いた件数を含むカバレッジ数を示してください。