cover

Cover：テストスイートジェネレーター

ホストに依存しないワークフローです。スキル名（cover）を指定して実行します。Claude Code のスラッシュルーティング、YAML フックローダー、.claude/chain については references/claude-code.md を参照してください。

実際のサービスとの統合テストと失敗の自動修復を行い、既存のコードに対する包括的なテストスイートを生成します。

注： disableSkillShellExecution が有効な場合（CC 2.1.91）、vitest/jest の前提条件チェックは実行されません。続行する前に、テストランナーがインストールされていることを確認してください：npx vitest --version または npx jest --version。

クイックスタート

cover authentication flow
cover --model=opus payment processing
cover --tier=unit,integration user service
cover --real-services checkout pipeline

引数の解決

代名詞で示された対象（this、them、the above）は会話から読み取り、1行で通知して使用します：Read("../../shared/rules/target-resolution.md") のインライン部分。

SCOPE = "$ARGUMENTS"  # e.g., "authentication flow"

# Flag parsing
MODEL_OVERRIDE = None
TIERS = ["unit", "integration", "e2e"]  # default: all three
REAL_SERVICES = False

for token in "$ARGUMENTS".split():
    if token.startswith("--model="):
        MODEL_OVERRIDE = token.split("=", 1)[1]
        SCOPE = SCOPE.replace(token, "").strip()
    elif token.startswith("--tier="):
        TIERS = token.split("=", 1)[1].split(",")
        SCOPE = SCOPE.replace(token, "").strip()
    elif token == "--real-services":
        REAL_SERVICES = True
        SCOPE = SCOPE.replace(token, "").strip()

---

ステップ -0.5：労力に応じたカバレッジの調整（CC 2.1.76、環境変数は 2.1.120 以降）

まず $CLAUDE_EFFORT（CC 2.1.120 以降）を読み取ります。明示的な --effort= トークンがある場合は、上書き設定として優先します。CC が 2.1.120 未満で、フラグが指定されていない場合のデフォルトは high です。パターンは assess と explore（#1540）に一致します。テスト生成の深さを調整します：

労力レベル	生成するティア	エージェント	Phase 5 を通過するための maxIterations
low	ユニットのみ	1 エージェント	2（修復 1 回 + 検証 1 回）
medium	ユニット + 統合	2 エージェント	2（修復 1 回 + 検証 1 回）
high（デフォルト）	ユニット + 統合 + E2E	3 エージェント	3（修復 2 回 + 検証 1 回）
xhigh（CC 2.1.111 以降）	ユニット + 統合 + E2E	3 エージェント	3（上限。xhigh では修復回数ではなくエージェント数が増加します）

値は Phase 5 で maxIterations として渡す数です。スクリプトは [2, 3] に制限するため（heal-loop.js）、範囲外の値はその範囲内に調整され、最終イテレーションでは必ず修復ではなく検証を行います。4 イテレーションのモードはありません。

上書き： 明示的な --tier= フラグまたはユーザーによる選択は、/effort による縮小を上書きします。

ステップ -1：MCP プローブ + 再開チェック

# Probe MCPs (parallel):
# memory is alwaysLoad in .mcp.json (CC 2.1.121+, #1541). Probe below kept as fallback for older CC:
ToolSearch(query="select:mcp__memory__search_nodes")
ToolSearch(query="select:mcp__context7__resolve-library-id")

Write(".claude/chain/capabilities.json", {
  "memory": <true if found>,
  "context7": <true if found>,
  "skill": "cover",
  "timestamp": now()
})

# Resume check:
Read(".claude/chain/state.json")
# If exists and skill == "cover": resume from current_phase
# Otherwise: initialize state

---

ステップ 0：スコープとティアの選択

AskUserQuestion(
  questions=[
    {
      "question": "What test tiers should I generate?",
      "header": "Test Tiers",
      "options": [
        {"label": "Full coverage (Recommended)", "description": "Unit + Integration (real services) + E2E"},
        {"label": "Unit + Integration", "description": "Skip E2E, focus on logic and service boundaries"},
        {"label": "Unit only", "description": "Fast isolated tests for business logic"},
        {"label": "E2E only", "description": "Playwright browser tests"}
      ],
      "multiSelect": false
    },
    {
      "question": "Healing strategy for failing tests?",
      "header": "Failure Handling",
      "options": [
        {"label": "Auto-heal (Recommended)", "description": "Fix failing tests up to 3 iterations"},
        {"label": "Generate only", "description": "Write tests, report failures, don't fix (skips the heal loop)"},
        {"label": "Strict", "description": "All tests must pass or abort"}
      ],
      "multiSelect": false
    }
  ]
)

選択に基づいて TIERS を上書きします。--tier= フラグが指定されている場合は、このステップをスキップします。

---

完了条件。 完了とは、生成されたすべてのテストが実行され、テストスイートが成功するか、残っている各失敗が heal-loop の分類とともに報告され、カバレッジレポートが作成されている状態を指します。Read("../../shared/rules/long-run-protocol.md") に従ってください。ユーザーからの入力が不要なステップは続行し、ユーザーなしでは続行できない場合、または破壊的な操作を行う前に限り、停止して確認してください。各サブエージェントの証拠を確認してから結果を受け入れ、確認できなかった項目は、どこを調べたかを添えて明記してください。

タスク管理（必須）

# 1. Create main task IMMEDIATELY
TaskCreate(subject=f"Cover: {SCOPE}", description="Generate comprehensive test suite with real-service testing", activeForm=f"Generating tests for {SCOPE}")

# 2. Create subtasks for each phase
TaskCreate(subject="Discover scope and detect frameworks", activeForm="Discovering test scope")    # id=2
TaskCreate(subject="Analyze coverage gaps", activeForm="Analyzing coverage gaps")                  # id=3
TaskCreate(subject="Generate tests (parallel per tier)", activeForm="Generating tests")            # id=4
TaskCreate(subject="Execute generated tests", activeForm="Running tests")                          # id=5
TaskCreate(subject="Heal failing tests", activeForm="Healing test failures")                       # id=6
TaskCreate(subject="Generate coverage report", activeForm="Generating report")                     # id=7

# 3. Set dependencies for sequential phases
TaskUpdate(taskId="3", addBlockedBy=["2"])  # Analysis needs discovery first
TaskUpdate(taskId="4", addBlockedBy=["3"])  # Generation needs gap map
TaskUpdate(taskId="5", addBlockedBy=["4"])  # Execution needs generated tests
TaskUpdate(taskId="6", addBlockedBy=["5"])  # Healing needs test results
TaskUpdate(taskId="7", addBlockedBy=["6"])  # Report needs healed suite

# 4. Update status as you progress
TaskUpdate(taskId="2", status="in_progress")  # When starting
TaskUpdate(taskId="2", status="completed")    # When done, repeat for each subtask

---

6 フェーズのワークフロー

フェーズ	作業	出力
1. 調査	フレームワークの検出、スコープのスキャン、未テストのコードの特定	フレームワークマップ、ファイルリスト
2. カバレッジ分析	既存テストを実行し、ティアごとにリスク対象の優先順位を決定	カバレッジのベースライン、理由を添えたリスク対象
3. 生成	ティアごとにテスト生成エージェントを並列実行し、その後に動作ゲートを実施	作成したテストファイル、ゲート判定
4. 実行	生成されたすべてのテストを実行	成功／失敗の結果
5. 修復	失敗を修正して再実行（最大 3 イテレーション）	成功したテストスイート
6. レポート	カバレッジの差分、テスト数、概要	カバレッジレポート

フェーズ間の引き継ぎ

フェーズ終了後	引き継ぎファイル	主な出力
1. 調査	01-cover-discovery.json	フレームワーク、スコープファイル、ティア計画
2. 分析	02-cover-analysis.json	カバレッジのベースライン、理由を添えたリスク対象
3. 生成	03-cover-generation.json	作成したファイル、ティアごとのテスト数、動作ゲートの判定
5. 修復	05-cover-healed.json	最終的な成功／失敗、使用したイテレーション数

---

フェーズ 1：検出

プロジェクトのテスト基盤を検出し、作業範囲を定めます。

# PARALLEL, all in ONE message:
# 1. Framework detection (hook handles this, but also scan manually)
Grep(pattern="vitest|jest|mocha|playwright|cypress", glob="package.json", output_mode="content")
Grep(pattern="pytest|unittest|hypothesis", glob="pyproject.toml", output_mode="content")
Grep(pattern="pytest|unittest|hypothesis", glob="requirements*.txt", output_mode="content")

# 2. Real-service infrastructure
Glob(pattern="**/docker-compose*.yml")
Glob(pattern="**/testcontainers*")
Grep(pattern="testcontainers", glob="**/package.json", output_mode="content")
Grep(pattern="testcontainers", glob="**/requirements*.txt", output_mode="content")

# 3. Existing test structure
Glob(pattern="**/tests/**/*.test.*")
Glob(pattern="**/tests/**/*.spec.*")
Glob(pattern="**/__tests__/**/*")
Glob(pattern="**/test_*.py")

# 4. Scope files (what to test)
# If SCOPE specified, find matching source files
Grep(pattern=SCOPE, output_mode="files_with_matches")

実サービスを使用するかどうかの判断：

• docker-compose*.yml が見つかった場合 → 統合テストでは実サービスを使用します
• 依存関係に testcontainers がある場合 → 分離されたサービスインスタンスに testcontainers を使用します
• どちらも見つからず、--real-services フラグが指定されている場合 → エラー：「No docker-compose or testcontainers found. Install testcontainers or remove --real-services flag.」
• どちらも見つからず、フラグも指定されていない場合 → 統合テストではモック（MSW/VCR）を使用します

実サービス検出の詳細を読み込みます：Read("references/real-service-detection.md")

フェーズ 2：カバレッジ分析とリスク対象の選定

既存のテストを実行してベースラインを取得し、リスクに基づいて対象を選定します。カバレッジはレポート用の情報であり、決して目標ではありません。

# Baseline: npx vitest run --coverage --reporter=json | pytest --cov=<scope> --cov-report=json | go test -coverprofile=coverage.out ./...
# Rank uncovered code by risk and record WHY each target was chosen:
# changed code, complex branches, error paths, security and money paths, past bugs
# gap_map[tier] = [{"target": "src/billing/refund.ts:roundRefund", "why": "money path, fixed in #812"}]

ベースラインと、リスク順に並べた対象およびそれぞれの理由を、すぐに出力します（段階的に出力）。シグナルとその確認方法：Read("references/behaviour-gate.md")。

フェーズ 3：生成（並列エージェント）

ティアごとにテスト生成エージェントを起動します。run_in_background=true を指定して、すべてを 1 つのメッセージで起動します。

分離： 各ティアのエージェントを Agent(isolation="worktree") で起動し、ティア（unit / integration / e2e）ごとに 1 つの worktree を使用して、競合を防ぎます。CC 2.1.154 でサブエージェントが worktree 分離ガードを回避できる問題が修正され、2.1.203 で完了しました。ork の最低バージョンは >= 2.1.220 のため、サポート対象のすべてのセッションで実際に分離されます。起動前に手動で worktree を作成しないでください。

新しいブランチのベースは worktree.baseRef 設定から取得し、ハードコードされたブランチ名は使用しません。ork では設定されません。プラグインから設定できず、ork の設定ファイルにも含まれていません。オペレーターが .claude/settings.json または ~/.claude/settings.json に "baseRef": "head" を設定していない限り、CC のデフォルトである "fresh" が適用されます。その場合、各ティアのエージェントは origin/<default> からブランチを作成し、プッシュされていないローカルコミットは参照できないため、今書いたコードに対して tsc を実行すると「cannot find module」エラーになります。起動前に設定を確認してください。完全なパターン：Read("../chain-patterns/references/worktree-agent-pattern.md")

# Unit tests agent (worktree-isolated)
if "unit" in TIERS:
    Agent(
        subagent_type="ork:test-generator",
        isolation="worktree",
        prompt=f"""Generate unit tests for: {SCOPE}
        Risk targets, each with why: {gap_map["unit"]}
        Framework: {detected_framework}
        Existing tests: {existing_test_files}

        Focus on:
        - AAA pattern (Arrange-Act-Assert)
        - Parametrized tests for multiple inputs
        - MSW/VCR for HTTP mocking (never mock fetch directly)
        - Factory-based test data (FactoryBoy/faker-js)
        - Edge cases: empty input, errors, timeouts, boundary values
        - BEHAVIOUR GATE: write a test ONLY if it asserts an observable result. Never write a
          mock-call-only, assertion-free, tautological, or source-reading test (references/behaviour-gate.md)""",
        run_in_background=True,
        max_turns=50,
        model=MODEL_OVERRIDE
    )

# Integration + E2E agents follow the same pattern:
# - subagent_type="ork:test-generator", isolation="worktree", run_in_background=True, same targets + BEHAVIOUR GATE lines
# - Integration focus: API endpoints (Supertest/httpx), real DB, contract tests (Pact), Zod schema validation
# - E2E focus: Playwright, semantic locators, Page Object Model, axe-core a11y, visual regression
#
# Special case: emulate (Vercel Labs stateful API emulation):
# When integration tests need GitHub/Stripe/Resend/Okta/etc. emulated
# (HMAC webhooks, parallel port isolation, full config from scratch),
# spawn emulate-engineer instead of test-generator for that tier:
# - subagent_type="ork:emulate-engineer" (same isolation="worktree" form)
# - Pairs with emulate-seed skill for seed YAML patterns

各エージェントの結果は、返ってきたらすぐに出力します。すべてのエージェントが完了するまで待たないでください。

フェーズ 3b：動作ゲート

フェーズ 4 の前に、新しいテストファイルのみを対象として node "${CLAUDE_SKILL_DIR}/scripts/check-behaviour-tests.mjs" --json <new test files> を実行します。終了コードが 1 の場合、却下されたテストとそのルールが表示されます。（a）モック呼び出しのアサーションのみ、（b）アサーションがない、恒真式（expect(true).toBe(true)）のみ、または仕様上の契約として「例外を投げない」ことが明示されていないのに not-to-throw のみ、（c）コードを実行せずにソースを読み取る、または grep する。却下されたテストをそれぞれ削除する（drop の場合はファイル全体。これは認識されたテストがすべて却下されたことを意味します）か、観測可能な結果をアサートするように書き換え、終了コードが 0 になるまで再実行します。unchecked のファイルやテストは決して削除しないでください（テストが認識されなかった、またはその本体が別の場所で宣言されている場合）。手動で確認してください。フェーズ 5 の後にも再実行してください。判定結果を 03-cover-generation.json に記録します。ルールと制限：Read("references/behaviour-gate.md")。

フォーカスモード（CC 2.1.101）： フォーカスモードでは、最終メッセージにカバレッジレポート全体（変更前後の差分、ティアごとのテスト数、作成ファイル）を含めてください。

フェーズ 4：実行

生成したテストをすべて実行し、結果を収集します。

# Run test commands per tier (PARALLEL if independent):
# Unit: npx vitest run tests/unit/ OR pytest tests/unit/
# Integration: npx vitest run tests/integration/ OR pytest tests/integration/
# E2E: npx playwright test

# Collect: pass count, fail count, error details, coverage delta

フェーズ 5：修復ループ

ループを手作業で作成してはいけません。実際の実行ツールを実行します。

Workflow(
  scriptPath="${CLAUDE_SKILL_DIR}/workflows/heal-loop.js",
  args={"testCommand": "<tier test command>", "tier": "unit", "testGlob": "tests/unit/",
        "maxIterations": 3}   # from the effort table above; omitted defaults to 3
)
# One invocation per tier that has failures.

ファンアウトのルール： 選択された失敗処理で修復ループを実行する場合、単一のパスを代替手段にしてはいけません。失敗がある各ティアで、修復ループのワークフロー呼び出しを実行します。実行されない場合は、実行を BLOCKED として終了し、その理由を伝えます。「生成のみ」では修復ループをスキップするため、違反にはなりません。

反復回数の上限は、指示ではなくスクリプトによって適用されます。 heal-loop.js は [2, 3] の範囲に制限された実際のカウント付きループを実行します。各反復では、診断エージェントを起動し、実際にテストコマンドを実行して、合否と失敗出力の全文を構造化して返します。続いて修復エージェントが、その失敗テキストを受け取り、テストファイルのみを編集します。テストスイートが成功した時点で、ただちに終了します。

最後の反復では診断のみを行い、修復は行いません。修復を検証するための実行が残らないためです。そのため、maxIterations: N は N 回の診断実行と N-1 回の修復パスを意味し、デフォルトの 3 は 2 回の修復を意味します。上限が 1 の場合は 2 に調整されます。1 では修復が 0 回になるためです。

各失敗は分類体系（assertion、import、setup、timeout、stale-selector、type、flaky、および source-bug）に分類され、それに応じて修正戦略が選択されます。

ワークフローは status: "healed"、または remaining_failures、failure_categories、反復ごとの台帳を含む構造化された失敗（status: "failed"、healed: false）を返します。"failed" の結果を成功として報告してはいけません。フェーズ 6 のレポートに、まだ失敗しているテストを記載してください。

戦略の詳細（分類テーブル、修正ルール、不安定なテストの防止）：Read("references/heal-loop-strategy.md")

境界：修復で直すのはテストであり、ソースコードではありません。 ソースコードのバグが原因でテストが失敗する場合は、そのことを報告してください。プロダクションコードを黙って修正してはいけません。

フェーズ 6：レポート

変更前と変更後を比較したカバレッジレポートを生成します。

レポートの完全なレイアウト（ベースライン→変更後の表、生成したテスト数、修復の反復回数、作成したファイル、残っているギャップ、次の手順のコマンド）：Read("references/coverage-report-template.md")。

完了時の PushNotification（CC 2.1.110 以降）

cover のフル実行（修復ループを含むユニットテスト＋統合テスト＋E2E テスト）には 15～45 分かかります。フェーズ 6 のレポートをまとめた後、PushNotification(message=f"ork:cover complete, {SCOPE}: {tests_kept} tests kept · {tests_dropped} dropped by behaviour gate · {heal_loops} heal iters", status="proactive") を呼び出します。完全なルール：Read("../chain-patterns/rules/push-notification-on-completion.md")。

カバレッジのドリフト監視（CC 2.1.71）

リスク対象の動作テストが維持されているかどうかを、週次で確認するよう任意でスケジュールできます。

# Guard: Skip cron in headless/CI (CLAUDE_CODE_DISABLE_CRON)
# if env CLAUDE_CODE_DISABLE_CRON is set, run a single check instead
CronCreate(
  schedule="0 2 * * 0",
  prompt="Weekly drift check for {SCOPE}: run the tests covering the risk targets in 02-cover-analysis.json.
    Alert if one was deleted or fails, or if newly changed code has no behaviour test. Coverage is reported as information only."
)

---

主要な原則

• 出力制限（CC 2.1.77 以降）： Opus 4.8 のデフォルトの出力トークン数は 64k（上限は 128k）です。大規模なテストスイートでは、出力が制限に近づいた場合、複数のエージェントターンに分けて生成します。
• 部分読み取り（CC 2.1.144 以降）： サイズの大きいファイルに対して Read を実行すると、エラーではなく最初のページが [PARTIAL view] として返されます。カバレッジ分析でファイル全体を確認できるよう、offset／limit を明示して再度読み取ります。
• テストのみ： プロダクションのソースコードは変更せず、テストファイルのみを生成します
• 利用可能な場合は実サービスを使用： 統合テストでは、モックと本番環境の乖離が本番環境でのサイレント障害を引き起こすため、モックよりも testcontainers／docker-compose を優先します
• 並列生成： 1 つのメッセージで、ティアごとにテスト生成エージェントを 1 つ起動します
• 修復は無限にループさせない： 反復は最大 3 回とし、その後、残りの失敗を報告します
• 段階的な出力： 各エージェントの完了に合わせて結果を表示します
• フィクスチャよりファクトリー： テストデータにはハードコードされた値ではなく、FactoryBoy／faker-js を使用します
• ネットワークレベルでモックする： MSW／VCR を使用し、fetch／axios を直接モックしてはいけません

---

エージェントの連携

コンテキストの受け渡し

各テスト生成エージェントには、担当ティアのリスク対象（それぞれの理由を含む）、動作ゲートのルール、テストフレームワークの設定、実サービスのインフラ（testcontainers、docker-compose）、およびプロジェクトのフィクスチャパターンを渡します。

Monitor + 部分結果（CC 2.1.98）

バックグラウンドエージェントによるテスト実行の出力をストリーミングするには、Monitor を使用します。

# Stream test suite output in real-time
Bash(command="npm test -- --coverage 2>&1", run_in_background=true)
Monitor(pid=test_task_id)  # Each line → notification

パターンの完全なリファレンス（until-condition ゲート、部分結果の救出、TaskOutput と Monitor の使い分け）：Read("../chain-patterns/references/monitor-patterns.md")。

部分結果（CC 2.1.98）： テスト生成エージェントが生成途中でクラッシュした場合、生成された内容をまとめます。

for agent_result in test_gen_results:
    if "[PARTIAL RESULT]" in agent_result.output:
        # Agent crashed: check if it wrote any test files before dying
        partial_tests = Glob(pattern="**/tests/**/*.test.*", path=agent_result.worktree)
        if partial_tests:
            # 6 passing tests from a crashed agent > 0 tests
            # Copy partial tests to main worktree, run them in Phase 4
            for test_file in partial_tests:
                Bash(command=f"cp {test_file} {main_worktree}/{test_file}")
            # Flag as partial in report

CC 2.1.246 以降では、maxTurns による停止も部分結果です（概要：「N ターンの上限で停止しました（部分結果。タスク ID に SendMessage を送って続行してください）」）。エージェントを再起動せず、SendMessage で続行してください。

SendMessage（テストの修正）

セッションをまたぐ返信は親に届きます（CC 2.1.248）： サブエージェントが別のセッションに SendMessage を送信すると、返信はサブエージェントではなく、親セッションの会話に届きます。サブエージェントはメッセージを送信して作業を続け、親が返信を確認します。セッションをまたぐ SendMessage / ListAgents は、Bedrock、Vertex、Foundry でも、テレメトリが無効な場合でも動作します（CC 2.1.248）。

生成したテストが失敗した場合、修正エージェントは生成エージェントにコンテキストを求めることができます。

SendMessage(to="test-generator-unit", message="Test user_service_test.py:42 fails: TypeError on mock return. What's the expected shape?")

スキルチェーン

標準チェーン：implement → cover → verify → commit。各ステップの間に addBlockedBy を使用します。

検証ゲート

カバレッジが完了したと主張する前に、Read("../../shared/rules/verification-gate.md") を適用します。カバレッジレポートをあらためて実行してください。「通るはず」は証拠になりません。

エージェントのステータスプロトコル

すべてのテスト生成エージェントは、Read("../../shared/status-protocol.md") を使用して報告します。インターフェースが不足していてテストを書けない場合は BLOCKED、テストの期待値が不明確な場合は NEEDS_CONTEXT とします。

品質基準

次のすべてを満たせば完了です。

• カバレッジレポートには、推定値ではなく、実際のカバレッジコマンドの出力に基づく変更前から変更後への差分が表示されている
• 生成されたテストファイルをすべて実行し、ランナーから得た最終的な成功数と失敗数を貼り付けている
• Phase 5 後、新しいテストファイルに対する動作ゲートが終了コード 0 で終了し、すべての対象について選定理由が示されている
• 本番ソースを変更していない（作成したのはテストファイルのみ）。ソースのバグは報告し、黙って修正しない
• 失敗は反復予算内（≤3、作業量に応じて調整）で修正するか、残りの失敗数を明記して報告している
• 要求された各ティア（ユニット／統合／E2E）について、テストを作成しているか、省略した理由を明記している

関連スキル

• ork:implement：実装中にテストを生成します（Phase 5）。より深くカバレッジを確認するには、その後に cover を使用します
• ork:verify：既存のテストを 0～10 で評価します。チェーン：implement → cover → verify
• testing-unit / testing-integration / testing-e2e：テスト生成エージェントが読み込むナレッジスキル
• ork:commit：生成したテストファイルをコミットします

セッションの復旧（CC 2.1.108 以降）： アイドル期間や中断の後は、チェックポイントからの再開状態に加えて会話のコンテキストを復元するため、/recap を使用します。CC 2.1.110 以降はデフォルトで有効です（テレメトリが無効な場合も含む）。

リファレンス

Read("references/<file>") で必要に応じて読み込みます。

ファイル	内容
real-service-detection.md	Docker Compose／testcontainers の検出、サービスの起動、終了処理
heal-loop-strategy.md	失敗の分類、修正パターン、反復予算
coverage-report-template.md	レポート形式、差分の計算、ギャップ分析
behaviour-gate.md	リスク対象のシグナル、3 つの却下ルール、チェッカーの使用方法と制限
scripts/check-behaviour-tests.mjs	Phase 3b チェッカー：新しいテストファイルについて、テストごとに保持または却下を判定
workflows/heal-loop.js	Phase 5 実行ツール：スクリプトで強制される 3 回の反復修復ループ（Workflow ツールから実行）

---

バージョン： 1.3.0（2026 年 9 月）：動作ゲート（Phase 3b チェッカー）とリスクベースの対象を、パーセンテージによるカバレッジ目標に代えて導入