amend-feature

Amend Feature

すでにリリース済みの機能を進化させます。グリーンフィールドのゲートを再実行する必要はありません。この機能には承認済みの仕様と動作するコードがあります。作業の目的は、変更をその仕様に照らして正直に分類し、仕様とテストが正しく保たれる範囲で最も軽いレーンに振り分けることです。

これはファストレーンであり、ゲートの回避ではありません。どの経路でも必ず test-first を通過し、実質的な設計上の疑問がある場合は frame-change にエスカレーションします。「小さい」というのは、既存の仕様に照らして立証する主張であり、感覚で判断するものではありません。

1. 既存の仕様を基準に変更を確認する

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

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

2. 変更を声に出して分類する

frame-change がティアを明示するのと同様に、どのケースに当たるのか、その理由とともに明言します。

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

エスカレーションを判断する正直な基準は、既存の仕様の意図が、すでにこの振る舞いを対象にしているかです。どう振る舞うべきかを新たに考案しているなら、それは新しいスコープです。上位の工程に引き継ぎます。

完了条件： ティアを明言し、ケースを選択していること。

3. 監査トレースを正確に保つ

変更が test-first を通じて反映されたら、新規または変更された要件の ID を、ほかの要件と同様にテストタグとコミットトレーラーに記載します。requirements.md、design.md、tasks.md を編集した場合は、必須サブスキルとして realign-spec を使い、Status: とトレースを再整合させます。それ以外の場合は、必須サブスキルとして audit-trace を直接使い、その検出結果を確認します。チェックに問題がないことが必要です。問題があれば、変更は未完了です。

完了条件： 変更が test-first で実装され、要件 ID のトレースが一貫してたどれ、audit-trace チェックでエラーが報告されないこと。

危険信号 — 選んだレーンが間違っています

• 仕様で説明されていない振る舞いを考案している → amend ではなく frame-change です。
• 「小さな」変更が、複数の実質的な選択肢を伴う設計上の決定に発展した → エスカレーションします。ここで感覚的に決めてはいけません。
• テストに手を加えずにコードを変更しようとしている → 常に test-first が必要です。
• 機能が仕様化されていない、または単に壊れている → amend ではなく、前者は frame-change（新規）、後者は root-cause（不具合）です。
• 1つの依頼を、些細な変更と新しい振る舞いに分割している → それぞれ別に振り分けます。調整はここで扱い、新しい振る舞いは frame-change に回します。