slice

スライス

意図を、具体的で範囲の定まった変更単位に落とし込みます。スライスは一貫した変更です。プロジェクト全体に関わる決定（それはADRです）でも、恒久的な仕様資料（.doctrine/spec/）でもありません。

プロセス

1. 枠組みを確認します。 コードを変更する意図があり、それをすでにカバーするスライスがないことを確認します。まず制約を確認します。ADR、.doctrine/spec/tech/、規約については /canon を、これから触れる領域のサブシステム固有の注意点については /retrieve-memory を使います。

2. スライスを作成します。

   doctrine slice new "<title>" [--slug <slug>]
   

   次の ID を割り当て、slice-nnn.toml（メタデータ、関係、ライフサイクルのステータス。初期値は proposed）と slice-nnn.md（スコープ文書）のひな形を作成します。

3. slice-nnn.md でスコープを明確にします。

   • 何を、なぜ変更するのか
   • スコープ内とスコープ外（境界を明記します）
   • 影響を受ける領域 — 具体的なパス／モジュール
   • リスク、前提、未解決の質問
   • 検証／完了の意図 — 何をもって「完了」と判断するか

   影響を受ける領域は、粗い scope-relevant セレクターとして登録します。変更箇所のおおよそのパス／glob の範囲を、スコープが新鮮なうちに記録します。

   doctrine slice selector add <id> "src/foo/**" "src/bar.rs" --intent scope-relevant
   

   これらは意図的に大まかな指定です（正確な変更対象の特定は /design の役割です）。監査時の slice conformance 差分に使われます。範囲が設定されていないスライスは、実際に Git で変更された内容と比較できません。

4. 構造を slice-nnn.toml に記録します。 メタデータとライフサイクルのステータスを記録します。保存ルールを守ってください。構造化データは TOML に、文章は MD に記述し、文章から検索・導出されるデータは記述しません。関係は手作業で行を記述せず、doctrine link を使って設定します。これにより、RELATION_RULES（使用可能な語彙。lib:reference/using-doctrine.md § エンティティ間の関係）に照らしてペアが検証されます。たとえば、ADR に対する governed_by、仕様に対する specs、以前のスライスに対する supersedes などです。

5. 適切な粒度か確認します。 作業が実際にはプロジェクト全体に関わる決定なら、doctrine adr new を使います。恒久的な仕様なら、技術仕様（doctrine spec new tech）または製品仕様（doctrine spec new product）を作成します。スライスはリリース可能な変更を1つに絞り、範囲が広がりすぎる場合は分割します。

次のステップ

計画の前に、必ず設計を固めます。ライフサイクルの状態遷移を記録し（doctrine slice status <id> design — 数字のみ）、/design に引き継ぎます。未設計のスライスから /plan や /execute に進んではいけません。/route のゲートで禁止されています。スコープ設定中に、実質的なトレードオフや不明点が明らかになった場合は、/consult を使います。

/design の前に /research に従って事前調査を行い、記憶ではなく引用可能な成果物に基づいて設計を進めてください。