# 关注与任务生命周期

- `partner_concerns` 管理当前伙伴的持续关注：list、update、resolve、stop、delete。修改、停止和删除需要查询得到的 `concernId` 与 `expectedUpdatedAt`，不会跨伙伴操作或覆盖并发修改。
- `partner_concern_suggest` 保留原有新增入口。一次性修复、生成和部署不作为持续关注；后台协调和定时唤醒不能引用以前的用户消息新增关注。
- 受阻任务由独立持久化 worker 接管，先创建者再需求负责人。相同任务的协调参与者不会无限重复唤醒；基础设施失败有有限重试和退避。已尝试仍未解锁的阻塞交需求统一汇报。用户显式重试可开始新的协调周期。
- 自动生成的临时周期计划可以绑定 `boardTaskId`，当前看板执行会话创建时自动绑定。任务完成或删除后清理；仍被消费的外部结果与未送达最终消息不会提前删除。取消的续接保留一分钟供在途读者收尾，然后清理。
- 历史周期计划若没有可靠的任务关联，不会根据名称猜测并批量删除。使用 `partner_schedule list` 核实用途，再 delete 或暂停；用户明确要求的长期周期任务不受清理影响。

所有变更仍使用原有状态存储与原子提交，不新增另一套任务状态文件。协调消息沿用内部看板消息类型，不直接发送渠道；最终成果/阻塞汇报继续由需求投递机制负责。

## 负责人交付与渠道边界

看板记录执行与验收结果，负责人处理创建确认、最终总结和需要用户决策的受阻情况。子任务不自行通知渠道。汇总时负责人调用 `partner_requirements prepare_delivery`，明确提交给用户的 summary 和已验收正式附件 ID 清单；无附件明确传 `[]`。渠道只投递这份清单，不自动挑选全部任务文件，也不另造一份总结文档。

渠道逐项保存成功回执。相同需求对同一接收人已经成功投递的同内容附件，不因阶段汇报、最终归档、文件副本或服务重启再次发送；不同接收人和新文件内容分别交付。通道断开且远端成功回执丢失时仍可能重发，这是远端 API 缺少幂等能力的边界，不宣称严格 exactly-once。

“需求成果交付”是页面投递回执，不会启动新任务，也不能切断当前用户消息的最终回复收集。真正的内部执行、验收和汇总轮次仍保持静默。