用途与实际影响
这项功能怎样使用
为什么需要它
如果助手继续找帮手、失败后任意换人，或把团队成果记在单个执行者名下，就无法解释真实能力和责任。
举个实际例子
我想知道“一个 AI 带几名直接帮手”和“一个 AI 独自做”会怎样不同。先核对两条路线是否都能用同一道题留下完整证据；条件具备后，再分别看帮手实际做了什么、根怎样解决冲突和验收。当前不能据此发布完整配置比较。
最后我会得到什么
具备运行条件并完成两条独立尝试后，才能分别看到独自完成与协作完成了什么、谁做了哪一步、哪里中断。当前完整比较仍受方法与 CI 缺口阻断。
正常时
当根任务、直接助手的身份与交付、冲突处理和最后验收都能回查时，协作样本才成立。
发现问题时
实际派发、助手身份或整合证据对不上时，这条协作尝试不能算通过。
入口不可用或证据不足时
需要的角色交付或整轮实际运行证据不齐时保留待验；单独执行路线另按自己的证据判断。
从哪里开始
在 CACB 项目的 AI 对话中说明要看单个根模型做题，还是看它调度直接子代理的协作结果。
需要准备什么
- 同一道工程题或要检验的能力
- 单独执行或协作路线的选择
从开始到拿到结果
- 1
系统核对并处理
按选定路线启动并记录真实父子关系，协作成果还需看分解、并发冲突和最终整合。
- 2
交付与接续
交回这一路线的实际产物和谱系；不能把子代理合作结果算作单模型独立完成。
技术实现与依据
这里保留实现、关键条件、精确入口、历史记录和验证结果。
原生编排 source 合同存在；当前 CI lint 未闭合且本轮没有 fresh orchestration E2E（端到端验证），两个 arm 均不能写成已合格结果关键规则与设计选择
编排与单工作者是独立完整样本。
零个child合法但根必须给具体不派发理由。
最多四个直接child且禁止后代、替补、重复和模型失败后重试。
CACB只报告冻结arm证据，不创建全局路由、Hook（钩子）或默认策略。
本模块用到的名词
- native orchestration arm（原生编排路线）
- 以Sol Max为根、直接原生子代理为有界执行者的独立完整样本。
- role-specific commitment（角色专属任务承诺）
- 根和每个child分别绑定的任务、身份、plan hash（内容指纹）、reader和receipt（执行回执）；child不复用根胶囊。
- phase S / E（选择/执行阶段）
- 先让根在无派发时冻结选择，再由Authority发布精确材料后执行，避免边选边改证据。
专业定义
把 Sol Max 作为根战略者，单独评测它怎样分解、尽早派发、选择零到四个直接子代理、并发推进、处理冲突、整合产物和完成最终验证。
解决什么
解决共享胶囊造成授权冲突、编排调用漂移、后代扩张、替补掩盖失败和多模型能力冒充单模型能力。
当前怎样实现
- native_orchestration.py 冻结精确 Sol/max 根、允许 child 身份、最大四个、fork_turns=none、无后代预算和 selection/dispatch/attempt/resolution schema（数据结构）。
- NativeOrchestrationOperator 把 S 选择和 E 执行分开；Authority 只在 selection 终态后发布 child plans、reader、prelaunch receipt（执行回执） 与 manifest（清单）。
- 实际 call id 只从 raw evidence 学得；每个执行 child 必须有唯一 call→started→output→depth-one lineage，未启动计划只能标 unused。
执行流程
- 1
冻结 orchestration arm 与共同 campaign
- 2
Sol Max root在S阶段提交零到四个选择并终态
- 3
Authority校验后发布角色专属child材料
- 4
同一root在E阶段按序直接派发
- 5
回读每个child原始lineage和产物
- 6
root处理冲突并最终验证
- 7
独立发布编排resolution
边界
- 不创建全局路由或默认subagent策略
- 不让child继续委派
- 不把编排结果并入Sol单工作者
- 不允许第五个child、替补、重复或额外回合
- 网页不启动任何真实arm
失败与恢复
- root/child（根代理/子代理）的capsule、identity、reader、receipt（执行回执）或lineage不闭合
- 整条arm失败关闭，不回退成单工作者成功。
- 出现第五个child、后代、替补或重试
- 拒绝dispatch或resolution，保留违反冻结边界的raw evidence。
- 根未解决冲突或未形成最终验证
- 保持incomplete，不挑最好子产物冒充整体完成。
真实入口
PRIVATE source · src/cacb/native_orchestration.pySol Max根、零到四个直接child、两阶段选择/派发与证据聚合
PRIVATE source · docs/NATIVE_RUN_OPERATOR.mdrole-specific capsule、Authority dispatch、lineage和失败关闭
PRIVATE source · docs/PRODUCT_DESIGN.md编排衡量对象、与单工作者分报及不激活全局路由
如何验证
- native orchestration focused tests 在 e6f7581 历史观察代曾存在；该证据不继承到当前 59b0b5c。
- 59b0b5c 固定两个独立完整样本 arm、精确 Sol/max 根、零到四个直接 child、role-specific delivery、无后代/替补/重试和分开报告。
- 当前 CI 仍在 lint 门失败且本轮未跑 fresh orchestration E2E（端到端验证），因此不发布合格结果。
与其他模块的关系
消费 question-bank 与 campaign 的冻结输入、identity-evidence 的精确身份和 workspace；独立编排终态交给 deterministic-verification，不影响 blind-quality-review 的单样本盲化边界。