sync-spec

仕様を同期する

1 つの機能の仕様トライアド（docs/specs/<date>-<feature>/{requirements,design,tasks}.md）を、コード、テスト、タスクで実際に正しい状態に合わせます。変更後に再同期されていない仕様は作り話になり、作り話は仕様がないよりも悪いものです。

一度に 1 つの機能を扱います。まず仕様ディレクトリを特定します（ユーザー、現在のブランチ、または docs/specs/INDEX.md から）。

厳守事項

• 要件 ID の番号を絶対に振り直さないでください。 ID は承認された時点で不変となり、後続のすべての項目から参照されます。
• 要件を絶対に削除しないでください。 廃止する場合は ~~**CODE-N.M**~~ <reason> とします。取り消し線付きの ID は定義済みとして数えられなくなりますが、履歴は判読できる状態に保たれます。
• 新しい要件には、そのストーリー内で次に空いている番号を付けます。新しいタスクは既存のタスク形式に正確に合わせます。

手順

a. ベースライン。 トレースチェックを実行し（必須サブスキル：trace を使用）、検出結果を記録します。これが「変更前」の状態です。

b. 要件 ↔ タスク。 requirements.md と tasks.md を比較します。

• 有効な要件を参照するタスクがない場合は、ファイル内の他のタスクと同じ形式で、それをカバーするタスクを末尾に追加し、_Requirements: CODE-N.M_ のフッターで終わらせます。
• 実装済みで検証の証拠も存在するなど、完了したことを確認できる作業について、タスクのチェックボックスが未チェックならチェックを入れます。

c. 要件 ↔ 設計。 要件 ID と design.md の Satisfies: 行を比較します。有効な要件がどの Satisfies: 行にも含まれていない場合は、ユーザーに指摘します。設計にセクションを追加する（拡張する）か、その要件が将来的な目標であれば（廃止を検討する）必要があります。設計内容を黙って作り出してはいけません。

d. 孤立項目。 取り消し線付き、または存在しない ID を参照しているタスクのフッターとテスト注釈をすべて列挙します。各項目について、対応案（有効な ID への付け替え、テストの廃止、または要件の復活）を添えてユーザーに提示します。孤立項目は単なる整理対象ではなく、判断が必要な項目です。

e. 状態の遷移 — 証拠がある場合のみ。

遷移	必要な証拠
Draft → Approved	ユーザーが仕様を明示的に承認していること。推測してはいけません
Approved → Implemented	すべてのタスクのチェックボックスにチェックが入り、トレースチェックで有効な要件すべてがテストでカバーされていること
Implemented → Shipped	機能がリリースに含まれていること（この手順は通常 release から呼び出されます）

証拠が揃っている遷移を適用します。requirements.md の Status: 行と、docs/specs/INDEX.md にある該当機能の行を更新します。証拠が不十分な場合は、遷移せずに何が不足しているかを具体的に伝えます。

f. 変更後の状態。 トレースチェックを再実行し、変更前と変更後の検出結果を並べて表示します。解消したエラーと警告、残っている項目、および解消のために行った変更を示します。docs/specs/INDEX.md が各仕様の現在の Status: 行を反映しており、同じコミットにステージされていることを確認します。

完了条件： 変更後のエラーが変更前より増えておらず、指摘された各項目に対して編集を行うか、ユーザーの判断待ちであることを明示しており、INDEX.md が各仕様の Status: 行と一致していること。