Durable

---
name: durable
description: "将复杂、耗时、适合无人值守的任务先塑形为可执行约定，在用户明确授权后持续实施、验证、评审和真实交付；也可保存为 Todo 供新会话直接启动。用于用户提到 Durable、长任务、今晚跑、不要中途询问、先准备后执行，或需要在长时间工作前澄清目标、交付链路、POC、权限与人工介入点时。AI 可以建议使用，但未经用户同意不得进入 Durable 执行。"
---

# Durable

把用户从长时间等待和盯守中释放出来，同时保留必要的知情权、授权边界和最终验收。Durable 是当前任务的执行方式，不是恢复系统、进度平台或固定流水线。

## 硬约束

1. 先理解用户最终要获得的状态，以及用户如何实际走到这个结果；文件、代码或命令完成不等于交付完成。
2. AI 可以建议使用 Durable，但只有用户明确说“开始”“执行”或等价表达后，才进入无人值守执行。用户已在本次请求中明确启动时，不重复索要同一授权。
3. 将任务塑形、POC 和 Durable 执行视为三种不同成本。POC 必须先说明价值、边界与副作用，并单独取得同意。
4. 不为 Durable 新建心跳、恢复协议、进度状态机或中间文件体系。保持同一会话持续执行；宿主的会话保存与压缩由宿主负责。
5. Durable 不扩大权限。付款、真实消息、公开发布、不可恢复删除和高风险生产变更仍需原任务明确授权。
6. 普通实现选择、可逆修改、测试失败和技术障碍自行处理，不把它们升级为 Human in the Loop。
7. 只有产物、完整使用链路和验证证据同时成立，才可宣布完成。
8. 不用虚假的精确时间承诺。说明这可能持续数小时或整夜，并披露有证据的主要耗时阶段、额度或外部副作用、不确定因素，以及下一次需要用户出现的节点。

## 进入路线

开始塑形、判断 POC、保存 Todo 或准备交付链路前，完整阅读 [`references/shaping.md`](references/shaping.md)。如果存在 `experience.local.md`，只读取与当前任务相关的已验证环境事实、POC 结论和长期偏好；环境或前提未实质变化时不要重复验证。

### 1. 塑形

从第一性原理还原一个人完成此任务的真实过程。先检查现有项目、可用 Skills、Todo 和已有证据，再只询问无法从现场得到、且会改变方向或造成长时间返工的问题。

达到最小启动条件后停止提问。若用户尚未授权启动，提供三个选择：

- 现在开始 Durable；
- 保存为 Todo，稍后在新会话开始；
- 继续调整。

如果用户已经明确要求现在开始，且塑形未发现新的高成本、权限或不可逆事项，则直接进入执行，不重复确认。

### 2. 明确启动

启动前用简短语言说明：

- 接下来是可能持续数小时或整夜的无人值守执行；
- 用户可以离开，不需要盯守；
- 下一次人工节点是最终验收，或确实无法由安全默认值解决的决定。

只有用户明确开始后才进入执行；这项授权可以来自本次请求的前文。账号、环境、POC 通过或状态为 `canDurable` 都不等于已经开始。

### 3. 持续执行

根据目标生成最薄的运行时工作骨架，只固定目标、强依赖、用户指定顺序、授权边界、人工检查门和最终验收；其余路径随证据动态调整。

- 优先复用项目默认值、已验证 POC 和现有 Skills。
- 在关键能力已证明可用后，再按依赖关系使用子代理并行独立工作。
- 对失败执行观察、诊断、修复、重试与替代方案闭环。
- 不因报告进度而暂停，也不要求用户读取中间文档。
- 若出现真正的 Human in the Loop 条件，保存已完成事实并只提出那个不可替代的问题。

### 4. 真实验收

按产物类型寻找并调用合适的独立 Reviewer，不在本 Skill 内维护万能检查表。Reviewer 应先识别产品类型、平台、输入方式、用户目标和现有设计语言，再动态生成评审路径。

交互产品必须从冷启动和真实入口开始，实际探索可点击元素及后续状态。Reviewer 先识别真实可达、会影响用户结果的状态，再验证所有适用状态，例如实际存在的加载、空、错误、边界内容和恢复路径；不得为满足清单而制造产品并不存在的状态。PC、移动端、桌面应用等分别采用符合其交互方式的评审标准。

对安全可逆操作执行到结果；付款、发布、真实消息和删除等动作优先使用隔离环境。没有隔离条件时验证到最终确认边界，并明确最后一步未执行。

发现问题后修复，并从真实入口重跑相关链路。部署属于交付时，还要在部署后的环境复验，不能用本地通过代替线上可用。

### 5. 交付与进化

最终报告只保留用户需要的事实：交付物、可直接使用的入口、完整链路验证、关键证据、未执行的高风险边界和仍需用户处理的事项。

每次 Durable 完成后调用 `efficiency-audit`，基于本次实际工具调用、返工和用户反馈进行无人值守审计。审计可以得出“无需修改”，不得为了表现出进化而强行改文件。

先按候选类型检查证据，不用同一门槛套用所有内容：

- Skill 规则调整需要可复现根因、外部证据、适用边界和明确目标 Skill。
- 环境事实与 POC 需要可复核证据、环境边界、验证时间和失效条件。
- 长期偏好需要用户明确表达、适用边界和与既有偏好的查重。

候选满足对应门槛后，继续自动进化：

1. 先在目标 Skill 的现有规则和经验中查重、查冲突。
2. 环境事实、已验证 POC 和明确的个人长期偏好写入对应 `experience.local.md`。
3. 可复现、可分享的规则写入对应 `SKILL.md` 或一层 reference，不写入个人自动记忆。
4. 用户指出 Reviewer 漏检时，从冷启动重新评审，并证明 Reviewer 能独立发现该问题。
5. 修改后运行原场景或等价盲测与回归；通过才自动保留，失败则恢复修改前版本。
6. 只修改用户管理、可写且处于当前授权范围内的 Skills；不修改无关或第三方稳定 Skill，不因追求结构完整而新增文件。

## 停止条件

仅在以下情况暂停等待用户：

- 多个产品方向会产生明显不同且难以回退的结果；
- 需要任务范围之外的新权限或外部协调；
- 即将发生未授权的付款、公开发布、真实通信、不可恢复删除或高风险生产操作；
- 缺少关键输入，任何合理假设都会显著改变最终结果；
- 已穷尽安全重试与替代路径，继续执行不再产生有效进展。

除此之外，继续工作直到真实交付完成。