当指令混合真实结果与可替换做法时，用结果边界契约固定结果…

在对话、提示、任务、规格、计划、政策或技能中，把真实需求与满足它们的一种可能方法分开时使用。

适用场景

解决思路

1. 在首次动作前，通过宿主技能加载能力加载 `starting-point`，用它维护 outcome、proof、constraints、starting path、unknowns 的私有映射，以及改变路线的 intervention gate。
2. 使用此处命名的包文件前，运行 `mise run validate`。
3. 当需要持久契约工件时，使用 `assets/contract-template.md`：先把它复制出已安装技能再填写，不要编辑打包资产。
4. 建立契约字段：Outcome 是可观察的最终状态。
5. 建立契约字段：Proof 是决定 PASS 或 BLOCKED 的证据。
6. 建立契约字段：Boundaries 包括范围、权限、资源、隐私、成本和可逆性。
7. 建立契约字段：Forbidden outcomes 是绝不能接受的状态。
8. 建立契约字段：Mandatory methods 是由权限、用户意图或交付物固定的方法。
9. 建立契约字段：Candidate paths 是可替换的达成结果的方式。
10. 建立契约字段：Adaptation rule 是替换候选路径所需的证据和批准。
11. 建立契约字段：Unknowns 是仍能改变契约的事实或判断。
12. 按移除或替换源指令会改变什么来分类：改变请求终态的是 outcome invariant；使 acceptance decision 失去所需证明的是 evidence obligation；改变范围、权限、安全、隐私、成本或可逆性的是 boundary；命名不可接受状态的是 forbidden outcome；方法精确、排他、合同化、监管要求、可复现性相关、教学用途、用户明确要求或本身就是交付物时，是 mandatory method；另一种方法能保持所有 invariant、proof obligation、boundary 和 forbidden outcome 时，是 candidate path；现有证据无法区分要求和 recipe 时，是 unresolved。
13. 不要凭猜测降级 imperative instruction；使用源措辞、权限、上下文和可检索证据；如果该区分仍会实质性改变工作，问一个简洁问题。
14. 对话模式：1) 构建 `starting-point` 私有结果映射；2) 从用户话语推断临时契约，不虚构需求；3) 尽早把最小有用契约或 worked example 放在用户面前；4) 标记观察到的事实、可逆假设和未决项；5) 最多保持一个未回答问题活跃；6) 根据用户反应更新同一契约，而不是重新开始发现；7) 当契约被接受或用户要求行动时，移交给匹配 owner。
15. 产物审计模式：1) 在提出更改前阅读完整源；2) 给每条实质指令按源顺序一个稳定 source ID；3) 记录文本或定位符、权限、类别、建议处置和原因；4) 保留 invariants、evidence obligations、boundaries、forbidden outcomes 和 mandatory methods，不丢失含义或强度；5) 除非证据支持 candidate-path 状态，否则保持 recipe mandatory；6) 返回分类账和最小变更的 proposed contract；7) 除非用户要求且正确的编辑 owner 已加载，否则不要变更源。
16. 应用 adaptation gate：仅当替代方案保留每个已接受契约字段、证据显示实质收益或当前路径被阻塞、替代方案保持在当前权限和副作用限制内、任何被放弃、延迟或重新排优先级的工作已获用户批准时，才替换 candidate path；否则保持当前路径或把路线标记为 unresolved；更好的组件不等于更好的整体结果。
17. 输出时先展示契约；审计模式随后展示分类账；保持 accepted contract、proposed route 和 execution evidence 之间的区别可见。
18. 按下一动作路由：文本修订加载 `meaning-preserving-rewrite`；仅技能简化路由到 `simplify-skill`；仅计划工作路由到 `plan`；长期目标打包路由到 `goal-prompt`；执行移交给匹配领域 owner。
19. 读取 worked examples：实时请求命名结果、边界和提议实现时读 `examples/conversation-candidate-path.md`；政策或规范可能混合固定审批规则与可替换工具时读 `examples/artifact-audit.md`；在给简单请求添加契约工作前读 `examples/simple-request-bypass.md`，这是最可能导致的失败。
20. 检查并避免这些陷阱：不把更短指令视为自动更好；不仅因步骤被写下就保留每个步骤；不因安全或证据规则听起来程序化就降级；未经证据或批准不替换用户选择的方法；不虚构 proof、constraints 或 forbidden outcomes；不把契约或建议重写当作执行证明；不在用户授权更改前编辑已审计源。
21. 渐进披露：在测试、审查或更改运行时行为前读取 `references/eval-cases.json`；在更改包结构或 native-to-public lineage 前读取 `references/generation-contract.md`；仅在测量 activation、behavior、failure handling、recovery 或 speed 时读取 `evals/cases.json` 和 `evals/` 其余部分；在更改验证行为前加载 `mise run test`，然后运行 `mise run ci`；普通使用不加载 `mise run test`。
22. 验证：确认 `starting-point` 在分类前塑造了私有 outcome map；每条实质源指令有一个 source ID 和可见类别；保留需求保持含义、权限和强度；每个被放松的 recipe 命名保留契约和支持证据；unknowns 保持可见而不是靠猜测解决；契约能接纳更好的安全路线而不允许更差结果；外部动作和源变更仍在正常 gate 后。
23. 工厂执行合同：接受结果是保留请求的结果边界和证明阈值，只替换失败的 candidate paths；保留当前结果边界行为，同时改变其最小 owner。
24. 工厂执行步骤：1) 用 `mise run ci` 冻结当前包并记录 digest；2) 运行 `mise run domain-research-policy`，然后判断当前 outcome boundary sources 和 counterevidence；3) 为命名 outcome boundary 操作运行 `mise run agentic-request`，语义选择留给模型；4) 运行 `mise run decision-policy`、`mise run ci` 和行为 evals，返回最低失败 owner；5) 运行 `mise run invocation-policy -- <receipt>` 并说明每个任务或其领域特定 non-use；6) 可选运行 `mise run improvement-policy`，仅当没有受保护维度回退时保留一个改变维度。
25. 仅当需要其契约时，通过 `mise run use-case-policy` 加载 `assets/use-case-contract.json`，通过 `mise run evals` 加载 `evals/evals.json`。
26. 让 Mise 负责可重复机制、排序、receipts 和检查；让模型负责解释、因果判断、创造性工作和代码无法提供的直接感知；在缺少权限、证据过期或 gate 失败时停止。

适用边界 · 注意事项

• 不要用于没有实质方法选择的简单请求。
• 不要削弱精确方法、明确用户需求或更高优先级规则。
• 当请求结果仅限于简化技能包时，使用 `simplify-skill`。