hrt-change-size-gate

hrt-change-size-gate

複数の独立したユーザーストーリーをまとめた変更は、後続のすべてのフェーズ（仕様、設計、タスク、適用）の負荷を一度に増大させ、品質を低下させます。このゲートは、アーティファクトが書き込まれる前の proposal でこれを検出します。

このゲートでは、1つの変更を優先します。過剰な分割のほうがよくある失敗です。複数のレイヤーや機能にまたがる単一の幅広いストーリーは通常どおりであり、分割を示すものではありません。エージェントは独自に分割してはなりません。提案し、判断するのはユーザーです。

実行するタイミング

proposal フェーズ内で、「What Changes」と「Capabilities」を作業用コンテンツとして下書きした後、どちらも確定する前に実行します。

チェック内容

エージェントは、「What Changes」の下書きリストに、次の3つの条件をすべて満たす項目が2つ以上あるかを確認しなければなりません。

1. 独立してリリース可能 — その項目だけを（ほかの項目は含めずに）リリースしても、ユーザーが利用して検証できるものが得られます。
2. 依存関係がない — その項目は、リスト内のほかの項目にコードやデータの依存関係がありません。
3. 機能が異なる — 下書き中の Capabilities セクションで、同じ機能に該当する項目が2つ以上ありません。（このフェーズではまだ specs/** は存在しないため、ディスクではなくCapabilitiesリストを確認します。）

例 — 独立している場合：「CSV エクスポートを追加する」＋「ダークモード切り替えを追加する」（どちらか一方だけでもリリースできます）。独立していない場合：「CSV エクスポートを追加する」＋「エクスポートの権限チェックを追加する」（エクスポートがなければチェックに意味がありません。1つのスライスです）。

• 該当する項目が2つ未満 → ゲートを発動してはなりません。何も言わずに1つの変更として続行します。
• 2つ以上 → スコープに大きく影響します。エージェントは停止し、ユーザーに「1つの変更にしますか、それとも複数にしますか？」と尋ね（独立していると思われる項目とその理由を示し）、ユーザーが回答するまで先へ進んではなりません。無回答は回答として扱いません。この質問は plain-language-writing スキルのCOMMSルールに従わなければなりません。

ダークモード（dark.md が存在する場合）でも、このゲートは引き続きユーザーに判断を求めなければなりません。hrt-dark-mode-decision-gate に振り分けてはなりません。判断はユーザーの余力と優先順位によって異なり、それらを示す根拠となるアーティファクトは存在しないためです。

ユーザーが1つの変更として進める場合

提案を変更せずに続行します。記録は残しません。

ユーザーが分割を希望した場合

以下を順番に実行します。ステップ 1〜3 は今実行し、ステップ 4〜5 は記載のとおり、同じフェーズ内の後のタイミングで実行します。

1. 今作成するスライスを尋ねます。そのスライスのみを対象に proposal.md を作成します。

2. proposal.md に ## Out of Scope セクションを追加し、除外するスライスを 1 行につき 1 つ記載します。

3. discovery.md の Key Decisions に 1 件追加します（Open Questions ではありません。これは却下した代替案を伴う、解決済みのスコープ決定です）。

   Scope: build slice <X> only — slices <Y, Z> split to separate changes (decided at the proposal size-gate). Alternative rejected: one combined change (too large; downstream phases inflate).

   この記録は永久に残さなければなりません。後続の変更でスライス Y に取り組む場合も、これを削除してはなりません。この記録は、この discovery セッションで扱った範囲を示します。

4. フェーズの hrt-adversarial-authoring ステップを実行する際、その Destructive Critic がスコープをさらに絞り込んだ場合は、新たに除外したスライスを ## Out of Scope に追加します。

5. ## Out of Scope が確定したら、openspec/BACKLOG.md を同期します。

   • 既存のエントリーがこの変更で対応済みになった場合（最終版の proposal.md と照らし合わせて「Slice」の行を判断します）、そのエントリーを削除します。

   • 残りの ## Out of Scope のスライスごとに、エントリーを 1 件追加します。

     ## <slug-kebab>
     - Raised by: <this change-id> (<YYYY-MM-DD>)
     - Slice: <1–2 sentences: what a user can demo when this slice is done>
     - Deferred because: <blocking dependency / scope / capacity>
     

   • ファイルが存在しない場合は、タイトルを # Deferred Slices として作成し、次の 1 行を記載します。

     別の変更を計画する際に挙がり、意図的に先送りされたスライスです。提案ではありません。discovery セッションを開始するのに必要な情報のみを記載しています。エントリーが変更になったら削除してください。

   • エントリーを削除した結果、ファイル内にエントリーがなくなった場合も、ヘッダーは残します。ファイルを削除してはなりません。

proposal.md の ## Out of Scope が正本です（変更とともにアーカイブされます）。BACKLOG.md はそこから派生し、後で取り組めるように保持されます。この重複は意図的なものです。

フォールバック

このゲートにはユーザーとの対話が必要です。非対話型の実行では質問に対する回答を得られないため、1 つの変更として進め、ゲートを実行できなかったことを proposal.md に記載します。これは OpenSpec 全般の制約であり、このゲート固有のものではありません。