# 协作边界示例

按需读取，不是每轮前置步骤，也不是第三种执行模式。角色职责与用户授权优先，不用一次额外模型判断来决定是否派发。

## 净收益与连续执行

- Main 已定位缺陷、知道修复方向：直接实现并验证；把说明写给新 Agent 不比执行便宜。
- 必须扫描大量陌生材料但只需少量结论：可委派有权限的 Explorer/Librarian，要求结论与最小证据；Main 不再完整重读无关材料。
- 两条工作线有真实独立输入、写边界和并行授权：Worker 分别完成完整闭环；共享接口未定或依赖未满足时先串行验证，不按目录数量拆分。
- 已有 session 覆盖目标：先读取已产生结果；需要补充时复用并只传增量。同一执行者负责普通修复，不重新安排“调查→设计→编码→修复”流水线。

## 设计自由度与升级

| 信息 | 示例 | 执行边界 |
|---|---|---|
| 必须遵守的约束 | 外部行为、兼容性、安全不变量、公共协议、不可逆迁移 | 实质变化说明影响并请用户决定，仅暂停受影响部分 |
| 可调整的方案 | 内部文件布局、函数抽取、局部算法、测试组织 | 执行者自主调整，重要差异写 Delivery，不重规划 |
| 待验证的假设 | 新 SDK 是否支持目标调用、迁移边界行为、环境能力 | 明确未知，先作本阶段授权内的最小验证；实施获授权后先打通关键路径 |

跨任务接口需要调整时由 Main 协调受影响任务；只有实质改变已确认公共方案/目标/验收/安全时请求用户决定。未变化的决策和已有效验证的成果不重新打开。

## 查询与增量继续

使用实际宿主已经提供的工具：查询只读状态、取已有结果、增量继续是不同动作；不要用继续执行代替查询，不为检查进度触发新推理，不密集轮询。如果没有只读取结果能力，承认局限，不编造工具或自动重做已完成目标。消息已排队不代表 Agent 已看到或执行。

## 验证与复审

Task 说明定向验证与责任，Worker 就近验证自身工作，Main 完成整体集成验证。代码、环境、依赖变化导致证据失效或原证据不足时补跑重叠检查；不能以节约为由忽略安全/测试失败。Reviewer 仅用户明确要求时启用；修复后只关注未解决项与新增风险，反复未收敛则说明原因，不机械重开所有旧结论。

## 文档与效果证据

保留完整结构：C01 维护目标验收，C02 维护共享方案，计划维护依赖安排，Task 补任务差异，Delivery 记实际增量。公共事实用可定位引用，简单任务短写但不能只有链接。效果评估比较完整目标的 Main 与子会话总用量、耗时和补查/返工；静态文案、fixture 通过不证明真实模型更省钱。

## 模式与短写

新目标默认Quick；连续执行和加载技能不升级SDD，关闭旧Change后不机械沿用模式。Quick直接交付摘要并按实际影响更新已有事实，不建研发文档链。需要SDD时保留完整结构，按[单任务短写示例](single-task-example.md)分别维护职责；派发引用Task和必要增量，不抄背景/公共方案。实际Current Truth与人工确认状态分开。

安装/升级后可显式执行一次真实最小委派，区分文件、native fixture与真实推理；不每轮调用模型预检。派发受旧默认模型影响时先核验subagent_defaults，只有显式修复意图才迁移，不覆盖自定义Main或任意默认模型。