先に仕様を書き、テストから始める小さな単位で作っていく

## 分からない要件は質問として記録し、答えが出るまで計画しない 重要な要件が不明確なまま、計画や実装を進めてはいけません。変更を提案する前に、未解決の要件、非機能面の期待事項、動作、テレメトリ、ポリシー、受け入れ基準を特定してください。 判断を求める前に、影響度が高い確認事項と影響度が中程度の不確実性をすべて、リポジトリで指定された未解決質問台帳に記録してください。各質問には安定した識別子を付け、解決するまで正本となる仕様書、計画、タスクリストの対象範囲をその識別子に対応させてください。 選択肢を提示する時は、まず同じ選択肢を記録し、その後でユーザー向けに直接要約してください。推奨案を最初に並べ、長所と短所を簡潔に示し、質問識別子を明記したうえで、必要な回答が得られるまで停止してください。解決後は、回答を仕様書の規範セクションへ組み込み、台帳の項目を閉じてください。 ## 計画の前に、仕様書とアーキテクチャのマップを読む リポジトリのルートを起点に作業し、リポジトリ全体の指示と関連するすべての下位ルールを適用してください。計画を立てる前に、現在のロードマップ、対象機能を統括する仕様書、モジュールマップまたはナレッジマップ、コーディング規約、対象機能に紐づくアーキテクチャ上の決定を読んでください。 変更が影響し得るモジュール、契約、責任範囲を整理してください。近くにあるファイルだけから関係を推測せず、リポジトリで保守されている最新のアーキテクチャスナップショットを使い、モジュール、依存関係、契約が変わった時はそのマップを更新してください。 仕様書、計画、タスク、アーキテクチャ決定には承認済みのテンプレートを使い、メタデータ、検証メモ、相互リンクの一貫性を保ってください。 ## 仕様書を先に直し、その後で計画とタスク一覧を直す 実装前に機能仕様書を作成または更新してください。要件、非機能要件、動作またはインターフェースの詳細、テレメトリとポリシー、受け入れ時の分岐を定義し、視覚的な動作が変わる場合はインターフェースの概略図も用意してください。 実装計画を作る前に、影響度が高い質問と中程度の質問をすべて解決してください。仕様書を更新した後、アーキテクチャ上重要な結論をアーキテクチャ決定記録に残し、解決済みの確認事項は旧形式の確認一覧ではなく規範セクションに保持してください。 その後でのみ、計画とタスクチェックリストを更新してください。実装より先にテストを配置し、作業を90分以内に収まると見込まれる論理的な単位へ分け、仕様書、計画、タスクの内容が一致した後にリポジトリの分析ゲートを実行してください。ユーザーが明示的に求めない限り、フォールバック動作や互換動作を独自に追加してはいけません。 ## 保存した1つの記録から前回の続きを始め、引き継ぐ前に更新する 前提情報のないセッションを始める時は、リポジトリのリセット手順書または引き継ぎ手順書に従ってください。新しい実装作業に着手する前に、ロードマップの状態、進行中の計画、未解決の質問を要約してください。 セッションをまたぐ現行状態の正本として、指定された現在セッション用スナップショットを1つだけ維持してください。引き継ぎ前に、進行中の機能、完了した作業、保留中の質問、検証状態、次に安全に行える作業を記録して更新してください。競合する進捗記録を作ってはいけません。 機能とモジュールの責任範囲を明確に保ち、文書、オートメーション、セキュリティ、永続化、インターフェースに関する作業がそれぞれの正本となる場所で更新されるようにしてください。 ## 動きごとに、失敗するテストを先に書く コードを変更する前に、正本となる仕様書と計画を更新してください。各動作について、実行可能な単体テスト、動作テスト、契約テスト、シナリオテストのいずれかを先に作成または拡張し、意図した理由で失敗することを確認してください。 計画時に成功、検証、失敗の各分岐を列挙し、各経路に対して薄い失敗テストを追加してください。テストを通すために必要な最小限のコードだけを実装し、成功状態を保ちながらリファクタリングしてください。 一連の作業が完了したら、カバレッジの変化、得られた知見、後続作業を計画またはロードマップに記録し、判断の経緯を監査可能な状態に保ってください。 ## 小さくまとまった変更にし、終わったタスクはすぐ完了にする 各作業単位を自己完結させ、リポジトリの言語、フレームワーク、文書、テストの規約に従ってください。深く入れ子になったインライン分岐よりも、小さな検証ヘルパーと正規化ヘルパーを組み合わせた直線的な処理構成を優先してください。 動作の変更に合わせて、ロードマップ、仕様書、計画、タスクチェックリストを同期してください。検証済みの各タスクは状態更新をまとめて行わず、その都度すぐに完了として記録し、モジュール間の関係や契約が変わるたびにアーキテクチャマップを更新してください。 決定記録は、確認済みのアーキテクチャ上の決定だけに使ってください。関連のないリファクタリング、一括書式変更、推測に基づく互換対応を避け、承認済みの作業単位から実装が外れないようにしてください。 ## 変えたファイルに合うチェックをかけ、失敗は飛ばさずに調べる 反復作業中は、適用できる最小範囲のフォーマッター、リンター、静的解析、型チェック、対象を絞ったテストを実行してください。完了前には、変更したファイル形式に対してリポジトリが要求するすべてのゲートと、直接影響を受ける統合境界のゲートを実行してください。 失敗したローカル検査や継続的インテグレーション検査は、回避すべきゲートではなく調査すべき不具合として扱ってください。リポジトリのポリシーが一時的なテスト免除を明示的に認めている場合は、影響を受けるテストだけを無効にし、理由を記した明確な`TODO`を追加して、後続作業を正本となる計画に記録してください。 変更したすべての動作についてテストを追加または更新してください。最終差分を確認し、文書とテストカバレッジが実装と一致していることを確かめ、必須の検査が失敗したまま作業単位の完了を宣言してはいけません。 ## 依存関係の追加や危ないGit操作の前に、承認を取る 作業単位に含まれるファイルだけをステージしてください。生成物、データベース成果物、並行作業が存在する可能性がある場合は、広範囲のステージングを行ってはいけません。文書とコードを一緒に変更した場合は仕様書への影響も含めて、アトミックなConventional Commits形式のコミット説明を用意してください。ただし、実行が明示的に委任されていない限り、指定された担当者にコミットを任せてください。 依存関係の追加または更新、指定されたファイルやディレクトリを取り除く操作、履歴の書き換え、プッシュ、外部レビューの作成を行う前に、明示的な承認を得てください。承認済みの依存関係を採用する理由は機能計画に記録し、管理されたフックと品質パイプラインが完了するのに十分な時間を確保してください。 シークレットをコミットしてはいけません。また、近道として破壊的なクリーンアップを使ってはいけません。予期しない追跡対象ファイルや未追跡ファイルはレビュー対象として提示し、関連のない作業には手を触れないでください。 ## 頼まれない限り互換用の逃げ道を足さず、危ない変更は先に提案する リポジトリで宣言された互換性方針に従ってください。インターフェースを新規設計として扱う場合、ユーザーが現在のタスクで明示的に求めない限り、フォールバック、シム、レガシーチェックを追加してはいけません。 プロンプトの要約、重要なコマンド列、判断理由を進行中の計画またはリンクされた付録に記録してください。危険なリファクタリング、永続化の変更、セキュリティ戦略の変更、重大な非機能面のトレードオフは編集前に提案し、承認されたアーキテクチャ上の決定を適切な決定ログへ記録してください。 自動ゲートが整うまでは、将来の契約テスト、ミューテーション解析、セキュリティ演習を計画上で追跡してください。運用ガイダンスは正本となるワークフローの近くに置き、変更され得る指示を複数の文書へ重複させないでください。 ## テストは専用のデータベースだけで行い、リセットの前に接続先を確かめる 接続先が未確認の状態で、データベースのリセット、全消去、新規マイグレーションコマンドを実行してはいけません。マイグレーションまたはリセットの前に、現在の環境、接続先、その操作が使い捨て可能なテスト用データベースの内部だけに限定されているかを確認してください。 アプリケーションのテストはリポジトリで指定された隔離済みテストデータベースに対して実行し、文書化されたトランザクションまたはマイグレーションの設定を使ってください。必要な場合も、明示的に特定したテストデータベースだけをリセットしてください。テストコマンドと対話型アプリケーションコマンドが同じ接続先を使うと仮定してはいけません。 新しいマイグレーションはファイルとして作成し、テストワークフローを通して動作を確認してください。データベースの対象範囲が曖昧な場合は、開発環境や本番データを危険にさらさず、停止して確認を得てください。 ## 作業の区切りごとに、変えた物と確かめた結果を引き継ぎに書く 自己完結した作業単位が該当するゲートを通過した後、完了タスク、ロードマップの状態、仕様書の変更、決定記録、現在セッション用スナップショットが同期していることを確認してください。 変更したファイル、実行した検査とその結果、未解決の阻害要因、後続作業、そのままコピーできる担当者向けコマンドを列挙した簡潔な引き継ぎを作成してください。実装済みの作業と、計画だけの作業または承認待ちの作業を区別してください。 検証後は機能のコミットを速やかに準備してください。ただし、実行するのはリポジトリの委任ポリシーで認められた場合だけです。次のセッションが調査を繰り返さず再開できるだけの証拠を残してください。