spec

仕様

一貫性のある変更について、実装可能な仕様を1つ作成します。 仕様のソースには、docs/<feature-slug>/spec.md、GitHub issue、またはユーザーが提供した別のドキュメントを使用できます。提供されたソースを更新し、重複するチケットやドキュメントは作成しないでください。ソースが提供されていない場合は、上記の Markdown パスを使用してください。依頼された場合にのみ、トラッカーに公開します。

プロセス

1. 依頼、リポジトリの指示、要件、アーキテクチャ、関連する実装を読みます。既定の決定を再利用し、現在の動作に関する主張を検証します。
2. 変更の成果とスコープを定義します。動作、データ、インターフェース、セキュリティ、互換性、運用、コスト、または検証方法を左右する未解決の選択肢について質問します。後から変更可能な局所的な実装方法は、実装に委ねます。
3. 以下の構成に従って仕様を作成します。共通要件やアーキテクチャは、繰り返し説明する代わりに参照します。
4. 新しいエージェントが、重大な決定を独自に補わずに実装できる内容になっているか確認します。該当する場合は、成功、拒否、無効な入力、部分的な失敗を追跡します。
5. 仕様をレビュー可能な状態にしたら終了します。タスクの計画や実装は行いません。

仕様の構成

成果とスコープ

問題、影響を受けるユーザーまたは呼び出し元、望ましい結果、制約、対象外を記載します。

必須の動作

入力、アクション、観測可能な結果、権限、ビジネスルール、障害からの回復を記述します。該当する REQ-n ID を参照します。機能固有のプロダクト詳細を確定します。

技術設計

変更される責務、インターフェース、データ、実行順序を説明します。曖昧さをなくすのに役立つ場合は、具体的な型、ペイロード、状態表、図を使用します。

変更に影響する場合に限り、スキーマの変更、インデックス、マイグレーション、トランザクション境界、並行処理、再試行、キャンセル、セキュリティ、互換性、可観測性、段階的な展開、ロールバックを取り上げます。重要な選択、その理由、コストを明記します。

システムアーキテクチャに必要な変更があれば、その内容を記載します。承認済みのルールを暗黙に上書きしてはいけません。提案するアーキテクチャの変更は、提供前にレビューできるよう記録します。

受け入れ条件と検証

観測可能な各条件と、影響を受けるアーキテクチャ上のルールに、それぞれ確認方法を対応させます。

ID	完了条件	確認方法
AC-1	具体的な結果	コマンド、自動化されたシナリオ、または手動確認

既存の AC-n、REQ-n、INV-n の参照を保持します。ID を再利用したり、番号を振り直したりしないでください。まだ存在しないコードに対する実行可能なコマンドを作らず、代わりにシナリオと期待される結果を定義します。

未決事項

不足している回答、妥当な場合の推奨デフォルト、提供を妨げるかどうかを記載します。すべて確定している場合は「なし」と記載します。不明点をプレースホルダーで隠してはいけません。

ライフサイクル

決定のステータスと提供のステータスを分けて記載します。提供後も、機能の決定事項と受け入れ確認を記録したものとして仕様を保持します。提供済みの PR と検証結果をリンクし、未実施の確認に合格したと主張してはいけません。提供中に生じた重大な変更を記録し、判断に至った理由を消してはいけません。現在のプロダクトルールとシステムルールは、要件およびアーキテクチャに保持します。

範囲の境界

1つの仕様から複数のタスクやプルリクエストが生じる場合があります。分割すると提供しやすくなる場合は、/plan を使用します。小規模で内容が確定した修正には、正式な仕様を作成せず、タスクの説明と確認項目を使用できます。局所的な変更に必要ないルートドキュメントを必須にしてはいけません。

返答

ソース、主な決定とトレードオフ、提供を妨げる質問があればその内容を報告します。