--- name: sdd-implement description: 要件と受け入れ条件に沿って機能を実装し、実際の動作とテストで確かめる。「仕様に沿って実装して」「このタスクを作って」「続きを開発して」と依頼されたときに使う。計画だけの依頼や、修正を伴わないQAには使わない。 --- # SDD実装 対象の受け入れ条件を満たす機能を、入口から結果までつなげて実装します。手順の説明や報告には日本語を使い、ユーザーが別の言語を指定した場合はそれに従います。 ## 1. 実装する範囲を固定する 1. プロジェクトの指示、現在のブランチ、作業中の変更、関連する要件・設計・タスクを読みます。対象の要件ID、コードの版、実行環境、完成条件、対象外を記録します。 2. 正式な仕様があれば使います。仕様がない場合でも、明確な依頼と既存の動作から作業用の条件を短く整理して進めます。文書が未承認であることだけを理由に、依頼済みの可逆的な作業を止めません。 3. 動作、互換性、権限、情報の扱い、費用を変える未決定事項はユーザーに確認します。回答が必要な部分だけを待ち、独立した実装は進めます。 4. 既存の構成と未コミットの変更を保持します。既存機能の削除・非表示・無効化は、その機能と影響範囲について明示的な依頼がある場合に行います。 ## 2. 一つの機能を最後までつなぐ 受け入れ条件ごとに、画面やAPIの入口、処理、保存先や外部サービス、表示結果、失敗時の処理を追います。まず一つの操作が結果まで届く単位を選び、必要な変更をまとめて実装します。 - 既存の責務の分担や設計に従い、関係のない整理を混ぜません。 - 仕様に必要な入力確認、権限確認、状態の更新、取り消し、後片付けを含めます。変更に応じて、同時操作、部分的な保存、移行、失敗後の再試行も扱います。 - 実行環境とアプリ、ブラウザー、サービスを可能な限り使い回します。共有サービスを勝手に再起動せず、今回作った一時的な資源だけを管理します。 - 判断が仕様と衝突したら、その差を説明します。実装に合わせて受け入れ条件を書き換えず、必要な仕様変更を先に解決します。 ## 3. 条件ごとに検証する 変更前の関連テストを必要に応じて実行し、既存の失敗を記録します。変更後は、対象の条件を確かめるテストや静的検査から始め、影響のある結合テストと実行時の確認へ進めます。変更の危険度やプロジェクトの規則に応じて、周辺機能の回帰確認も行います。 新しくテストを作る場合は、利用者の動作、境界条件、失敗後の状態などを確かめます。実装の内部構造をそのまま写したテストや、低リスクの文言変更だけのためのテストは増やしません。 画面の成功表示だけで保存や外部サービスとの接続を成功としません。必要な環境では、再読み込み後の状態、取得APIの結果、許可された保存先の確認など、別の観察方法でも結果を確かめます。ローカルのテスト、CI、デプロイ、認証後の動作、実サービスとの接続は、それぞれ確認した範囲を明示します。 テストで一部の依存先を代役に置き換えた場合は、その境界を記録します。その結果を実サービスとの接続確認に使いません。依存先が使えないときに、固定の成功応答、未承認の仮実装、認証の回避へ置き換えて完成としません。テストの期待値やセキュリティ上の制御を弱めて合格させることも避けます。 ## 4. 差分と残件を確認する 差分と変更後の処理を読み直し、未実装の分岐、エラーの握りつぶし、偽の成功表示、秘密情報、終了しない処理、解放されない資源がないか確認します。既存機能や利用経路を意図せず失っていないかも確認します。 各受け入れ条件について、変更箇所と実行した検証を対応させます。 | 要件・条件 | 実装箇所 | 実行環境・コマンドまたは操作 | 結果・証拠 | 残件 | | --- | --- | --- | --- | --- | | 対象の条件 | ファイルや入口 | 再現できる手順 | 実際の結果や成果物 | 未確認事項があれば記載 | 不具合を直したら、影響する検証を再実行します。状況が変わらない実行や環境の作り直しを繰り返さず、必要な情報、権限、依存先を特定します。待っている間も、独立した作業と一時資源の後片付けを進めます。 ## 完了の報告 対象条件を満たし、その条件に必要な検証が通ったものだけを完了とします。タスクの完了欄を更新する場合も、この証拠に従います。未実行、失敗、環境待ちの条件は残件として示し、完了率のために条件を減らしません。 変更した動作、検証結果、残っている制約、次に必要な作業を簡潔に報告します。プッシュ、PR作成、マージ、公開、Slackへの通知は、ユーザーから依頼されている範囲で行います。コードが書けたことだけで、QAや公開後の確認まで完了したとは報告しません。