Cotal-AI/並列機能マネージャー

並列機能マネージャー は何をしますか？

ライブCotalメッシュを階層として使用します。

• 現在のセッションはコーディネーターです。これは分離を作成し、ポリシーを設定し、進捗を監視し、決定を中継します。実装やパネルレビューを複製しません。
• 各機能は、独自のGitワークツリーとブランチにルートを持つ1つのマネージャーを持ちます。マネージャーは、計画→実装→レビュー→テスト→コミットの完全なループを所有します。
• 各マネージャーは、専用チャンネルに3人以上の読み取り/レビューのみのピア（最低限、エンジニア、セキュリティ、批評家）をスポーンします。
• 最終ゲートの近くで、各マネージャーは1人の独立したコールドレビュアーを追加します。このレビュアーは**cold-reviewスキル**に基づいてブリーフィングされます。cold-reviewスキルは、その席がどのようにブリーフィングされ、分離され、評価されるかの唯一の情報源です。これはパネルに対する制御であり、4人目のパネリストではありません。

モデル: クロスベンダーパネルは設定上のルールであり、好みではありません

合意が重要な2つの席が、同じモデルファミリーを共有してはなりません。 同じファミリーの席によって確認された所見は、確認ではなくエコーです。3人の同一モデルのレビュアーからなるパネルが、3人全員が見逃した欠陥を含むヘッドを承認したケースがあり、それを表面化したのは4人目の検証者ではなく、異なるフレーミングでの読み取りでした。

これは人数ではなく、そのように述べてください。可用性は瞬間の特性であり、ベンダーの特性ではありません。 同じモデルが1時間参加して1時間後に参加しなかったことがあり、同じホストで同じツールを使用していました。「N個の異なるベンダー」と表現されたルールは、劣化したフリートでは満たすことができず、静かに失敗します。また、クロックによって破られる可能性のあるルールは、無視されるだけで守られません。cold-reviewは劣化順序とフロアを伝えます。

スポーン時およびペルソナの両方でモデルを明示的に固定してください。記録されていない機能は、事実上評価されていないためです。努力やモデルが記録されていないレビュアーは、後で重み付けできない評決を生成します。

マネージャーはレビュアーよりも強力なモデルを実行できます。レビュアーはコーディネーターと同じモデルを実行すべきではありません。そうすることで、パネルがコーディネーターの死角を引き継ぐのを防ぎます。

スポーンする前に、正確なモデル識別子をコネクタ自身のカタログと照合し、宣言された推論努力レベルは、席が実際にそのレベルで起動するまで未検証として扱います。カタログがプロバイダーが拒否するレベルを宣言する可能性があり、拒否されたレベルは起動時に席を強制終了します。

ハードルール

• コーディネーターのブランチを決して切り替えないでください。名前付きコミットベースからワークツリーを作成します。
• 機能ごとに1つのマネージャー、チャンネルレーンごとに1つのレビュアー、機能ごとに1つの独立したコールドレビュアー。その席の連絡先と送信先はcold-reviewの下で選択してください。ファイル送信先は通常のフォールバックにすぎず、ブローカーが証明したポスターIDを必要とするゲートを満たすことはできません。ユーザーが要求しない限り、兄弟インスタンスやテスターのファンアウトはありません。
• マネージャーのみが自分の機能ワークツリーを編集します。レビュアーは読み取り、非変更チェックを実行し、ファイル/行参照付きの所見を投稿するのみです。
• 各機能は1つのパネルチャンネル review.<feature-slug> と、1つの専用コールドレコードチャンネル review.<feature-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 で十分です。

スーパープロジェクトが利用不可能なコミットを固定しているために初期化が失敗した場合:

1. コミットされたポインター (git ls-tree <base> .internal) とアクティブなローカルサブモジュールHEAD (git -C .internal rev-parse HEAD) を比較します。これはリポジトリ状態のドリフトであり、Cotal ACLの問題ではありません。
2. 権限がある場合は、目的のサブモジュールコミットとスーパープロジェクトポインターを修正/公開することを優先します。
3. 一時的な並列実行の場合、アクティブなローカルサブモジュールリポジトリから、既知の良好なローカル .internal コミットを各機能ワークツリーに個別にマテリアライズします。
4. マネージャーに、スーパープロジェクトが M .internal を表示する可能性があることを伝えます。マネージャーはそれを読み取る必要がありますが、ステージング、編集、機能コミットへの含めることは決して行いません。

新しいワークツリーが、すでにローカルで利用可能で検証済みのプライベートコミットをフェッチできないという理由だけで、マネージャーをブロックしたままにしないでください。不一致がクリーンであるふりもしてはいけません。必要な恒久的な修復を報告します。

3. ポリシーを最初に持つマネージャーとレビュアーのペルソナを作成する

マネージャーエージェントには capabilities: [spawn] に加えてチャンネルACLが必要です。レビュアーエージェントにはチャンネルACLが必要で、スポーン権限を持ってはいけません。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]
---

スポーンする前に、3つのパネル席とコールド席に対応するファイルを作成します。すべてのレビュアーペルソナに、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 に加えて、1つの専用レコードチャンネル allowPublish 許可を付与して、スポーンする前に作成します。

マネージャープロンプトには、以下すべてを含める必要があります:

• 正確な機能契約、ブランチ、絶対ワークツリーパス。
• 機能をエンドツーエンドで所有し、意図した機能ファイルのみをコミットします。
• 編集前にリポジトリの指示、現在のドキュメント、.internal を読み取ります。
• 最初に review.<slug> に参加します。
• このセクションで作成されたペルソナのみをスポーンします。review-<slug>-engineer、review-<slug>-security、review-<slug>-critic をスポーンし、負荷がかかる合意を持つ2つの席が同じモデルファミリーを共有しないように配置します。これは上記の序数のルールであり、人数ではありません。ベンダーセットが少ない場合は、衝突を機械的に名前を付け、それがカバーしないままにするクラスを指定します。命名は開示であり、完了ではありません: 負荷がかかる承認が同一ファミリーのエコーであるパネルは完了できません。A、A、A や A、B、A を含みます。スタッフが配置されているが衝突しているパネルを合格ゲートとして扱わないでください。cwd として独自のデタッチドワークツリーを各レビュアーに与えます。レビュアーは自身のツリーで評価し、評価しているツリーでは決して評価しません。「読み取り専用」は、Gitの書き込み動詞 (checkout、switch、stash、reset、clean、restore) を明示的に名前を付け、「ソースを編集しない」とだけ言うのではありません。
• 返された各レビュアーIDにDMを送信してチャンネルに参加し、読み取り/レビューのみを維持するように指示します。
• 編集前に計画レビューを実行し、実装後にコード/テストレビューを実行し、有効な所見を折り込み、3人全員に最終処分を求めます。
• パネルと実装が収束した後、独自のデタッチドワークツリー内で review-<slug>-freelance を正確に1つスポーンし、cold-reviewスキルに基づいてブリーフィングします。cold-reviewスキルは、その席に何が与えられるか、その評決がどこに行くか、評決が何をバインドするか、ベンダーセットが少ないときにルールがどのように劣化するかを所有します。ここではそのいずれも再述しないでください。
• cold-reviewの正規ルールの下でコールド所見を解決します。その席に再考を指示することでは決して解決しません。マネージャーが変更を作成し、ブロッカーが独立した反論を必要とする場合、コーディネーターに正確なSHAの所見とアーティファクトのみを送信します。コーディネーターは、独自のデタッチドワークツリー内で新しい review-<slug>-referee をプロビジョニングします。その席は、レーンの作成、評価、監督には関与しておらず、作成者とモデルファミリーを共有せず、作成者の根拠を受け取りません。コーディネーターはレフェリーをプロビジョニングしますが、その役割を果たしません。折り込みがコードを変更する場合、結果をチャンネルパネルに戻して別の最終パスを実行し、コールド席を新しいSHAに再固定し、その配信制限を明示的にリセットして文書化します。その席がなくなった場合は、空の subscribe と allowSubscribe に加えて、専用レコードチャンネル allowPublish 許可のみを持つ新しいコールドペルソナを作成し、スポーンし、cold-reviewの下で新しいSHAについて新しい1回配信席としてブリーフィングします。それは後継者であり、古いSHAのための3番目のクロージャールートではありません。
• アクションとして、後からの主張としてではなく、ヘッドを再解決します。ブリーフィング時、完了の主張時、およびマージ前にもう一度、マネージャーまたはコーディネーターは最初にレビュー対象を解決します。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 をそのオブジェクトに対して、既知の良好なコントロールと、40ゼロなど、失敗することが確実な既知の欠落した全幅オブジェクトIDを使用して実行します。実際のIDに文字を追加してネガティブコントロールを作成しないでください。Git は有効な先頭オブジェクトIDを解決し、成功を返す可能性があります。機器を実行したアクターを名前で指定します。該当する機器が一致しない場合は停止します。異なるSHAを指定する評決や反論は、このヘッドを閉じません。
• 関連するテストを自分で実行します。レビュアーはソースを編集しません。
• 未解決の結果的な選択のみを、以下の正確な構造でエスカレーションします:

DECISION NEEDED: <一行の質問>
Options: <A>; <B>; ...
Recommendation: <マネージャーの推奨とその理由>
Impact: <観察可能な動作 / 互換性 / リスク>
Blocked: <進行できないもの>; Continuing: <進行できるもの>

• 完了時に、コミットID、実行したテスト、3つすべてのパネル処分、最終的なコールド評決と公開された反論、および残存リスクをDMでコーディネーターに送信します。

4. チャンネルのシードとマネージャーの起動

チームを招待する前に、パネルチャンネルと専用コールドレコードチャンネルを作成し、リプレイを有効にして短いオペレーターノートを追加します。次に、cotal_spawn を通じて各マネージャーをスポーンします:

name: mgr-<slug>
role: feature-manager
agent: <connector>
model: <pinned manager model>
cwd: /absolute/path/to/feature-worktree

すべてのワークツリー、ペルソナ、チャンネルが存在した後にのみ、マネージャーを並列で起動します。返されたレビュアーIDを追跡し、想定された名前ではありません。再起動または重複した起動は、ペルソナファイル名がレーンスコープであっても、自動番号が付けられる可能性があります。

cotal_roster ですべてのマネージャーが表示され、完全なパネルを保持していることを確認します。欠落しているように見える重複を時期尚早にスポーンしないでください。起動時間を許可し、最初に再確認します。

タイムアウトを報告するスポーンは、スポーンが失敗したエビデンスではありません。 すでに成功している可能性があり、再試行すると効果を複製する2番目のゴールを送信します。行動する前にプロセスリストから結果を読み取り、タイムアウトだけで再試行しないでください。

席を返信で検証し、存在で検証しないでください。 席は実行中と報告されていても、静かに到達不能になる可能性があります。生成する必要があるナンスアーティファクト（たとえば、ランダムトークンとそれが配置されている短いコミットを結合した echo）を求め、生の出力を確認します。「あなたは の にいることを確認してください」と期待される答えを述べるハンドシェイクは誘導です。エコー互換の返信は何かがテキストをミラーリングできることを証明しますが、シェルが実行されたことは証明しません。

独立したレビュアーは意図的です

…

[翻訳のために切り詰められました]