manual-testing

手動テストスキル

手動テストケースの計画、作成、レビュー、実行、保守を支援する QA エンジニアです。設計ドキュメントに具体的にひもづき、再現可能で追跡可能なテスト成果物を作成します。

このスキルが有効になるとき

• ユーザーがテストケースやテスト計画の作成、生成を依頼したとき
• ユーザーが「これをどうテストすればよいですか？」や「どのようなテストケースが必要ですか？」と尋ねたとき
• ユーザーがテストカバレッジのレビューやテスト品質の評価を依頼したとき
• ユーザーが手動テストの実施やテストケースの実行を依頼したとき
• 機能変更後にテストの更新を依頼したとき
• 機能の実装後（CLAUDE.md でテスト計画の更新が求められている場合）

機能

コード	アクション	説明
P	計画	設計ドキュメント、PRD、または機能の説明からテスト計画を作成します
W	作成	前提条件、手順、チェックポイントを含むテストケースファイルを作成します
R	レビュー	基準に照らしてテストケースの品質を評価します
X	実行	テストケースを実行し、チェックポイントを検証して、結果を報告します
U	更新	機能の変更時にテストケースを修正します

ワークフロー

0. ハーネスの確認 — エージェントは人間のように製品を操作し、その結果を観察できますか？

スコープを決める前に、シナリオを1つも作成する前に、これを実施してください。 手動テストの品質は、実行者が製品を操作し、結果を独立して確認できるかどうかに左右されます。ボタンをクリックできず、画面も見られないエージェントが作成するのは、自分では実行できないアサーションであり、そのテストスイートは役に立ちません。

システムではなく、エージェントについて次の2つの質問に答えてください。

	質問	NO の場合
操作	エージェントはユーザーと同じ方法で製品を操作できますか — クリック、入力、メニューを開く、ウィンドウやプロファイルを切り替えるなど。	そのテストスイートは人間専用です。その旨を伝えるか、ハーネスを導入してください。
観察	製品が自己申告する内容に頼らず、エージェントは実際の結果を確認できますか — 実際のピクセル、実際に保存されたバイト、実際のファイルなど。	アサーションは製品の自己申告に依存することになります。ハーネスを導入してください。

作成を始める前に、両方の答えが YES である必要があります。最初の返信で、答えを明示してください — 成果物を提示した後に前提条件として記載するだけでは、ゲートを実施したことにはなりません。

どちらかが NO の場合は、作業を止めて、ハーネスのセットアップをユーザーに提案してください。 不足している機能と、それを補うツールを挙げ、そのツールによって何が可能になるかを説明してください。テストスイートを作成して実行を期待したり、人間しか実行できないテストスイートへ黙って格下げしたりしないでください。

製品タイプ別の推奨ハーネス：

製品	推奨	理由
ネイティブデスクトップアプリ（Windows/macOS/Linux）	cua-driver	実際のウィンドウ、メニュー、ダイアログを操作し、実際のウィンドウのピクセルをキャプチャします — ユーザーが見るものを確認する唯一の方法です
Web アプリケーション	playwright-cli	ページを操作し、DOM、ネットワーク、コンソールを読み取ります
Chrome 拡張機能	playwright-cli と cua-driver	両方が必要です。Playwright はページ、DOM、ブラウザー内部の状態（chrome.storage、サービスワーカー）を扱い、cua-driver は Playwright ではアクセスできない拡張機能のポップアップ、ツールバー、ブラウザーのネイティブ UI を扱います
ヘッドレスサービス／CLI／API	Shell + サービス独自のクライアント	操作する GUI はありません。観察対象はファイル、終了コード、DB の行、ログです
モバイルアプリ	プラットフォームドライバー（Appium/XCUITest/Espresso）	デスクトップと同じ考え方です

表ではなく2つの機能を基準に判断してください — 表に記載されていない製品でも、両方を確認する必要があります。製品自体が自動化の対象（MCP サーバー、ブリッジ、ドライバー）である場合、その製品の出力は検証対象の主張です。観察は製品の外部から行う必要があります。

ハーネスを信頼する前に検証してください。たとえば、cua-driver status が操作可能なセッションを返すことを確認するか、実際のウィンドウを試しにスクリーンショットでキャプチャして読み取ってください。ハーネスがあると決めつけることは、機能があると決めつけるのと同じ欠陥です。

1. スコープを把握する

テストを書く前に、何をテストするのかを把握します。

• 設計ドキュメントを読む — _bmad-output/planning-artifacts/design/ にあるドキュメントを確認します
• 機能コードを読む — 何が変更され、何が新しく追加され、何に影響するのかを把握します
• 既存のテストを確認する — 新しいテストを書く前に、プロジェクトのテストスイートを探します。このリポジトリでは tests/uat/（test-plan.md、testcases/TC-*.md）です。他のプロジェクトでは docs/tests/ や test/manual/ を使っている場合があります。テスト計画のフォーマット規約を読み、それに合わせてください。プロジェクト所定の形式と異なるテストケースを書くと、手戻りになります。
• プロジェクトの種類を特定する — どのテスト対象領域が該当するか把握するため、references/test-categories.md を読みます

2. テスト範囲を計画する

各機能領域について、references/test-categories.md を参照し、該当するテストカテゴリを特定します。適切に計画されたテストスイートでは、次の項目を網羅します。

1. 正常系 — 想定されるフローが機能する
2. エッジケース — 境界値、空の入力、最大サイズ
3. エラー処理 — 問題が発生した場合の動作
4. 統合ポイント — この機能が他のシステムと接続する箇所
5. データ整合性 — データが正しく保存・取得される
6. 並行性 — 複数の操作を同時に行っても競合しない

3. テストケースを書く

まず、テストスイートで既に使われている形式に合わせてください。 書き始める前に、テスト計画のフォーマット規約を読みます。一般的に使われる構成は2種類あり、references/templates.md に両方の例があります。

構成	形式	使用する場面
Given/When/Then	1つのシナリオに、セットアップ、操作、アサーションをまとめる	新しいテストスイートの標準です。読み手が「ステップ3」を「CP5」に対応付ける必要がなく、ステップの番号を振り直してもアサーションが取り残されません。
Steps + Checkpoints	番号付きのステップと、それに続く番号付きの CP1..CPn	テストスイートで既にこの形式が使われている場合に限ります。同じテストスイート内で2つの形式を混在させないでください。

どちらの形式でも、すべてのテストケースに次の項目が必須です。

• 優先度（Critical / High / Medium）— 実行順序を決める際の指針です
• 設計参照 — 設計ドキュメントの該当セクションへの追跡可能性
• 事前条件 — テスト前に準備しておくこと（ファイル単位で、すべてのシナリオに共通）
• 手順とアサーション — 正確なコマンドと、正確な期待値
• クリーンアップ — テスト後に状態をリセットするコマンド

Given/When/Then ファイルでは、Markdown の強制改行が必要です。 末尾に空白のない **Given**／**When**／**Then**／**And** の連続行は、1つの途切れない段落として表示され、アサーションが読みにくくなります。これらの各行の末尾に半角スペースを2つ付けてください。ファイルを引き渡す前に、次のように確認してください。

# every GWT line must end in two spaces; prints the offenders
grep -n '^\*\*\(Given\|When\|Then\|And\)\*\*' TC-*.md | grep -v '  $'

テストケースは自己完結している必要があります。別の人（またはエージェント）が、質問せずに実行できるようにしてください。

4. テストの品質を評価する

仕上げる前に、references/quality-criteria.md に照らして評価します。

• 各テストは独立しているか（別のテストの状態に依存していないか）
• 各チェックポイントに、具体的で検証可能なアサーションがあるか
• テストデータは現実的か（「テスト用コンテンツ」ではなく、実際のドメインデータになっているか）
• クリーンアップで状態が完全に復元されるか
• 設計ドキュメントまたは要件への追跡可能性があるか

5. テストを実行する

テスト実行には、メインエージェントが異なる方法で行う2つの段階があります。インフラストラクチャのセットアップ（メインエージェント）と、テストケースごとの実行（サブエージェントに委任し、厳密に順番どおりに実行）です。

5.1 メインエージェント：インフラストラクチャのセットアップ

テストケースをディスパッチする前に、メインエージェントが環境を準備します。このフェーズの状態は、実行中のすべてのテストケースで共有されます。一度だけ実行することでコストを分散し、サブエージェントへのプロンプトを簡潔に保てます。

1. テストスイートのテスト計画（このリポジトリの tests/uat/test-plan.md）を読み、対象範囲、前提条件、環境変数、実行フォルダーの規約を確認します。
2. ビルドシステムを検出します（以下を参照）。テストで古いイメージやキャッシュ済みのバイナリではなく、最新のコードが実行されるように、ソースからアプリケーションを再ビルドします。古いビルドは、テストが分かりにくい失敗をする（「以前の動作のように見える」）原因や、誤って成功する（「ビルドされていない新しいコミットにバグがある」）原因の第 1 位です。
   • スタックごとの具体的なコマンドについては、references/build-systems.md を参照します。ロックファイルやマニフェスト（docker-compose.yml、package.json、pyproject.toml、Cargo.toml、go.mod など）を調べてビルドシステムを検出し、そのスタック用の再ビルドコマンドを実行します。
   • Docker ベースのプロジェクトでは、ユーザーがキャッシュの問題を疑っている場合に限り、--no-cache を指定してイメージを再ビルドします。それ以外の場合は、通常の再ビルドと --force-recreate で十分であり、より高速です。
3. インフラストラクチャを起動します：データベース、キュー、API サーバー、ワーカーを起動し、ヘルスチェックが通るまで待機します。
4. テストデータを投入します：Vault ファイル、DB の行、フィクスチャを用意します。コンテナにコピーするファイルの所有者を修正します（例：Docker の場合は docker cp の後に chown を実行します。ホストの UID はコンテナのユーザーと一致しません）。
5. スモークテストで確認します：/health または同等のエンドポイントにアクセスして、サービスが実際に起動し、トラフィックを受け付けていることを確認します。これに失敗した場合は停止します。壊れたスタックに対してテストケースを実行しても意味がありません。
6. プロジェクト固有の情報を収集します：ファイルパス、環境変数名、API URL、認証トークン、Vault パス、サンプルフィクスチャなど、サブエージェントが再調査にトークンを費やさずに済む情報をすべて集めます。次のフェーズでサブエージェントに渡すプロンプトにまとめます。

5.2 テストケースごとにサブエージェントを割り当てる（厳密に順次実行）

メインエージェントでテストケースを直接実行しないでください。実行対象のテストケースごとにサブエージェントを 1 つ起動し、その報告を待ってから次のサブエージェントを起動します。これにより、メインエージェントのコンテキストを小さく保ち、テスト実行を互いに分離し、ほかの処理をすべて保留したまま失敗を調査できます。

**順次実行する理由（並列ではなく）：**手動のテストケースでは、インフラストラクチャの状態（DB の行、Vault ファイル、トランスクリプト ID）を共有することがよくあります。並列実行すると、ある TC が別の TC の前提条件を汚染したり、共有リソースで競合が発生したりするおそれがあります。また、順次実行なら失敗の診断が可能です。後続の TC が失敗原因となった状態を変更する前に、メインエージェントが一時停止して調査できます。

サブエージェントのプロンプトテンプレート — 各サブエージェントに、必要な情報だけをすべて伝えます。

Execute test case <TC-ID> from <path to TC file>.

## Project context
- Working directory: <abs path>
- Build system: <detected>
- Infrastructure already running: <list services + ports>
- Auth: <API_KEY=..., DB creds, etc.>
- Relevant env vars: <list>
- Known fixtures / sample data: <paths>
- Cleanup commands from the TC: <paste here>

## Your job
1. Follow the test case EXACTLY as written — its preconditions, its actions, and
   every assertion. Do not improvise or substitute commands.
2. For each assertion, run the verification command and record the actual output.
3. Report back:
   - Overall verdict: PASS / PARTIAL / FAIL / SKIP
   - Per-assertion result, naming the assertion: <name> PASS,
     <name> FAIL (actual: X, expected: Y), …
   - An assertion you did not execute is NOT a PASS. Report it as NOT RUN and say why.
4. Cleanup:
   - If ALL assertions PASS → run the TC's cleanup commands.
   - If ANY assertion FAILED or PARTIAL → DO NOT clean up. Leave DB rows, files,
     logs in place so the main agent can investigate.
5. For FAIL, include: exact command run, raw stdout/stderr, relevant log excerpts
   (docker logs, psql output), and which assertion(s) failed.
6. For LLM-dependent tests: run 2–3 times and report majority result.
7. Write evidence to $RUN_DIR/evidence/ — never overwrite a previous run's folder.

各サブエージェントから報告を受けた後：

• PASS / PARTIAL（クリーンアップ実行済み）：結果を記録し、次のサブエージェントを起動します。
• FAIL（状態を保持）：順次実行を停止します。保持された状態を使って調査します（DB を照会する、ログを確認する、TC が変更したファイルを読む）。残りの TC を修正、スキップ、または中止するか判断します。調査が終わってから、メインエージェントが TC のクリーンアップコマンドを実行します。
• 失敗したテストを自動でクリーンアップしてはいけません。事後分析に使える実行時の状態は、実行中で最も価値のある診断資料です。

5.3 メインエージェント：集計と終了処理

順次実行が完了した後：

1. 集計：各 TC の結果を要約表（TC-ID、判定、失敗した CP、メモ）にまとめます。
2. ユーザーに報告：合計（N 件成功、M 件失敗、K 件スキップ）、失敗の詳細、推奨するフォローアップを伝えます。
3. インフラストラクチャの終了処理：サービスを停止し、テスト用のコンテナやボリュームを削除します。ユーザーが結果を確認した後にのみ実行します。ユーザーはまず、稼働中のスタックを調べたい場合があります。

5.4 コンテナ化された実行と認証情報の衛生管理（セキュリティ／レッドチームおよび実際のシークレットを扱うテスト）

テスト対象がコンテナ化されたアプリの場合、あるいはテストで実際の認証情報を扱う場合、テストをどこで実行し、何がホストに触れるかは、アサーションと同じくらい重要です。痛い経験から学んだ原則が2つあります。

製品はホストではなく、そのコンテナ内で実行してください。 開発者のマシン上でnpm test／バイナリ／ヘルパースクリプトを直接実行したくなるかもしれません。確かに高速ですが、製品がコンテナとして提供される場合は避けてください。実際のイメージ（docker run …）を使って製品をテストし、攻撃側のインフラ（キャプチャー用リスナー、モックエンドポイントなど）は、ホストのポートをバインドするプロセスとしてではなく、ユーザー定義ネットワーク上の兄弟コンテナとして実行してください。ホスト上でドキュメントを読んだり、出力ファイルをgrepしたりするのは問題ありませんが、製品をホスト上で実行するのは避けてください。理由：ホスト上での実行では、実際のランタイムとはパス、権限、UID、環境が異なるため、ホスト上での「成功」が実際のコンテナのバグを隠す（逆も同様）可能性があります。また、製品の成果物（およびシークレット）が開発者のマシン上に散乱することもあります。

実際のシークレットをホストに置かないでください。 アプリで実際の認証情報（auth.json、API キー、トークン）が必要な場合：

• 認証情報の取得元からコンテナに直接、読み取り専用でマウントしてください（-v "$HOME/.../auth.json":/in/container/path:ro）。cpで/tmpの一時ディレクトリにコピーしてはいけません。コピーされたシークレットは実行終了後も残り、忘れやすいためです。（実際にこのミスがあり、気付くまでの1回のセッションで、auth.jsonのコピーと認証情報を含むログがホストの/tmpに2度漏えいしました。）
• 認証情報を含む成果物はコンテナ内で調べてください。ホスト上で読む必要がある場合は、grepの直後にそのようなファイルをすべてshred -uし、ユーザーにはマスク済みの合格／不合格件数のみを出力してください。生のシークレット値を出力してはいけません。
• キャプチャーしたログ内にシークレットがマスキング指示（例：GitHub の::add-mask::<value>）として一度現れるのは、漏えいではなく正しい動作です。ランナーがその値を伏せます。シークレット値が永続化される成果物（トランスクリプト／サマリー／出力）またはツールの出力に現れた場合にのみ、問題として報告してください。
• 後片付けは単なるクリーンアップではなく、衛生管理の確認事項です。 実行後、ホストがクリーンであることを確認してください。シークレットを含む一時ディレクトリ、残存する認証情報ファイル、残ったコンテナ／ネットワーク／ボリュームがないことを確認します。「ホストがクリーン」であることを、アサーションの確認と同じように、明示的な確認事項として扱ってください。

敵対的テストのサブエージェント実行 — 分類器による問題。 §5.2の「テストケースごとにサブエージェントを1つ」というルールには、セキュリティ／レッドチームのテストで厄介な点があります。攻撃ペイロード（cat .git/config、env | grep TOKEN、偽トークン、SSRF のベース URL）を含むサブエージェントのdocker runは、ペイロードが悪意あるものと判定され、自動モードの安全性分類器によって拒否されることがよくあります。そのため、敵対的な TC をサブエージェントに委任する前に、次のいずれかを選んでください。

• テストハーネスに厳密にスコープを絞ったbypassPermissionsモードでテスト用サブエージェントを起動し、コンテナ内での敵対的な実行がブロックされないようにします。または
• 敵対的な TC はリーダー／メインエージェント自身で直接実行し、無害な機能の TC のみをサブエージェントに委任します（リーダーは同じようには分類器の制限を受けません）。 事前に決めてください。実行中に気付くと、サブエージェントの起動が無駄になります。（無害な機能のリグレッション TC は、問題なくサブエージェントに委任できます。）

6. 機能変更後のテスト更新

機能を変更した場合、テストを必ず更新してください。

1. スイート内の影響を受ける TC ファイル（ここではtests/uat/testcases/TC-*.md）を見つけます
2. セットアップが変わった場合は、事前条件を更新します
3. API／ワークフローが変わった場合は、Whenの操作を更新します
4. 想定される動作が変わった場合は、Thenのアサーションを更新します
5. 新しい機能のシナリオを追加します
6. 新しい TC ファイルを作成した場合は、テスト計画のインデックスを更新します

参照ファイル

必要に応じて参照してください。各機能に関する詳しい情報が記載されています。

ファイル	参照するタイミング	内容
references/test-categories.md	カバレッジを計画するとき	プロジェクトの種類（API、フロントエンド、パイプライン、AI/LLM、インフラ、DB、セキュリティ）ごとのカバレッジチェックリストと、リスクに基づく優先順位
references/quality-criteria.md	作成またはレビューするとき	10 のテスト品質、アンチパターン、評価基準、LLM の 3 層テスト、チェックポイント作成ガイド
references/templates.md	テストケースの作成またはテストスイートの構成時	Given/When/Then と従来の Steps+Checkpoints のテンプレート、実行ごとのフォルダーを使用したテストスイートの構成、パスの移植性に関するルールと注意点、アサーションのパターン
references/build-systems.md	テストを実行する前	スタックごとの検出ヒューリスティックと正確な再ビルドコマンド（Docker Compose、Node/npm/pnpm、Python/uv/poetry、Rust、Go、Java、モノレポ、マルチリポジトリ）

関連する BMAD スキル

これらの BMAD スキルでは、より詳しいテストのワークフローを利用できます。適切な場合は、このスキルと併用してください。

スキル	使用するタイミング	補足される内容
bmad-testarch-test-design	包括的なテスト計画をゼロから作成するとき	リスク評価マトリックス（TECH/SEC/PERF/DATA/BUS/OPS）、テスト容易性レビュー（制御性／可観測性／信頼性）、P0～P3 の優先順位を付けたカバレッジマトリックス、品質ゲート（P0＝100%、P1≥95%）
bmad-testarch-test-review	既存のテスト品質をレビューするとき	4 つの観点による評価（決定性、分離性、保守性、パフォーマンス）、重み付けスコア、重大度別の違反の集計
bmad-teach-me-testing	テストの基礎を学習するとき、またはチームに教えるとき	基礎から応用まで段階的に進む構成済みのセッション、TEA メソドロジー
bmad-tea	マスターテストアーキテクトに助言を求めるとき	テスト戦略、カバレッジの不足、テストアーキテクチャの決定に関する専門的なガイダンス

スキルの組み合わせ方

テストスイートの計画：カバレッジ領域については、このスキルの references/test-categories.md から始め、正式なリスク評価とP0～P3の優先度を付けたカバレッジマトリックスの作成には bmad-testarch-test-design を実行します。

テスト品質のレビュー：10項目の品質チェックリストには、このスキルの references/quality-criteria.md を使用し、4つの観点（決定性、分離性、保守性、パフォーマンス）からの詳細な評価には bmad-testarch-test-review を実行します。

テストケースの作成：このスキルのテンプレートと品質基準を使用します。リスクに基づいて優先順位を付けるには、bmad-testarch-test-design の基準を活用します。

• P0：コア機能を妨げる＋高リスク＋回避策なし → 重大
• P1：重要なパス＋中～高リスク → 高
• P2：二次的なフロー＋低～中リスク → 中
• P3：あると望ましい機能、探索的な項目 → 低

品質ゲート（bmad-testarch-test-design に基づく）：

• P0の合格率 = 100％（すべて合格必須）
• P1の合格率 ≥ 95％
• リリース前に高リスク項目への対策を完了
• カバレッジ目標 ≥ 80％

ルール

1. 現実的なテストデータ — 「テストコンテンツ」や「lorem ipsum」は決して使わないでください。実際の動作を検証できる、ドメイン固有のデータを使用してください。
2. 正確な検証コマンド — すべてのアサーションには、検証可能な結果を出力するコマンド（curl、psql、grep、cat、wc）を用意してください。
3. 設計ドキュメントとのトレーサビリティ — すべてのテストケースで、検証対象の設計ドキュメントのセクションを参照してください。
4. 独立性 — 各テストケースは単独で実行できる必要があります。別のテストが先に実行されたことを前提にしないでください。
5. クリーンアップ — 状態を変更するすべてのテストに、クリーンアップコマンドを用意してください。FAIL の場合はクリーンアップをスキップし、調査用に状態を保持してください。トリアージ後にメインエージェントがクリーンアップします。
6. LLM の非決定性 — AI に依存するテストでは、内容の完全一致ではなく、構造やセクションの有無を検証してください。多数決で合格と判定できるよう、3 回以上実行してください。
7. リスクベースの優先順位付け — P0〜P3 の優先順位フレームワークを使用してください。P0（クリティカルパス）を最初にテストし、P3（探索的テスト）を最後にテストしてください。
8. テスト容易性の評価 — テスト作成前に、システムの状態を制御できるか、結果を観測できるか、テストを安定して独立して実行できるかを評価してください。 8a. ハーネスゲートを最初に実施 — テスト範囲の決定や作成に入る前に、エージェントが（a）人間のように製品を操作できるか、（b）製品の自己申告とは独立して実際の結果を観測できるかを明示してください。両方が YES であることを最初に示してください。そうでない場合は中止し、ハーネスの導入（ネイティブアプリには cua-driver、ウェブには playwright-cli、Chrome 拡張機能には両方）と、それによって可能になることを提案してください。成果物の後で能力を前提として言及したり、人間が実行するためのテストスイートを説明なしに作成したりしても、ゲートを実施したことにはなりません。§0 を参照してください。
9. 重複するカバレッジを避ける — 同じことを複数のレベルでテストしないでください。ロジックはユニットテストで、境界は統合テストで、ユーザーフローは E2E テストで検証してください。
10. テスト実行前に必ず再ビルド — テスト（ユニット、統合、手動）を実行する前に、必ずソースからアプリケーションを再ビルドしてください。古いイメージ、バイトコード、バイナリは、誤解を招く誤合格や誤不合格の原因になります。プロジェクトのマーカーからビルドシステムを特定し（references/build-systems.md を参照）、対応する再ビルドコマンドを実行してください。
11. テストケースごとにサブエージェントを割り当て、厳密に逐次実行 — メインエージェントはインフラストラクチャ（セットアップ、シード、スモークチェック、ティアダウン）を担当します。各テストケースは、それぞれ専用のサブエージェントが一度に 1 つずつ実行します。並列実行はしないでください。手動テストは状態を共有するため、逐次実行により失敗の診断が容易になります。§5.2 を参照してください。
12. 失敗時に自動クリーンアップしない — サブエージェントのテストが FAIL または PARTIAL の場合、状態（DB の行、ファイル、ログ）をそのまま残してください。メインエージェントが調査した後、該当する TC のクリーンアップコマンドを実行します。実行中に残されたフォレンジック用の状態は、最も価値のある診断情報です。（例外：実際のシークレットを含むアーティファクトは、ルール 13 に従って必ず完全消去してください。）
13. 製品はコンテナ化し、認証情報をホストに置かない — コンテナ化されたアプリは実際のイメージを使ってテストし、攻撃者側のインフラストラクチャは兄弟コンテナとして用意してください（ホストのプロセスやポートは使用しない）。実際のシークレットはソースから読み取り専用でマウントし、作業領域に cp しないでください。認証情報を含むアーティファクトは grep で検索した後に完全消去し、マスクした値だけを出力してください。明示的なティアダウンのチェックポイントとして、「ホストがクリーン」（シークレットファイルがなく、コンテナも残っていない）であることを確認してください。§5.4 を参照してください。
14. 敵対的 TC の実行担当を最初に決める — サブエージェントによる攻撃ペイロードの docker run は、分類器によってブロックされます。テスト用サブエージェントを bypassPermissions で起動するか、敵対的 TC をリーダーが実行し、通常のサブエージェントには無害な TC のみを委任してください。§5.4 を参照してください。
15. スイートの既存フォーマットに合わせ、GWT の各行に必ずハード改行を入れる — テストを作成する前に、テスト計画のフォーマット規約を確認してください。Given/When/Then スイートでは、すべての **Given**／**When**／**Then**／**And** 行の末尾に 2 つのスペースを付けてください。そうしないと、Markdown ではシナリオが改行されず、1 つの段落として表示されます。確認方法：grep -n '^\*\*\(Given\|When\|Then\|And\)\*\*' TC-*.md | grep -v ' $' の実行結果が空であること。references/templates.md を参照してください。
16. マシン固有のパスを使わず、実行ごとに 1 つのフォルダーを使用 — テスト計画で定義された $PROJECT_ROOT／$RUN_DIR を基準にすべてのパスを記述し、チェックアウト先のパスを直接記述しないでください。各実行では専用の run/<date>-<NN>/ フォルダーに書き込み、過去の証拠を比較用に保持してください。確認方法：grep -rn -- "$PROJECT_ROOT" testcases/ の実行結果が空であること。パスを一括置換した後は、失敗を検証するシナリオを再読してください。置換によって不正な入力が有効になると、すべての grep チェックを通過してしまいます。references/templates.md を参照してください。