并行功能管理器 是做什么的？
将实时Cotal网格用作层次结构：
- 当前会话是协调员。它负责创建隔离、设置策略、监控进度以及传递决策。它不会重复实施或小组审查。
- 每个功能都有一个管理器，该管理器基于自己的Git工作树和分支。管理器拥有完整的计划 -> 实施 -> 审查 -> 测试 -> 提交循环。
- 每个经理在一个专用频道中生成三个或更多只读/审查同行：至少包括工程师、安全专家和批评家。
- 在最终关口附近，每个管理器添加一个独立的冷审阅者，该审阅者根据**
cold-review技能**进行简报，该技能是该角色如何被简报、隔离和评分的唯一来源。它是面板上的一个控制点，而不是第四个小组成员。
模型：跨供应商面板是一个正确性规则，而非偏好
没有两个具有承重一致性的角色可以共享同一模型系列。 由与提出者同一系列的角色确认的发现是回声，而不是确认。一个由三个同模型审阅者组成的小组批准了一个带有缺陷的头部，而所有三人均未发现该缺陷，揭示该缺陷的是不同框架的阅读，而不是第四个验证者。
以这种方式陈述，而不是作为人数。可用性是时刻的属性，而不是供应商的属性：同一个模型在一个小时内加入并交付，下一个小时却无法加入，同一台主机和工具集下。将规则表述为“N个不同供应商”在降级的机群上是无法满足的，而且是静默失败，而可以被时钟打破的规则会被悄悄忽略而不是遵守。cold-review携带降级顺序和底线。
在生成时和在角色描述中都明确指定模型，因为未记录的能力实际上等同于未分级：一个其工作或模型未被记录的审阅者会给出一个事后无法衡量的裁决。
管理器可以运行比其审阅者更强的模型。审阅者不应运行与协调员相同的模型，这样小组就不会继承协调员的盲点。
在生成之前，根据连接器的目录验证确切的模型标识符，并将声明的推理努力等级视为未经验证，直到实际启动了一个席位：目录可能声明提供商拒绝的等级，而被拒绝的等级会在启动时杀死该席位。
硬性规则
- 切勿切换协调员的分支。从指定的已提交基础创建工作树。
- 每个功能一个管理器，每个频道通道一个审阅者，每个功能一个独立的冷审阅者。根据
cold-review选择该席位的联系人和目标。文件目标仅作为规范回退，不能满足需要经纪人认证发布者身份的关口。除非用户要求，否则无同级实例或测试者扇出。 - 只有管理器才能编辑其功能工作树。审阅者只能读取、运行非变异的检查，并发布带有文件/行引用的发现。
- 每个功能使用一个面板频道
review.<function-slug>，外加一个专用的冷记录频道review.<function-slug>.cold-record。将确认和状态信息排除在面板频道之外；用于计划、发现、理由充分的处理、代码审查请求和最终结果。 - 独立冷审阅者不在该频道中。其隔离、简报和报告由
cold-review拥有；在那里强制执行，而不是在每个通道中重述。 - 产品/设计决策通过DM传递：管理器 -> 协调员 -> 用户 -> 协调员 -> 管理器。管理器不得猜测未解决的关键选择。
- 除非用户要求，否则切勿合并、推送、打开PR或删除工作树。
- 切勿干扰实时网格代理。测试使用临时空间和随机高位端口；通过精确PID杀死测试进程，切勿使用宽泛的
pkill。
1. 建立功能矩阵
对于每个请求的功能，选择并记录：
| 字段 | 示例 |
|---|---|
| 功能 | channels export |
| 短名称 | channels-export |
| 分支 | feat/channels-export |
| 工作树 | 同级路径，如Cotal-feature-channels-export |
| 管理器角色 | mgr-channels-export |
| PR | 确切编号，或none直到存在 |
| 频道 | review.channels-export |
| 契约 | 具体行为、边界、测试和已知非目标 |
在创建任何内容之前解决分支/路径冲突。检查git status、git worktree list --porcelain和现有分支。不要清理或恢复不相关的脏状态。
按顺序创建工作树，因为它们会修改共享的Git元数据：
git worktree add -b feat/<slug> /absolute/sibling/Cotal-feature-<slug> <base>
除非用户明确要求堆叠工作，否则对所有功能使用相同的基础提交。
2. 使私有仓库上下文可用
在启动之前，验证每个工作树可以读取.internal/plans/STATUS.md和相关指南。通常git submodule update --init .internal就足够了。
如果初始化失败，因为父项目锁定了一个不可用的提交：
- 比较提交的指针（
git ls-tree <base> .internal）与活动本地子模块HEAD（git -C .internal rev-parse HEAD）。这是仓库状态漂移，而不是Cotal ACL问题。 - 在授权时，优先修复/发布预期的子模块提交和父项目指针。
- 对于临时并行运行，从活动本地子模块仓库中将已知良好的本地
.internal提交独立地物化到每个功能工作树中。 - 告知管理器父项目可能显示
M .internal；他们必须读取它，但绝不暂存、编辑或将其包含在功能提交中。
不要仅仅因为新工作树无法获取已可用并本地验证的私有提交就让管理器阻塞。也不要假装不匹配是干净的；报告所需的永久修复。
3. 首先创建管理器和审阅者角色并设置策略
管理器代理需要capabilities: [spawn]以及频道ACL。审阅者代理需要频道ACL且不能有spawn。cotal_persona不能授予策略，cotal_spawn不能覆盖allowSubscribe或allowPublish，因此在生成之前必须编写每个角色文件。这些文件在此仓库中是本地/忽略的。只有默认角色的干净机器无法组建小组：如果这些文件不存在，下面的生成名称将失败，而遗留的本地角色不能替代，因为其授权可能缺失或比通道更宽。
---
name: mgr-<slug>
role: feature-manager
model: <pinned manager model>
description: 拥有<feature>及其审查小组。
tags: [manager, <slug>]
subscribe: [review.<slug>]
allowSubscribe: [review.<slug>, review.<slug>.cold-record]
allowPublish: [review.<slug>]
capabilities: [spawn]
---
在任何生成之前，为三个面板席位和冷席位编写匹配的文件。为每个审阅者角色起一个通道范围的名称，例如review-<slug>-engineer；角色目录由并发通道共享，因此通用文件名即使在工作树和频道不冲突时也会冲突。面板角色仅在review.<slug>上订阅和发布。冷角色列出空的subscribe和allowSubscribe，以便不加入是席位的属性，而不是指令，并且只能发布到review.<slug>.cold-record。不要重用或重新定义来自其他通道的审阅者角色。
---
name: review-<slug>-engineer
role: reviewer
model: <pinned panel model, family A>
subscribe: [review.<slug>]
allowSubscribe: [review.<slug>]
allowPublish: [review.<slug>]
capabilities: []
---
---
name: review-<slug>-freelance
role: reviewer
model: <pinned cold model, not the author's family>
subscribe: []
allowSubscribe: []
allowPublish: [review.<slug>.cold-record]
capabilities: []
---
为review-<slug>-security和review-<slug>-critic重复面板模板，使用不同的模型系列。如果后来需要仲裁者，在生成之前以与冷席位相同的方式编写review-<slug>-referee，具有空的subscribe和allowSubscribe以及一个专用的记录频道allowPublish授权。
管理器提示必须包括以下所有内容：
- 确切的功能契约、分支和绝对工作树路径。
- 端到端拥有功能，并且只提交预期的功能文件。
- 在编辑之前阅读仓库说明、当前文档和
.internal。 - 首先加入
review.<slug>。 - 仅生成本节中编写的角色。生成
review-<slug>-engineer、review-<slug>-security和review-<slug>-critic，安排座位使得任何两个具有承重一致性的角色不共享模型系列。这是上面的顺序规则，而不是人数。当供应商集合不足时，机械地命名冲突以及它留下的未覆盖类别。命名是披露，而不是完成： 承重批准是同一系列回声的面板无法完成，包括A、A、A和A、B、A。不要将已配备但冲突的面板视为通过的关口。为每个角色提供其自己的分离工作树作为cwd。审阅者在其自己的工作树中打分，绝不在其正在打分的工作树中打分，“只读”必须明确命名git写入动词（checkout、switch、stash、reset、clean、restore），而不仅仅是说“不要编辑源代码”。 - DM每个返回的审阅者身份以加入频道并保持只读/审查模式。
- 在编辑之前运行计划审查，在实施之后运行代码/测试审查，折叠有效的发现，并询问所有三个席位以获得最终处理意见。
- 当面板和实施收敛后，生成恰好一个
review-<slug>-freelance在其自己的分离工作树中，并根据**cold-review技能**简报该席位，该技能拥有该席位被赋予的内容、其裁决去向、裁决绑定什么以及当供应商集合不足时规则如何降级。不要在此处重述任何内容。 - 根据
cold-review的规范规则解决冷发现，绝不要通过告诉那个席位重新考虑。如果管理器编写了更改并且阻止者需要独立的反驳，仅向协调员发送精确SHA的发现和工件。协调员在其自己的分离工作树中提供一个全新的review-<slug>-referee；该席位在编写、评分或监督该通道方面没有任何作用，不与作者共享模型系列，并且不接收作者的任何理由。协调员提供仲裁者但不充当它。如果折叠更改了代码，将结果返回给通道面板进行另一轮最终通过，并以书面形式明确重置冷席位的交付限制到新的SHA。如果那个席位已经消失，编写一个新的冷角色，具有空的subscribe和allowSubscribe以及仅其专用的记录频道allowPublish授权，生成它，并根据cold-review以新的SHA作为新的一次性交付席位简报它。那是后继者，而不是旧SHA的第三个关闭途径。 - 将头部重新解析为操作，而不是稍后的断言。在简报时、在任何完成声明时以及在合并之前，管理器或协调员首先解析审查目标。对于PR，运行
git ls-remote origin refs/pull/<n>/head并交叉检查gh pr view <n> --json headRefOid。对于没有PR的分支，解析git ls-remote origin refs/heads/<branch>并省略仅PR的API交叉检查。如果尚未存在，将解析的对象获取到分离的审查工作树中，然后在该对象上运行git cat-file -t，并同时使用已知良好的控制和已知缺失的全宽度对象ID（例如四十个零）进行测试，该测试必须失败。不要通过向真实ID追加字符来制作负控制：Git可能解析有效的前导对象ID并返回成功。命名执行仪器的参与者。如果适用的仪器不同意，停止。命名不同SHA的裁决或反驳不会关闭此头部。 - 自行运行相关测试。审阅者不编辑源代码。
- 仅以以下确切结构上报未解决的关键选择：
DECISION NEEDED: <单行问题>
Options: <A>; <B>; ...
Recommendation: <管理器的建议及原因>
Impact: <可观察的行为 / 兼容性 / 风险>
Blocked: <什么不能继续>; Continuing: <什么可以继续>
- 完成后，通过DM向协调员发送提交ID、运行的测试、所有三个面板的处理意见、最终的冷裁决以及任何公开的反驳和剩余风险。
4. 种子频道并启动管理器
在邀请团队之前创建面板频道和专用冷记录频道，启用回放并附带简短的操作员说明。然后通过cotal_spawn生成每个管理器：
name: mgr-<slug>
role: feature-manager
agent: <connector>
model: <pinned manager model>
cwd: /absolute/path/to/feature-worktree
仅在所有工作树、角色和频道存在后并行启动管理器。跟踪返回的审阅者身份，而不是假设的名称；即使角色文件名是通道范围的，重新启动或重复的启动仍可能自动编号。
使用cotal_roster验证每个管理器都出现并持有其完整面板。不要过早生成看似缺失的重复项；允许启动时间并首先重新检查。
报告超时的生成不能证明生成失败。 它可能已经成功，重试会提交第二个目标并重复效果。在行动之前从进程列表中读取结果，切勿仅凭超时重试。
通过REPLY验证席位，而不是通过存在。 席位可以报告为正在运行但静默不可达。要求其生成必须产生的nonce工件，例如连接到其所在短提交的随机令牌的echo，并检查原始输出。陈述预期答案的握手（“确认你在上”）是引导性的：与echo兼容的回复只能证明某物可以镜像文本，而不能证明shell运行过。
独立审阅者是故意的。
…[截断以进行翻译]