tc-run

スキル：tc-run — 完全なテストケースファイルからバッチごとのレポートまで

2026/09/15のPayroll SITセッション（335 TC、7シート）から抽出。決定論的なツール：harness/scripts/tc-xlsx.py （extract・classify・plan・report）。バッチの実行環境：/orca-graph。ブラウザー：ログイン済みのユーザーセッション（SSO）上のclaude-in-chrome。 レポート：MCP tester-kit → tao_report_test。

WHAT

目的とコンテキスト

• 目的： 完全なテストケースの.xlsxファイル1つから、各TCの画像付きPASS/FAIL/BLOCK結果と、バッチごとのtester-kitレポート.xlsxを作成します。
• 使用するタイミング： ユーザーがテストケースの.xlsxファイル（SIT/UAT/回帰テスト）を提示し、「実行して確認」「小さく分割」「レポートを出力」したい場合に使用します。
• 対象外： 新しいテストケースの作成には使用しません（その場合は/uat-nonit-testcaseを使用します）。コードの単体テストにも使用しません。

メンタルモデル

xlsx → tcs.json（extract）→ ui|calc|perf|security|gapラベル（classify）→ バッチごとのPLAN → orca-graph（t1でHITLログイン → バッチを並列実行 → レポート）→ results/<lô>.json + shots/<id>.png → report-<lô>.xlsx → summary.md。

入力と出力の契約

	フィールド	必須？	意味
In	テストケース.xlsxファイル	はい	複数のシート、Test Case ID/Description/Steps/Expected/Priority/Type列
In	アプリのURL + ログイン済みセッション	はい	ユーザーがclaude-in-chromeのタブで自分でログインします（HITL）
In	calcの入力データ	いいえ	ユーザーが用意するペルソナ/給与期間データ。ない場合、calc TCは実行しません
Out	tcs.json + シートごとの分類表	はい	ui/calc/perf/security/gapの件数
Out	PLAN.md + graph	はい	1バッチあたり≤ 8 TC、graphは≤ 20 node
Out	results/<lô>.json + shots/<id>.png	はい	各TCのPASS/FAIL/BLOCK + 実際の結果 + 証跡
Out	report-<lô>.xlsx + summary.md	はい	バッチごとのtester-kitレポート。バッチごとに集計

ルールと機能

• RULE-01（必須）：各TCの結果には実際の画像 + 観測可能な実際の結果が必要です。画像がない場合、PASSにしてはいけません。
• RULE-02（必須）：calcはユーザーが用意した入力データ（ペルソナ/給与期間）がある場合にのみ実行します。数値を捏造してはいけません。
• RULE-03（必須）：securityとperfはsummaryに「自動化の対象外」と明記し、黙って省略してはいけません。
• RULE-04（必須）：画像とコンテキストが膨らまないよう、1バッチあたり≤ 8 TCにします。graphは≤ 20 node（orca-graphの上限）です。→ uiが約150 TCを超えるファイルは、PLANを複数に分けます（親graph → 子）。
• RULE-05（必須）：tester-kitのスキーマに準拠したレポートにします。priorityはHigh/Medium/Low（P0、P1→High、P2→Medium、P3→Low）、descriptionにはSTEPS/EXPECTED/ACTUAL/STATUSを含めます。
• 機能：xlsxの読み込みと決定論的な分類、ユーザーのログイン済みセッションでのブラウザー操作、結果ファイル/画像のローカル保存、レポート出力サービスの呼び出し。

失敗時の境界

• ログイン/SSOページが表示された場合 → blocked。ユーザーが同じタブでログインするまで待ちます。パスワードを入力したり、ユーザーに代わってSSOを操作したりしてはいけません。
• 実データに対する保存/削除/更新が必要な手順 → ユーザーが明示的に許可しない限り、そのTCはBLOCKとして「専用のSIT環境が必要」と記録します。
• calc TCの入力データが不足している場合、またはgapのstepsが空の場合は実行せず、summaryに記載します（partial）。
• 画像を撮影できない場合、そのTCをPASSにしてはいけません。

HOW

メインワークフロー

ステップ	種類	入力	アクション	出力／終了条件	失敗時／次の処理
W01	決定論的	ファイル .xlsx	抽出＋分類（tc-xlsx.py extract の後に classify）を行い、シートごとの表を報告する	tcs.json ＋ 表	ヒューリスティックの誤判定 → auto ラベルを修正し、どの TC を修正したか明記する
W02	決定論的	tcs.json	バッチごとに PLAN を生成してからグラフを構築する（orca-graph.py build --strict）	PLAN ＋ グラフ	build エラー → PLAN を修正して繰り返す
W03	効果あり	アプリの URL	HITL でログインセッションを確立し、app.json に記録 → set t1 done_user_reported	ログイン済み	ログイン／SSO が表示されたら → 停止してユーザーに依頼する
W04	効果あり	バッチ	各バッチを実行する：lock → dispatched → 作業 → set done、スクリーンショットを撮り、Expected と照合する	results/<lô>.json	実データを書き込む場合 → 該当 TC を BLOCK にする
W05	効果あり	results	tao_report_test ＋ summary.md で各バッチのレポートを作成する	report-<lô>.xlsx、summary	—
W06	決定論的	グラフ	cockpit で進捗を追跡し、orca-graph などのモデルの回答を audit する	進捗	—

各ステップの詳細（W01～W06 の信頼できる情報源）：

1. 抽出＋分類（0 トークン）：

   python3 harness/scripts/tc-xlsx.py extract <file.xlsx> -o scratchpad/<tên>/tcs.json
   python3 harness/scripts/tc-xlsx.py classify scratchpad/<tên>/tcs.json
   

   シートごとの表をユーザーに報告します：ui（ブラウザーで実行可能）、calc（入力データが必要で、数値を確認）、perf、security（SSO／ログイン。安全に自動化できない）、gap（steps が空、または業務上の確認待ち）がそれぞれ何件あるかを示します。ヒューリスティックが誤っている場合は、tcs.json の auto ラベルを修正し、どの TC を修正したか明記します。
2. バッチごとに PLAN を生成してからグラフを構築：

   python3 harness/scripts/tc-xlsx.py plan tcs.json --app "<tên app (URL)>" --batch 8 --only ui -o llmwiki/wiki/sources/draft/DDMMYY-<tên>-PLAN.md
   python3 harness/scripts/orca-graph.py build <PLAN> --strict && orca-graph.py ask <id> parallel
   

   Task 1 は常に hitl（アプリの調査＋ログインセッション）とします。バッチは並行して実行し、最後の task でレポートを出力します。各バッチは、verify が TC 数分の results ファイルである 1 つのノードとします。
3. ログインセッション — HITL。先へ進んではいけません： claude-in-chrome のタブで URL を開きます。ログイン／SSO ページが表示されたら、停止し、そのタブ内でユーザー自身にログインボタンを押してもらいます。パスワードを入力したり、ユーザーの代わりに SSO ボタンを押したりしてはいけません。ログイン後、app.json に記録します（logged_in: true、実際のメニュー）→ set t1 done_user_reported。
4. 各バッチを実行（lock → dispatched → 作業 → set done）：各 TC について Test Steps に従い、find／computer／read_page を使い、shots/<id>.png にスクリーンショットを撮り、Expected と照合します → PASS|FAIL|BLOCK ＋ actual ＋ evidence。実データに対する保存／削除／更新を行う前に必ず停止し、「別途 SIT 環境が必要」として BLOCK にします。ユーザーから明確な許可がある場合を除きます。results/<lô>.json に記録します。
5. 各バッチのレポートを作成： tc-xlsx.py report results/<lô>.json --tcs tcs.json --url <URL> → payload → MCP tao_report_test を呼び出す → xlsx を report-<lô>.xlsx にコピーします。最後に summary.md を作成し、バッチごとの PASS／FAIL／BLOCK、ユーザー対応が必要な TC、残りの calc／perf／security TC を記載します。
6. cockpit（control-room.html）で進捗を追跡します。orca-graph などのモデルの回答を audit します。

分岐

ID	種類	条件	動作	スキップ／失敗	合流先
B01	リカバリー	ヒューリスティックによる分類で誤ったラベルが付いた	tcs.json の auto ラベルを修正し、どの TC を修正したか明記する	—	W02
B02	条件付き必須	ファイルに ui TC が約 150 件を超えて含まれる（20 ノード超）	PLAN を複数に分割する（親グラフ → 子グラフ）	—	W03
B03	ユーザー任意	ユーザーが実データへの書き込みを明確に許可している	保存／削除／更新のステップも実行する	許可がない → 「別途 SIT 環境が必要」として BLOCK にする	W04
B04	条件付き必須	calc TC があり、ユーザーが persona／給与期間を用意済み	calc TC を実行し、数値を確認する	データが不足 → 実行せず、summary に記録する	W05

検証と停止条件

各バッチは、verify が TC 数分の results ファイルである 1 つのノードとします。PASS とするのは実際のスクリーンショットと actual がある場合のみです。すべてのバッチノードが done になり、各バッチのレポートが作成された時点で停止します。残りの TC（calc／perf／security／gap、BLOCK）は summary.md に列挙します。

例

• 成功例： SIT Payroll のファイルに 335 TC、7 シートが含まれている場合 → ui の部分を分類 → plan --batch 8 --only ui → ユーザーがタブ内で SSO にログイン → 各バッチに 8 TC があり、shots/<id>.png ＋ results/<lô>.json が作成される → report-<lô>.xlsx ＋ バッチごとの PASS／FAIL／BLOCK を記載した summary.md。
• 境界条件／失敗例： TC で実データの給与表の「保存」を押す必要があり、ユーザーの許可がない場合 → その TC を「別途 SIT 環境が必要」として BLOCK にし、ボタンを押しません。TC のスクリーンショットを撮れない場合 → PASS にしません。

まとめ

/tc-run = xlsx → tc-xlsx.py extract/classify → バッチごとの PLAN → orca-graph → ログイン済みセッションで実行 → results JSON + 画像 → バッチごとに tao_report_test → summary。 意外なユースケース：チームのテストケースファイルに対して classify を実行すると、誰かが完了日を約束する前に、何％がギャップ／業務待ちなのかをすぐに把握できます。