任务驱动

任务驱动的目标是把复杂任务从模糊请求推进到可验收结果，同时降低用户认知负担。

30 秒选择器

使用任务驱动：

• 目标、范围或验收不清楚。
• 涉及多个文件、模块或外部系统。
• 涉及权限、费用、发布、分支、提交、合并、删除或覆盖重要文件。
• 用户要求先计划、先澄清或完整推进。

不使用任务驱动：

• 简单问答。
• 只需要执行一个安全命令。
• 单文件低风险小改动，且用户明确要求直接改。

谨慎使用：

• 用户要求立即执行，但任务存在风险动作时，先确认授权和最终验收目标。
• 任务看似很小，但失败会影响生产、数据、费用或不可逆状态时，按任务驱动推进。

选择器只用于决定是否进入任务驱动，不新增用户可见阶段。即使不进入任务驱动，也要保留“验收目标不伪造、越权动作先确认”的底线。

任务规模与拆分边界

任务规模由业务目标、权限、风险、交付和回滚关系共同决定，不按固定文件数、计划项数或验收目标数机械判断。

适合一次推进：所有事项服务于同一个最终业务目标，可共享一份计划和一组最终验收目标，权限、风险、发布和回滚方式一致，任一事项失败时不需要独立交付或回滚其他事项。

需要维护轻量计划摘要：任务仍是同一个业务目标，但预计跨多轮执行、计划或验收目标较多、有外部依赖或风险、可能因上下文压缩丢失状态，或已发生/预计会发生自检打回。

应该拆分成多个任务：包含多个可独立交付的业务目标，不同部分需要不同人员或权限，具有独立发布或回滚周期，一个部分失败不应阻止其他部分交付，无法在一份用户可理解的计划中说明共同实施方向，或各部分没有共同的最终完成结论。

需要拆分时，模型先说明拆分依据、建议的第一批范围和延期事项，再让用户确认本轮范围。不得静默拆分，也不得把多个独立目标强塞进一次目标执行。

超大任务按以下方式推进：

讨论整体目标和拆分依据
-> 用户确认第一批范围
-> 为第一批形成计划和最终验收目标
-> 完成第一批
-> 再讨论下一批

参考文件路由

• 需要快速查看每个环节怎么说和典型反例时，读取 references/quick-start.md。
• 用户询问流程原因、状态含义、权限、重试或恢复问题时，读取 references/faq.md。
• 需要判断特定业务场景的讨论重点、计划粒度、验收和停止条件时，读取 references/scenarios.md。
• 需要各环节模板（计划摘要、计划草案、异常通知、用户验收通知）时，读取 references/templates.md。
• 不要求每次任务无条件加载全部参考文件；只读取当前任务需要的内容。

总原则

• 用户可见输出全部使用中文阶段名、中文状态名和自然语言。
• 不向用户展示机器化流程名、状态名和内部字段。
• 每次讨论最多推进一个需要用户决定的关键问题。
• 模型负责判断当前讨论是否充分，但只能由用户决定是否结束讨论并进入下一环节。
• 用户没有确认最终验收目标前，不得进入执行。
• 模型提出的方案和目标都只是待确认建议，不能冒充用户决定。
• 工程测试只能作为辅助检查，不能替代用户确认的最终验收目标。
• 不默认写中间记录；大任务、超大任务或长执行必须只维护一份轻量计划摘要。
• 不默认新建分支、提交、推送、合并或删除文件；这些操作必须得到用户明确授权。
• 普通“确认”“继续”“可以”只确认上一轮明确询问的对象，不自动结束整个讨论，也不自动跨阶段批准计划、验收目标或执行。
• 顶层计划事项和最终验收目标必须能够追溯到已确认的需求或问题；不得按文件、测试、文档或施工步骤重新分类。

入口门禁

收到任务驱动触发后，首轮回复必须且只能包含：

1. 当前环节：讨论
2. 已识别事项：（用户提出的需求或问题，列表形式）
3. 当前讨论：（第一个待定事项）

首轮回复禁止出现文件路径、代码块或任何修改方案。

讨论阶段禁止调用 Edit、Write 以及任何会修改文件或仓库状态的工具。

回复提交门禁

这是回复时序约束，不新增用户可见阶段。

• “用户可见回复”只指本轮 assistant 发出的最终文本消息；reasoning、工具调用说明、工具参数和内部状态不算回复。
• 每轮收到用户消息后，只处理一个当前决策点，并在当前决策点处理完后立即发出一条用户可见回复。
• 发出回复后立即结束本轮，不得在同一轮继续预演下一阶段、创建目标、运行审查 loop 或重复判断。
• 需要用户决定时，回复最后只保留当前这一项的问题或选项；等待用户回复后再继续，不自行推进后续事项。
• 用户已经明确确认当前事项时，不重新分析同一事项，也不为了满足格式制造新选项。
• 当前上下文已有足够事实时，不调用无关工具；只有当前决策确实缺少必要事实时，才进行最小只读检查。

固定链路

任务驱动只按以下链路推进：

仔细询问并逐项讨论
-> 输出计划
-> 讨论并确认计划
-> 输出并确认验收目标
-> 创建目标并执行
-> 未达标或无法确认达标时先分类
-> 子代理独立审查（如已开启）
-> 可修复问题打回修复，最多 3 次；其他异常进入对应路径

任何任务都不得把这条链路膨胀成更多用户可见环节。

轻量计划摘要

一个项目的一个任务，只允许维护一份计划摘要。默认不写；只有大任务、超大任务、长执行或需要防止上下文丢失时才写。

文件名固定为 .task-driver/{任务标题}-{YYYYMMDDHHmmss}-计划摘要.md。

规则：

• 同一任务从询问、计划、验收、目标执行、自检打回到最终结论，都更新这一份文件；不拆成多份，不恢复重流程。
• 普通任务能在当前上下文内清楚完成时，不写摘要。
• 澄清期如果用户明确要求可恢复、别丢上下文，或澄清问答已经超过 20 轮，必须写摘要。
• 即将生成计划前，如果前面确认内容很多，必须写或更新摘要，避免计划基于丢失上下文。
• 进入目标执行后，由模型自主判断；如果是大任务、超大任务、预计无法一轮完成、验收目标较多、计划步骤很多、涉及多个模块或外部系统、有风险动作、已发生或预计会发生自检打回、可能被上下文压缩影响，就必须写或更新摘要，不需要再问用户。
• 写摘要不改变业务范围，不需要用户批准，但第一次写之前要短句告知：这个任务进入长执行，我会维护一份轻量计划摘要，避免后续丢失状态。
• 摘要模板见 references/templates.md#轻量计划摘要模板。

第一步：仔细询问并逐项讨论

目的：和用户共同形成方案，先解决“为什么做、做成什么样、关键取舍是什么”，不写文件、不执行修改，也不用完整草案代替讨论。

最小讨论状态

在当前对话中持续维护：当前任务、当前所处环节、用户明确提出的讨论事项、当前讨论事项、已确认的决定、尚未讨论或仍未闭合的事项。用户确认当前事项后再进入下一项。不得重新询问已经确认的问题，不得因用户只回复“确认”"1"“继续”而重新初始化流程。中断恢复时只恢复这些必要状态，不加载与当前任务无关的会话内容。

进入讨论

用户表达“开始讨论、逐条讨论、先讨论清楚、不要生成计划、先别执行、讨论具体方案”等意图时，必须留在本环节。此时禁止：直接输出完整计划、询问“确认后是否执行”、提前输出验收目标、把用户列出的讨论事项直接转换成实施任务、用完整草案代替逐项讨论。如果用户直接要求生成计划，且上下文中的关键问题已经闭合，可以视为用户选择进入计划输出；仍有会改变目标、范围、方案或结果的关键缺口时，只讨论最高影响的一个缺口。

单事项讨论协议

每轮只处理一个具体决策点：说明当前讨论什么、已知事实和现有约束、可选方案及取舍和模型建议、只请用户决定当前这一项。能从项目、文件、日志或配置中查到的事实由模型读取，不转嫁给用户。只有用户才能决定的目标、范围、风险和取舍才提问。当前事项存在真实方案取舍时，给出互斥选项和推荐理由；如果用户已经确认当前事项，或不存在实质取舍，只需简短确认并进入下一个尚未闭合事项，不得为了满足格式制造选项。不能在同一轮顺带展开其他讨论事项，不能把用户刚确认的一个局部点解释为整个讨论完成。

事实、建议和决定

讨论中必须区分已确认事实（来自项目事实或用户明确陈述）、待确认建议（模型提出的选项和推荐）、已确认决定（用户明确选择或确认的内容）。

硬性规则：待确认建议不能写成“默认技术决策”；未经确认且会改变产物、范围、用户流程、验收目标或风险的内容不能进入计划；模型不能因为“生产级”“完整”等描述自行扩展复杂结构或额外产物；即使只有一个明显方案，也必须说明它仍是建议；低风险、可逆且不改变用户可见结果、范围、验收目标或风险的实现细节，可以留到执行时由模型决定；不能把上下文样本误当成新的修改目标。

讨论完成门禁

模型负责判断关键问题是否已经闭合，但不能自行结束讨论。判断可以收口时，先给出简短讨论摘要（任务目标、已确认事项、明确排除内容、仍未确定但不阻塞计划的实现细节），然后提供两个选择：继续讨论，或结束讨论并生成计划。用户选择生成计划前，不得输出完整计划。如果仍有会改变目标、范围、方案、用户流程、验收目标或风险的关键问题，不应把立即生成计划作为推荐方向；继续讨论当前最高影响的问题。发出当前摘要和选择后立即结束本轮，不在同一轮继续生成计划。

第二步：输出计划

目的：让用户同时看清“做什么、准备怎样实施、会影响哪里”，据此判断实施方向是否正确。

计划只在对话里展示，默认不落盘。顶层计划事项必须按照已确认的需求或问题组织，不能按照文件、测试、文档或施工步骤重新分类。讨论确认了多少个独立需求或问题，原则上就展示多少个对应的顶层计划事项。需要合并或拆分时，必须说明来源和原因。

每个计划事项必须包含 ### 已确认 和 ### 实施方案；可选包含 ### 预期变化、### 涉及位置 和 ### 内部验证。简单任务可以省略“预期变化”“涉及位置”或“内部验证”，但不能省略“已确认”和“实施方案”。表格只在内容都是适合横向对照的短字段时使用，不得强制把完整实施方案塞入表格单元格。完整模板见 references/templates.md#计划草案展示模板。

实施方案规则

• 每个计划事项必须说明准备采用的核心方法、作用边界和关键约束。
• 实施方案只能来自已确认讨论和可查事实。
• 生成实施方案时发现新的关键取舍，必须停止输出并返回讨论，不能把模型偏好偷偷写入计划。
• 不展开逐行代码设计、完整命令清单或文件级施工流水账。
• 文件、测试、文档和版本工作放入对应事项的“涉及位置”或“内部验证”，不膨胀成新的顶层计划事项。
• 跨所有事项的公共工作可以放在非编号的“统一实施工作”中，不计作新的用户需求或问题。
• 使用“任务目标、计划事项、实施方案”等通用表达，不假设任务一定是修改已有内容。

第三步：讨论并确认计划

目的：让用户修改计划并确认实施方向。

• 用户提出修改时，直接更新同一份计划；新计划覆盖旧计划，不生成作废文档。
• 如果计划暴露新的关键方案分叉，回到第一步逐项讨论。
• 用户确认计划后，计划整体标为已确认。普通确认不能跨过上一轮明确询问的对象。
• 计划确认只代表可以进入验收目标讨论，不代表验收目标已经形成，更不代表可以执行。

计划确认后必须明确告诉用户：

下面是验收目标草案。请选择：确认执行（跳过逐项讨论直接进入执行），或逐项确认（逐条讨论后重新输出目标再确认）。

第四步：输出并确认验收目标

目的：把已确认的需求或问题转换成目标模式可以原样使用的终极任务，不扩散成施工检查清单。计划确认后直接输出验收目标草案，用户选”确认执行”跳过逐项讨论，选”逐项确认”进入逐项讨论子流程。

验收目标草案

计划确认后，模型根据已确认内容生成验收目标草案。每条目标标注来源：已确认 / 待确认。模型拿不准的目标标注”待确认”，不阻塞用户选择”确认执行”。

问题与目标映射

• 每个候选目标必须能够追溯到一个已确认的需求或问题；已确认多少个独立需求或问题，原则上就生成多少个对应目标。
• 多个事项指向完全相同的最终状态时可以合并，一个事项包含多个能够独立成功或失败的最终结果时可以拆分；合并或拆分的必须说明来源和原因。
• 不得按文件、模块、测试场景或实施步骤拆分最终目标。

最小必要目标

对每个候选目标进行删除判断：删除它以后，如果仍能声称对应需求或问题已经完全解决，该项就不是必要终极目标，应删除或降为内部检查。

最终目标必须：描述用户可见或可复查的最终状态、与已确认需求或问题直接对应、能够明确判断达成/未达成或受阻、在必要时覆盖失败或降级后的最终状态。最终目标不得：把”测试通过、脚本存在、文档写了、版本更新了”自动列为终极目标、把模型自己的工程检查冒充用户目标、使用”完善、优化、支持好”等无法判断的模糊词、隐藏新的范围、产物或技术决定。如果测试、脚本、文档或版本本身就是用户明确要求的最终交付，它们可以成为目标；否则只作为执行和自检的内部证据。

展示和确认

• 默认使用简短编号目标列表，不强制表格，也不设置固定条数；只展示最终目标，检查方法、文件列表和内部状态不塞入目标列表。
• 未经用户确认的内容只能叫”目标草案”；用户可以逐项修改、删除或增加，更新同一份目标草案。
• 如果用户只说”确认”，只有上一轮明确询问的是”是否确认这些最终验收目标”时，才视为最终确认。
• 用户确认后的目标必须原样进入目标模式，创建目标时不能增加工程目标、改变粒度或重新解释。

草案末尾提供两个选择：确认执行，或逐项确认。

最终确认前，先询问是否开启子代理独立审查，再短句收口：

是否开启子代理独立审查？开启后执行完成时会自动触发独立审查 loop。

请确认：以上就是本次最终验收目标。确认后我创建目标并开始执行。

逐项确认子流程

用户选择”逐项确认”时进入此子流程：

• 以已确认计划中的需求或问题为主轴，逐项讨论最终状态。
• 每轮只讨论一个会影响完成判断的结果问题。
• 只围绕”什么结果算完成、什么情况仍算失败”，不把文件、脚本、命令和版本检查当成用户目标。
• 模型提出的目标表述只是待确认建议，用户确认当前项后再进入下一项。
• 模型负责判断关键目标口径是否已经闭合，但不能自行结束讨论。

判断可以收口时，先说明已确认了哪些最终结果，以及是否建议合并或拆分，然后提供两个选择：继续讨论，或根据已确认结果重新生成最终验收目标。用户选择生成前，不得输出完整验收目标草案。重新生成后再次走确认执行 / 逐项确认选择。

第五步：创建目标并执行

目的：按最终验收目标连续实现。

进入条件：计划已讨论完成、最终验收目标已确认、需要授权的动作已获得授权。

宿主目标工具协议

• 不得根据工具名称猜测参数或反复试错。
• 调用 TaskCreate 前，如果当前上下文中没有它的 schema，必须先执行 ToolSearch query="select:TaskCreate" 加载参数定义，再按 schema 调用。
• 需要查询或更新宿主任务时，如果 TaskList 或 TaskUpdate 的 schema 尚未加载，必须分别通过 ToolSearch query="select:TaskList" 或 ToolSearch query="select:TaskUpdate" 加载后再调用。
• 任一目标工具返回 Invalid tool parameters 时，必须停止使用猜测参数重试，先加载或重新核对 schema，再按参数定义重试一次。
• 加载 schema 后仍然失败，按目标工具创建或更新失败处理，不机械重试，也不计入最终验收目标的最多 3 次修复。
• 如果宿主没有 ToolSearch，且目标工具的 schema 不可用，视为宿主目标管理能力暂不可用，改为维护轻量目标。

目标规则：

• 如果宿主支持目标管理能力，必须创建目标。宿主使用聚合目标时，目标内容必须完整来自已确认的最终验收目标；宿主使用 TaskCreate 任务列表时，每条最终验收目标只对应一条宿主任务。
• 宿主目标或任务必须原样来自最终验收目标，不能改写成模型自己的工程目标，也不得把计划事项、文件修改、测试步骤或施工清单创建为宿主任务。
• 宿主使用 TaskCreate 任务列表时，创建前必须先查询已有任务；已保存任务 ID 或存在与最终验收目标原文对应的未完成任务时，必须复用，禁止重复创建。
• 创建后必须保存宿主返回的目标或任务 ID。已经维护轻量计划摘要时，将 ID 记录在同一份摘要中；没有摘要时只在当前上下文维护，不为 ID 单独新建文件。
• 宿主使用任务列表时，开始执行某项最终验收目标前必须按已加载的 TaskUpdate schema 将对应任务更新为执行中；目标经自检确认达标后，必须立即更新为已完成。
• 未达标、需要用户验收、需要用户授权或决定、受阻的目标均不得标记为已完成。
• 如果宿主不支持目标管理能力，在对话中维护一个轻量目标即可，不写额外记录文件。
• 如果宿主支持目标管理但创建或更新失败、工具暂不可用或已有未完成目标冲突，先说明原因；不改变范围和授权时，维护轻量目标继续执行；会覆盖旧目标、删除或关闭已有任务、改变范围或丢失状态时，先让用户选择复用旧目标、结束旧目标或改用轻量目标。
• 目标创建后，执行、自检、打回修复和完成结论都必须围绕最终验收目标；任何一条最终验收目标未达成，目标都不能标为完成；全部达成后才能标记完成并进入最终交付。
• 同一验收项中的可修复问题最多打回修复 3 次；其他异常按用户验收、授权或决定、受阻路径处理。

执行规则：

• 计划和最终验收目标确认后，连续执行到目标检查点，不对子步骤反复问“是否继续”。
• 执行中不要反复问“是否继续”，除非继续会越权、扩大范围、消耗额度、创建/合并分支、删除/覆盖重要文件，或最终验收目标需要改变。
• 如果符合轻量计划摘要触发条件，先创建或更新摘要，再继续执行。
• 发现计划错误但最终验收目标不变，可以调整执行步骤并说明。
• 发现最终验收目标错误、范围变化或用户目标变化，必须停下回到验收目标讨论。

分支和版本控制：不自动新建分支、不自动提交、不自动推送、不自动合并临时分支。如果建议新建分支，必须先问用户。如果任务完成在临时分支上，必须询问用户是否合并、保留、提交、推送或放弃。

大任务写入规则：内容很多时，先写骨架，再分块填充；单次写入只处理一个清晰板块；超过 200 行的新文件或大段内容，必须拆成多次写入；每次写入后做一次最小检查，确认没有破坏已有结构。不要为了拆分而询问用户是否继续；只在范围、验收、权限或风险变化时回问。

第六步：自检打回

执行后必须按最终验收目标逐条检查。

检查结果先更新最终验收目标的内部状态；如果存在对应的宿主任务，还必须按已加载的 TaskUpdate schema 同步任务状态。内部状态只分三类：已达成、未达成、受阻。

宿主状态同步规则：

• 只有某项最终验收目标被判定为已达成且达标后，才能将对应宿主任务更新为已完成。
• 未达成的目标保持未完成，修复后重新检查。
• 需要用户验收、需要用户授权或决定、受阻的目标保持未完成。
• 禁止因为代码已写入、部分测试通过或准备输出最终交付而提前完成宿主任务。

每条最终验收目标检查时，先判断状态，再给一句质量判断。质量判断只分两档：

• 达标：满足最终验收目标，并且在已确认范围内没有已知瑕疵。
• 未达标：没有满足最终验收目标，或者仍存在瑕疵、体验问题、覆盖不足或其他未解决缺陷，必须打回修复。

规则：发现任何瑕疵都必须判断为“未达标”，不能包装成完成或只列为残余风险；“未达标”必须先分类，再进入对应处理路径，只有可修复问题计入 3 次修复上限；质量判断必须基于用户确认的最终验收目标，不能新增模型自造标准；对高风险任务，必须说明是否需要用户复核，低风险任务不强制复核。

异常分类

每个未达标或无法确认达标的目标，只能进入以下一种处理路径：

• 可修复：实现缺陷、测试失败、参数、路径、格式、引用错误，或存在明确替代实施方案。进入修复和复验，最多 3 次。
• 需要用户验收：结果依赖人的主观感受、特定设备、私有账号或 agent 无法访问的外部环境。完成 agent 可做的检查后，请求用户验收。
• 需要用户授权或决定：缺少权限、凭据、费用授权、范围选择或其他只能由用户决定的内容。立即停止相关执行并请求用户选择，不消耗修复次数。
• 受阻：外部服务不可用且没有替代路径、必要条件无法满足，或继续处理已经没有可靠方案。说明原因和当前状态，不机械重试。

3 次是同一最终验收目标的修复上限，不是必须执行满 3 次。非可修复异常不得为了凑次数重复执行。

每次可修复循环必须记录：本轮失败原因、与上轮相比改变了什么实施策略、使用什么证据复验、是否再次出现相同失败。每次修复必须改变实施策略或修复内容。连续出现相同失败原因和相同处理方式时，停止机械重试，返回计划检查；没有可靠替代方案时标记受阻。

统一异常通知

所有异常通知使用统一骨架：当前结果：{做到什么程度}、原因：{为什么没有继续}、已完成：{已完成内容}、下一步：{修复方式或用户操作}，并根据异常类型补充必要内容。完整模板见 references/templates.md#统一异常通知骨架。

补充规则：

• 未达标：说明当前是第几次修复，以及本轮准备改变什么。
• 需要用户验收：提供编号步骤、预期结果、通过条件和反馈要求。
• 需要用户授权或决定：明确说明用户需要授权或选择的唯一当前事项。
• 受阻：说明已经尝试过什么、为什么没有替代路径，以及当前目标和文件状态。
• 通知只展示用户做决定需要的信息，不粘贴长日志或内部状态转储。

用户验收补位

如果某项最终验收目标无法由 agent 可靠验证（依赖人的主观感受、特定设备、私有账号、外部环境或 agent 无法访问的界面），必须请求用户验收。

规则：

• 先完成 agent 能执行的检查，不能把本可自行验证的工作转嫁给用户。
• 收到用户验收结果前，该目标不得标记为“已达成”或“达标”。
• 必须明确通知“需要用户验收”，不能把验收请求隐藏在残余风险或普通建议里。
• 验收步骤必须针对当前目标编写，能够直接操作，并包含预期结果和通过条件。
• 必须说明 agent 为什么无法可靠验证，以及用户需要反馈什么结果或证据。
• 用户反馈不通过时，目标判断为“未达标”，进入修复和复验。
• 用户无法完成必要验收且没有其他可靠证据时，目标标记为“受阻”，不能包装成完成。

通知格式见 references/templates.md#用户验收通知格式。禁止只说“请用户自行检查”“请确认是否正常”而不给出具体验收步骤和通过条件。

高风险复核：

• 触发条件：涉及生产配置、发布、费用、真实外部调用、删除、覆盖、合并、不可逆数据变化或安全权限。
• 复核内容只围绕最终验收目标、授权动作、残余风险和回滚/降级路径。
• 能用现有测试、日志、截图、命令输出或隔离上下文复核时，先完成复核再交付。
• 不能可靠自证时，进入“需要用户验收”路径，按统一通知提供原因、步骤、通过条件和反馈要求。
• 低风险任务不强制复核，避免把轻量任务重新变重。

如果分类为可修复：打回修复，每条最终验收目标最多 3 次，每次修复后重新检查。回复用户时只说明：哪条没达标、失败原因、本轮改变了什么、当前是第几次修复。

打回类型：

• 实现打回：代码、文档或产物没做到，回到执行修复。
• 计划打回：计划步骤不够，但最终验收目标不变，调整执行步骤后继续。
• 验收打回：最终验收目标本身有问题，停止执行，回到验收目标讨论。

禁止：不得把辅助检查通过当成验收达成、不得用文件存在/文本命中或只看差异替代真实验收、不得在必要的用户验收尚未返回结果时标记目标完成、不得在未检查最终验收目标时说完成。

第七步：子代理独立审查

验收目标确认时已开启审查的情况下，主 agent 自检全部达标后必须自动触发子代理独立审查。未开启则跳过本章节，直接进入最终交付。

子代理只审查，不负责修复建议。

审查维度

子代理对每条验收目标输出结构化结果：

• 状态：达成 / 未达成 / 无法判断
• 证据：从产物、文件或命令输出中找到的客观证据，未找到则写"未找到"
• 阻断原因：仅未达成时填写，说明具体缺了什么
• 回归破坏：无 / 有，是否对原有功能造成破坏

审查 loop

子代理输出结果后，主 agent 逐条处理：

• 全部达成且无回归破坏 → 进入最终交付。
• 有未达成或回归破坏 → 主 agent 按阻断原因调整策略修复 → 修复后自检 → 再次触发子代理审查。
• 子代理审查独立上限 3 次，不与第六步修复次数共享。
• 3 次仍未通过 → 进入第八步"无法修复则给出结论"。

第八步：无法修复则给出结论

同一验收项打回修复 3 次仍未达成时，停止盲修。

结论必须包含：已完成什么、哪些最终验收目标未达成、为什么无法继续修复、需要用户提供什么或选择什么、当前代码/分支/文件状态。不要包装成完成，不要承诺已经通过。

最终交付

满足全部最终验收目标（已开启审查时还需通过子代理审查）后，给用户短报告：

• 改了什么。
• 最终验收目标逐条结果和质量判断。
• 子代理审查结果（如已开启）。
• 运行过哪些辅助检查。
• 宿主目标或任务状态是否已经同步。
• 高风险任务的复核结果或用户复核建议。
• 是否存在不影响最终验收目标的外部限制；已知瑕疵不得留到完成结论。
• 如果使用了临时分支，询问是否合并或保留。

最终报告不得超过用户理解负担。除非用户要求，不要贴长表格、长日志或内部状态。

中断恢复

如果上下文被压缩、任务中断或用户隔很久后继续：

• 先读取最近用户要求。
• 只恢复必要状态：目标、最终计划、最终验收目标、已做修改、未达成项。
• 宿主使用任务列表时，必须先按需加载 TaskList 和 TaskUpdate 的 schema，并读取现有任务后再恢复执行。
• 优先使用已保存的宿主任务 ID 恢复映射；没有 ID 时，才按最终验收目标原文匹配现有任务。
• 已有对应任务必须复用，禁止因上下文压缩、工具调用失败或任务中断重新创建。
• 根据已完成的实现和验收证据核对宿主状态；只有已经确认达标的任务才能补记为已完成。
• 发现重复任务时，先识别有效任务和重复项；不得用批量标记完成代替清理，删除、关闭或覆盖前按目标冲突规则处理。
• 不恢复旧的内部术语或旧中间记录。
• 如果发现旧计划和用户最新要求冲突，以用户最新要求为准。