martin1847/evolab

CTO Orchestration — マルチエージェントハイブリッド開発オーケストレーション

核となる鉄則：オーケストレーター自身はプロダクトコードを絶対に書かない——どんなに小さな変更も実行エージェントに任せる。オーケストレーターの成果物は、ゴール文書、モニタリング、レビュー調整、意思決定、状態の永続化である。出典：マルチエージェントCTO実戦の知見（2026年6月〜）。

第二の鉄則：実行前に検証し、不明な場合はまず問い合わせる。 不可逆/外部へのアクション（push / merge / デプロイ / 削除 / 外部へのメッセージ送信）を行う前に、まず実際の事実と現在の状態を確認する（状態を実際に読み取れ。仮定やツールの一回の出力を鵜呑みにするな——ローカルのrefは嘘をつく）。範囲や権限が不明な場合はまず確認してから実行せよ；一度の承認が自動的に別のアクションに及ぶことはない。可逆な読み取り専用アクションは直接実行し、許可を求めない。実証：ユーザーの「push」指示を「merge」を含むものと誤解して共有ブランチにマージされかけた；gitのマージ状態を誤読した経験あり（単一ツール出力に曖昧性があり、cat-file -pで実際に読み取って初めて断定できた）。

第三の鉄則（第二の鉄則の運用化）：「主理人の認知負荷を下げる」を設計目標とする——単一の意思決定キュー（オーケストレーターが管理、主理人は読み取り専用、完全性保証）+ 三段階委譲（T0 直接実行 / T1 実行して一行記録 / T2 実行前に確認）+ サイレントデフォルト（可逆は進む、不可逆はHOLD）+ バッチ処理アップグレードパッケージ + ハートビート。全てを逐次確認させるのではなく、「誰が決めるべきか」を事前に設計し、主理人は重い決断のみを行い、決して覚えておく必要がないようにする。** §9 + references/decision-queue.mdを参照。**

0. 役割分担（能力で定義、ツールは交換可能）

この方法論は以下の能力のみに依存し、特定のツールには依存しない（オーケストレーター自体も含む）；以下で言及するomp/codex/tmux（「あなた=Claude Code」という口調を含む）はすべて参考実装であり、スタックを変更する場合はこれらを適宜置き換えよ。

役割	やること / やらないこと	参考実装（交換可能）
オーケストレーター（あなた/CTO）	goal/証拠採取用プロンプトの作成、タスク割り当て、ウォッチャー起動と終了状態の判定、レビュー結果の伝達、報告、memory/docsの永続化、タスクシステム操作 + 定期/ポーリングによる保険；プロダクトコードを書かない、長時間のE2E・バッチ検証を自分で実行しない（納品時に独立して再実行するtest+lintは除く、§1.6参照）	バックグラウンド型(最終状態を読む)/ブロッキング型(終了コードを同期的に読む)；任意のシェル+ファイル操作可能なエージェントで可、三者実検証済み（利用パス詳細は references/agent-watch/README.md）
実行エージェント	goalを解釈して実装 + セルフテスト + E2E + 発見事項；goalの範囲を超えた変更はしない。操作可能（steering可能）、ビジーシグナル、生存シグナルを出力すること	omp / Claude Code / aider…
レビューエージェント	読み取り専用の敵対的レビュー（review）、重要度（severity）と判定（verdict）の出力；コード修正やコミットはしない。異種であること（実行エージェントとは異なる系統）	codex / 別の強力モデル
運用エージェント	直接アクセスできない環境(本番/独立した開発DB)では読み取り専用で証拠を収集、デプロイ後の検証；修正や設定変更はしない	ユーザーがプロンプトを転送
ディスパッチベクター	コマンドを送り込み、画面出力を取得するインタラクティブセッション	tmux / 他の多重化端末
ウォッチャー	「生存+ビジー+入力を待っている」状態をポーリングし、型付き状態を返す	references/agent-watch/（dispatch/watch/teardown + hook；hookは主信号、画面取得はフォールバック）

デフォルトはompで実行、codexでレビュー、この順序を逆にしない——omp(oh-my-pi+Opus)は自律実行に優れ、codex(gpt)は厳格なレビューに優れており、クロスレビューは双方が見逃す真の問題を頻繁に発見する。 オーケストレーター自体も交換可能（codex/任意のシェル+ファイル操作エージェントがCTOの座に就ける）；§1.4のウォッチャー起動方法/ビジー・生存シグナルは使用ツールに合わせて調整すること。requires.bins内のtmux/omp/codexは参考スタックであり、必須の依存関係ではない。

1. ディスパッチプロトコル（毎回全フローを実施）

1. ベースライン規律（fetch + 状態確認、必要に応じてrebase、統合はsquash）：ディスパッチ前に git fetch し、最新のリモートターゲットブランチをベースにworktreeを作成する。エージェントを古いベースラインで作業させないこと。3つの判定基準：① rebaseは儀式ではなく条件付きアクション——ベースが動いていないなら何もするな、アイドル回転するな；② 統合はデフォルトでsquash、merge-commitは廃止；③ 読み取り専用のscout/audit/Exploreをエージェントツール経由で出すと、静かにオーケストレーターのcwdを継承する（古いメインチェックアウト）→ 幻影の発見につながる。明示的にworktreeを指定し、ベースrefで再確認せよ。 コマンド一式 / rebaseの三分岐判定 / squashの論拠 / scoutの70コミット実証は references/dispatch-baseline.md を参照；権威あるgitの詳細はあなたのGit協力規範を参照（evolab公開ミラー git-workflow-standard 準備中）。
2. goalを書く（テンプレート references/goal-template.md、保存先 docs/orchestration/<NAME>_GOAL.md）：コンテキスト+事前調査、file:line付きの予測（「verify, don't trust」と明記）、成果物、検証要件、ガードレール（scope / stop-and-report / redaction / commit-local-no-push）を含める。
3. ディスパッチ（dispatchを使用）+ フック検証（ハードゲート）+ 理解の門：references/agent-watch/dispatch を使用してセッションを起動し、send-keysでgoalパスを送信する（コマンド一式 + 注意点：text/Enter配信、@ 補完、codex updateのプロンプト——references/agent-watch/README.md参照）。起動後すぐにフックを検証：watchが一瞬でRead状態になることを確認し、必ずセンチネル WORKING 行が見えること；no sentinel (hook not wired) → fallback と表示された場合 = dispatchが正しく動いていない / codexがフックを信頼していない → 停止して再起動、問題を抱えたまま実行するな。ディスパッチ後、作業開始前にまず「理解の門」を通過せよ：最初のラウンドでエージェントに「どのファイル/契約に触れるか、どのようなリスクがあるか」を復唱させ、確認が取れてから続行を許可する；弱い回答/方向性の誤りはその場で訂正し、沈黙を同意と見なすな。この一度の復唱要請で、「goalを誤解して黙々と修正する」という問題の大半を防げる。
4. ウォッチャーを付ける（references/agent-watch/、フックは主信号、画面取得はフォールバック）：エージェントはステップ3でdispatchを使って既に起動しているため、このステップでは単に watch <session> で監視し、終了時に teardown する。4つの判定基準；メカニズム全文 + 型付き状態の全列挙 + STALLED-EXTERNAL / 非同期完了通知のブラックホール / 積極的証拠の2つの落とし穴 / フォールバック自己チェック / cto-guardの実証は当該ディレクトリのREADMEを参照：
   • 型付き状態が存在すること、DEAD≠DONE、WAITINGは入力を待っていること（idleやウォッチャーの裁定を終了状態と誤認するな）。
   • 完了判定は積極的証拠に基づき、idleやウォッチャーの裁定に頼るな——tmuxリンクに失敗シグナルはなく、ウォッチャーの裁定は手がかりに過ぎない；完了を積極的成果物（ローカルコミット／成果物カウント／レビューマーク）に結び付け、自分で capture-pane して確認せよ。
     • 分割コミットタスクにおけるidleはトラップ（各パートの境界で一瞬idleになる。単純なidleや「最初のコミット」検出では途中で誤判定する；実証：3パートのリファクタリングで、Part A+C完了後、Part B開始前の一瞬のidleが手書きのポーリングを騙した）。再発防止は規律ではなく構造に頼れ（ルールを覚えるだけでは不十分——ルールがあっても違反した）。ガード：references/agent-watch/cto-guard-bash.py がツール呼び出し層で「純粋なidle不在のみに依存し、積極的grepを行わない」生のポーリングを拒否する（git成果物検証 / pane取得によるVerdict・プロンプト通過確認）。
   • 純粋なイベント駆動は盲目的待機につながる → タイムアウト上限で保険をかけよ：予想所要時間 ×2 でフォールバック自己チェックを設定する（ScheduleWakeup/cron）。期限を過ぎても終了状態が得られない場合は能動的に capture-pane する——「WORKINGでスタック/ホットリトライ」による決してDONEにならない状態に対処する（上記の偽のDONEとは別の失敗モード）。
     • ブラウザ/E2Eサブエージェントからの完了通知はブラックホール化する（生きているPlaywrightセッション/devサーバー/bg forkが通知をトリガーさせず、盲目的に待機してタイムアウトする）。ディスパッチ時に即座にデッドラインと積極的証拠のwatchを設定せよ（出力ファイルの増加/新しいスクリーンショット/マイルストーンSendMessageを監視する）。期限を過ぎても動きがなければSendMessageでつつき、それでもダメならkillして再起動する。自動通知を盲目的に待つな。強制層：references/agent-watch/cto-guard-agent.py（PostToolUse·Agent|Task）がディスパッチの瞬間にリマインダーを注入する（omissionはハードに拒否できず、launch時に強制的に顕在化させるのみ；リマインダーはJSON additionalContext 経由でエージェントに届く）。
   • バックグラウンド起動には決してシェルの & を付けない（既にデタッチされている。さらに付けると二重バックグラウンド = 孤児プロセス + 誤った喪失判定につながる）；うっかりミスの保険としてPreToolUse·Bashの references/agent-watch/cto-guard-bash.py が &/& disown をブロックする（上記のidleポーラと同じスクリプト）。
   • 配線（wiring）：2つのフックエントリを並行して、repo-governance-bootstrap §11 で既に作成されている設定ファイル（settings.json）に追加する（その3ディスパッチャーパターンを流用し、新しい足場を作らない）；CCのfrontmatter hooks: はセッション途中のアクティベーションではトリガーされないことが確認されており、それに依存しない。全テーブル + 2つのエントリは references/agent-watch/README.md §Wiring を参照。
5. steering：新しい事実や指示が現れたら、補足文書として書くか、直接send-keysでセッションに送信し、「あなたの仮定と矛盾する場合、事実が優先される」と明確に伝える。
6. 納品検証 + Implemented→Verified：ウォッチャーが測定するのはidle、エージェントが自己申告するのは「done」——どちらもImplementedに過ぎず、納品ではない（納品状態を実行者の自己申告に任せるな。§1.4の生存検出も同じテーマ）。Verifiedに昇格するのは、① 検証4点セットを通過 + ② 異種のcodexが独立に確認した場合のみ（実行者がどれほど厳しい自己レビューをしても、同じ系統 = 自己バイアスであり、信用できない）；roadmap / ACTIVE_CONTEXT / チケット完了はVerifiedのみを認める。検証4点セット（git status / git log / test+lint再実行 / grepカウント + 実証）は references/dispatch-baseline.md を参照。

2. 敵対的レビューサイクル

まずリスクに応じてレビューの深さを決定せよ：低リスクは軽量標準レビュー（codex review --base）、高リスク（認証/マイグレーション/基盤/大規模リファクタリング）は完全な敵対的サイクルで行う。codexに組み込みの「敵対的」モードはない——敵対的とはプロンプトレイヤーで実現するもの（自らセッションを立ち上げ、軸を指定し、severity/verdictを出力させ、複数ラウンドで収束させる）。必ず自分でセッションを立ち上げてプロンプトを制御し、サブコマンドは使うな。完全なテンプレート + 軸の全列挙 + 実証 + ledgerのカラム + 合格ラインは references/review-dispatch.md を参照。判定基準：

• briefはコールドコンテキストで、自分の結論を混ぜない（自分の判断をcodexに与える = アンカリング。モデルを変えても推論チェーンを共有すれば、脱相関の価値が無駄になる）。
• 最も失敗しやすい軸を指定する（クラッシュリカバリ/並行処理/フラグ分岐パス/機能低下/セキュリティ契約/マルチテナント分離/メトリクスの正直性）。codexに自らプローブを書かせる。
• レビュー前にまず実行パスの分岐を列挙する（provider/mode、live vs rehydrate…）。codexに「まだ到達していない分岐はどれか」を確認させる。
• ゲート/トリガー型機能は必ずunder-fireをチェックする（トリガー条件が満たされた時に実際にトリガーされたか）、over-fireだけでなく。
• レビュー記録はledger構造で、単なる追記ではない（blocking/queued/advisory/已修/stagnationをラウンドごとに更新）。各ラウンドの再レビュー時には、元のgoalの不変の受け入れ基準を再提示する。
• 三分類で収束：blocking が残っている場合のみサイクルを継続；advisory→follow-upとして、既に準備のできたpushをブロックしない；既に判断済みのものを再度挙げない。
• stagnation検出：同じfindingが繰り返し現れる = 行き詰まり。収束させるか、人間の介入を仰げ。無限の応酬を続けるな。
• レビュー中はompを同じworktreeで動かすな（codexが内部でテストを実行すると結論が汚染される）。

3. 変更規律

• フラグゲーティング：動作変更はデフォルトで環境フラグの背後に隠し、デフォルトOFF = バイトレベルでゼロ変更とする；例外：ReOpenで承認された修正はデフォルトON可（goalに理由を明記）。パフォーマンス/実験的なものは一律OFF。
• measure-before-more / 計測してから断行せよ：最初の一手を打った後、制約を結合する対象は変わる——まず実測してから次の一手を決め、推算で複数のレバーを連続的に動かすな。バグ修正も同様に、着手前に ① バグが現在の状態で本当に再現するか、② 観測値が本当に何らかのメカニズムで制約されているか（観測値5 < 上限10 なら上限は制約ではない）、③ 実行が本当に疑っているコードに到達しているか（コードを読むだけでは候補を挙げるに過ぎない。「ここに到達した」はログ/traceで証明せよ）を検証せよ。結合制約が証明されていない場合、まず計装を仕込んで再テストし、投機的な修正を送るな（実証：コードを3ラウンド読んで存在しない「ハングアップ」を推定し、毎回実際のデータで却下された）。よくある疑似バグ：間違ったデータソースを調べた（空テーブルを本当のテーブルと誤認 / 間違ったログ文字列 / 間違ったsession）、「受信していない」(クライアント) ≠ 「送信していない」(サーバー)。
• コミットはローカルに留め、push/PRはユーザーの明示的な承認を必須とする；一度の承認はそのアクションのみをカバーする。
• 検証の正直さ：納品は3部構成で——何を検証したか（実際に実行した）/ 何を検証しなかったか / 残存リスク。ローカルでモック化・迂回した部分（実際のLLM、実際のキュー）は明示的に注釈し、デプロイ後の運用で補完検証せよ。実証：ローカルLLMのモック化により、un-awaited coroutineが本番環境に漏れ出した。
• 代用検証パス ≠ 本当のパス（バックエンド/エージェント/フロントエンド共通）：mock / スタブ / stream smokeが全てグリーン ≠ リアルパスが成立していること——実際のデプロイパスで受け入れよ。代用検証を本当の検証と誤認するな。本当のパスはmockしたパスと同じではないことが多い（フロントエンドの例は§7：カードは execute/async 経由で execute/stream ではない。3段階グリーンでもReOpenになった）。最も重要な点：検証しようとしている境界そのものをmockするな——テスト対象の関数をスタブ化する = テストは情報ゼロ、たまたまバグを隠蔽する；真のアプリケーションE2Eこそが「テスタブル」の入り口である（実証：一日のうちに4つのバグが全てreview+ユニットテストをパスしたが、E2Eだけがそれらを捉えた）。
• 編集前に変更される可能性のあるファイルを再読せよ：rebase / 別のエージェントが同じworktreeを操作した / ファイルを変更するgit操作を自分が実行した後、インコンテキストのファイルビューはstaleしている——まず再読してから編集せよ。read-before-editのガードレールを持つツールはstaleな編集をブロックする（must be read first と報告するのはバグではなく、古いビューで他人の変更を上書きするのを防いでいる）；ガードレールのないツールは静かに上書きし、より悪い。読み取りと編集の間にファイルを変更するコマンドを挟むな。

4. 間接的な環境アクセス（運用エージェントモード）

直接アクセスできない環境（本番、独立した開発ランタイムライブラリ）については推測するな——自己完結型の証拠採取用プロンプト（テンプレート references/ops-prompt-template.md、保存先 docs/orchestration/<NAME>_PROMPT.md）を書き、ユーザーに運用エージェントへ転送させる。要点（読み取り専用のコマンド / SQLは完全に記述 / 期待される読み取り値と判定ルールを完全に記述 / 報告フォーマットは固定 / 機密情報はメタデータのみ取得）は当該テンプレートを参照。 判定基準：運用エージェントからの報告は自分の推測より優先される——現場の状況とHEADのコードが矛盾する場合、まずビルドドリフト（古いバージョンがデプロイされている）を疑い、次に自分の制御フロー分析を疑え。

5. 状態の永続化とリズム

• docs/orchestration/ がSoT（信頼できる情報源）：*_GOAL / *_FINDINGS|IMPL_omp / *_REVIEW_codex / *_PROMPT / *_RESULT。ファイル名にはタスク番号を含め、証拠は全てfile:lineで示す。ライフサイクル：クローズしたらドキュメントを archive/ に移動する（READMEにインデックス行を追加）。Liveディレクトリには現在進行中・待機中のもののみを置く。ドキュメントは作成されるだけで削除されない → ライブと履歴が混在する（実証：とあるプロジェクトで最初のクリーンアップまでに38ファイルが蓄積された）。
• memory：ワークストリームごとに1ファイル + インデックス1行（状態/PR/オープンな課題/次のステップへの入り口）。「圧縮/外部入力待ち」の前に必ず更新する。memoryはオーケストレーターのプライベート領域であり、エージェント/新しいセッションはdocsのみを読み取る——memoryだけ更新してdocsを同期しないと、共有ガバナンス層が腐敗する（実証：とあるプロジェクトでACTIVE_CONTEXTが4日間凍結され、無価値になった）。三分業：docsは全エージェント共有の状態スナップショットを格納する（what/why）、ACCESS.local.md は接続方法と認証情報を格納する（how-to-reach、機密情報はgitignored、repo-governance-bootstrap参照）、memoryはオーケストレーター私的な教訓 + 入り口ポインタを格納する。短期ワーキングメモリ（現在のタスクの草稿/進捗/ToDo）はこれら3つには入れない——コンテキストウィンドウか一時的な /tmp NOTESに生き、いつでも破棄できる。memory（セッションをまたぐプライベート層を汚染）やACTIVE_CONTEXT（それはクローズ時のスナップショットであり草稿ではない）に詰め込むな。
  • 書くときの規律（振り返りを待たない）：上のアンロードはやりながら行う——memoryを書くその場で事実詳細をACCESS/docsに書き込め。振り返りまで溜めておくな。
  • スキルテキストで覚えきれない高頻度の規律には PostToolUse hook で保険をかける（強制層でsalienceの減衰を補う；テンプレートはrepo-governance-bootstrap参照）。
• 振り返り儀式（イベント駆動：クローズ/圧縮前/ReOpen発生後は能動的に提案）——これは即興ではなくチェックリストである。 「振り返り/クローズ/ハンドオフ」を聞いたら → references/retrospective.md を読み、7ステップを1つずつチェックする。記憶だけで即興でやるな（即興版は一見完全に見えても、重要なガバナンスステップを静かにスキップする——実証 2026-06-26：「振り返り儀式」を要求されたが自由に進め、roadmapの状態確認 + ACTIVE_CONTEXT全文書き換え + コンテキストガバナンスをスキップした）。
  • ハードゲート（これを通過しなければ完了を宣言できない）：bash references/retro-check.sh --base <branch> --docs <docs-dir> --memory <MEMORY.md> を実行して機械的に検証する（マージ済みブランチに孤児worktreeがない / ACTIVE_CONTEXTが今日書き換えられた / roadmapが最近更新された / MEMORY行数超過なし）；機械的な代理検証のみを行い、意味的な判断はあなたに委ねられる。
• 孤児掃除：完了したタスクのセッションを閉じる（重要なコンテキストを保持してサスペンドしているものは保持）；エージェントが起動した孤児プロセスを掃除する——docker ps / ps / バックグラウンドジョブ。一時的なcomposeはtrap/finally down --remove-orphans を使用し、reproでは裸の while True を禁止する（境界のあるループ/デッドラインを使用）。実証：とあるreproの無限ループが2.5日間空転し、CPUを65%消費した。

6. タスクシステム（外部タクトラッキング：Jira / Linear / 飛書 bitable など）

• タスクシステムのCLI/APIを使用してタスクを読み書きする；ステートマシンはプロジェクトに応じて定義する（未処理/処理中/テスト可能/完了/ブロック中/ReOpen）。
• チケット完了基準：修正 → E2E検証 → スクリーンショットの証拠をタスク添付ファイルにアップロード（レビューアが一目で確認できる）→ 結論を一行 → 状態を遷移。
• ReOpen：まず証拠を取ってから修正する——前回の「修正済み」メカニズムがそもそも制約の原因でない可能性がある。
• ガバナンスドキュメント内に第二のタスク台帳を作るな：外部システムがタスクのSoTであり、roadmapはそのマッピング層に過ぎない。ルール詳細（外部IDの使用 / SoTの明記 / いつ内部RD番号を作るか）は repo-governance-bootstrap の「外部タスクシステム優先」で実装する。

7. フロントエンド修正の検証（ブラウザデバッグ）

フロントエンドタスクをディスパッチした後の検収規律：コードレビュー + ユニットテストだけでは不十分。必ずブラウザで実際のレンダリングを確認せよ。さらに、mock / SSEフレーム / ローカルが全て通っても ≠ 実ユーザーがそれを目にできること。クローズループには、デプロイされた実際のアプリケーションにログインして実際の操作を一通り行い、スクリーンショットを撮って初めて完了と見なす（代用検証パス ≠ 本当のパス のフロントエンドにおける具体例。一般原則は§3参照）。E2Eは検収であり、オーケストレーターのメインコンテキストを占有してはならない——ブラウザMCPを持つサブエージェントに委譲せよ（§0「自分で長時間のE2Eを実行しない」のフロントエンドにおける具体例）。完全な方法論（MCP主CLI補完、a11y優先、ネットワークパネルによるネットワークバグ診断、CLIでSSEを取得、デリバリークローズループ、E2Eのサブエージェント委譲、ローカルでのサービス起動時の落とし穴をプロジェクトの AGENTS.md に記載）は references/frontend-verify.md を参照。

8. 新規プロジェクトオンボーディングチェックリスト

新規プロジェクトの6ステップ（ガバナンス骨格のブートストラップ → 委譲境界の補完 → orchestrationディレクトリの作成 → 最初のタスクで§1の全フローを実行 → memory working-styleエントリの作成 → DECISION_QUEUEの作成）は references/onboarding-checklist.md を参照。

9. 主理人の注意力と意思決定キュー（認知負荷低減）

第三の鉄則の具体化。目標は主理人が決断を減らすことではなく、重い決断のみを行わせること（戦略的/不可逆/金銭/価値に関わるもの）。各決断には咀嚼された選択肢が添えられ、主理人は決して覚えておく必要がないこと。 完全な方法論（7つのメカニズム + 委譲ボード + 失敗モード + 出典の正直な注釈 + copy-pasteテンプレート）は references/decision-queue.md を参照。 本章では重要な要点のみを残す：

• 単一の意思決定キュー docs/DECISION_QUEUE.md：オーケストレーターが管理し、主理人は読み取り専用。🔴 彼の判断が必要 / 🟡 私がドライブ / 💤 parked / ✅ クリア。 完全性保証=唯一の面であり、他に保存せず、静かに失わない（信頼の前提。そうでなければオフロードは機能しない）。各 🔴 には推奨 + サイレントデフォルト + revisitトリガーが付随する。
• 三段階委譲：T0 直接実行（可逆/既に承認済み/価値判断不要）・ T1 実行して一行記録（可逆だが知らせる価値あり、拒否可能）・ T2 実行前に確認（不可逆/外部向け、戦略/優先度/金銭/価値に関わる、実質的な判断の余地がある真の曖昧さ）。負荷軽減 = できるだけT1に寄せ、T2を同期ゲートとして多用しない。
• サイレントデフォルト：主理人が返答しない場合 → 可逆なものは明記されたデフォルトに従って進む、不可逆なものは一律HOLD（決して自動的に不可逆アクションを越えない）。
• その他のメカニズム（集約トリップワイヤー / バッチ処理アップグレードパッケージ / ハートビート / HELD revisit / キューの腐敗防止 / 三段階ガバナンスの混同防止）は references/decision-queue.md を参照。