spec-checklistlisted

# 設計書品質チェックリスト 「コードが動くか」ではなく「設計書自体が良く書けているか」を検査する。 /ml-pipeline では Planner の計画作成後に**必ず**自動実行される(手順3.3)。 単独でも「設計書をチェックして」で呼べる。 ## 検査対象 - 設計書がある場合: docs/drafts/ または docs/active/ 配下の設計書 + Planner の計画 (トレーサビリティ表が全 R-ID を覆っているかもカバレッジ次元で見る) - 設計書が無い場合(直接依頼のパイプライン): Planner の計画そのものを検査する。 このとき「完全性」は計画の検証方法・リスクセクションに対して、 「カバレッジ」はトレーサビリティ表ではなく「全ステップに検証方法があるか」に読み替える ## 検査の5次元 各次元について、設計書(または計画)の該当箇所を引用しながら判定する。 | 次元 | 検査内容 | 例 | |------|---------|-----| | 完全性 | 曖昧性タクソノミーの全カテゴリ(境界値・例外系・状態・順序・データ・非機能・スコープ境界。研究系なら仮説・変数・ベースライン・成功基準・再現性も)に答えが書かれているか | 「NaN 入力時の挙動が書かれていない」 | | 明確性 | 解釈が一意か。「適切に」「なるべく」「高速に」「必要に応じて」等の曖昧語が残っていないか | 「『十分な精度』→ 数値で定義されていない」 | | 一貫性 | 設計書内で矛盾する記述が無いか。用語が CONTEXT.md と一致しているか | 「§2 では bag 単位、§4 ではインスタンス単位と書かれている」 | | 測定可能性 | 受け入れ条件テーブルの全要件が、実行コマンドまたは明確な目視基準で検証可能か。期待結果が機械照合できる形式か。計画に『事後条件』欄があり、各事後条件が実行コマンドで機械照合できる形か(実装を見る前に固定できる内容になっているか) | 「R-003 の期待結果『改善する』→ 数値条件になっていない」/「PC-2 の満たすべき条件が『問題なく動く』→ 機械照合できる形になっていない」 | | カバレッジ | 本文に書かれた全ての決定・要件が、受け入れ条件テーブルの R-ID に対応しているか(本文にあるのにテーブルに無い要件は漏れ) | 「§3 の seed 固定の記述に対応する R-ID が無い」 | ## 進め方 1. 作業スコープ直下に CONTEXT.md があれば先に読む。 2. ��象の設計書(無ければ Planner の計画)を読み込む。 3. 5次元を1つずつ順に検査する(複数を同時に浅く見ない)。 4. 指摘には必ず設計書(または計画)の該当箇所(セクション名や引用)を添える。 ## 出力形式 ### 設計書品質チェック結果 - 対象: <設計書のパス。設計書が無い場合は計画ファイルのパス> - 総合判定: **READY**(指摘なし or LOW のみ) / **NEEDS_WORK**(MEDIUM 以上あり) | 次元 | 判定 | 指摘 | |------|------|------| | 完全性 | OK / NG | [重大度] 指摘内容(該当箇所) | | 明確性 | OK / NG | ... | | 一貫性 | OK / NG | ... | | 測定可能性 | OK / NG | ... | | カバレッジ | OK / N