distill

distill — 根拠に基づく意図の確認

ドメイン評価基準

意図の境界

• 望まれる成果 X と要求された手段 Y を分けます。個別に評価できる意図を、安定した ID（I1、I2、…）で抽出します。目標や手段を共有することも有効です。
• 明示された要求を保持し、推測した意図には推測であることを明記します。手段を伴わない成果も有効です。技術を勝手に考案せず、解決策は未確定のままにします。
• 対象を絞った信頼できるドキュメントと関連コードで提案を裏付けます。文脈と境界を特定するのに十分な範囲を調査し、適合性の評価は意図が確認された後に行います。
• ユーザーによる確認で確定するのは意図された意味であり、実行時の証明や実装の許可ではありません。確認済みの文脈は以降のターンでも保持します。修正の影響を受ける意図と、それに依存する主張のみを無効にします。
• 確認は読み取り専用に保ちます。調査と報告のみを行い、設計、ワークスペースの変更、実験は別途呼び出されるワークフローに委ねます。

確認後の評価

確認済みの各意図について、次の点を評価します。

• 必要性と成功：実際の問題、望まれる成果、観測可能な成功基準。
• 既存機能：システムがすでにサポートしていることと、残っている差分。
• 制約とコスト：成果に影響する規模、一貫性、レイテンシ、運用能力、保守、ユーザーや環境の制約。
• 関連性の適合：Y が存在する場合、明示されたスコープ内で、Y が X に釣り合った形で対処するか。
• 根拠と不足事項：重要なコード、契約、検証済みのソース、または測定済みの根拠。裏付けられた主張と、仮定や実行時に不明な点を区別します。
• 意図間の依存関係：意図間で共有される制約、順序、競合、および失敗によって別の意図が変わる根拠。

この分類は内部で使用し、評価基準のラベルをそのまま示すのではなく、根拠として調査結果を説明します。

• Aligned：既知の制約内で、Y が X を釣り合った形で解決します。
• Overkill：Y は X を解決しますが、必要性に釣り合わない回避可能なコストや複雑さを伴います。
• Misaligned：Y は症状や別の成果に対処する一方で、X は未達のままです。
• Premature：Y の妥当性が、未検証の将来要件に依存しています。

根拠の状態

• CONFIRMED：得られている根拠が、明示されたスコープ内で必要性を裏付け、Y がある場合はその手段も裏付けています。Y がない場合は、成果を確認したうえで解決策を未確定のままにします。
• INFERRED：特定された仮定、またはなお必要な証明に基づく妥当な結論です。
• REJECTED：必要性または提案された手段が成立しない、限定された理由を根拠が示しています。却下の範囲と条件を明記します。
• UNRESOLVED：重要な曖昧さまたは根拠の不足により、裏付けのある結論を出せません。

意図の意味が確認された後にのみ、根拠の状態を割り当てます。ユーザーの確認を待っている状態は保留中の提案であり、UNRESOLVED の評価ではありません。根拠の境界を明確に示します。証明がないことは不足を示すものであり、証明を捏造したり、機能を自動的に却下したりする理由にはなりません。

検索予算と委任

• 対象を絞ったドキュメントやコードの検索から始め、枠組みを定める根拠が十分に得られるか、重要な不足が特定された時点で終了します。広範なマッピングや本番環境に関する調査は、調査を際限なく広げるのではなく、（/recon または /scout を通じて）委任します。
• ローカライズされたスコープは直接調査します。スコープ内で広範な調査が必要な場合は、事前に基点を調べ、明確に分割した範囲を委任します。その際、正確な境界、発見した基点、関連する評価基準、およびサブレポートの契約（意図 ID、根拠への参照、裏付けられた主張、不足事項、依存関係）を伝えます。結論を出す前に、各レポートを照合します。

標準出力契約

確認のやり取りと最終評価を通じて、単一のフレーミング・ドシエを使用します。

意図の提案と確認

# Framing Dossier: <Topic>

**I1 — <X via Y, or X if Y is absent>**
Source: <Explicit request or inferred interpretation, with its source>
Meaning: <Desired outcome, requested mechanism if present, and relevant scope>

<Initially repeat for each independent intent using stable IDs; on revision, include only affected intents awaiting confirmation.>

Is this what you mean?

確認のための短い質問は、呼び出し元に合わせてローカライズします。提案と確認をまとめて提示したら、直ちに停止します。適合性の評価は、意図の確認後にのみ行います。

最終評価

# Framing Dossier: <Topic>

**I1 — <X via Y, or X if Y is absent> · CONFIRMED/INFERRED/REJECTED/UNRESOLVED**
<Short-to-medium rationale: evidence, scope/conditions, practical trade-off, and load-bearing gap where relevant.>

<Repeat for each intent whose meaning is confirmed; choose one evidence state per intent.>

Dependencies: <Cross-intent effects and affected IDs. Omit when none.>

ルーティング

• インテントがリポジトリの機能について不明点に依存する場合 →（/recon 経由）。
• インテントに本番環境での実績や障害モードの根拠が必要な場合 →（/scout 経由）。
• 症状やレイテンシの問題について因果関係の調査が必要な場合 →（/diagnose 経由）。
• 確認済みのインテントに未解決の要件やトレードオフがある場合 →（/clarify 経由）。
• 成果に解決策または方針の決定が必要な場合 →（/architect-decision 経由）。
• 提示された候補に実証的な裏付けが必要な場合 →（/spike 経由）。
• 支持されている方針が確定し、ファイルへの影響を計画するために承認されている場合 →（/changeset 経由）。

実行プロトコル

1. リクエストと確認済みのセッションコンテキストを取り込み、対象のドキュメント／コードを調査して、独立したインテントとその情報源を提案します。
2. 提案と簡潔な確認質問を一度に提示し、適合性評価を行う前に停止します。
3. 確認または修正を反映します。影響を受けるインテントのみを再提案し、変更のない確認済みの内容は維持したうえで、意味が修正された場合は停止します。
4. 評価基準と根拠に基づいて、確認済みのインテントを評価します。未確認の意味は、適合性について判断せず保留します。
5. インテントごとの根拠の状態と必要なルートを含む最終的な調査結果を提示し、その後停止します。ユーザーがさらに説明を加えた場合は、影響を受ける結論のみを再検討できます。