outcome-bounded-work

以结果为界的工作

目标

调整正在进行的对话，或审查包含指令的材料，确保所需结果、证明和安全要求保持不变，同时让可替换的实现方式保持开放。

触发条件与边界

当对话、提示词、任务、规范、计划、政策或技能可能混淆了真实要求与一种可能的实现方式时使用。

对于没有实质性方法选择的简单请求，不要使用。不要弱化精确指定的方法、明确的用户要求或更高优先级的规则。如果所请求的结果仅限于简化技能包，请使用 simplify-skill。

首次采取行动前，使用宿主的技能加载功能加载 starting-point。它负责维护私有的目标、证明、约束、起始路径和未知项地图，以及更改路径的干预门槛。本技能将该地图和源指令转化为可检查的契约，但不会接管规划或执行。

实时请求使用对话模式。仅当用户要求检查现有的指令材料时，才使用材料审查模式。

契约字段

资源门槛：使用此处提到的包文件前，先运行 mise run validate。

• 目标： 可观察到的最终状态。
• 证明： 决定结果为 PASS 或 BLOCKED 的证据。
• 边界： 范围、权限、资源、隐私、成本和可逆性。
• 禁止结果： 绝不能接受的状态。
• 强制方法： 由权限、用户意图或交付物所固定的方法。
• 候选路径： 可替换的目标实现方式。
• 调整规则： 替换候选路径所需的证据和批准。
• 未知项： 仍可能改变契约的事实或判断。

需要持久化契约材料时，请使用 assets/contract-template.md。填写前，将其从已安装的技能中复制出来。不要编辑已打包的资源。

分类规则

根据移除或替换某条源指令会带来的变化进行分类：

• 如果所请求的最终状态会改变，则属于目标不变量。
• 如果验收决定会失去必需的证明，则属于证据义务。
• 如果范围、权限、安全、隐私、成本或可逆性会改变，则属于边界。
• 如果指令指出了不可接受的状态，则属于禁止结果。
• 如果方法是精确指定的、唯一指定的、合同要求的、法规要求的、与可复现性或教学相关的、由用户明确要求的，或本身就是交付物，则属于强制方法。
• 如果其他方法能够保留所有不变量、证明义务、边界和禁止结果，则属于候选路径。
• 如果现有证据无法判断某项内容是要求还是操作方案，则属于未解决。

不要凭猜测降低指令的强制性。应参考源文本措辞、权限、上下文和可检索证据。如果这种区分仍会实质性影响工作，请提出一个简短的问题。

对话模式

1. 构建 starting-point 私有目标地图。
2. 根据用户的措辞推断临时契约，不要凭空添加要求。
3. 尽早向用户展示最精简且有用的契约或示例。
4. 标明已观察到的事实、可逆假设和未决事项。
5. 同一时间最多保留一个尚未回答的问题。
6. 根据用户的反馈更新同一份契约，而不是重新开始探索。
7. 契约获接受或用户要求执行时，移交给相应负责人。

工件审计模式

1. 提出修改建议前，通读完整源文。
2. 按源文顺序为每条重要指令分配一个稳定的源 ID。
3. 记录其文本或定位信息、权威性、类别、拟议处置方式和原因。
4. 完整保留不变量、证据义务、边界、禁止结果和强制方法，不得削弱其含义或力度。
5. 除非证据支持将某项做法归类为候选路径，否则必须将其保留为强制要求。
6. 返回分类台账和改动最少的拟议契约。
7. 除非用户提出要求且已加载有权编辑的负责人，否则不要修改源文。

适配门槛

仅在满足以下条件时替换候选路径：

• 替代方案保留了每个已接受的契约字段。
• 有证据表明替代方案有实质性好处，或当前路径受阻。
• 替代方案未超出当前权限和副作用限制。
• 任何被取消、延迟或调整优先级的工作都已获得用户批准。

若无法证明满足这些条件，则保留当前路径或将路线标记为未解决。某个组件更好，并不能证明整体结果更好。

输出

先展示契约。在审计模式下，随后附上分类台账。明确区分已接受的契约、拟议路线和执行证据。

下一步需要修订文本时，加载 meaning-preserving-rewrite。仅涉及技能简化的工作交由 simplify-skill，仅涉及计划的工作交由 plan，长期目标打包交由 goal-prompt，执行工作交由相应领域负责人。

应阅读哪个示例？

资源门槛：使用此处所列的包文件前，先运行 mise run validate。

当实际请求中指定了结果、边界和拟议实现时，阅读 examples/conversation-candidate-path.md。当政策或规范可能混合固定审批规则与可替换工具时，阅读 examples/artifact-audit.md。在为简单请求增加契约工作前，阅读 examples/simple-request-bypass.md；这是该技能最可能导致的失败。

常见陷阱

• 认为指令越短就一定越好。
• 仅因某个步骤被写下来，就将其全部保留。
• 因安全规则或证据规则听起来像流程要求，就降低其级别。
• 在没有证据或批准的情况下，替换用户选择的方法。
• 臆造证明、约束或禁止结果。
• 将契约或拟议改写当作执行证明。
• 未经用户授权就编辑接受审计的源文。

渐进式披露

测试、审查或更改运行时行为前，阅读 references/eval-cases.json。更改包结构或从原生内容到公开内容的沿袭关系前，阅读 references/generation-contract.md。仅在测量激活、行为、故障处理、恢复或速度时，才阅读 evals/cases.json 和 evals/ 中的其余内容。更改验证行为前，加载 mise run test，然后运行 mise run ci；常规使用时无需加载 mise run test。

验证

• starting-point 在分类前构建了私有结果映射。
• 每条重要源指令都有一个源 ID，并清晰标注类别。
• 保留的要求维持了原有含义、权威性和力度。
• 每项被放宽的做法都说明了保留的契约和支持证据。
• 未知事项保持可见，不靠猜测来定论。
• 契约允许采用更好的安全路线，同时不允许结果变差。
• 外部操作和源文修改仍须通过各自的常规门槛。

工厂执行契约

可接受的结果是：在替换失败的候选路径时，保留请求的结果边界和证明阈值。在改变结果边界时，只更改其最小归属方，同时保留当前结果边界的行为。

1. 使用 mise run ci 冻结当前软件包并记录其摘要。
2. 运行 mise run domain-research-policy，然后评判当前结果边界的来源和反证。
3. 针对指定的结果边界操作运行 mise run agentic-request。由模型做出语义选择。
4. 运行 mise run decision-policy、mise run ci 和行为评估。返回到失败层级最低的归属方。
5. 运行 mise run invocation-policy -- <receipt>，并说明每项任务的处理情况，或说明其领域特定的不适用原因。
6. 可选运行 mise run improvement-policy。只有在没有受保护维度退化时，才保留一个变更维度。

只有在需要相应契约时，才通过 mise run use-case-policy 加载 assets/use-case-contract.json，并通过 mise run evals 加载 evals/evals.json。

Mise 负责可重复的机制、顺序、回执和检查。模型负责代码无法提供的解读、因果判断、创造性工作和直接感知。若缺少授权、证据过时或某个门禁未通过，则停止。