既存挙動を保護しながら、計画に基づいてプロダクションコードの実装前にテストを作成してください。
Workflow Contextに示されたReport Directory内のファイルのみ参照してください。他のレポートディレクトリは検索/参照しないでください。

**重要: プロダクションコードは作成・変更しないでください。テストファイルのみ作成可能です。**

**やること:**
1. 計画レポートを確認し、要求で変わる挙動と変えてはいけない既存挙動を分ける
2. 対象モジュールの既存コードと既存テストを確認し、テストパターンを把握する
3. 既存契約を守る回帰テストが不足している場合は追加する
4. 計画された機能または修正に対する単体テストを作成する
5. インテグレーションテストの要否を判断し、必要なら作成する
   - 3つ以上のモジュールを横断するデータフローがあるか？
   - 新しいステータス／状態が既存ワークフローに合流するか？
   - 新しいオプションが呼び出しチェーンを通じて末端まで伝搬するか？
   - いずれかに該当すればインテグレーションテストを作成する

**テスト作成の方針:**
- プロジェクトの既存テストパターン（命名規約、ディレクトリ構成、ヘルパー）に従う
- Given-When-Then 構造で記述する
- 1テスト1概念。複数の関心事を1テストに混ぜない
- 正常系・異常系・境界値・エッジケースを網羅する
- 既存期待値を実装都合に合わせて緩和しない
- 外部契約がある場合は、契約どおりの入力位置を使ったテストを含める
  - 例: request body は定義された root shape のまま渡す
  - 例: query / path parameter は body に流用せず、本来の位置から渡す
- レスポンス標準の envelope をリクエスト解釈へ流用した実装を見逃さないテストを含める
- テストは実装完了後にパスすることを前提に書く（この段階ではビルドエラーやテスト失敗は想定内）

**非実行資産に関する制約:**
- 説明文、ガイド、README、Markdown ドキュメントなどの本文・章タイトル・構成を固定するテストは作成しない
- docs-only 変更では、明示的な実行契約がない限りテストを追加しない
- テストが必要なのは、CLI例・設定例・生成物など、コードの挙動や機械処理と結びつく契約がある場合に限る

**テスト実行について:**
- テスト作成後、テストを実行して結果を確認する
- 実装前のためテスト失敗・import エラーは想定内（未実装モジュールの import を含む）
- 既存モジュールの import パスミスなど、実装完了後も解消しないエラーは修正する

**必須出力（見出しを含める）**
## 作業結果
- {作成・更新したテストの要約}
## 保護した既存契約
- {テストで守った既存挙動}
## テスト結果
- {実行した場合はコマンドと結果。未実行の場合は理由}
