slice-tdd

実装フェーズ — 小さく TDD する

なぜこの skill があるか

要件と設計が固まった後、実装を一気にやると「途中で詰まる」「どこで間違えたか分からなくなる」「動いてるけど未完成のものが本番に残る」といった問題が起きる。

「小さく分割しつつ TDD で進める」のがアジャイルの本質的な動き方。各単位で TDD のサイクル（レッド → グリーン → レビュー → リファクタ → コミット）を回し、テストと実装の両方からフィードバックを得てリズムよく開発する。「小さく」が先で「繰り返し」は結果。要件がもともと小さければ 1 サイクルで終わってよい。

実装方針: outside-in TDD（この skill の芯）

このプロジェクトの実装は outside-in TDD を例外なしのルール にする。

サイクルは入れ子（マトリョーシカ）

1 サイクル = レッド → グリーン → レビュー → リファクタ → コミット。ここまでで 1 つ、分割しない（グリーンで止めて次に進まない、レビューとリファクタを飛ばさない、コミットで閉じる）。

大きいサイクル（ストーリー全体を E2E で駆動）の中に、小さいサイクル（層ごと）が入れ子で並ぶ。小さいサイクルも同じ形。実装は「大きいサイクルを 1 本回す」ではなく、中の小サイクルを 1 つずつ開いて各々を回す。マトリョーシカの一番外の人形だけ開けて中を開けない（大サイクル 1 本に潰す）が崩れ。

outside-in ＝ インタフェース先行の「設計」（各階層で同じ動き）

outside-in は「外側の層から内側へ進む」向きだが、本質は インタフェースを先に決める設計 にある。外側（入口・呼び出し側）を先に書くと「ここは何を受け・何を返すか」という 契約を先に設計させられる。その契約が、内側に何が必要かを浮かび上がらせる。だから outside-in は実装順のテクニックであると同時に 論理設計のプロセス そのもの。

この設計の動きは、どの階層でも同じように再帰する:

• ストーリーの階層では、UI / API が外に見せる契約（E2E が固定する振る舞い）を先に決める
• バックエンドの各層でも同じ — その層が外に見せる契約を先に決めて、内側に何が要るかを浮かび上がらせる（入口 → 内側のロジック → データアクセス、と外から内へ）

内側の層のサイクルも、同じ「契約を先に決める」動き。ストーリーの境界だけでなく、実装の中の各層でも これを効かせる。

これはテストの有無と無関係。outside-in は設計なので、ユニットテストを書かない層（例: 薄い入口やデータアクセス）でも効く。「この層が外に見せる契約」を先に決めるのはテストの話ではなく設計の話だから、外側から設計する。

設計（契約先行）は全ての層で再帰する。ただし TDD のレッド→グリーンのサイクルは、テストがある単位でだけ回る（テストを持たない層は外側のテストがカバーする）。この 2 つは必ずしも一致しない — 設計はどの層でも外→内、レッド→グリーンのサイクルはテストのある所で回る。だから「全層をサイクルで回せ」でも「全層にテストを書け」でもない。

境界: outside-in は方向・設計まで。テストは project の領分

outside-in が決めるのは 進む向きと、契約先行の設計 だけ。その先の「何をどうテストするか」— どの層にどのレベルのテスト（ユニット / E2E）を置くか、テストが何を担保するか、粒度 — は project 固有の流儀（implementation / e2e skill を呼んで探す）。層の名前（例: route / usecase / gateway）も project 依存なので、この skill では 例としてだけ 出す。

アンチパターン: ボトムアップ（内→外）／形だけ outside-in

• ボトムアップ: 最内層（データアクセス・純ロジック）から積み上げ、外側（入口）を最後につなぐ。「動くものから書いている」ように見えて、外側＝価値が最後まで検証されず、統合の不備が終盤に噴出する。特にバックエンドの中で「依存を先に作る（データ → ロジック → 入口）」に流れやすい。それは契約を先に決める "設計" でなく、動かすための "構築" に落ちたサイン。外側の契約から設計すれば内側は後から surface する
• 形だけ outside-in: 最上位で E2E を 1 本 "書く" だけで、中は全部内側から積む。E2E を書いただけでは outside-in ではない（そのあと内側から積めば向きはボトムアップのまま）