testkit

testkit

すでに動作しているコードのために構築するテストスイートです。testkit は、テストがないコードベースや、古くなったテストが少しだけあるコードベースを読み込み、テストする価値のある箇所を優先順位付けし、対象を一つ選んで、採用する前に失敗することを実際に確認したテストを書きます。

モードは 2 つです。audit はテストされていない範囲を優先順位付けし、台帳だけを書き出します。cover はテストを書きます。

防止する問題

「このプロジェクトのテストを書いて」と依頼されたエージェントは、確実にテストの見せかけを作り出します。実装を一行ずつなぞるテストの山、モックが呼び出されたことを検証するテスト、初回から通るテスト、バグも含めて現在のコードの動作を固定するテストです。

それは本物のテストスイートとまったく同じ見た目をしています。同じ構成、同じ緑色のチェックマーク、同じカバレッジ数です。しかし、何も検出せず、メンテナンスの負担だけがいつまでも続き、裏付けにならない議論の証拠として緑色のチェックマークを渡すため、テストがないよりも悪いものです。

本物のブラウンフィールドテストとそのようなテストの山を分ける特性は 2 つあり、どちらも強制しなければ構造的に欠けています。

1. テストが失敗することを実際に確認していること。 テストより先にコードが書かれている場合、何もしなくてもレッドからグリーンにはなりません。意図的に失敗を作り出さなければ、失敗はまったく起きません。
2. 期待値が実装の外部から得られていること。 テスト対象の関数を見て期待値を決めたテストは、現在の動作を写した写真であって、正しい動作についての主張ではありません。

以下のすべてのルールは、この 2 つを努力目標ではなく必須にするために設けられています。

どのようなときに使うか

すでに動作しているコードについて「これをテストして」、 「このリポジトリにはテストがない」、「テストカバレッジを追加して」、「テストをセットアップして」、「最初に何をテストすべきか」、「カバレッジがひどい」、「/testkit」。

最も近いキットとの境界は次のとおりです。

• 新しい作業のためのテストではありません。 まだ存在しないコードや、現在構築中の機能のテストを依頼された場合は、ビルドスキルに振り分けます。テストファーストなら TDD モードの implementkit、構築直後にテストするなら tests-after モードを使います。implementkit がない場合は、テストはビルドと一緒に行うものだと伝えてください。testkit の前提は、コードがすでに存在し、すでに動作していることです。つまり、testkit が扱うのは後付けです。
• 手動 QA 計画ではありません。 QA スキルは、人が手作業で実行する手順を書きます。testkit が作成するものを人が実行することはありません。
• プルリクエストのためのブラウザー検証ではありません。 ビジュアル検証スキルはブラウザーを一度操作して、画像を取得します。testkit は、テストコマンドで何度でも実行できる仕様を書きます。
• 診断ではありません。 デバッグスキルは、1 つの症状を原因まで追跡し、再現用に失敗するテストを 1 つ作成することがあります。testkit はテストスイートを構築します。

修正も再構成もしません

どちらもその場では違和感を覚えるであろう、譲れない境界が 2 つあります。

テストの後付けでバグが見つかることがあります。testkit はバグを報告し、修正はしません。 実際に確認した動作が外部から得た期待値と矛盾する場合、テストに合わせてソースを編集したり、ソースに合わせてテストを編集したりしないでください。意図された動作を検証するテストを書き、1 行の説明を添えてスキップ状態または失敗想定にし、報告してください。欠陥を見つけてその修正も行うスキルは、報告を書く前に結論を出したことになります。

再構成しなければテストできないコードもあります。testkit は再構成しません。 インターフェースの抽出も、依存関係の注入も、「ついでに小さな接続箇所を作る」こともありません。テストできないコードは台帳のテスト容易性の阻害要因となり、次の担当に引き継がれます。リファクタリングスキルの未テストの結合パターンは、まさにこの調査結果に提案を添えたものです。

testkit がソースを編集するのは、失敗ゲートでの一時的なミューテーションだけであり、そのすべてを元に戻します。

モードの選択

該当する最初の条件を選びます。

1. ユーザーがモードを指定した場合。たとえば /testkit audit や /testkit cover src/billing です。明示的な指定が常に優先されます。
2. 台帳がある場合 → cover。台帳がない場合 → audit。

台帳のないリポジトリで cover を要求されても、中断しません。 ランキングをその場で行い、対象範囲を選び、どの経路で実行したかを伝えて続行します。調査文書ができるまでテストの作成を拒むのは官僚主義であり、スキルがアンインストールされる原因になります。

任意のスコープ引数を指定すると、どちらのモードでもランキングの対象を絞れます。書き込む内容は変わりません。

台帳

リポジトリごとに1ファイルを作成します。ファイル名は docs/tests/NNNN-testplan-<repo>-YYYY-MM-DD.md です。日付は作成日で、ファイル名全体は永久に固定されます。シリアル NNNN を取得するには、このワークツリー、git worktree list が示すほかのすべてのワークツリー、origin/HEAD（git fetch origin の後に git ls-tree --name-only origin/HEAD docs/tests/）を対象に、docs/tests/ 内で先頭に付く4桁のシリアルの最大値を取得し、1を加えます。該当するものがなければ 0001 から始めます。並行するワークツリーで同じシリアルが使われないよう、3つすべてを調べます。リモートがないなど、取得に失敗したソースはスキップします。git が使えない場合は、ディレクトリだけを一覧表示します。シリアルはディレクトリごとに管理され、再利用されることはありません。audit は台帳を作成します。それ以降の実行では、先頭にシリアルがあるかどうかにかかわらず、testplan-<repo>- で台帳を検索し、同じファイルを更新します。スコープを絞った実行では、同じファイル内のスコープ見出しの下に追記し、2つ目のファイルは作成しません。

ファイルを1つにまとめることで、N+1回目の実行を手軽にできます。ブラウンフィールドの改修は1回のセッションでは終わりません。スコープごとに日付入りの調査文書を新規作成するスキルでは、再開できる状態が残らず、調査文書が積み上がるだけです。

台帳には次の内容を記録します。

• ランキングした未テストの対象範囲。ranked against <sha> on <date> の形式で記録します。
• 各実行でカバーした内容。日付と、申告した件数と実際の件数を記録します。
• 先送りした内容と、その理由。
• テスト可能性の阻害要因。構造を変更しないとテストできないコードを指します。
• 未検証のテスト。捕捉すべきミューテーションがあっても通過した既存のテストを指します。
• 範囲が広すぎるテスト。名前に挙げていない動作を対象としたミューテーションによって失敗した既存のテストを指します。

永続的に保存でき、コミット可能なものです。testkit がこれをコミットすることはありません。

リポジトリにテスト計画文書の既存の保存場所や命名規則がある場合は、その規則を優先し、それに従ったことを伝えます。書き込み可能なファイルシステムがない場合（ブラウザーベースのエージェントの場合）は、標準パスを示すコードブロックとして台帳を出力します。

モード：audit

読み取り専用です。台帳以外は何も書き込みません。テストファイルもソースの編集も行いません。

1. 未テストの対象範囲を導き出す

存在するソースとテストを特定し、テストが実際にカバーしている範囲を確認します。カバレッジレポートを読むのは、すでにディスク上にある場合に限ります。生成してはいけません。また、証拠を得るためのツールをインストールしてはいけません。 分析ツールを探し、その出力を解析すると、マイナーリリースで変わる形式にスキルが依存することになるためです。

ランキングの前に除外します。生成コード、ベンダーのツリー、単純な設定、純粋な委譲は対象外です。これらは件数を水増しするだけで、何の証明にもなりません。

すべてのソースファイルが候補リストまたは名前の付いた除外区分のどちらかに入った時点で、この手順は完了です。

2. 順位付けする

履歴を一度読み込むだけで、2つのシグナルを同時に得られます。git log --format= --name-only --since=<about a year> を実行すると、各ファイルが変更された頻度と、どのファイルが繰り返し 一緒に 変更されているかが分かります。

次の4つのシグナルに基づいて順位を付けます。

• 変更頻度。 どれくらい頻繁に変更されているかです。誰も触れないコードが壊れることはありません。
• 依存数。 どれだけ多くのモジュールが依存しているかです。ここで壊れると、あらゆる場所に影響します。
• 障害時のコスト。 金銭、認証、データ損失、マイグレーションなど、取り消せないあらゆるものが対象です。
• テストのコスト。 このコストで割ります。3つのサービスを立ち上げる必要がある動作は、順位が示す以上にコストがかかります。

Git の履歴がない、つまり浅いクローンかリポジトリでない場合は、順位付けを行いません。代わりに構造を見て調査し、優先順位付けを省略したことを明確に伝え、カバレッジの主張を実際以上に受け取られないようにします。

すべての候補に順位が付くか、順位付けを省略したこととその理由が実行結果で明示されたら、このステップは完了です。

3. 対象を1つに絞る

順位の上位を、同時変更のクラスターに沿って一貫性のあるスライスにまとめ、必ず1つだけ選びます。次点の候補は順番に示します。ファイルではなくスライスを選びます。一貫性のある動作は1つのファイルに収まることがほとんどなく、ファイルは意味の単位ではありません。

1つに絞ることが作業です。見た目が同じくらいの候補を5つ並べても、ユーザーがすでに抱えていた状態のままです。

4. 台帳を書く

各実行では、ターミナルとファイルの両方にカバレッジ行を記録します。例：「1,240ファイルに順位を付け、3つのスライスにわたって上位40件を読み込みました。」上限が見えなければ、完全に網羅したかのように受け取られます。

重要な未テスト領域が見つからない監査では、ファイルを作成せず、その旨を伝えます。 調査で何らかの所見を出すよう義務付けると、所見を捏造することになります。テスト対象について捏造された助言は、本物の助言と見分けがつきません。

モード：cover

テストを作成します。

1. スライスを選び、順位が今も有効か確認する

台帳、ユーザー、またはどちらもない場合はインラインの順位付けから選び、どこから選んだかを伝えます。

台帳の順位付けには、計算の基準となったコミットが記録されています。HEAD と比較してください。その sha 以降のコミットで、台帳にある上位スライスのファイルが変更されていた場合は、順位を付け直します。 それ以外の場合は、信頼した sha を明示して、順位をそのまま使うことを伝えます。持続する順位付けは、対象となったコードより長く残ります。そのため、8月の順序が、かつて注目されていたものを対象に11月の実行を進めてしまうことがあります。

スライスとその出所、そして信頼した sha または新たに計算した順位を実行結果で明示したら、このステップは完了です。

2. テストランナーがなければ導入する

リポジトリにすでにテストランナーがある場合は省略します。

• エコシステムのデフォルトに従います。 テストのないプロジェクトには尊重すべき既存の方針がないため、後から異議が出にくい選択肢は、その言語の公式ドキュメントが推奨するものです。選択肢が実際に意見の分かれるものなら、ここで判断せず、調査スキルに委ねます。
• リポジトリの既存のエントリーポイントに組み込みます。 npm test、make test、pytest などに組み込み、誰もがまず試すコマンドからテストスイートを実行できるようにします。チャットログに書かれた呪文でしか実行できないテストスイートは、テストスイートとは言えません。
• テストファイルの配置にも同じルールを適用します。 同じエコシステムに、仕様ファイルをコードと同じ場所に置く方法と tests/ ツリーに置く方法のように、現役の規約が2つある場合は、独自の好みを持ち込まず、リポジトリの既存レイアウトが示す方法に従います。
• 依存関係をインストールする前に、一度だけ確認します。 開発用の依存関係も、他者のプロジェクトに長く残る変更です。
• 実際のテストを書く前に、成功するスモークテストを1つ追加します。 動作確認していないテスト環境に対して、最初から40個のテストを追加すると、テストを通じてテスト環境をデバッグすることになります。

言語、ビルドシステム、依存関係の状況が原因で標準的なテストランナーを組み込めない場合は、具体的な障害を報告して停止します。テスト環境を独自に即席で作ることは決してしません。 手作りのテストループは、他の人が実行、保守、置き換えできないものです。このスキルが残すものの中で、最も長く残ってしまう可能性があります。

リポジトリのエントリーポイントからスモークテストが1つ成功するか、特定した障害を理由に実行を停止したら、このステップは完了です。

3. 何かを書く前に規模を宣言する

最初のテストファイルを作る前に、**「このスライスには N 個の振る舞いがあり、今回の実行では M 個を対象にします。」**と明言します。

数値は自分で決めます。あらかじめ記録し、引き継ぎでは実績を宣言値と照らして報告します。宣言の上限を超えそうな実行は、範囲を広げるのではなく、停止してその旨を伝えます。

これ以外に実行の範囲を制限するものはありません。テストが 3 件でも 30 件でも、後から見ればどちらもルールに従っていたように見えます。また、失敗時のゲートのコストは、誰も記録していない数値に比例して増えます。固定の上限では、200 行のユーティリティにも決済モジュールにも対応できません。一方、毎回質問が必要では、無人実行ができなくなります。

4. テストを書く

各期待値の根拠は実装の外部に置きます。つまり、docstring、README、issue、型シグネチャ、呼び出し元での実際の使われ方、またはドメインです。外部に根拠がない場合、そのテストは特性テストです。現在の振る舞いを固定して変更を検知するものであり、正しさについては主張しません。

種類を問わず、すべてのテストに 1 行の出典コメントを付けます。

// per README: "amounts are stored in cents"
// characterization: no docstring, no issue, no caller assertion

両方に同じコストを課すことが、この仕組みのすべてです。無料のラベルは何にでも付けられ、やがて区別の意味がなくなります。代わりに使う方法よりコストの高いラベルは、それを避けるために外部の期待値をでっち上げる動機になってしまいます。それこそ、このルールが防ごうとしている不誠実さです。どちらにも出典を求めることで、両方向の抜け道をなくします。

偽装するのはプロセス境界だけです。つまり、ネットワーク、時計、乱数、ファイルシステム、またはサードパーティサービスに限り、実物が利用できないか、非決定的な場合にだけ行います。境界の内側にある協調オブジェクトを偽装してはいけません。**呼び出しが発生したことをアサートしてはいけません。**唯一のアサーションが呼び出し回数やスパイの引数に関するテストは、実装がその実装どおりに動くことを確認しているだけです。

1 つのテストにつき 1 つの振る舞いとし、たまたま経由する関数ではなく、その振る舞いにちなんだ名前を付けます。

矛盾が見つかった場合は、テストをスキップして報告します。ソースを編集したり、アサーションを弱めたりしてはいけません。修正も再構成もしないを参照してください。

宣言した M 個の振る舞いそれぞれに、出典コメント付きのテスト、またはスキップしたテストと報告が用意された時点で、このステップは完了です。

5. 実行前に、すべての対象が安全か確認する

使い捨て可能であることを確認していないデータストアやサービスのテストキットに対しては、何も実行しません。

対象として認められるのは、localhost、コンテナのテストキット、ユーザーが起動したテストキット、または明示的に指定されたテスト用 URL です。どのような名前のファイルであっても、環境に存在する .env から引き継いだ値は対象として認められません。 test と名付けられた設定は単なる主張であって事実ではありません。それを信頼することこそ、誰かのデータを破壊する前提そのものです。

使い捨て可能な対象がない場合は、一度だけ、セットアップの作成を提案します。断られた場合は、統合テスト作業をブロッカーとして台帳に記録し、ユニットテストの層を続行します。

ここにあるルールのうち、破った場合に取り返しがつかないのはこれだけです。だからこそ、注意喚起ではなく拒否として記しています。

6. e2e 層が適用される場合

オプトインで、対象は絞ります。アプリがすでに非対話的に起動でき、かつドライバーがインストール済みであるか、ユーザーがインストールを承認した場合にのみ実行します。サインインや重要なトランザクションなど、クリティカルパスの仕様を少数に絞り、UI の一式をそのまま再現してはいけません。

**testkit はセッション操作としてブラウザーを開きません。**仕様を作成するのは testkit ですが、ブラウザーを操作するのは、その仕様を実行するリポジトリ独自のテストコマンドだけです。したがって、失敗時のゲートはユニットテストとまったく同じように、ランナーを介して e2e 仕様にも適用されます。最も誤って書かれやすい層だからといって例外にはなりません。

これは、ビジュアル検証スキルとの境界線です。同じ起動コマンド、フィクスチャ、ドライバー設定を両方のスキルが正当に必要とするため、どちらがドライバーを呼び出すのかという観点で定めています。成果物のライフサイクルという観点では、この重複を乗り越えられません。

失敗ゲート

testkit が残すテストは、すべて失敗するところを確認済みです。 失敗するのを一度も確認していないテストでは、コードと結び付いているかどうかについて何も証明できません。

コードはすでに存在するため、先に失敗させてから成功させる方法は使えません。代わりに、動作を壊し、テストを実行して失敗するのを確認し、元に戻します。

有効な変更は意味的な変更であり、削除ではありません。 戻り値を変える、比較を反転する、分岐を取り除く、書き込みをスキップする、といった変更をします。関数やファイルを削除すると、何も検証しないテストも含め、すべてが失敗します。それではインポートパスが解決されることしか証明できません。テストが確認すると主張している動作だけを変える、最小限の編集をしてください。

ランナーがサポートする、最も対象を絞った選択を実行します。 対象のテストと、同じファイル内のテストだけを実行します。フルスイートは決して実行しません。期待したテストが失敗することを確認し、同じく失敗した近接テストをすべて読んでください。ランナーでファイルやパターンを選択できない場合は、申告する動作数を減らし、その理由を述べます。

失敗した近接テストには2種類あり、ゲートで見分けられます。

• 妥当な重複です。 近接テストが名前に掲げる動作自体が、変更したコードに依存しているため、失敗すべきものです。1つの価格計算関数をテストする2つのテストが、丸め処理を反転すると両方失敗する場合などです。両方を残し、変更記録に重複を記録します。
• 過度に広いアサーションです。 近接テストは別の動作を掲げているにもかかわらず、その動作を超える範囲、たとえばオブジェクト全体、完全なスナップショット、無関係なフィールドまでアサートしているために失敗しています。この実行で testkit がそのテストを書いた場合は、アサーションを掲げた動作に絞り、再度ゲートを実行します。既存のテストの場合は、台帳に over-broad として記録し、そのままにします。

変更に対して判断するのは、近接テストの名前と出所コメントです。変更を適用したままでは、テストが掲げる動作が正しくなり得ないなら、その重複は妥当です。

遅いからといってゲートを省略することはありません。 スイートが遅い状況こそ、ゲートに価値があるため、免除を設ければ、まさにゲートを省略したくなる状況で通過を許すことになります。フルスイートを実行するのは、完了ゲートでちょうど2回だけであり、それ以外では実行しません。

この実行で testkit が作成し、変更を加えても成功したままのテストは削除し、 削除したことを報告します。

変更を加えても成功したままの既存テストは削除せず、記録します。 台帳に、見逃した変更とともに unproven として記録し、ユーザーに引き継ぎます。削除ルールの対象は、この実行で testkit が作成したテストに限られます。別の対象を狙った変更の証拠を根拠に、他者のテストを削除するのは、このスキルが正当化できる範囲を超えており、有益なシグナルを回復不能なものに変えてしまいます。

ミューテーション台帳

ミューテーションとは、追跡対象のソースに対する編集です。実行開始時にユーザーが未コミットの作業をしていた可能性があり、ミューテーションを戻す際にそれを決して元に戻してはいけません。

• 最初にベースラインを取得します。 台帳は作業ツリーの外にあるディレクトリに置きます。最初のミューテーションの前に git stash create を実行し、git rev-parse HEAD、git diff --binary --cached、git status --porcelain=v1 --untracked-files=all の結果を台帳に記録します。
• スナップショットが存在するかどうかを記録します。 git stash create は追跡対象の変更を含む参照されていないコミットを書き込みますが、参照もファイルも変更しません。クリーンなツリーの場合と、変更が未追跡ファイルのみの場合は、何も出力されません。その場合は none と記録し、存在しないオブジェクトの復旧行を決して出力しないでください。スナップショットが存在する場合は、その SHA と git stash apply <sha> の復旧行を引き継ぎ事項に記載します。Git は到達不能なオブジェクトを独自のスケジュールで削除するため、効果を誇張せず、その旨を伝えてください。
• 未追跡ファイルは別途保護します。 スナップショットには未追跡ファイルは含まれません。ミューテーションが未追跡のソースファイルに触れる前に、そのファイルを台帳にコピーします。
• 各ミューテーションを、それぞれ直前の状態に対する独立したパッチとして記録します。 ミューテーションごとに、その前にファイルを台帳内の新しい mutation-NN/ ディレクトリにコピーします。実行後、そのコピーとファイルとの差分を取ります。あるファイルに対する最初のミューテーションの前には、.base コピーも保存します。古いコピーに対して作成したパッチには、それ以前のミューテーションも含まれるため、適用を戻すと変更が二重に戻されます。ミューテーションごとに、ファイル、パッチ、検証対象の動作を記載した行を残します。
• 記録したパッチを patch -R で逆適用して戻します。ファイルを復元してはいけません。 git checkout -- <file> は反射的に実行しがちな操作ですが、既存の未コミット編集を気付かれないまま破壊してしまいます。ベースライン時にクリーンに見えたファイルにも、この禁止には例外がありません。考慮が必要な例外を設けた禁止は、禁止とは言えないためです。
• 逆適用で競合が発生したら、実行を止めて報告します。 強制してはいけません。復元で代用してはいけません。
• 完了を宣言する前に、ベースラインを検証します。 すべての変更済みファイルが .base コピーと一致すること、HEAD とインデックスが記録内容と一致すること、そして未追跡ファイルの一覧が testkit が作成したテストファイルを除いて一致することを確認します。ミューテーションが触れた未追跡ファイルは、すべて台帳内のコピーと一致している必要があります。意図的に残したものがあれば、そのパスを明記します。
• testkit が行っていない変更は、決して元に戻したり、stash したり、破棄したりしてはいけません。

完了ゲート

「完了」とは、すべてのテストが成功し、シャッフル実行され、クリーンであることを意味します。推測でコマンドを決めず、リポジトリ自体（package.json のスクリプト、Makefile、pyproject.toml、justfile、CI 設定）からコマンドを調べます。

• 新しいテストスイートが成功する。
• 残すテストはすべて、名前を明示したミューテーションに対して失敗することを確認済みである。
• テストスイートを連続して 2 回実行し、両方とも成功する。ランナーが対応している場合は、ランダムな順序で実行します。順序依存は、後付けのテストスイートに特有の不安定さの兆候です。既存の共有状態に対して書かれたテストは、その状態を引き継ぐためです。
• リポジトリ独自のビルド／型チェックが引き続き成功する。
• ソースツリーにミューテーションが残っていない。

ゲートに失敗した場合は、自分が作成した出力を修正して再実行します。試行回数はおよそ 3 回までに制限し、その後は停止します。ゲートに失敗したまま完了を宣言してはいけません。延々と繰り返してはいけません。ここで誘惑される修正はアサーションを弱めることですが、それは修正ではありません。

カバレッジ数値

目標にしてはいけませんし、終了条件にもしてはいけません。 パーセンテージを報告するのは、ツールチェーンがすでに数値を出力している場合に限り、変更前後の事実としてのみ報告します。

終了条件は、宣言された件数です。目標パーセンテージを設定することは、このスキルが防ごうとしている問題を正確に生み出す最も確実な方法です。上記の各ルールにはコストがかかりますが、数値はどのルールも守らずに達成できるからです。

引き継ぎ

このセクションは手順を示す文体で書きます。各文に指示を1つだけ含め、能動態、現在形を使い、比喩は使いません。

audit の後。 カバレッジの行、最上位のスライス、次点を順に報告します。台帳のパスを示します。実行で見つかった場合は、テスト容易性を妨げる要因と、既存テストのうち未検証のものを挙げます。テストコードはまだないと伝えます。次のアクションを1つ選び、最上位のスライスに対して cover を実行します。audit でファイルが書き込まれなかった場合は、対象範囲はすでにカバーされており、次のステップはないと伝えます。

cover の後。 次の項目を報告します。

• モードと、スライスの出所（台帳、ユーザー、インラインのランキングのいずれか）。
• 宣言された数と実際の数。例：「8つの振る舞いを宣言し、8つをカバー」。
• 作成・変更したファイル。ランナーの配線を含めます。
• ゲートの結果。実行したコマンド、保持したすべてのテストで失敗が確認されたこと、スイートが連続2回合格したことを示します。
• 削除したテスト。testkit が作成後、成功し続けたために削除したテストです。
• 未検証および範囲が広すぎる既存テストを、パスとともに示します。
• ベースラインのスナップショット：baseline snapshot: <sha> · recover with git stash apply <sha>、または baseline snapshot: none (no tracked change at start) · mutation patches in <ledger>。
• ツリーの状態。変更されたファイル、インデックス、未追跡ファイルの各ベースラインチェックの結果、または変更が残っているパスを示します。

すべての変更はステージングしないでください。git add は実行しないでください。コミットしないでください。コミットメッセージを作成しないでください。

次のアクションを1つ選びます。

• 台帳に保留中の作業がある → 次のスライスに対して、もう一度 cover を実行します。
• 実行で矛盾が見つかった → デバッグスキルがインストールされている場合は、そこに案内します。そうでない場合は、振る舞いと期待値のどちらが間違っているかを、誰かが判断する必要があると明確に伝えます。
• 実行でテスト容易性を妨げる要因が見つかった → リファクタリングスキルがインストールされている場合は、そこに案内します。そうでない場合は、テストする前にコードにシームが必要だと伝えます。
• 残りがない → スライスは完了したと伝え、次のアクションとしてコミットを挙げます。ユーザーが実行するメッセージとして test(<area>): cover <slice> などを提案します。自動的にコミットしてはいけません。

注意事項

• 成功を装わないでください。 「完了」と宣言する場合は、ゲートが実際に合格していることを意味します。範囲を限定した修正の後も失敗している場合は、失敗として報告します。
• ソースコードへの恒久的な変更はゼロにします。 書き込み可能な対象は、テストファイル、ランナーの配線、台帳のみです。変更はすべて一時的なもので、元に戻します。
• 分析は読み取り専用です。 Git の履歴、ファイルの読み取り、grep のみを使います。証拠を生成するために分析ツールをインストールまたは実行してはいけません。ディスク上にすでにある成果物を読み取り、新たに生成してはいけません。
• 案内するだけで、起動しないでください。 次に使うキットと1行の呼び出し方法を示し、実際には呼び出さないでください。
• 案内するだけで、必須にしないでください。 名前を挙げたキットがインストールされていない場合は、すべての推奨を具体的なアクションに置き換えます。testkit は、git 以外に何もない素のリポジトリでも役立ちます。
• ここでのデフォルトよりリポジトリの規則を優先します。 確立されたテストの配置、文書化された規約、またはリポジトリのエージェントガイドファイル（CLAUDE.md などの同等ファイル）に記載された方針がある場合は、それに従い、その旨を伝えます。
• ファイルシステムまたはシェルを使えない場合。 ファイルの書き込み、ゲートの実行、変更ができないため、失敗ゲートは実行できません。検証済みとしてテストを提示してはいけません。提案するテストはパス付きのフェンス付きブロックで示し、台帳は標準のパスを付けたコードブロックで示します。ユーザーが自分で実行する必要があるゲートコマンドを列挙します。