@see2et

大きな「やりたいこと」を、1Spec=1PRとしてレビュー可能・検証可能・安全にマージ可能なサイズへスライスする。ここでは具体的な仕様書（受入条件の詳細化・テスト観点の網羅・docs/specs/* の作成）は行わない（それは sdd-init / sdd-test-cases の責務）。出力は「スライス案（S/M/L）」「推奨スライス」「前提・制約・リスク・未決事項」「次フェーズへの入力（sdd-init に渡す要点）」に限定する。

sdd-initで作成したSpecドラフトを入力として、TDDを回せるだけのテスト観点（ハッピー/代表的失敗/境界/不変条件/非機能）をSpecに網羅する。ここではテスト実装・プロダクション実装は行わない。スコープ変更・要件追加もしない（必要なら未決事項として質問を起票し、合意が取れるまでTDDへ進ませない）。出力は「Specの更新（テスト戦略・テストケース一覧・カバレッジチェック）」「ブロッカー/未決事項」「tdd-redに渡す“次に書くべきテスト1つ”候補」に限定する。

Rustでのエラー設計を、境界ごとに thiserror / anyhow を使い分けて実装する。ドメイン/ライブラリは型付きエラー(thiserror)、アプリ境界のみ anyhow。context付与、unwrap禁止、HTTP/CLI変換、Clone運用の指針を含む。