distill

distill — 基于依据的意图探询

领域准则

意图边界

• 将期望结果 X 与请求的机制 Y 分开。提取可独立评估且带有稳定 ID（I1、I2、...）的意图；目标或机制相同的意图也有效。
• 保留明确请求，并将推断出的意图标记为推断。没有机制的结果同样有效；保持解决方案开放，不要臆造技术方案。
• 依据有针对性的权威文档和相关代码提出方案。检查足够内容以识别上下文和边界；仅在意图得到确认后评估其适用性。
• 用户确认确立的是预期含义，而非运行时证明或实施授权。在后续轮次中保留已确认的上下文；修订只会使受影响的意图及其依赖的主张失效。
• 保持探询只读：检查并报告；将设计、工作区修改和实验留给单独调用的工作流。

确认后的评估

针对每项已确认的意图进行评估：

• 需求与成功标准：实际问题、期望结果和可观察的成功标准。
• 现有能力：系统已支持的内容及尚存差距。
• 约束与成本：会影响结果的规模、一致性、延迟、运营能力、维护成本以及用户／环境限制。
• 关联适配度：若存在 Y，它是否在既定范围内与 X 相称地解决问题。
• 证据与缺口：关键代码、契约、已核实来源或测量证据；区分有依据的主张、假设和运行时未知因素。
• 跨意图依赖关系：共享约束、顺序、冲突，以及可能因失效而影响其他意图的证据。

内部使用此分类；将结论转化为理由，而不要暴露分类标签：

• Aligned：Y 在已知约束范围内与需求相称地解决 X。
• Overkill：Y 能解决 X，但成本或复杂度不必要地高于需求。
• Misaligned：Y 解决的是某种症状或不同的结果，却没有满足 X。
• Premature：支持采用 Y 的依据取决于尚未核实的未来需求。

证据状态

• CONFIRMED：现有证据支持该需求，并在存在机制时支持其在既定范围内的适用性。若没有 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. 提交最终档案，列出每个意图的证据状态以及任何必要的路由，然后暂停。用户后续的澄清只能重新开启受影响的结论。