amend

Amend

すでにリリース済みの機能を、グリーンフィールドのゲートを再実行せずに進化させます。その機能には承認済みの仕様と動作するコードがあります。まず、その変更が仕様に照らしてどのようなものかを正直に分類し、仕様とテストを正しく保てる範囲で、最も軽いレーンに進めます。

これは高速レーンであり、ゲートの回避策ではありません。どの経路でも最後は tdd を通り、実質的な設計上の疑問がある場合は brainstorm にエスカレーションします。「小さい」という判断は感覚ではなく、既存の仕様に照らして検証してください。

1. 変更の根拠となる既存の仕様を確認する

docs/specs/INDEX.md を使って、対象機能の仕様 docs/specs/<date>-<feature>/{requirements,design,tasks}.md を見つけ、変更に関係する要件と、それを扱う設計セクションを読みます。その機能に仕様がまったくない場合、amend は適切なスキルではありません。まったく新しい機能なら brainstorm、不具合なら debug です。

完了条件： 変更が影響する要件 ID を挙げられること。

2. 変更を分類し、明言する

brainstorm がティアを示すのと同じように、どのケースに当たるのか、その理由とともに明言します。

• Tier 0 — 振る舞いの変更なし。 色、アイコン、ラベル、文言の変更など。既存のすべての受け入れ基準が変更なしで引き続き成立します。→ 必須サブスキル：tdd を使用します（ビジュアルまたは振る舞いの変更を、その接点で検証します）。基準の文言が古くなった場合を除き、仕様の編集は不要です。
• Tier 1 — 既存の仕様化された振る舞いを変更または拡張し、所要時間は約半日以内。 既存の要件がすでに約束していることを変更するか、その要件に小さな追加を行います。→ ミニ仕様：要件を追加または修正し、動作し続ける必要がある振る舞いについて ... SHALL CONTINUE TO ... ガードを追加します（必須サブスキル：write-requirements をtier-1 mini-spec モードで使用します。対象機能の requirements.md に修正とガードを追記します。新しい機能コードの追加や、ファイル全体のレビューは行いません）。続いて、必須サブスキル：tdd を使用します。
• 真に新しいスコープ。 仕様で一度も扱われていない新しい振る舞い、実際に選択肢が複数ある UX または設計上の判断、約半日を超える作業、または複数のサブシステムにまたがる変更です。→ amend は中止します。必須サブスキル：brainstorm を使用します。これには通常の一連の工程が必要です。ここで大きな新規作業の形を決めないでください。

エスカレーションが必要かを判断する率直な基準は、既存の仕様の意図が、すでにこの振る舞いをカバーしているかです。期待される振る舞いを新たに考案する必要があるなら、それは新しいスコープです。上位の工程に引き継いでください。

完了条件： ティアを明言し、該当するケースを選んでいること。

3. トレースを正しく保つ

tdd を通じて変更を反映した後、新規または変更された要件の ID を、他と同様にテストタグとコミットトレーラーに引き継ぎます。requirements.md、design.md、または tasks.md を編集した場合は、必須サブスキル：sync-spec を使用して Status: とトレースを整合させます。それ以外の場合は、必須サブスキル：trace を直接使用し、検出結果を確認します。チェックがクリーンでなければ、変更は完了していません。

完了条件： 変更がテストファーストで実装され、要件 ID が最初から最後までトレースされ、trace チェックでエラーが報告されないこと。

注意すべき兆候 — 進めているレーンが違います

• 仕様に記述のない振る舞いを考案している → amend ではなく brainstorm です。
• 「小さい」変更から、実際に選択肢のある設計上の判断が生じた → エスカレーションしてください。ここで感覚に頼って決めないでください。
• テストに手を加えずコードを変更しようとしている → 常に tdd が必要です。
• その機能に仕様がない、または単に壊れている → amend ではなく、新規なら brainstorm、不具合なら debug です。
• 1つの依頼を、些細な変更と新しい振る舞いに分けようとしている → それぞれを別々に進めます。微調整はこちらで行い、新しい振る舞いは brainstorm に進めます。