tcrdd

TCRDD

ネイティブの git を使って、レッド／グリーン／リファクタリングを進めます。各フェーズでステージングしてテストを実行し、期待どおりの結果なら自動コミットし、そうでなければ自動的に元に戻します（git reset --hard）。外部ツールは不要です。

事前条件：クリーンなツリーから開始してください。未コミットの変更や未追跡ファイルがない状態にします。 元に戻す処理（git add -A ＋ git reset --hard）は未追跡ファイルを削除し、reflog からも復元できないため、サイクル開始時に存在する未追跡ファイルは失われます。残しておきたいファイルは、最初の add -A の前に git stash -u（または専用の worktree）で退避してください。

モード

• インタラクティブ（人間がループに参加している）：以下の承認ゲートを使用します。まず計画の承認を得てから、各ステージング・テストサイクルの前に差分の承認を得ます。
• 自律（無人での実行など、人間による承認が得られない）：そのままループを実行してください。 承認ゲートは任意です。省略して続行してください。フェーズごとにコミットし、一度に一つの小さなステップだけを進めます。決して、得られることのない承認を待って停止しないでください。

重要なガードレール

• RED／GREEN と宣言したりコミットしたりする前に、実際のテストランナーの実行結果全体を確認してください。予測を根拠に先へ進んではいけません。
• 無人実行でも、各フェーズで進めるのは小さなステップ一つだけにしてください。テストスイート全体や実装をまとめて実行・実装してはいけません。
• テスト前に git add -A でステージングしてください。そうすれば、失敗したステップで新規ファイルも元に戻せます。リセット前に失敗の詳細を記録し、その後 tcr-failure-log.md に追記して、ログを別途コミットしてください。フェーズを実行する前にgit サイクルを読んでください。
• リポジトリのテストコマンドを一度特定し（パッケージのスクリプト、Makefile、言語の慣習、次に README／CI、または確認を依頼）、各フェーズで同じ CI テストスイート全体を再利用してください。ただし、ユーザーが明示的に対象を限定している場合を除きます。
• 自律実行では、予算を設定し、並行エージェントには隔離された worktree を使い、フェーズのコミットにタグを付け、予算に達したら停止してください。同じステップで元に戻す処理が2回を超えたら、ステップを分割してください。さらに分割した後、2回目の試行が停滞した場合は中断し、ブロッカーを報告してください。必要な構造化ハンドオフについては自律実行に従ってください。
• 簡単なコード、GUI レイアウトの微調整、信頼できるサードパーティ内部のコード、または本当に使い捨ての作業に限り、スキップするか簡略化してください。長期的に使う GUI ロジックは切り出して TCRDD の対象とし、サードパーティとの境界では自分のコードをテストしてください。例外と限定的な制約については実用上の指針を読んでください。

ワークフロー

GREEN：現在失敗しているテストを通すために必要な最小限のコードだけを書いてください。 一般化したり、将来のケースに対応したりしてはいけません。以下の変換のうち、番号が最も小さいものを使ってください。

RED   → plan test → approval? → write test → diff approval? → stage + run tests
        test FAILS (expected)?   commit [RED]      → GREEN
        test PASSES (unexpected)? log → reset --hard → try again

GREEN → plan code → approval? → write code → diff approval? → stage + run tests
        tests PASS?  commit [GREEN]      → REFACTOR
        tests FAIL?  log → reset --hard  → try again

REFACTOR → plan cleanup → approval? → refactor → diff approval? → stage + run tests
           tests PASS (no behaviour change)? commit [REFACTOR]     → (loop or done or back to RED)
           tests FAIL?                       log → reset --hard   → try again

コードの書き方

各フェーズの前に（インタラクティブモードのみ）：ユーザーの計画承認を得てから、ステージングとテスト実行の前に差分の承認を得てください。

一度に一つのステップ。まとめて一度に実行してはいけません。 各フェーズで進めるのは、小さなステップ一つだけです。失敗するテストを一つ書き、そのテストを通すための最小限のコードを書きます。自律モードでも、テストスイート全体や実装全体を一度に書いてはいけません。1回のターンで機能を完成させた場合、TCRDD を実行していません。

• RED — 次の最小の振る舞いを選び、失敗するのに十分なテストだけを書きます（最初のコンパイルエラーまたはアサーション失敗で止めます）。
• GREEN — 現在失敗しているテストに必要な最小限の本番コードを書きます。追加のヘルパー、依存関係、将来のケースは加えません。変換の段階から番号が最も小さい手法を使います。番号の大きい手法が必要になるなら、テストが大きすぎたということなので、分割してください。
• REFACTOR — すべてのテストが成功したら、本番コードとテストコードを自由に整理します。
• REPEAT — 機能が完成したか確認します。未完成なら RED に戻り、完成していれば中間コミットを一つのクリーンなコミットにまとめます。

詳細、12段階の全ステップ、小さなステップと一括実行の例、エラー処理の表については、以下の参考資料を参照してください。

必要に応じて読む

読むタイミング	リンク
RED／GREEN／REFACTOR フェーズを書くとき、または変換方法を選ぶとき	フェーズガイド
ベビーステップの例を見るとき、またはリバート／不安定／ダーティツリーの状況が発生したとき	例とエラー
無人で実行するとき、またはオーケストレーターに報告するとき	自律実行
ステージ／テスト／コミット／リバートと失敗ログを実装するとき	Git サイクル
ループをスキップするか、簡略化するかを判断するとき	実践的な考慮事項
TCR／TDD／TPP の理論と原著記事（Beck、Uncle Bob）について知りたいとき	さらに読む
ベンチマーク結果を確認するとき	ベンチマーク

上流

TCRDD を始める前に	スキル	理由
その機能を開発する価値があるか判断できないとき	kano	red／green／refactor のサイクルに取り組む前に、機能を分類します