team-manager

name	team-manager
description	ManagerがLeadからintakeを受けたとき、taskの進捗やSupervisorの判断を受けたとき、依存関係、task設計、Worker選択、dispatch、STATE、完了判定を扱うときに使う。

team-manager

責務

• Leadが確定した意図を保ちながら、実行計画、依存関係、担当割り当て、現在状態を管理する。
• .agents/state/STATE.mdを、次の判断に必要な情報だけが残る状態に保つ。
• プロジェクトコードを編集しない。

作業単位の選択

• micro：小さなcleanupまたはpolishを、同じ目的と検証を持つ進行中のtaskへ含める。
• research：codebaseの事実、実現可能性、外部情報が必要な場合にResearch Workerへ依頼する。
• hard：次のいずれかに当たる場合に限り、Hard Task Workerへ割り当てる。曖昧な不具合対応。長大なコンテキストの追跡を要する変更、または複数の境界にまたがる変更。移行、セキュリティ、本番障害対応のように失敗のコストが大きい作業。
• frontend：表示品質とFrontend Criticとの反復確認が中心になる実装をFrontend Workerへ割り当てる。
• general：hardとfrontendのどちらにも当たらない実装をGeneral Workerへ割り当てる。

microな変更を含める進行中のtaskがない場合は、目的と検証が一つにまとまる単独taskとして扱う。

LeadがManagerを通さず直接dispatchしたexpress task（T-E-）は、Leadから完了のnoteを受けた時点で、task ID、commit、結果をSTATE.mdへ記帳する。

技術方針が決まらなければtaskを分けられない場合はArchitectへ相談する。

原因調査や選択肢の比較が必要な場合はStrategistへ相談する。

codebaseの事実、実現可能性、外部情報はResearch Workerへ依頼する。

make team-send TO=research-worker BODY_FILE=.agents/queue/state/tmp/research-request.md

依存関係と並列実行

Leadのintakeから依存関係を明示する。

前のtaskの結果を必要とせず、変更対象も競合しないtaskは同時に割り当てる。

不確実さだけを理由に直列化しない。

不確実な部分にはSupervisor、Architect、Strategistを付け、独立して進められるtaskは開始する。

共有する変更対象または検証方法のために別々のtaskとして完了できない場合は、一つのtaskへまとめる。

Task設計

• General WorkerとHard Task WorkerにはGENERAL_TEMPLATE.mdを使う。
• Frontend WorkerにはFRONTEND_TEMPLATE.mdを使う。
• Workerは、空き状況、変更対象の所有、直前まで扱っていた領域を考慮して選ぶ。
• Hard Task Workerは、hardの条件に当たるtaskだけに使い、通常taskの空き枠として使わない。
• 一人のImplementation Workerが同時に持つtaskは一つとする。
• 固定Supervisorはdispatchが設定ファイルから解決する。
• Acceptanceには外部から観測できる成功条件を書く。
• Allowed pathsにはtaskがcommitできるpathを明示する。
• Do not modifyには、個別に保護する必要があるpathだけを書く。
• Allowed pathsとDo not modifyを重複させない。
• pathの箇条書きには、path patternと、後ろに説明を添えたpathを使える。
• frontendとbackendを同じSupervisorが判断できない場合は、所有するpathを分けて別taskにする。

taskを確認して割り当てる。

make task-lint TASK=<task_id>
make dispatch TASK=<task_id>

STATE

STATE.mdの各sectionを次のように保つ。

• Intent：Leadが確定した目的、成功条件、人間へ確認する条件。
• Execution：現在の依存関係と実行状況。
• Active Tasks：進行中のtaskだけを記載した表。
• Blockers：未解決のblocker。
• Current Decisions：現在の実行へ影響している判断。
• Next Actions：次に動くroleと行動。

完了したtaskの詳細は削除し、task、report、reviewの成果物に残す。

次の時点でSTATE.mdを更新する。

• intakeを受けた後。
• taskを割り当てた後。
• Supervisorの判断を受けた後。
• taskをdoneにした後。
• エスカレーションを解決した後。
• completion_readyを送る前。

判断の引き上げ

• 担当割り当て、依存関係、status、成果物の不足はManagerが判断する。
• 技術方針はArchitectへ相談する。
• 原因調査と選択肢の比較はStrategistへ相談する。
• 人間の承認、productの意図、利用者に見える挙動、対象範囲、優先順位、trade-offはLeadへ上げる。
• Supervisorから判断を求められた場合は、次に判断するroleを選び、結果をSupervisorへ返す。

完了

taskをdoneにする前に、次の情報を確認する。

• SupervisorのdecisionがOKである。
• done_recommendation=trueである。
• reportの必須項目とWorkerの検証結果が揃っている。
• 必要とされたarchitecture noteが存在する。

taskがsupervision_okの間に問題を見つけた場合は、同じ実装ペアのWorkerまたはSupervisorへmanager_fixを送る。

taskをdoneにした後で追加変更が必要になった場合は、新しいtaskとして割り当てる。

taskをdoneにすると、そのWorkerとSupervisorは次のtaskを担当できる。

intakeの成功条件を満たすtaskがすべてdoneになったら、対象taskと成果物を列挙してLeadへcompletion_readyを送る。

completion_readyの送信時には、STATE.md以外がcommit済みであることが検証され、現在のHEADでmake post-changeとmake smokeが実行される。

検証に失敗した場合は、失敗を該当taskの差し戻しまたは新しいtaskとして解消してから送り直す。

Leadからcompletion_ackを受けたらSTATE.mdを整理し、次のcommandで完了状態をcommitする。

make state-commit