escalate

这是终端交接，仅在有用的独立工作已全部完成后调用。 较早的阻塞通知应写入执行器的进度报告；它不会结束本次运行。如果仍有有用的独立工作，应先返回调用方执行器继续处理，再升级。

从 /do 接收 Manifest 路径，以及受影响的门禁和每项门禁背后的实际证据。按原样转述这些证据，不得虚构本次运行未进行的验证。报告开头说明所需的干预——缺少知识或访问权限、需要新的授权，或需要更改 Outcome 或硬性要求——并给出你建议的解决方案；直接报告，不要开启提问后等待的循环。将其与阻塞证据一并呈现：说明无法满足的 Outcome 或标准（OUTCOME、INV-G 或 AC ID），以及已调查的可信恢复路径和这些路径失败的原因。说明已完成哪些独立工作，以及剩余工作为何依赖该干预。如果 /do 留有执行日志，写明其路径，以便恢复运行时查看本次运行尝试过的内容。

还要说明重要的自主决策及其理由，包括重要工作主张和证据的修订及其依据、Appetite 修订及其新增复杂度或维护成本所带来的收益、偏离的 Process Guidance、与 Initial Approach 或 Deliverable 顺序不符之处、途中修复的问题、/do 移交的债务——仅列出本次运行无法修复的事项，并逐项按原样提供；对于用户希望处理的事项，提出 ticket-up，绝不得把低于某项门禁标准的发现或途中已修复的既有问题列入其中；以及每个已标记为需由人员处理而非已接受的提议——无论是本次运行标记的，还是 Manifest 的 ASM-* 条目所标记的——还有每条由 Agent 担任决策者的决策记录，并说明接受该提议或审阅该记录会带来什么变化。即使执行日志中已记录这些内容，也要在此列出。/do 提供的任何草拟 Taste 条目都必须原样附上，并保留征求用户同意的问题。

用户的决定。 如果两个谨慎的人依据相同证据可以合理地作出不同决定，且差异会影响用户，那么这就是用户的决定。用这句话检验每项重要决策；你有多大把握并不能代替判断。遇到用户的决定时，先遵守任何明确保留的决定或适用的授权；然后查看用户的 Taste 条目——已加载记忆文件中 ## Taste 部分的、已获认可的偏好。只有条目明显适用于此类决策，且遵循该条目会改变选择时，才予以遵循。仅仅倾向于少花精力或降低成本等几乎会影响所有决策的一般偏好，本身不算适用。否则依据证据作出决定。报告决策时，先逐项列出本次运行重新审议的每条决策记录，说明搁置原决定的理由，以及推翻该决定的代价；然后列出用户的决定，并逐项说明未选的备选方案，以及决定依据——遵循的条目，或不适用任何条目。

即使某个门禁已通过，调用方无权修改的错误硬性前提仍可能在此出现。应引用报告，或说明执行过程中实际显示的情况，而不是尝试通过的门禁本身并不具备的内容。只要修复仍可行，门槛成本高并不构成阻塞，且本技能绝不会降低门槛。

单独给出验证器的 BLOCKED 判定并不足够：执行器必须先调查可恢复之处并完成有用的独立工作。引用剩余的 BLOCKED 说明，并指出所需的外部操作。根据禁止等待政策，纯外部等待应报告为待处理；否则，执行器应等待并重新验证。若等待停滞且没有可行的恢复路径，应在此说明所需的干预。有关 Manifest 或流程的纯用户问题由执行器直接回答。 如果用户之后提出范围或需求变更，请使用 Manifest 路径调用 define，然后使用本报告中指定的日志路径，在 Manifest 上恢复执行器。如果他们解除阻碍或补充缺失的上下文，也请以相同方式恢复执行。他们的回复用于指引；恢复后的执行仍保持无人值守。