Test Team Coordination

tests/scenarios/teams/ のテストシナリオを対象チームに対して実行する。 調整パターンの動作を観察し、受け入れ基準を評価し、 採点ルーブリックをスコアリングし、tests/results/ に RESULT.md を生成する。

使用タイミング

• チームの調整パターンが期待される動作を生成するかを検証する場合
• チーム定義やエージェントを変更した後に構造化テストを実行する場合
• 同じシナリオを異なるチームで実行して調整パターンを比較する場合
• チーム構成のベースラインパフォーマンスメトリクスを確立する場合
• 新しいエージェントを追加したり、チームメンバーシップを変更した後の回帰テスト

入力

• 必須: テストシナリオファイルへのパス（例：tests/scenarios/teams/test-opaque-team-cartographers-audit.md）
• 任意: 実行IDの上書き（デフォルト：YYYY-MM-DD-<target>-NNN 自動生成）
• 任意: チームサイズの上書き（デフォルト：シナリオのフロントマターから）
• 任意: スコープ変更のスキップ（デフォルト：false — 定義されている場合はスコープ変更を注入する）

手順

ステップ1: テストシナリオの読み込みと検証

1.1. 入力で指定されたテストシナリオファイルを読み込む。

1.2. YAMLフロントマターを解析して抽出する：

• target — テスト対象のチーム
• coordination-pattern — 期待されるパターン
• team-size — スポーンするメンバー数
• 受け入れ基準テーブル
• スコアリングルーブリック（存在する場合）
• 真値データ（存在する場合）

1.3. シナリオファイルに必須セクションがすべてあるか確認する：

• Objective（目標）
• Pre-conditions（前提条件）
• Task（タスク）（Primary Taskサブセクションを含む）
• Expected Behaviors（期待される動作）
• Acceptance Criteria（受け入れ基準）
• Observation Protocol（観察プロトコル）

期待結果： シナリオファイルが読み込まれ、解析され、必須セクションがすべて含まれている。

失敗時： ファイルが見つからないか解析できない場合は、欠落しているファイルまたは不正なセクションを特定するエラーメッセージで中止する。任意のセクション（Rubric、Ground Truth、Variants）がない場合は、その不在を記録して続行する。

ステップ2: 前提条件の検証

2.1. シナリオの各前提条件チェックボックスを確認する。

2.2. ファイル存在チェックにはGlobを使用する。

2.3. レジストリカウントチェックについては、関連する _registry.yml を解析し、total_* をディスク上の実際のファイル数と比較する。

2.4. ブランチ/git状態チェックについては、git status --porcelain と git branch --show-current を実行する。

期待結果： すべての前提条件が満たされている。

失敗時： 前提条件が失敗した場合は、結果でBLOCKEDとして記録する。続行するか（ソフト前提条件）中止するか（ハード前提条件、例：対象チームファイルの欠落）を決定する。その決定を文書化する。

ステップ3: 調整パターン基準の読み込み

3.1. tests/_registry.yml を読み込み、シナリオの coordination-pattern 値に一致する coordination_patterns エントリを見つける。

3.2. このパターンの key_behaviors リストを抽出する。

3.3. これらの動作が観察チェックリストになる — 実行中に各動作が観察/未観察として記録されなければならない。

期待結果： パターンの主要な動作が読み込まれ、観察の準備ができている。

失敗時： 調整パターンがレジストリで定義されていない場合は、シナリオのExpected Behaviorsセクションを唯一の観察ソースとして使用する。警告を記録する。

ステップ4: タスクの実行

4.1. 結果ディレクトリを作成する：tests/results/YYYY-MM-DD-<target>-NNN/。

4.2. T0（タスク開始タイムスタンプ）を記録する。

4.3. シナリオのチームサイズを使用してTeamCreateで対象チームをスポーンする。シナリオのTaskセクションからPrimary Taskプロンプトをそのまま渡す。

4.4. チームの実行フェーズを観察する。以下のタイムスタンプを記録する：

• T1：フォームアセスメント/タスク分解の完了
• T2：ロールアサインメントが見える

4.5. シナリオがScope Change Triggerを定義し、skip-scope-changeがfalseの場合：

• フェーズ2（ロールアサインメント）が見えるまで待機する
• T3（スコープ変更注入タイムスタンプ）を記録する
• SendMessageでチームにスコープ変更プロンプトを送信する
• T4（スコープ変更が吸収された — ロール調整が見える）を記録する

4.6. チームがアウトプットを提供するまで観察を続ける。

• T5（統合開始）を記録する
• T6（最終レポート提供）を記録する

4.7. チームの完全なアウトプットをキャプチャする。

期待結果： チームが調整パターンのフェーズを通じてタスクを実行する。すべてのトランジションのタイムスタンプが記録される。スコープ変更（該当する場合）が注入・吸収される。

失敗時： チームがアウトプットを生成できない場合は、失敗ポイントとエラーメッセージを記録する。チームが行き詰まった場合は、最後に観察されたフェーズとタイムアウトを記録する。部分的な結果で評価に進む。

ステップ5: パターン動作の評価

5.1. ステップ3の各主要動作について、実行中に観察されたかどうかを判断する：

• 観察: チームのアウトプットまたは調整における明確な証拠
• 部分的: 一部の証拠があるが不完全または曖昧
• 未観察: 証拠なし

5.2. シナリオのExpected Behaviorsセクションから各タスク固有の動作について、同じ評価を適用する。

5.3. 観察ログに所見を記録する。

期待結果： パターン固有およびタスク固有の動作のすべてまたは大部分が観察されている。

失敗時： 未観察の動作は所見であり、テスト手順の失敗ではない。正確に記録する — それらは調整パターンが完全に現れなかったことを示す。

ステップ6: 受け入れ基準の評価

6.1. シナリオの各受け入れ基準を確認する。

6.2. 各基準について判定を割り当てる：

• PASS: 観察可能な証拠を持って基準が明確に満たされている
• PARTIAL: 基準が部分的に満たされている（0.5ウェイトでしきい値に対してカウントされる）
• FAIL: 機会があったにもかかわらず基準が満たされていない
• BLOCKED: 評価できなかった（前提条件の失敗、チームのタイムアウトなど）

6.3. シナリオにGround Truthデータが含まれる場合は、報告された所見を照合する：

• カテゴリ別の精度パーセンテージを計算する
• 偽陽性と偽陰性をフラグ立てする

6.4. シナリオにScoring Rubricが含まれる場合は、簡潔な根拠を添えて各次元を1〜5でスコアリングする。

6.5. サマリーメトリクスを計算する：

• 承認：通過した基準X/N（PARTIALは0.5としてカウント）
• しきい値：シナリオで定義されたしきい値 >= の場合PASS
• ルーブリック合計：X/Yポイント（該当する場合）

期待結果： すべての受け入れ基準が判定を持っている。サマリーメトリクスが計算されている。

失敗時： 半数以下の基準しか評価できない場合（BLOCKEDが多すぎる）は、テスト実行は不確定である。理由を文書化し、前提条件を修正した後で再実行することを推奨する。

ステップ7: RESULT.mdの生成

7.1. シナリオのObservation ProtocolのRecording Templateを使用して tests/results/YYYY-MM-DD-<target>-NNN/RESULT.md を作成する。

7.2. すべてのセクションを記入する：

• 実行メタデータ（観察者、タイムスタンプ、期間）
• 記録されたすべてのタイムスタンプを含むフェーズログ
• ロール出現ログ（adaptive/チームテストの場合）
• 受け入れ基準結果テーブル
• ルーブリックスコアテーブル（該当する場合）
• 真値検証テーブル（該当する場合）
• 主要な観察（ナラティブ）
• 教訓

7.3. チームの生のアウトプットを付録として、または同じ結果ディレクトリ内の別ファイル（team-output.md）に含める。

7.4. トップに総括的な評決を追加する：

**Verdict**: PASS | FAIL | INCONCLUSIVE
**Score**: X/N criteria (Y/Z rubric points)
**Duration**: Xm

期待結果： すべてのセクションが記入され、明確な評決を含む完全なRESULT.md。

失敗時： 結果ファイルを書き込めない場合は、フォールバックとして結果をstdoutに出力する。評価データは決して失われてはならない。

バリデーション

• テストシナリオファイルが読み込まれ、必須セクションがすべて存在する
• 前提条件が検証されている（またはBLOCKEDとして文書化されている）
• 調整パターンの主要な動作がレジストリから読み込まれている
• チームがスポーンされ、タスクが提供されている
• スコープ変更が適切なタイミングで注入されている（該当する場合）
• すべてのパターン固有の動作が評価されている（観察/部分的/未観察）
• すべての受け入れ基準が判定を持っている（PASS/PARTIAL/FAIL/BLOCKED）
• 真値検証が完了している（該当する場合）
• すべてのセクションが記入されたRESULT.mdが生成されている
• サマリー評決が計算・記録されている

よくある落とし穴

• 調整ではなくアウトプット品質を評価する: このスキルはチームがどのように調整するかをテストし、タスクアウトプットが完璧かどうかではない。うまく調整するが9つの壊れたrefのうち7つしか見つけないチームはパターンを示している。
• スコープ変更を早すぎに注入する: ロールアサインメントが明確に見えるまでスコープ変更の注入を待つこと。早すぎるとチームがまだ差別化されていないため、適応すべきものがない。
• チームメンバーのアウトプットとチームのアウトプットを混同する: opaqueチームは統一されたアウトプットを提示すべきである。個々のメンバーレポートが見える場合、それはテストインフラの問題ではなく、不透明性についての所見である。
• 真値の厳密な一致: 真値カウントは近似である。所見が正しい範囲にあるかを評価し、正確に一致するかどうかではない。
• タイムスタンプの記録を忘れる: タイムスタンプはフェーズ期間と適応速度を測定するために不可欠である。事後ではなく、イベントが発生した時に設定すること。

関連スキル

• review-codebase — チームレベルのテストを補完する深いコードベースレビュー
• review-skill-format — 個々のスキルフォーマットを検証する（このスキルはチームの調整を検証する）
• create-team — このスキルがテストするチーム定義を作成する
• evolve-team — テストの所見に基づいてチーム定義を進化させる
• test-a2a-interop — A2Aプロトコル準拠の類似したテストパターン
• assess-form — opaque チームリードが内部的に使用するmorphicアセスメント