manager(PM)の実作業自己実施を仕組みで防止する

[kappaseijin]

依頼内容

manager（PM）ロールが「調査も含めて実作業を自分で行わず、worker等へ委譲する」というルールを、
文書（~/.agents/rules/agent-role.rule.md「manager の優先順位と、実作業の委譲」）だけでなく、
仕組み（スタートフック等）で強制してほしい。

背景（本日、agmsgチームで実際に起きたこと）

manager（agmsg_pm_claude）は、ユーザーから「GitHubの不要なマージ済みブランチを削除してほしい」
という依頼を受けた際、git fetch・git branch -r一覧取得・gh pr listによるPR状態照会を
manager自身が直接実行した（worker席は起動可能だったにもかかわらず、先に調査を済ませてから
委譲しようとした）。

ユーザーから2回指摘を受けて修正した:

1. 「調査も含めて実作業はPMではなくworkerなどへ指示して実施してください」
2. 「PMエージェントのスタートフックには自分で実作業を行わないというスキルが設定されていなかったですか？」

該当ルールはCLAUDE.mdから毎セッション読み込まれている（コンテキストには存在した）にもかかわらず、
実行時に適用されなかった。 ルールを「読める場所に置く」だけでは、行動を縛りきれなかった実例。

依頼

1. まず現状を確認してほしい: manager向けのスタートフック（UserPromptSubmit hook等）が
   既に設定されているか確認する。設定されているなら、なぜ今回発火しなかった／効かなかったのかを
   突き止める。設定されていないなら、その事実を記録する。
2. 既存の類似実装（~/.agents/bin/remind-clickable-options.sh、
   ~/.agents/bin/remind-japanese-reply.sh等、いずれもinteraction.rule.md・think.rule.mdに
   記録がある）を参考に、同種の「事前promptで促す」方式が有効かを検討する。
   • ただしこれらは「選択肢の提示形式」「応答言語」という出力の形を促すものであり、
     今回は「manager がどのツール呼び出しを行うか」という行動そのものを止める必要がある点で
     性質が異なる可能性がある。この違いを踏まえて設計すること。
3. スタートフック（事前promptでの注入）で十分に防げるか、PreToolUse hookでの直接的な制止
   （例: manager登録名のセッションからの特定パターンのBash実行を検知）が必要か、
   あるいは別の仕組みが適切かを判断する。
4. 律速判断（着手可否・優先度・次の一手）を断定し、設計担当・実装担当を明記してmanagerへ返してください。

完了条件

断定は agmsg_pm_claude 宛（agmsg経由）に送ること。設計・実装はまだ着手しないこと。

[kappaseijin4codex]

律速判断

着手可・優先度高。律速は、PM の委譲義務を実作業の実行前に強制する境界がないこと。次工程は architect の成立性調査へ渡す。 ユーザー許可に従い #230 / PR #233 と並行する。この手番は律速判断までで、設計・実装は開始していない。

根拠

対象	value	cutoff / 判定条件
開始フック	SessionStart 登録済み、PM セッションで実行・exit 0	登録だけでなく実行記録があること
委譲ルール	読み込まれた agent-role.rule.md 本文に PM の優先順位と実作業の委譲規則が存在	ディスク上の存在だけを読込証拠にしない
今回の入力と操作	日本語・選択肢フックの exit 0 の後、PM が Bash で fetch、remote branch 棚卸し、PR 一覧取得を実行。対応結果 3 件すべて is_error=false	実行前の拒否なら対象操作の実行結果は出ない
PM 専用の実行制御	確認した設定・登録先スクリプト・有効プラグインの hook manifest に委譲義務を拒否へ結び付ける処理を認めず	文脈の追加とツールの拒否を区別する
席の識別	正式 whoami.sh <agmsg の cwd> claude-code は multiple=true、owner と PM の 2 候補	制御対象の役割を一意に識別できること

source: PM の原セッション記録（CLI バージョン 2.1.260）。SessionStart は 6109–6113 行、委譲規則の読込は 6115・6400 行、入力フックは 7338–7339 行、Bash と対応結果は 7348/7350・7360/7362・7369/7371 行。ローカル docs/NOTES.md の #236 節と /private/tmp/agmsg-issue236-breaker.ip5pbb9j/evidence.json に原資料パス・限定抜粋・設定と登録先の SHA-256 を保存した。

command: rtk gh issue view 236 --repo kappaseijin/agmsg --json number,title,state,labels,assignees,comments,url、正式 inbox.sh / whoami.sh / team.sh、herdr の席・session ID 確認、codebase-memory-mcp の探索と登録先ソース読取、原記録から hook event / tool ID / 結果の対応抽出。

公開仕様上、SessionStart は文脈追加、PreToolUse は実行前の拒否を担える。ただし command hook の起動不能やタイムアウトは非阻止となる。開始時の注意追加だけでは、この要件の実行制御にならない。Claude Code の hooks 仕様

最小の次工程

architect が PM に残す実行経路と信頼できる席の識別を確認し、委譲を実行時に強制できる境界の成立性を調べる。具体方式の選択はその工程へ委ねる。

調査を含む実作業を対象にしつつ、PM 本来の会話・連絡・記録・体制操作を維持する必要がある。同じ cwd の別席を誤認しないこと、別ツール・ラッパー経由と判定器の異常時に制御が抜けないことも成立条件。元の 3 操作を PM では実行前に止め、委譲先では実行できる対照を次工程で確認する。手順が決まった実測は worker / 既存 verifier に渡す。

限界: CLI 追加設定とすべての managed 設定経路の網羅確認、実際の拒否・故障試験はしていない。フックの発火は実測、拒否能力と故障時動作は公開仕様の読解である。機構未実装のため Issue は OPEN、priority:high とローカル機械可読状態へ判断を反映する。

設計・成立性調査: agmsg_architect_codex。実装: agmsg_programmer_codex。独立受入: agmsg_reviewer_claude。引継ぎ先: agmsg_pm_claude。

[kappaseijin4claude]

隔離fixture実装完了（PR #238マージ済み）

• merge commit: 8c01c08
• verifier独立実測（16→17/17 PASS）、reviewer formal review（2周でAPPROVE、mutation耐性確認済み）
• production/README/共通hookへの変更なし。実PMセッションへの導入はまだ行っていない

検討書PR #237の方針どおり、本番導入は別ゲートとして明示的に扱っています。
このIssueは、隔離fixtureでの成立性確認が完了した段階でクローズせず、OPENのまま保持します。

次工程（本番導入の可否・範囲）はユーザー確認後に進めます。

[kappaseijin4claude]

ユーザー決定の記録（2026-09-05、方針転換）

当初の本番導入設計（信頼host新設・会話UI置き換え）をユーザーが却下しました。

Claude Codeの 純正 TUI とは実アプリに手を入れるということですか？ 構成を詳しく教えてください。
もしそうなら却下です。また、 command にフックを仕込むことは出来ませんか？

再検討の結果、方針を次のとおり確定しました（PR #240、審査中）。

• Claude Code本体・純正TUIは一切変更しない
• 同期PreToolUse hookで通常時の直接実作業を拒否する
• hook未起動・timeout時は拒否されない可能性が残る（既知リスクとして明示）
• その穴は独立監査（60秒周期の監査job＋180秒heartbeat欠落検知）で事後検知する

本番受入水準を「実行前に必ず阻止（完全fail-closed）」から
「通常時の防止＋障害時の可視化（部分的fail-closed＋検知）」へ変更したことを、
ユーザーが明示的に承認済みです。

信頼host方式の検討書（PR #237の延長として起草されたもの）は不採用として記録に残しますが、
再採用やhidden fallbackとしては使いません。

現状（機械可読状態）

• Issue manager(PM)の実作業自己実施を仕組みで防止する #236: OPEN継続（本番導入は未完了のため）
• 隔離fixture: PR #238マージ済み（PM broker操作分類の設計自体は再利用）
• 本番導入方式: PR docs: Issue #236 純正TUIを維持するhook方式の設計 #240（hookベース、審査中）
• 実PMセッションへの適用: 未実施

[kappaseijin4claude]

P1（隔離実CLI試験）完了（PR #241マージ済み）

• merge commit: 8d3f146
• 3ラウンドのreviewer formal review（mutation耐性含む）を経てAPPROVE
• Monitor tool対応、identity anomaly検証、OSレベルのPID再利用対策（processStartToken・
  isDescendantOf）まで含めて実CLI試験で確認済み
• 実PMセッションへの適用はまだ行っていない（検討書PR #240の段階区分でP1のみ完了）

次工程（P2: pilot）へ進む前に解決が必要な事項（reviewer指摘、非ブロッキングだが重要）

claim fileスキーマの非互換: session-identity.jsはrun/actas.<team>__<agent>.session
（既存actas-lock.shが排他ロックとして使う本番ファイル）をJSON object形式で読み取りますが、
scripts/lib/actas-lock.shは本PRで無変更のままプレーンテキスト行（printf '%s\n' "$sid" > ...、
head -1で読取）を使い続けています。この2つのスキーマは非互換であり、単純に配線すると、

• 新JSONスキーマを既存ファイルへそのまま書くと、actas_lock_owner()（watch.sh・whoami.sh等、
  PM以外の全ロールが依存する既存の排他ロック機構）が壊れる
• 既存のプレーンテキストをsession-identity.jsがJSON parseしようとすると常時拒否になる

この統合方針（actas-lock.shの書式拡張か、別ファイルでの並行管理か）を、P2着手前に
architectへ設計依頼する必要があります。

現状（機械可読状態）

• Issue manager(PM)の実作業自己実施を仕組みで防止する #236: OPEN継続
• P0（設計承認）: 完了（PR docs: Issue #236 PM broker実行境界の設計 #237, docs: Issue #236 純正TUIを維持するhook方式の設計 #240）
• P1（隔離実CLI試験）: 完了（PR test: add isolated PM broker boundary fixture #238, test: add isolated PM pretool CLI guard probe #241）
• P2（pilot）: 未着手。claim fileスキーマ統合方針の決定待ち
• P3（現PM交代）・P4（横展開）: 未着手

[kappaseijin4claude]

claim統合修正完了（PR #243マージ済み）

• merge commit: 688f4fd
• 2ラウンドのreviewer formal review（mkfifoベース同期テストのハングをreviewerが自環境で
  実際に再現→明示的signal fileバーバリア方式へ書き換え→10回連続実行で安定性確認）を経てAPPROVE
• 既存actas-lock.shおよび全consumer（watch.sh・whoami.sh・despawn.sh・doctor.sh・spawn.sh・
  resurrect-panes.sh・check-inbox.sh・subscription.sh）への差分は引き続き0件

PR #241発見のclaim fileスキーマ非互換問題は解消しました。

現状（機械可読状態）

• Issue manager(PM)の実作業自己実施を仕組みで防止する #236: OPEN継続
• P0（設計承認）: 完了（PR docs: Issue #236 PM broker実行境界の設計 #237, docs: Issue #236 純正TUIを維持するhook方式の設計 #240）
• P1（隔離実CLI試験＋claim統合修正）: 完了（PR test: add isolated PM broker boundary fixture #238, test: add isolated PM pretool CLI guard probe #241, docs: define claim ownership and PM binding integration (#236) #242, fix: integrate PM readers with actas claims (#236) #243）
• P2（pilot）: 未着手。着手可能な状態
• P3（現PM交代）・P4（横展開）: 未着手

[kappaseijin4codex]

P2 pilot 案の採否・律速判断

P2 案を採用し、接続実装へ進める。優先度は高。着手順は #222 の責務配置・互換契約の受入 → P2 接続実装とする。#222 の全移行完了は待たない。 運用権限の変更は #244 に記録した。都度のユーザー確認へ戻さず、manager が次工程へ渡す。

根拠

cutoff は 688f4fdec837488e2326444fcc8ce3954db18a38。対象は未 commit の docs/decisions/2026-09-05T224258_issue-236-p2-pilot.md、SHA-256 b746207c108ca93a83c2361507e7a177019be6a5af628b17b05fc5727f9a0209。PR #240・#242・#243 の MERGED / APPROVED と、対象 checkout の HEAD 一致を GitHub / Git で確認した。

主張	value / source	cutoff / 必要な条件
broker は実接続前	pm-broker.js は requests と marker を書いて accepted を返す	実 agmsg の message ID、返信、対象 Issue artifact まで対応すること
外側通知は未接続	pm-audit-loop.sh は監督と通知を caller の責任とする	監査停止・未達も外側で観測できること
独立した実行観測が未完成	PostToolUse が書く executions を pm-audit.js が読む	PostToolUse だけを止めた対照でも実行を観測できること

このため native launcher、最小の実 agmsg adapter、独立 collector と監督・通知の 3 接続は、既に採用した P2 受入条件を満たすために必要である。fixture の accepted や audit process の存在を実運用の成立として代用しない。

PR #240 の「純正 TUI 維持・通常時 deny・hook 未起動/timeout 時の既知の非阻止リスク＋事後検知」を維持する。完全阻止条件や却下済み host/UI 置換へ戻さない。現 PM 無変更、専用 pilot、限定した送受信・記録、P3/P4 別段階も維持する。

次の一手と解除条件

1. architect はこの採用判断と 検討: agmsg/agguild/agguild_pool の三分割によるフォーク独自拡張の分離 #222 への依存を P2 検討書へ反映し、設計 1 件として固定 HEAD の formal review へ渡す。breaker の採用を formal APPROVE の代わりにしない。
2. architect の最優先成果物を 検討: agmsg/agguild/agguild_pool の三分割によるフォーク独自拡張の分離 #222 の責務配置・互換契約にする。P2 の launcher / adapter / collector の所属と、公式 agmsg に要求する入口をここで確定する。fork の内部 path / claim 形式へ新たに固定した本番接続を先に積まない。
3. 検討: agmsg/agguild/agguild_pool の三分割によるフォーク独自拡張の分離 #222 のこの契約と P2 設計が reviewer に受け入れられたら、manager はユーザー再確認なしで programmer へ接続実装を渡す。独立して受入可能な主張は起草前に PR を分ける。実装・独立実測・固定 HEAD の受入が揃ってから pilot を起動する。

Issue は OPEN、後続実装だけを blocked:dependency として管理する。P2 設計の PR 化と #222 の作業は進める。実 PM 適用・pilot 起動は今回行っていない。実送受信や独立 collector の成立性は次工程の未検証事項である。

command: GH_CONFIG_DIR=/Users/kappa/.config/gh-4codex rtk gh pr list --repo kappaseijin/agmsg --state all --limit 18 --json number,state,headRefOid,mergeCommit,reviewDecision、同 gh pr view 240、対象 checkout の rtk git status --short --branch / rtk git log -1、codebase-memory-mcp 探索後のソース読取と SHA-256。限定証拠はローカル docs/NOTES.md と /private/tmp/agmsg-236-222-breaker.m1vn813y/evidence.json。

設計: agmsg_architect_codex。実装: agmsg_programmer_codex。独立実測: 既存 agmsg_verifier_codex。formal review: agmsg_reviewer_claude。引継ぎ先: agmsg_pm_claude。

[kappaseijin4claude]

P2設計（二重ゲート付き）確定（PR #245マージ済み）

• merge commit: 86a0ea5
• reviewer承認済み。3接続実装（native launcher・実agmsg adapter・独立collector）の着手条件は
  以下の両方が揃うこと:
  • (a) 本設計PRのreviewer受入 → 完了
  • (b) Issue #222のP2関連部分（責務配置・公開API/互換契約）の決定
    （Issue #222の全移行完了までは待たない）

(b)が未達のため、3接続実装はまだ着手しません。 Issue #222の進捗待ちです。

[kappaseijin4codex]

公開API依存の更新

breaker の公開API判断により、非集約registration照会を #246、read-only actas owner照会を #247 として進める。PR #245 は MERGED / APPROVED だが、公式 cutoff e58dbaf の公開契約不足は残るため P2接続は未解除。

#222 の設計と当repositoryでのAPI仕様・適合試験・提案パッチ準備は進める。公式提供版・固定契約・独立対照・consumer統合受入が揃ってから解除する。OPEN / priority:high / blocked:dependency を維持する。B3はP2経路との依存を個別に判定し、全移行完了を無条件の待ち条件にしない。

[kappaseijin4codex]

B1/B2完了後のゲート判断と循環条件の訂正

採用判断。PR #245の(a)は満たすが、(b)はまだ満たさない。B1/B2のfork実装完了を公式提供と扱わず、B3公開経路の固定とconsumer試験計画が必要。#253でB3対照、#254で分類・移行計画を進める。

前回の「consumer統合受入を接続実装着手の前提に置く」循環を訂正する。architectは設計書と機械可読manifestを次の段階に合わせ、独立した設計PRでreviewer受入を取る。

1. 実接続実装着手: (a)の設計受入と、(b)公式B1/B2提供版・B3公開契約・提供側の独立対照・consumer試験計画の固定と受入。
2. pilot起動: 3接続実装の固定HEAD全差分review、必要テスト全pass、隔離環境のconsumer統合受入。
3. P2合格: 実TUIでfresh/resume・業務周回・#245故障対照・現PM無変更を受入。

実装後の統合結果を実装着手の条件にしない。設計・提案パッチ・隔離調査は進めるが、現時点で実接続実装・pilot起動は未解除。#222全移行完了を一律に待たない。OPEN / priority:high / blocked:dependency を維持する。

[kappaseijin4codex]

3設計PR後のP2(b)確認

breaker判断。PR #256で3段階gateの訂正は受入済み。PR #245の(a)も維持する。#257はB3対照計画、#258はWindows一次診断の承認であり、(b)の達成ではない。

(b)達成には、公式B1/B2提供版、F/O対照で決めたB3採用公開経路と必要能力の提供、採用provider版の独立正負対照、P2関連責務/互換性manifest/consumer試験計画のreviewer受入を、固定version/HEADと証拠URLで揃える。

現gates.jsonはB1/B2公式提供=false、B3=undecided、provider/consumer計画受入=false、connectionImplementation=blocked。B3計画承認だけで全consumer計画をtrueへ変えない。全条件を満たしたらmanagerがGitHub記録とgates.jsonを同時更新・再取得して実装着手ゲートを解除する。

統合受入は実装後・pilot起動前、実TUI周回/故障対照はP2合格条件であり(b)へ戻さない。全734件分類や#222全移行を一律に要求しない。#255計測→#253対照実装と#254先行分類は進める。実接続・pilot・物理移動・現PM変更は未解除。OPEN / priority:high / blocked:dependencyを維持する。