平行功能管理器 是做什麼的？
將當前的 Cotal mesh 作為階層使用：
- 當前會話是協調者。它負責建立隔離、設定政策、監控進度，並轉達決策。它不會重複實作或小組審查。
- 每個功能有一個管理器，位於自己的 Git worktree 和分支中。管理器擁有完整的規劃 -> 實作 -> 審查 -> 測試 -> 提交循環。
- 每個管理器在一個專用頻道中 spawn 三個或更多唯讀/僅審查的對等體：至少包括工程師、安全性和評論員。
- 接近最終關卡時，每個管理器會新增一個獨立的冷審查員，在
cold-review技能下接受簡報，這是該席次如何被簡報、隔離和評分的單一來源。它對小組而言是一種控制，而非第四個小組成員。
模型：跨供應商小組是正確性規則，而非偏好
沒有兩個其協議具有負載意義的席次可以共享模型系列。 由與產生發現相同的模型系列之席次確認的發現是回聲，而非確認。一個由三個相同模型審查員組成的小組可能已經核准了一個帶有所有三位審查員都忽略的缺陷的提交，而最終浮現該缺陷的是一種不同框架的閱讀，而非第四個驗證者。
請照此方式表述，而非作為人數。可用性是當下的屬性，而非供應商的屬性：同一個模型可能在一小時內加入並交付，而在下一小時無法加入，即使是在相同的主機和工具上。一條表述為「N 個不同供應商」的規則在降級的叢集中是無法滿足的，而且是默默地無法滿足，而一條可能被時鐘打破的規則會被悄悄忽略，而非遵守。cold-review 承載了降級順序和底限。
在 spawn 時和 persona 中明確固定模型，因為未記錄的能力實際上等同於未評分：一個其努力或模型未被記錄的審查員會產生一個事後無法衡量的裁決。
管理器可以執行比其審查員更強大的模型。審查員不應執行與協調者相同的模型，這樣小組就不會繼承協調者的盲點。
在 spawn 之前，請根據連接器自己的目錄驗證確切的模型識別碼，並將已宣告的推理努力層級視為未經驗證，直到某個席次實際啟動了該層級：目錄可能宣告提供商拒絕的層級，而被拒絕的層級會在啟動時殺死該席次。
硬性規則
- 永遠不要切換協調者的分支。從已命名的已提交基礎建立 worktree。
- 每個功能一個管理器，每個頻道通道一個審查員，每個功能一個獨立的冷審查員。在
cold-review下選擇該席次的聯絡人和目的地。檔案目的地僅是規範性的後備方案，無法滿足需要經紀人認證的發佈者身分的關卡。除非使用者要求，否則沒有同級實例或測試器扇出。 - 只有管理器可以編輯其功能 worktree。審查員僅讀取、執行非變異的檢查，並發佈帶有檔案/行號參考的發現。
- 每個功能使用一個小組頻道
review.<feature-slug>，加上一個專用的冷記錄頻道review.<feature-slug>.cold-record。將確認和狀態訊息保留在小組頻道之外；將其用於計畫、發現、有理由的處置、程式碼審查請求和最終結果。 - 獨立的冷審查員不在該頻道上。其隔離、簡報和報告由
cold-review擁有；在那裡執行它們，而不是每個通道重新陳述。 - 產品/設計決策透過 DM 傳遞：管理器 -> 協調者 -> 使用者 -> 協調者 -> 管理器。管理器不得猜測未解決的後果性選擇。
- 除非使用者要求，否則永遠不要合併、推送、開啟 PR 或移除 worktree。
- 永遠不要干擾當前的 mesh 經紀人。測試使用一次性空間和隨機高埠；透過精確的 PID 殺死測試程序，永遠不要使用廣泛的
pkill。
1. 建立功能矩陣
對於每個請求的功能，選擇並記錄：
| 欄位 | 範例 |
|---|---|
| 功能 | channels export |
| Slug | channels-export |
| 分支 | feat/channels-export |
| Worktree | 同級路徑，例如 Cotal-feature-channels-export |
| 管理器 persona | mgr-channels-export |
| PR | 確切號碼，或直到存在為止為 none |
| 頻道 | review.channels-export |
| 合約 | 具體行為、邊界、測試和已知的非目標 |
在建立任何內容之前解決分支/路徑衝突。檢查 git status、git worktree list --porcelain 和現有分支。不要清理或還原不相關的髒狀態。
依序建立 worktree，因為它們會變異共享的 Git 元數據：
git worktree add -b feat/<slug> /absolute/sibling/Cotal-feature-<slug> <base>
除非使用者明確想要堆疊工作，否則為所有功能使用相同的基礎提交。
2. 提供私有儲存庫上下文
在啟動之前，驗證每個 worktree 可以讀取 .internal/plans/STATUS.md 和相關指南。通常 git submodule update --init .internal 就足夠了。
如果初始化失敗，因為超級專案固定了一個不可用的提交：
- 比較已提交的指標 (
git ls-tree <base> .internal) 與活躍的本地子模組 HEAD (git -C .internal rev-parse HEAD)。這是儲存庫狀態偏移，而不是 Cotal ACL 問題。 - 在獲得授權時，優先修復/發佈預期的子模組提交和超級專案指標。
- 對於臨時的平行執行，從活躍的本地子模組儲存庫中，將已知良好的本地
.internal提交獨立地物化到每個功能 worktree 中。 - 告訴管理器超級專案可能顯示
M .internal；他們必須讀取它，但永遠不要暫存、編輯或將其包含在功能提交中。
不要僅僅因為新的 worktree 無法獲取已經可用並在本地驗證的私有提交，就讓管理器阻塞。也不要假裝不匹配是乾淨的；報告所需的永久性修復。
3. 首先使用政策建立管理器和審查員 persona
管理器代理需要 capabilities: [spawn] 加上頻道 ACL。審查員代理需要頻道 ACL，並且不能有 spawn。cotal_persona 不能授予政策，而 cotal_spawn 不能覆蓋 allowSubscribe 或 allowPublish，因此請在 spawn 之前撰寫每個 persona 檔案。這些檔案在此儲存庫中是本地/被忽略的。只有預設 persona 的乾淨機器無法組成小組：下面的 spawn 名稱會失敗，除非這些檔案存在，而遺留的本地 persona 不是替代方案，因為其授予可能缺失或比通道更寬。
---
name: mgr-<slug>
role: feature-manager
model: <固定的管理器模型>
description: 擁有 <feature> 及其審查小組。
tags: [manager, <slug>]
subscribe: [review.<slug>]
allowSubscribe: [review.<slug>, review.<slug>.cold-record]
allowPublish: [review.<slug>]
capabilities: [spawn]
---
在任何 spawn 之前，為三個小組席次和冷席次撰寫匹配的檔案。為每個審查員 persona 指定一個通道範圍的檔案名稱，例如 review-<slug>-engineer；persona 目錄由並行通道共享，因此當 worktree 和頻道不衝突時，通用檔案名稱仍會衝突。小組 persona 僅在 review.<slug> 上訂閱和發佈。冷 persona 列出空的 subscribe 和 allowSubscribe，這樣不加入就是席次的屬性，而不是指令，並且只能發佈到 review.<slug>.cold-record。不要重用或重新定義來自另一個通道的審查員 persona。
---
name: review-<slug>-engineer
role: reviewer
model: <固定的小組模型，系列 A>
subscribe: [review.<slug>]
allowSubscribe: [review.<slug>]
allowPublish: [review.<slug>]
capabilities: []
---
---
name: review-<slug>-freelance
role: reviewer
model: <固定的冷模型，非作者的系列>
subscribe: []
allowSubscribe: []
allowPublish: [review.<slug>.cold-record]
capabilities: []
---
使用不同的模型系列重複 review-<slug>-security 和 review-<slug>-critic 的小組範本。如果之後需要仲裁者，請在 spawn 之前，以與冷席次相同的方式撰寫 review-<slug>-referee，包含空的 subscribe 和 allowSubscribe 加上一個專用記錄頻道的 allowPublish 授予。
管理器提示必須包含所有以下內容：
- 確切的功能合約、分支和絕對 worktree 路徑。
- 端到端擁有該功能，並且只提交預期的功能檔案。
- 在編輯之前閱讀儲存庫說明、當前文件和
.internal。 - 首先加入
review.<slug>。 - 僅 spawn 本節中撰寫的 persona。Spawn
review-<slug>-engineer、review-<slug>-security和review-<slug>-critic，坐席方式使得沒有兩個其協議具有負載意義的席次共享模型系列。這是上述的順序規則，而非人數。當供應商集合很短時，機械地命名衝突以及它留下未覆蓋的類別。命名是揭露，而非完成： 其具有負載意義的批准是相同系列回聲的小組無法完成，包括 A、A、A 和 A、B、A。不要將已配備但衝突的小組視為通過的關卡。為每個提供其自己的分離 worktree 作為cwd。審查員在自己的樹中評分，永遠不會在它正在評分的樹中，而「唯讀」必須明確命名 git 寫入動詞（checkout、switch、stash、reset、clean、restore），而不僅僅是說「不要編輯原始碼」。 - DM 每個返回的審查員身分，以加入頻道並保持唯讀/僅審查。
- 在編輯之前執行計劃審查，在實作之後執行程式碼/測試審查，折疊有效的發現，並要求所有三位給出最終處置。
- 在小組和實作收斂之後，在其自己的分離 worktree 中 spawn 恰好一個
review-<slug>-freelance，並在cold-review技能下對其進行簡報，該技能擁有該席次被給予的內容、其裁決的去向、裁決綁定什麼，以及當供應商集合很短時規則如何降級。不要在這裡重述任何內容。 - 在
cold-review的規範規則下解析冷發現，永遠不要透過告訴該席次重新考慮來解析。如果管理器撰寫了變更，而阻塞需要獨立的駁斥，則僅將確切 SHA 的發現和工件發送給協調者。協調者在其自己的分離 worktree 中提供一個全新的review-<slug>-referee；該席次沒有參與撰寫、評分或監督該通道，不與作者共享模型系列，並且不會收到作者的任何理由。協調者提供仲裁者，但不擔任仲裁者。如果折疊變更了程式碼，將結果返回給頻道小組進行另一次最終傳遞，並以書面形式明確重置其交付限制，將冷席次重新固定到新的 SHA。如果該席次已消失，請撰寫一個新的冷 persona，包含空的 subscribe 和 allowSubscribe 加上僅其專用記錄頻道的 allowPublish 授予，spawn 它，並在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 交叉檢查。將解析的物件提取到分離的審查 worktree 中（如果尚未存在），然後在該物件上執行git cat-file -t，使用一個已知良好的對照和一個已知缺失的全寬物件 ID，例如四十個零，它必須失敗。不要透過將一個字元附加到真實 ID 來製作消極對照：Git 可能解析有效的領先物件 ID 並返回成功。命名執行這些工具的 actor。如果適用的工具不一致，則停止。一個命名不同 SHA 的裁決或駁斥不會關閉這個頭部。 - 自行執行相關測試。審查員不會編輯原始碼。
- 僅使用此確切結構升級未解決的後果性選擇：
決策需要：<一行問題>
選項：<A>；<B>；...
建議：<管理器的建議及其原因>
影響：<可觀察的行為/相容性/風險>
阻塞：<無法繼續的事項>；繼續中：<可以繼續的事項>
- 完成後，DM 給協調者提交 ID、執行的測試、所有三個小組處置、最終的冷裁決以及任何公開的駁斥，以及殘餘風險。
4. 播種頻道並啟動管理器
在邀請團隊之前建立小組頻道和專用冷記錄頻道，啟用重播並帶有簡短的運營者備註。然後透過 cotal_spawn 啟動每個管理器：
name: mgr-<slug>
role: feature-manager
agent: <連接器>
model: <固定的管理器模型>
cwd: /absolute/path/to/feature-worktree
僅在所有 worktree、persona 和頻道都存在後，再平行啟動管理器。追蹤返回的審查員身分，而不是假設的名稱；重新啟動或重複的啟動可能仍然被自動編號，即使 persona 檔案名稱是通道範圍的。
使用 cotal_roster 驗證每個管理器是否出現並持有其完整小組。不要過早 spawn 看起來缺失的重複項；允許啟動時間並先重新檢查。
報告逾時的 spawn 並非 spawn 失敗的證據。 它可能已經成功，而重試會提交第二個目標，重複了效果。在採取行動之前，從程序清單中讀取結果，並且永遠不要僅因逾時而重試。
透過回覆驗證席次，而非透過存在。 一個席次可以報告為正在執行，但實際上處於靜默不可達狀態。要求一個必須由它產生的隨機工件，例如一個隨機令牌與其所在位置的簡短提交連接起來的 echo，並檢查原始輸出。一個陳述預期答案（「確認你在 的 上」）的握手是具有引導性的：一個相容於回覆的 echo 證明某些東西可以鏡像文字，而不是一個 shell 執行過。
獨立的審查員是故意的
…
[為翻譯而截斷]