[设计] 收敛 Task 对象与生命周期：Chief 接纳、单线交接、并行子任务及恢复验收 #2179

Written-by: Codex

定位

记录用户已确认的 Task 产品边界，作为字段、状态、接口及持久化设计和后续实施拆分的依据。
关联 #2170（独立个人代理）、#2171（Project 边界与角色治理）、#2175（咨询与 Handoff、打回续接）、#2177（上下文预算和记忆整理）。

本单是设计总 issue，不代表已实现、已部署或已通过真实任务验证；不自动启动开发或打断现有前端执行。常规技术取舍可独立完成，只有需要改变以下产品规则或权限边界时再向用户提出具体方案。

一、Task 的定义与边界

Task 是 Project 中一项对项目产生直接或间接影响、具有明确目标与可确认结果的行动承诺。

• 修改代码、验证质量、形成项目正式技术决策、更新规范、发布版本等均可成为 Task。
• 咨询本身不是 Task。问进度、解释方案、获取意见使用 consultation，不因耗费 Bot 时间而创建 Task。
• 咨询中发现需落实的行动时，另行提出 Task，写清目标和预期影响；不能把咨询归类成一种 Task。
• Task 属于 Project，具有稳定身份，不绑定单个仓库；遵守 Project 与仓库数量关系不受限制的约定。
• Dev → Reviewer → Dev → Tester → Chief 围绕同一个 Task；交接、打回、重试不自动产生新的业务 Task。
• 只有形成独立目标和验收要求的工作才拆成子 Task。

二、创建与接纳

• 项目成员及其有效授权个人代理可提出工作；提出后形成稳定 Task 记录，处于待澄清/待接纳状态。
• Chief 确认目标、预期项目影响、范围、验收要求足够清楚后，才进入角色任务池。
• Chief 可根据项目目标主动创建工作，但不因此获得超出项目授权的决策或发布权限。
• 关键歧义优先向提出方的个人代理澄清，必要时联系本人。
• 个人代理安全模式下正式提交 Task 需要用户授权；值守模式遵守用户授予的有效权限。不能以 Chief 接纳替代必要授权。

三、对象职责

• Task：目标、范围、验收要求、整体进展、依赖及最终结果。
• 子 Task：可独立验收的工作，保留父子关系；各自仍为稳定 Task。
• Handoff：下一步推进责任的交接、原因、要求、证据与接手凭据，遵守 [设计] 明确角色协作协议：持久化 Handoff、咨询分离、打回续接与个人代理优先 #2175。
• Attempt：某一轮执行过程与结果；一次失败不等于 Task 失败或关闭。
• Session：某角色处理同一任务的上下文，可跨 Attempt 恢复，遵守 [设计] 明确角色协作协议：持久化 Handoff、咨询分离、打回续接与个人代理优先 #2175/[设计] 统一 Chief 与工作角色的上下文预算、长期记忆整理及会话恢复机制 #2177。
• 验收与结果记录：版本化要求、证据、裁定与产物引用，不能只靠对话文本推断完成。

四、单线执行与并行拆分

每个可执行 Task 默认只由一个执行实例持有推进主动权；其他角色可提供咨询，咨询不夺走主动权。
需要并行时：

1. 当前 Bot 提出/创建独立子 Task，写明各自目标、验收要求及父子关系。
2. 父 Task 记录后续续接点及等待条件，进入“等待子任务”的阻塞状态，释放执行资源。
3. 子 Task 经 Chief 确认后进入各角色池，可以并行执行；每个子 Task 内仍单线推进并遵守 Handoff。
4. 子 Task 经 Chief 裁定完成后解除对应阻塞；所有阻塞解除时，父 Task 自动重新入列。
5. 父 Task 被领取后 resume 原角色处理父 Task 的 Session，读取子任务结果和交接增量，继续后续工作。

• 子 Task 取消或执行失败不自动当作依赖满足；Chief 判断替代结果是否足够、是否调整计划。
• 子 Task 全部完成不等于父 Task 完成；父 Task 负责集成和整体验收，最后仍由 Chief 裁定。
• 并发完成通知、重复事件、响应丢失和服务重启，只能形成一次有效的父 Task 入列/领取授权。
• 设计中明确防止父子/依赖循环和同一 Task 双执行，不把并行实现成共享 Session 或多人同时改同一工作区。

五、验收、变更与结束

• 提出方表达预期，Chief 整理确认验收要求；执行 Bot 可建议调整，不能自行降低标准。
• 补充信息追加到工作记录；目标、范围或验收要求实质变化须经 Chief 确认，保留版本并通知当前执行者。
• 若已经成为另一项工作，另建关联 Task，不悄悄改写旧任务的承诺。
• 执行 Bot 提交结果，Chief 根据验收要求与证据裁定完成；执行一轮结束、交接已处理、测试通过均不自动关闭 Task。
• 授权参与者可申请取消，由 Chief 按项目权限处理；取消必须保留原因，不计为完成。
• 完成后发现原验收未满足可申请重开，并保留原结果与裁定历史；新增要求另建 Task。
• 阻塞、等待答复、一次 Attempt 失败不等于 Task 结束。记录阻塞原因、解除条件、下一步责任方，由 Chief 巡检介入。
• 巡检频率是定时任务配置；沿用已确认的 30min 默认配置方向，不能硬编码到框架。
• Task 关闭由 Chief 裁定，与 Project 关闭不同。Project 关闭仍由 Owner 二次确认；未完成 Task 记录到项目最终记录即可，不能新增清空任务的关闭门槛。

六、结果汇合、可见性与上下文

• 子 Task 提交结构化结果、证据、产物及候选代码版本引用，父 Task 恢复后负责集成和整体验证。
• 同仓并行修改明确独立工作区、候选版本及集成关系，不能把子 Task 完成误当作已集成。
• Task 默认是项目协作记录，对有权限的成员/Bot 可见；权限校验覆盖查询、执行、交接、检索与产物引用。
• 个人代理私聊和私有记忆不自动进入 Task；只提交必要、获授权的信息。
• 打回、恢复、父任务续接使用原 Task-role 上下文；新 Attempt/进程不等于新 Session；不可恢复时显式报告，不能静默重置。

七、后续设计交付

在以上约定内独立完成：

1. 对象字段、身份/引用关系、版本与数据不变量。
2. Task 状态转换及其与当前责任方、执行 lease、阻塞、Handoff/Attempt 状态的区别；不要压成一个含糊 status。
3. 提出、澄清、接纳、修改、查询、入列、领取、交接、阻塞/解除、拆分/汇合、提交结果、裁定、取消/重开的语义接口。
4. 每个接口的调用主体、权限、前置条件、幂等键、并发/代次校验、返回结果及错误/恢复语义。
5. 原子持久化、提交后派发、重复事件处理、故障恢复和可观测性；复用既有任务存储、角色池、Handoff、Effects/outbox，避免第二套调度器。
6. 对照主仓 main 与 delivery/ai-centric-development-service 等既有分支，逐项标注已存在、待补齐与迁移要求；不把分支已有能力误报为 main 已上线。
7. 拆成可独立审阅的实施 issue，标注依赖、文档、测试与真实任务验收。此处接口名称可在设计时确定，不机械新增同义入口。

八、测试与验收

• 普通咨询不建 Task、不转移主动权；新增项目行动独立提出。
• 提出后有稳定记录，未接纳不执行；资料不足先澄清；安全/值守模式权限与成员隔离。
• Dev → Reviewer → 打回 Dev → Tester → Chief：Task 身份不变、原角色会话恢复、证据和裁定可追溯。
• 父 Task 阻塞释放资源；多个子 Task 并行；只在全部有效阻塞解除后重新入列一次，并恢复父会话。
• 子 Task 失败/取消不误解除依赖；结果已产出但未集成时不误报父 Task 完成。
• 验收版本变更、取消、重开及历史保留；执行 Bot 无权自行降低标准或标记最终完成。
• 持久化前后故障、重启、重复通知、并发子任务完成、旧代次回调及领取竞争：无丢任务、无双授权、无重复有效入列。
• 跨项目和私有记忆隔离；产物引用权限；大型上下文及 resume 失败按关联 issue 处理。
• 区分测试替身/单测通过与真实 SDK、多角色任务实际跑通；报告测试提交、实际执行项与未覆盖范围。
• 同步项目长期记忆、架构/子系统文档、接口参考、使用示例及变更记录。

非目标

不重做 control-plane/UI，不恢复固定 DAG 派活，不新增 Project 关闭门槛，不通过换名另建平行任务系统，不在设计记录阶段擅自上线或中断现有执行流程。