1TDD実装1

Prompt file imported from masakinihirota/masakinihirota-github (.github/prompts/1TDD実装1.prompt.md). Copyright stays with the author.

このプロンプトは masakinihirota リポジトリ上で TDD（RED→GREEN→REFACTOR） を厳格に実践するためのエージェント実行指示です。 実装は必ず最小単位に留め、コロケーション規約を守り、1 作業単位につき「失敗するテストを必ず 1 つだけ追加する」ことを強制してください。

目的

IMPORTANT: このプロンプトは mvp_tasks.md に記載された要件に基づき、TDD サイクルを通じてコードを実装することを目的としています。

最重要ルール（必ず守る）

1. 最小の失敗テストを 1 つだけ追加する（RED）:
   • 一度の変更で追加してよい「失敗するテストケース」は必ず 1 つのみ です。
   • 複数のテストを一気に追加したり、最初からパスするテストを追加することは禁止します。
2. TDD サイクルを守る: RED（失敗確認）→ GREEN（実装して成功）→ REFACTOR（整理）の順序を厳守してください。
3. コロケーション: テストは実装ファイルと同じディレクトリに配置してください（例: src/components/Foo/Foo.test.tsx）。
4. DB テスト: ユニット／UI テストは常に実行しますが、DB 統合テストはローカル Supabase 環境（RUN_DB_TESTS=1）でのみ実行してください。
5. アトミック性: 1 変更で複数の独立機能を同時に追加しないでください。

実行手順（必須フロー）

1. 要件特定: mvp_tasks.md を読み、次に実装すべき「最小の機能単位」を特定する。

2. RED（テスト作成）:

   • 最小の失敗テストケースを 1 つだけ src/.../<Target>.test.(ts|tsx) に追加する。
   • runTests を実行する。
   • 検証:
     • 追加したテストが 期待通りに失敗すること を確認する。
     • もしテストがパスしてしまった場合は、テストコードが間違っているか、テスト対象が適切でないため、修正する。
     • コンパイルエラー（型エラー等）でテストが実行できない状態は RED とみなさない。最低限テストが走る状態（スタブ作成など）にしてから失敗させること。

3. GREEN（実装）:

   • edit で最小限の実装を追加し、runTests を再実行して該当テストをパスさせる。
   • この段階ではコードの美しさよりも「テストを通すこと」を優先してよい。

4. REFACTOR（リファクタリング）:

   • テストが通った状態で、可読性向上・重複排除・型安全性の改善を行う。
   • 必要な場合、supabase/generate_typescript_types を実行して型定義を更新する。
   • 重要: 機能（振る舞い）を変えてはならない。リファクタリング後に再度 runTests を行い、全てのテストが GREEN であることを確認する。

5. 自動チェックとレビュー:

   • 静的解析（lint等）を実行し、問題がないか確認する。
   • 自身の変更に対し、以下の観点で自己レビューを行う:
     • 新規に追加された「失敗 → 成功」したテストケースは 1 つか？
     • 既存の他のテストを壊していないか（回帰テスト）？

6. 完了記録:

   • 問題がなければ、serena/* を使用して作業ログ、変更ファイル一覧、RED→GREEN の証跡を残す。
   • 完了したタスクがあれば mvp_tasks.md にチェックマークを入れてください。
   • ユーザーには問題が発生するなどのトラブルがない限り実装すべき項目が終わるまで指示を仰ぐのは禁止。
   • まだ実装すべき項目が残っている場合は、次の TDD サイクルへ進む。

出力フォーマット（完了時）

以下の情報を構造化して出力すること：

1. 変更ファイル一覧（フルパス）
2. TDD 実行ログ要約:
   • 追加したテスト名: Describe > It should ...
   • RED 時のエラーメッセージ抜粋
   • GREEN 時の成功確認
3. 実装内容の要約（1-3 行）
4. 次アクションの提案:
   • 次に実装すべきテストケースの提案
   • または、残作業の確認

ガードレール（自動チェック）

• エージェントは testFailure ツールまたはテスト実行ログの解析を通じて、「今回追加された失敗テスト数が 1 であること」を常に監視してください。

  • 具体的には、テスト実行時の失敗数を検査するか、直近の Git diff で "新規追加されたテストのうち FAIL している数" を検出してください。
  • テスト実行ログからの判定では、ファイル単位で新規作成されたテストファイルの中で失敗している count===1 を期待値とします。
  • 自動判定で不確実な場合は、該当テストファイルの名前と一つだけ失敗していることのスクリーンショット（ログ抜粋）を作業証跡として残してください。

  ※ 参考／自動化補助: リポジトリには scripts/check-new-tests.js と npm スクリプト pnpm check:new-tests を追加しました。これは

  • Git の差分（origin/main...HEAD）から新規に追加されたテストファイルを検出し、
  • それらに対して vitest --reporter=json を実行して JSON を解析し、"新規に追加された失敗テスト" の数を取得します。
  • 成功条件は new failing test count === 1 です（違う場合は非ゼロ終了コードで失敗します）。

  Agent は内部チェックとして pnpm check:new-tests を呼び出して厳密判定を行うことができます（CLI／CI どちらでも利用可）。

integration テストの取扱い（明確化）

• Integration / DB 必須テストの規約:
  • integration レベルのテストは必ず tests/integration/** 配下に配置してください。
  • Integration テストはローカル DB / Supabase に依存するため、実行するときは必ず環境変数 RUN_DB_TESTS=1 を付けてください。CI で自動的に走らせないことを強制します。
  • Agent が integration テストを走らせる場合は、RUN_DB_TESTS の有無をチェックし、無い場合はスキップして下さい（失敗とみなさない）。

完了時のコミット／更新ルール（自動化しやすく）

• 作業完了時のコミットメッセージテンプレート（推奨）:
  • TDD: complete <mvp_tasks.md#TaskIdentifier> — <short-description>
  • 例: TDD: complete mvp_tasks.md#Task 5.1.1 — ignore resource-scoped exceptions for global checks
• 作業後は mvp_tasks.md の該当行にチェックを入れ、変更のコミットに必ず含めてください。Agent は mvp_tasks.md の該当タスク行を更新することを忘れないでください。

変更検証とエビデンス

• Agent は RED→GREEN→REFACTOR の各ステップのログ（コマンドの結果）を作業証跡として保存または serena/* に記録してください。ログは短い抜粋でよいので、RED の失敗メッセージ、GREEN のテスト成功行、最後に lint 結果を含めてください。

タスク整合性ルール（必須）

実装と mvp_tasks.md のチェックマークが一致していないことは混乱の元です。以下のルールを必ず守ってください。

1. 実装後の検証

   • RED→GREEN→REFACTOR の各サイクルが完了したら、必ず mvp_tasks.md を確認し、該当する項目のチェックマークが現実の実装状態を正しく反映していることを確認してください。
   • もしチェックマークが事実と異なる場合（未実装なのにチェックが入っている、実装済みなのにチェックがない等）は、修正（チェックの追加/除去）を行い、その理由をコミットメッセージと serena の作業ログに残してください。

2. 指示が不足している場合の対応

   • mvp_tasks.md に「次に何をするか」の記述がない、もしくは曖昧な場合は、この jisou.prompt.md に短く明確な実行指示（1〜2 行）を追記してください。指示は日本語で、目的と最小の RED テストを書いた後の次アクションを示すこと。
   • 追記した指示は TDD の流れ（RED→GREEN→REFACTOR）で実施可能であることを確認し、対応するテスト／実装ファイルパスも併記してください。

3. ドキュメント編集の運用ルール

   • ドキュメント（mvp_tasks.md）の変更は必ず小さなコミットで行い、変更理由を説明するコミットメッセージを付してください。
   • 変更によってテストや CI に影響がある場合は、必ずローカルでテストを実行してからコミットしてください。

これらのルールを守ることで、実装状況とタスクリストを一貫して保てます。