ln-404-test-executor

パス： ファイルパス（references/、../ln-*）は、このスキルディレクトリからの相対パスです。

テストタスク実行者

タイプ： L3 ワーカー

単一の Story 最終テストタスク（ラベル「tests」）を実装・実行し、「レビュー待ち」まで進めます。

目的と範囲

• 「tests」ラベルの付いたタスクのみを扱います。それ以外のタスクは ln-401 に引き渡します。
• 11 セクションのテストタスク計画（E2E／統合／単体、インフラ／ドキュメント／クリーンアップ）に従います。
• リスクベースの制約を適用します：優先度 15 以上のシナリオを網羅すること、各テストが有用性基準を満たすこと、フレームワーク／DB／ライブラリ／パフォーマンスのテストを行わないこと。
• このタスクのみを対象にトラッカー／カンバンを更新します：未着手 -> 進行中 -> レビュー待ち。

Hex-line による効率化（利用可能な場合）： テスト対象を読む前に outline(file_path) を使用します。テスト構造を把握するには、inspect_path(path=<relevant test dir>) で範囲を絞って調査します。tests/ 全体の一覧が意図的に必要な場合は、デフォルトのパターン上限ですべて表示されると想定せず、max_entries=0 を指定します。 まず grep_search(output_mode="summary") でテスト／ヘルパー／フィクスチャを検索し、後続の編集に正規のハンクが必要な場合にのみ output_mode="content", edit_ready=true に切り替えます。allow_large_output=true は明示的に必要な場合のみ使用します。テスト／コード／設定ファイルには、主な手段として read_file() と edit_file() を使用します。通常の調査では read_file() を検出モードのまま使用します。リビジョン／チェックサムのプロトコルが必要な編集の前には、read_file(edit_ready=true, verbosity="full") を使用します。引き継ぎの前に verify() と changes() を使用します。hex-line が利用できない場合に限り、組み込みの Read／Edit を代替手段として使用します。

入力

入力	必須	ソース	説明
taskId	はい	args、親 Story、カンバン、ユーザー	実行するテストタスク

解決方法： タスク解決チェーン。 ステータスフィルター： 未着手（ラベル：tests）

タスクストレージモード

必読： references/environment_state_contract.md、references/storage_mode_detection.md、references/tracker_provider_contract.md、references/input_resolution_pattern.md を読み込みます。

必読： references/ci_tool_detection.md を読み込みます — テストコマンド実行時のコンパクトな出力フラグ、pipefail、切り詰め前の正規化ポリシー。

抽出項目：task_provider = Task Management → Provider（linear | github | file）。このスキルの操作はプロバイダーに依存しません。正規の操作セットについては references/tracker_provider_contract.md を、トランスポートのバインディングについては provider_*.md を参照してください。

このスキルで使用するトラッカー操作：getTask、getStory、updateStatus（未着手 → 進行中 → レビュー待ち）、addComment（テスト結果）。プロバイダーごとのトランスポートは references/provider_file.md, references/provider_github.md, references/provider_linear.md にあります。

必読： references/mcp_tool_preferences.md を読み込みます — 利用可能な場合は、コードファイルに必ず hex-line MCP を使用します。hex-line が停止している場合を除き、標準の Read／Edit に切り替えてはいけません。

ワークフロー（簡潔版）

1. taskId を特定する： ガイドに従って Task Resolution Chain を実行します（ステータスフィルター：[Todo, label: tests]）。
2. タスクを読み込む： 設定済みのトラッカープロバイダー（getTask）を使用してテストタスクの説明全文を取得し、リンクされているガイド／マニュアル／ADR／調査資料を読みます。親 Story（getStory）と、提供されている場合は手動テストの結果を確認します。 2b) ゴールゲート： 必読： references/goal_articulation_gate.md を読み込みます。これらのテストの真のゴール（「テストを書く」ではなく、検証すべきビジネス動作）を明確にします。ゴールではないもの：ビジネスロジックではなく、テストインフラやフレームワークの動作をテストすること。隠れた制約：実装変更によって壊れる可能性のある既存テスト。
3. 環境ドキュメントを読む： docs/project/infrastructure.md を読みます — サーバー IP、ポート、サービスエンドポイントを確認します。docs/project/runbook.md を読みます — テスト環境のセットアップ、Docker コマンド、テスト実行の前提条件を把握します。Runbook に記載された正確なコマンドを使用します。
4. 計画を検証する： 優先度 15 以上のカバレッジと有用性の基準を確認し、ビジネスフローに重点が置かれていること（インフラのみのテストでないこと）を確かめます。
5. 作業を開始する： 設定済みのトラッカープロバイダー（updateStatus）を使用してタスクを In Progress に設定し、かんばん上で移動します。
6. 実装して実行する： 必読： references/code_efficiency_criterion.md を読み込みます。計画に従ってテストを作成／更新し、既存のフィクスチャ／ヘルパーを再利用して、テストを実行します。失敗する既存テストを修正し、必要に応じてインフラ／ドキュメントのセクションを更新します。引き渡す前に、効率性のセルフチェックを 3 つ実施します（特に、セットアップを重複させずにフィクスチャを再利用していることを確認します）。
7. 完了する： 件数／優先度が引き続き制限内であることを確認し、タスクを To Review に設定して、かんばん上で移動します。カバレッジ、実行したコマンド、逸脱事項があればその概要をコメントに追加します。

重要なルール

• 1 タスクのみ対応します。一括更新は禁止です。
• Done に設定しないでください。承認はレビュアーが行います。タスクは To Review で終了する必要があります。
• タスクの言語（EN／RU）に合わせます。
• フレームワーク／ライブラリ／DB／パフォーマンス／負荷のテストは禁止です。ビジネスロジックの正しさに重点を置きます（インフラのスループットではありません）。
• 制限と優先度を守ります。違反している場合は作業を中止し、判明事項を報告します。
• コミットしないでください。 すべての変更を未コミットのままにします。レビューとコミットはレビュアーが行います。

ランタイム概要アーティファクト

必読： references/coordinator_summary_contract.md、references/worker_runtime_contract.md、references/task_worker_runtime_contract.md を読み込みます。

共通コントラクト：

• summary_kind=task-status を出力します
• スタンドアロンモードでは runId と summaryArtifactPath を省略します
• マネージドモードでは、ワーカーが検証済みのサマリーを書き込む前に、runId と正確な summaryArtifactPath の両方を渡します

Monitor（2.1.98+）： 30 秒を超えることが想定されるテスト／カバレッジコマンドでは、Monitor を使用します。代替手段：Bash(run_in_background=true)。

完了の定義

• タスクをテストタスクとして特定し、In Progress に設定した。かんばんを更新した。
• 計画を検証（優先度／制限）し、ガイドを読んだ。
• テストを実装／更新して実行した。既存の失敗を修正した。
• タスク計画に従ってドキュメント／インフラを更新した。
• タスクを To Review に設定し、かんばん上で移動した。コマンドとカバレッジを記載した概要コメントを追加した。
• ランタイム概要アーティファクトを共有の task-status の保存先に書き込んだ。

テスト失敗分析プロトコル

重要： 新たに記述したテストが失敗した場合は、何かを変更する前にいったん停止し、分析してください（新しいテストの失敗は、テストの問題ではなく実装のバグを示していることが多く、原因を調べずに修正すると根本原因が隠れてしまいます）。

ステップ 1：テストの正しさを確認する

• テストは AC 要件（Story の Given／When／Then）に厳密に合致していますか？
• 期待値はビジネスロジックに照らして正しいですか？
• 判断できない場合：ref_search_documentation(query="[domain] expected behavior") を実行して確認します。

ステップ 2：判断する

テストは AC に合致しているか？	対応
はい	コードのバグ → テストではなく実装を修正します
いいえ	テストが誤っています → テストのアサーションを修正します
判断できない	必須： MCP Ref を確認し、変更する前にユーザーに確認します

ステップ 3：トラッカーのコメントに記録する（addComment） 「テスト [name] が失敗しました。分析：[テストは正しい／テストは誤り]。対応：[コードを修正／テストを修正]。理由：[根拠]」

危険信号（ユーザーの確認が必要）：

• ⚠️ 実際の出力に合わせてアサーションを変更する（「テストを通す」）
• ⚠️ 「動作しない」テストケースを削除する
• ⚠️ 期待値を緩める（例：toEqual ではなく toContain を使う）

安全に進められるケース：

• ✅ テストのセットアップ／モックデータの誤字を修正する
• ✅ AC 要件に合うようコードを修正する
• ✅ 不足しているテストのセットアップ手順を追加する

テスト作成の原則

1. 厳密なアサーション — 不一致があれば失敗させる

デフォルトでは完全一致のアサーションを使用します：

厳密（推奨）	緩やか（正当な理由がない限り避ける）
完全一致のチェック	部分一致／部分文字列のチェック
長さの完全一致チェック	「長さがあればよい」チェック
オブジェクト全体の比較	オブジェクトの部分一致
型の完全一致チェック	truthy／falsy のチェック

WARN レベルのアサーションは禁止です。テストは PASS または FAIL のいずれかにしてください。警告は出さないでください。

2. 決定論的な出力には期待値ベースのテストを使う

決定論的な応答（API、変換など）の場合：

• 複雑な決定論的出力にはスナップショット／ゴールデンファイルテストを使用します
• 実際の出力を期待値の参照ファイルと比較します
• 比較の前に動的データを正規化します（タイムスタンプ → 固定値、UUID → プレースホルダー）

3. 黄金律

「期待値がわかっているなら、その値を厳密にアサートします。」

禁止事項： 正確な値がわかっているのに、テストを「通す」ために緩やかなアサーションを使用すること。

参照ファイル

• 環境状態： references/environment_state_contract.md
• ストレージモードの操作： references/storage_mode_detection.md
• カンバン形式：docs/tasks/kanban_board.md
• 必ず読むこと： references/research_tool_fallback.md を読み込みます

---

バージョン： 3.2.0 最終更新日： 2026-01-15