red-green-tdd

name	red-green-tdd
description	赤/緑の TDD で機能追加やバグ修正を行う。まず失敗するテストを書き、失敗を目で確認してから実装する。新しい挙動とバグ修正はすべてこれで進める。

赤/緑 TDD

テストが先、実装が後。引数は実装したい挙動、または直したいバグ。

どこにテストを置くか

対象	テストの置き場所	走らせ方
純ロジック（キー名変換、設定の検証、アクション解決、マクロ展開、色、レイアウト計算）	test/host/*.cpp	uv run python tools/check.py host
設定 JSON の仕様適合、キー名テーブルの網羅	test/spec/test_*.py	uv run python tools/check.py spec
ハードウェアに触る層（M5Unified / BLE / SD / NVS）	自動テストは書けない	/device-check と /manual-test

テストできる形に設計するのが先。ハードウェア依存と絡んだロジックは、まず firmware/core2-deck/src/core/ に切り出して純関数にする。切り出せば赤/緑が回る。 切り出せなければ回らない。この判断がこのプロジェクトで最も効く設計判断になる。

手順

1. テストを先に書く。 欲しい挙動（またはバグの失敗ケース）を自動テストにする。 明らかなエッジケースも書く。特に 不正入力を拒否すること のテスト （仕様の受け入れ基準の多くがこれ）。
2. RED — 失敗を確認する。 uv run python tools/check.py host を走らせ、新しい テストが落ちるのを見る。この手順は省略できない。実装前から通るテストは 何も検証していない。すぐ通ってしまったら、本当に落ちるまで書き直す。
3. 実装する。 テストが通る最小のコードを書く。
4. GREEN — 全体が通ることを確認する。 新しいテストだけでなく既存も。 出力が長いときは test-runner サブエージェントに投げる。
5. 必要ならリファクタ。 緑を保ったまま。
6. ハードウェアに関わる変更なら、ここで終わりではない。/firmware-build で実機 ビルドを通し、/device-check で実機の挙動を確認する。

なぜ

• エージェントの典型的な失敗（動かないコード／使われないコード）への保険。
• 恒久的な回帰スイートが残る。実機でしか気づけないバグを、二度と実機で 踏まないための唯一の手段。