Briefbound 自动协作开发闭环

目标

一次确认后，驱动同项目平级会话完成、验证、合入 main；不建主从或接管任务。

Briefbound task contract

• Context Boundary: 已对齐目标、授权的现有同项目 thread、各自 scope/branch/worktree、共享契约、目标 main/验证门。
• Output Contract: agreement、交付证据、integration queue、本地 main 验证和恢复清理。
• Allowed Action: 在授权范围内读取 thread 状态、维护本任务 registry、执行本地写入/提交/合入 main、验证和安全清理；当前 BRT_TRANSPORT_DISABLED，不得发送 thread 消息。新建会话、远程 push/PR merge/发布、破坏性或高风险动作仍需单独授权。
• Success Evidence: 每个原任务达到验收，目标 main 包含预期交付，集成门通过，open coordination、恢复债务和已知开发残留清零。
• Stop Condition: 未获开启确认、共同目标或 target 不明、产品/安全/数据迁移取舍未决、需要远程授权、破坏性动作，或自动恢复连续失败。
• Route Out: 各 Agent 原 owner、briefbound-multi-agent-orchestration、briefbound-thread-coordination、briefbound-pr-review、briefbound-development-cleanup、briefbound-project-memory、briefbound-router 或 BLOCKED。

统一调用契约

• 用户可见内容默认中文；只报行动决定、blocker 和最终证据。Route Out 仅以 Briefbound task contract 为准；有自然闸门（需用户裁决、批准或被外部阻塞）时末行 下一步建议: <一个具体动作>，否则声明继续已授权工作。
• 各 Agent 仍负责自己的任务、scope、branch；Loop Owner 只维护闭环。
• 开启后不在每个阶段、task、普通冲突或恢复动作后询问是否继续。

开启与授权

Briefbound Router 仅在非简单目标确有多会话协作价值时，询问一次明确列出项目、既有参与会话、integration target 和本地集成范围的授权。确认后才可联系这些现有会话、协商、安全开发、验证和限定目标的本地集成，直到完成、取消或自然闸门；泛化“继续/确认”不扩大到创建会话或新的 integration target。

没有合适会话时，只询问一次是否创建。远程 push、PR 或破坏性操作不继承授权。自动循环还必须具备已验证的 BRT_DIRECT_USER_TURN_V1，且运行环境提供平级多会话原语（见 harness 能力矩阵）；任一不满足保持 BLOCKED_TRANSPORT，不启动跨任务循环或 outbox。

角色与持久状态

• Loop Owner：维护状态、租约、outbox、恢复债务和完成门，不代写 peer 结论。
• Peer Owner：完成任务，提供 scope、依赖和 MERGE_READY。
• Integration Owner：由任一合格 peer 在首个 MERGE_READY 出现后可原子认领，维护当前队列；只有目标干净、授权范围匹配且重验通过时才合入 main。claim 有效期间不启动新的无关实现任务，变忙时先转交队列。
• Recovery Dispatcher：任何活跃参与者在 Loop Owner 租约过期时可 takeover，继承 outbox、恢复和集成义务，但不能继承或伪造 peer 的完成声明。

状态为 DISCOVER -> AGREEMENT -> RUNNING/NEGOTIATING -> MERGE_READY -> INTEGRATING -> INTEGRATED -> CLOSED。每个 peer 只记 Task / Scope / Branch or Worktree / Dependency / Checkpoint / Tests / Blocker / Resume Debt；优先 registry，跨会话恢复才用 memory。

自动循环

1. 发现与约定

只读最多 3 个相关 thread，确认收益、边界、契约、依赖和 Integration Target，用 briefbound-multi-agent-orchestration 建 agreement。Integration Owner 可等首个交付入队后认领；无收益则返回原 owner。

2. 并行推进

各 peer 继续非冲突任务。BRT_TRANSPORT_DISABLED 期间不得通信、轮询、入队或催促；MERGE_READY 只由原任务交付或用户直接传达。未来恢复后，消息默认只发差量：From/Task / Changed Fact / Action Impact / Evidence Pointer / Reply Needed；背景、方案和测试用指针，首次契约或安全语义才展开。

3. 冲突协商

普通重叠先缩 scope、调顺序或交换接口，由 briefbound-thread-coordination 复用 discussion。仅无法拆分且继续写会立即覆盖/回归时暂停冲突 surface，记录 resumePendingAgentIds；解决后发 CONFLICT_RESOLVED 并确认恢复。

main 变化、排队或 gate stale 不暂停。Peer 聚焦验证并提交 MERGE_READY 后结束执行，由 Integration Owner 集成；不等待 stable main，不反复 closeout。

4. 故障与接管

每次收发在未来恢复后均先通过 briefbound-thread-coordination 的 BRT_DIRECT_USER_TURN_V1 验收门：只允许同项目、fresh read_thread 返回精确 threadId 的平级顶层 thread；原生子 agent 不得加入 outbox 或 relay。当前不得调用 send_message_to_thread，不得保存 outbox，也不得依据 /root、agent 标签或旧 registry 重新寻址。Loop Owner 失活时只记录交接事实，不自动唤醒其他任务。

自动恢复先分类为任务、依赖、集成或环境失败；证据发给 owner，其他 peer 继续。只有高风险取舍或同一 blocker 经两轮不同恢复策略仍失败才询问用户。

接管者只继承推进义务，不能继承证据所有权。失活 peer 没有正式 MERGE_READY 时：

• Git commit/artifact、scope 和新鲜验证足以独立重验：接管者可标记 MERGE_READY_RECOVERED，必须注明原 owner 未确认及重验证据。
• 只有聊天中的采纳、计划、进度或草稿：标记 RECOVERY_PENDING_EVIDENCE；接管者自行完成缺口或恢复原 owner，不能代其宣告完成。
• 无法安全完成且两轮恢复失败：保持明确 owner/blocker 后再询问用户，不把缺证据项目合入。

5. 集成队列

每个 peer 用 MERGE_READY 入队，完整证据字段规范见 briefbound-multi-agent-orchestration 的 team-protocol.md。MERGE_READY_RECOVERED 也必须满足相同证据门。Integration Owner 以 Git 和新鲜测试为事实源：

首个交付入队时检查一次 lane=integration/<target-key>：无 claim 则认领队列并发 INTEGRATION_CLAIMED。baseline/dirty main 时进入 WAITING_FOR_CLEAN_TARGET，保留证据但不应用、变基或合并；已有负责人则其他 peer 停止合并。Loop Owner 对空缺自行认领或只联系一个合适 peer，不轮询或询问用户。细节交 briefbound-thread-coordination。

1. 无依赖且不重叠的交付可成组；共享契约或依赖项串行。
2. Peer 只需聚焦验证；Integration Owner 对过期 base 变基或应用提交，重验受影响窄面。机械冲突可处理，语义冲突才回相关 peer。
3. 全部预期交付合入本地 main 后只运行一次完整集成 gate；失败才重开责任任务和受影响依赖。
4. 不用远程 CI 替代本地证据，也不在未授权时 push 或操作远程 PR。

gate 期间若无关任务推进 main，不冻结全项目：比较新增提交与本轮 scope；无重叠则在最终 HEAD 补受影响的窄验证，有语义重叠才重跑对应 gate。不得因无关漂移重跑整套门禁。

可重建的 ignored/untracked 测试缓存不阻塞 MERGE_READY，统一留给 final cleanup；删除受阻且不影响 tracked 交付时保留，不更换多种命令追查。

6. 收尾

验收和集成 gate 通过后，广播一次 INTEGRATED，释放 integration claim 并关闭 merge coordination；债务清零后用 briefbound-development-cleanup 清理安全残留，最后只做一次整体汇报。

完成门

以下条件必须同时成立：

• 每个 peer 的原任务已完成或由用户明确取消；“消息已发送”“已采纳”“接近完成”和恢复生成的总结都不能代替交付证据；
• 本地 main 包含所有预期交付且集成验证通过；
• 没有有效或遗留 integration claim、未处理 outbox、open coordination、stale owner 或 resumePendingAgentIds；每个 TRANSPORT_EXPIRED 都有 fresh list/read 证据；
• 清理没有删除未合并工作，远程动作仍保持未执行；
• 失败和 Deferred 项有明确 owner、证据和触发条件。

未满足时由当前 Loop Owner 或接管者继续闭环，不把普通协调债务抛回用户。