エンジニアリング（Engineer）
発見結果を2つの耐久性のある成果物、すなわち/implementが実行可能な仕様書と、記憶に値する決定のためのADRに統合します。
入力: $ARGUMENTS。
暗黙の前提は一切禁止。 すべての設計上の選択は、ユーザーによって行われるか、前提としてリストアップされます。これには、小さすぎて質問しにくいと思われる選択（ライブラリ、エラーフォーマット、命名、デフォルト値、制限）、コードベースから推測したこと、自身の推奨事項も含まれます。プロセス全体を通じて想定台帳（Assumptions Ledger）（✅ ユーザー確認済み · ❓ 未確認 · ❌ 却下）を保持し、確認されていない選択を決定として仕様書やADRに記載しないでください。
プロセス
- 吟味（Refine）。 このセッションでまだ洗練された概要（Refined Brief）がない場合は、まず
/refineプロセス（問い詰め → 受入基準）を実行します。設計を妨げる未解決の質問があるまま進めないでください。概要がすでにある場合は、その❓の想定を台帳に引き継ぎ、それらに依存する設計を行う前に解決します。 - モデル化（Model）。 新しい概念や変更された概念に対して
/domain-modellingプロセスを実行し、ドメインドキュメントを更新します。仕様書ではそれらの正式な用語を使用しなければなりません。 - コードベースを探索する。 変更が影響するモジュール、インターフェース、データストア、テストを特定します。従うべき既存のパターンをメモします。実際のパスを参照してください。今日のコードの動作は意図ではなく証拠です。「
src/x.tsの既存パターンに従う」という選択自体も、ユーザーに確認すべき選択であり、その情報源とともに記録します。 - 設計する。 重要な決定ごとに、トレードオフと推奨事項を含む2～3の選択肢を提示します。ユーザーが決定し、推奨事項はユーザーが明示的に選択した場合にのみ有効となります。より小さな選択については、自分で決定するのではなく、一度に確認するリストにまとめます。データモデルとマイグレーション、API/契約の変更、エラー処理、セキュリティ、パフォーマンス、可観測性、ロールアウトとロールバック、後方互換性を考慮します。
- ADRを記録する。 決定が元に戻しにくい、複数のモジュールに影響する、または将来のエンジニアが「なぜこの方法でやったのか」と疑問に思う可能性がある場合、ADRに値します。各ADRを
docs/adr/NNNN-ケバブ-タイトル.md（次の空き番号、4桁）にadr-template.mdを使用して書き込みます。ADRが別のADRを無効にする場合は、古いADRのステータスを更新します。ユーザーが決定を確認した場合のみ、ADRをAcceptedとしてマークします。それ以外の場合はProposedのままです。 - 仕様書（spec）を書く を
docs/specs/<ケバブ-タイトル>.mdにspec-template.mdを使用して書き込みます。作業を小さく、順序付けられ、独立してテスト可能なタスクに分割します。各タスクにはそれを証明するテストを1つ以上含めます。仕様書の想定セクションを台帳から埋めます。すべての設計記述はユーザーの決定に遡れるか、❓としてそこに表示されなければなりません。 - ユーザーとレビューする。 仕様書とADRを要約し、未解決の❓項目を提示し、承認を求め、調整します。タスク、受入基準、またはADRに影響する❓が存在する間は、仕様書を
Approvedに設定しないでください。
ルール
- プロジェクトに既存の仕様書/ADRフォルダやテンプレートがある場合は、それらの規則を尊重し、それらを使用します。
- 仕様書は何をそしてどのように検証するかを記述し、曖昧さを排除するのに十分などのようにを含めます。行ごとの実装ではありません。
- すべての受入基準は、少なくとも1つのタスクとテストに対応していなければなりません。
- 変更内容に応じて、可能な限り短く保ちます。
次のステップ
/handoff（新しいセッションで実装を開始するため）または/implement docs/specs/<ファイル>.mdを直接推奨します。