antithesis-mutation-testing

Antithesis ミューテーションテスト

スキルのバージョン： 2026-10-21 4f8d80b

目的と目標

テスト対象システムではなく、オラクルを検証します。

テストが成功しても、悪いことが観測されなかったことしか示されません。プロパティがそれを検出できたことを示すわけではありません。ミューテーションテストでこの曖昧さを解消します。各プロパティについて、そのプロパティを正確に破るように設計された現実的なバグを1つ注入し、Antithesis で実行して、プロパティが発火することを確認します。

成功の条件は次のとおりです。

• スコープ内のすべてのプロパティがミュータントによって偽とされるか、次の4つの判定のいずれかを持つこと：変更不能、未解決、撤回済み、または改良済み（references/evidence-and-report.md の「判定と修飾子」を参照）
• 各偽判定が、プロパティが無関係な連鎖反応によるものではなく、予測した理由で失敗したことを示す実行証拠によって裏付けられていること
• 途中で見つかった不適切なオラクルやワークロードの不足が修正されていること。不適切なプロパティは antithesis-research に差し戻されていること
• antithesis/scratchbook/mutation-testing/report.md に、スコープ内のすべてのプロパティの結果と、それを証明する実行が記録されていること
• ユーザーの作業ツリーにミューテーションが残っていないこと。すべてのミュータントはフォーク内にあり、clean.sh で確認できること。承認された修正はフォークに反映してかまいませんが、ミューテーションは反映してはいけません

プロパティカタログの作成には antithesis-research スキルを、ハーネスのひな形作成には antithesis-setup スキルを、アサーションとテストコマンドの実装には antithesis-workload スキルを使用してください。実行の送信には antithesis-launch スキルを使用してください。snouty launch を直接実行しないでください。結果の確認には antithesis-triage スキルを使用してください。

前提条件

• Antithesis スクラッチブック（通常は antithesis/scratchbook/）がない場合、またはコード内のアサーションより内容が古い場合は、それらのアサーションとベースライン実行からカタログを再構築してください。references/catalog-reconstruction.md を参照してください。これは作業を妨げるものではありませんが、スイープで主張できる範囲は狭まります。
• Antithesis の設定ディレクトリに manifests/ サブディレクトリが含まれている場合は、作業を進めないでください。Kubernetes ハーネスはまだサポートされていません。ミュータントの選択では、ミュータントごとに1つのイメージをビルドし、docker-compose.yaml 内のタグを差し替えます。このことをユーザーに伝え、停止してください。Kubernetes ハーネスには docker-compose.yaml がないため、以下の Compose の確認より先にチェックしてください。
• Antithesis 用の docker-compose.yaml がなく、manifests/ ディレクトリもない場合は、作業を進めないでください。antithesis-setup スキルを使用して Compose ハーネスを作成してください。
• SUT とワークロードのどちらにも Antithesis SDK のアサーションが1つもない場合は、作業を進めないでください。まず antithesis-workload スキルを使用してください。検証対象のオラクルがなく、再構築で代用することもできません。
• snouty がインストールされていない場合は、作業を進めないでください。インストール方法については https://raw.githubusercontent.com/antithesishq/snouty/refs/heads/main/README.md を参照してください。
• snouty が 0.8.0 より古い場合は、作業を進めないでください。バージョンの確認には snouty --version を使用してください。更新には snouty update を使用してください。
• このリポジトリ内でソースからビルドされる SUT サービスがない場合は、作業を進めないでください。一部のサービスはソースからビルドされ、残りはビルド済みという部分的なケースは問題ありません。その場合は、以下のスコープ設定で対応します。

ベースラインゲート

現在のコード状態でベースラインがグリーンであることが、ミュータントを設計する前提条件です。 バグのある SUT に対するミューテーションテストでは何も測定できません。発火したプロパティがミュータントによるものなのか、もともと失敗していたのかを判別できないためです。

グリーンとは： 安全性クラスのプロパティ（Always、AlwaysOrUnreachable、Unreachable）がすべてパスすることです。

それとは別に、変更する予定のプロパティが実行時のプロパティリストに実際に含まれているかを確認してください。これにはカタログスラッグとプロパティ名の対応付けが必要です。実行結果では name としてアサーションのメッセージ文字列が報告され、スラッグは報告されません。そのため、今のうちに references/sweep-and-verdicts.md の「Map slugs to property names first」に従って対応付けを作成してください。Antithesis がカタログに登録していないアサーションは反証できませんが、これはゲート失敗の理由にはなりません。見つからないプロパティはそれぞれ 未対応 — カタログ未登録 として対象外にし、残りの作業を続けてください（見つからない理由は references/catalog-reconstruction.md で診断します）。ただし、フォールバック SDK または JavaScript サービスの場合、見つからないことが意味するのは「この実行では検出されなかった」だけです。他と同様に変更し、実行イベントからマーカーを読み取ってください（references/catalog-reconstruction.md の結合テーブルを参照）。プロパティが一つも見つからない場合に限り、ハーネスは不完全なのではなく故障しています。そこで停止して、その旨を報告してください。

計測シグナルも確認してください。Software was instrumented、Symbols were uploaded、Thread pausing was enabled（antithesis-triage、references/instrumentation.md）です。これらを報告してください。ただし、カバレッジ計測に対応する言語の場合にのみ、ゲート条件としてください。Python はカタログ登録のみで、フォールバック SDK はこれらのシグナルを一切出力しません。その場合、ファザーにはダイバージェンスへ誘導するカバレッジフィードバックがないため、サバイバーに対しては 不適切なオラクル と診断するより、再実行時間を長くすることを優先し、その旨をレポートに記載してください。

グリーンであるために、実行内のすべてのプロパティがパスする必要はありません。

• Reachable または Sometimes が失敗してもスイープを妨げません。記録して antithesis-workload に引き継ぎ、対象範囲の検討に含めてください。同じ未実行領域にある安全性プロパティも、おそらく 未対応 — ワークロードの不足 になります。
• テレメトリとボリュームのプロパティ（Hypervisor utilization、Customer output volume など）は、SUT の正しさを示すシグナルではありません。無視してください。

安全性プロパティが失敗した場合、このスキルを停止します。 失敗を報告し、ユーザーに antithesis-workload または antithesis-research を案内してください。ただし、まず counterexample_count を確認してください。Always と Sometimes は Reachable を含意するため（antithesis-triage、references/properties.md）、到達していない安全性プロパティは、不変条件に違反していなくても失敗として表示されることがあります。counterexample_count が 0 より大きければ実際の違反であり、スイープを停止します。反例も実例もなければ、一度も評価されていません。これはカバレッジの不足であり、上記の失敗した Reachable と同様に扱います。

記録済みのベースラインを status.md で確認してください。そのベースラインが有効なのは、base_tree のフィンガープリントが現在のものと一致している間だけです。初回のスイープでは、references/evidence-and-report.md で定義された形式でこのファイルを作成し、継続的に書き込んでください。最後にまとめて書き込むだけでは、中断したスイープを再開できません。有効なベースラインがない場合は、references/sweep-and-verdicts.md の「Establishing the baseline」に従って確立してください。

カタログを再構築している場合は、この実行を最初に行い、プロパティリストを取得してください。ゲート自体は変わりません。名前を付けたカタログがあるかどうかにかかわらず、安全性プロパティがレッドならスキルを停止します。

上限は実行回数で定められています。測定したベースラインの実行時間が、面談で示された目安から大きく外れていても、変わるのはスケジュールであり、許可ではありません。再確認を求めず、上限内で続行してください。

定義と概念

• SUT： テスト対象システムです。
• ミュータント： ちょうど1つのプロパティに違反するように設計された、小規模で現実的なソースコードの変更です。独立したイメージとして構築され、mNN-<slug> 形式の ID で識別されます。
• 反証済み（キル）： ミュータントのマーカーを含む履歴において、そのミュータントの実行で対象プロパティが失敗し、ログ上、その理由が乖離に結び付いている状態です。実行全体のカウントでマーカーがグリーン、対象がレッドだったというだけでは該当しません（references/sweep-and-verdicts.md の「反証の帰属」）。
• 生存： ミュータントが実行され、バグのあるコードが実行されたにもかかわらず、対象プロパティがパスした状態です。通常はミュータント、オラクル、ワークロード、またはプロパティの不備を示します。判定手順では、単に探索で該当ケースに到達しなかった場合と、これらの不備を区別します。
• ベースライン： すべてのミュータントと同じソースから構築した、パッチ適用前の SUT の実行です。対照となります。
• base_tree： フォークの mutation-base コミットの Git ツリーハッシュです。記録済みのベースラインが引き続き適用されるかどうかを決めるフィンガープリントです。
• アナウンス： ミュータントのパッチが含む起動時のログ行です。正しいビルドがデプロイされていることを証明します。実行予算を消費する前に、ローカルで確認できます。
• マーカー： ミュータントのパッチが乖離の発生箇所で出すシグナルです。バグのあるコードが実行されたことを証明します。SDK がアサーションをカタログ化する場合は Reachable アサーションを、そうでない場合はログレコードを使用します。
• 付随的な損害： ミュータントの実行で失敗する、対象以外のプロパティです。想定されるものであり、証拠から真に独立した違反であると確認できた場合に限り、計上されます。

初回ヒアリング

まずスキャンしてください。質問2では安全性クラスのプロパティ数を N として尋ねますが、その数が分かるのはスキャンだけです。その後、ほかの作業に入る前に5つすべての質問をしてください。これらの回答によって、スキルがどれだけの予算を使うか、どこまで自律的に進めるか、ツリーに何を変更してよいかが決まります。

SDK のアサーション呼び出し箇所は必ずスキャンしてください。カタログがない場合だけではありません（言語ごとの表記については references/catalog-reconstruction.md を参照してください）。スキャン結果から、次の3つの状況のどれに当てはまるかが分かります。

• カタログがあり、スキャン結果とも一致している — 安全性クラスのプロパティ数を数えます。それがミュータント数です
• カタログがない — カタログを再構築します（references/catalog-reconstruction.md）。スキャンで得られた安全性クラスの数がミュータント数です
• カタログはあるが、スキャンで記載されていないアサーションが見つかる — カタログが最新ではありません。不足しているエントリだけを再構築し、その旨を伝えてください

どちらの場合も、各プロパティのクラスとともにプロパティ一覧をユーザーに提示してください。名前や範囲について修正するなら、予算を使う前に行う必要があります。

1. フォークの場所。 一時的に変更を加えるコピーを置く場所です。デフォルトはエージェントのスクラッチパッドです。また、コピーから除外する大きなビルドディレクトリがあるかどうかも尋ねてください（references/mutation-harness.md を参照）。
2. 予算と並行実行数。 範囲で提示してください。ミュータント N 個とベースラインで最低 N+1 回ですが、再試行、長時間の再実行、コア修正の各ラウンド後に行う全件再スイープを含めると、妥当な見積もりは約 5N 回です。セッション全体の実行上限として、この回数を提案してください。さらに、イメージセットのビルドが約 N × T 回必要になります。T はイメージセット全体のビルド1回分で、サービス数から見積もります。多くの場合、こちらのほうが大きな数になります。T と実際の1回あたりの所要時間（15分の実行なら、セットアップとレポート作成を含めて約45分）は、ベースラインで測定するまで分からないことを明確に伝えてください。その後、同時に実行中にできる実行数を尋ねてください。投入はどちらの場合も直列化されます（references/sweep-and-verdicts.md）。
3. ラウンド。 各スイープ後にチェックポイントを設けるか、自律的に繰り返すかを尋ねてください。
4. ソースへの変更。 アサーションやワークロードの修正をスキルがユーザーのツリーに直接適用してよいか、それとも適用せずに提案だけにするかを尋ねてください。どちらの場合も、ミュータントのパッチが実際のツリーに触れることはありません。対象となるのは、スイープで見つかった修正です。
5. 問題のあるプロパティについて。 停止して antithesis-research に引き継ぐか、カタログをその場で調整して（プロパティを修正するか、概念的に反証不可能な場合は取り下げて）、ほかのプロパティの作業を続けるかを尋ねてください。

自律的に進める、調整する、適用すると回答すると、収束するか予算を使い切るまで実行するワークフローになります。

予算を使う前に、回答を antithesis/scratchbook/mutation-testing/interview.md に記録してください。パス、5つの回答、合意した範囲（形式は references/evidence-and-report.md を参照）を記載し、回答が変わるたびに更新します。ここが、ユーザーの許可内容と停止したスイープの再開地点を記録する唯一の場所です。

ここで確定した実行上限は、このセッション全体に適用される継続的な許可です。 どちらのワークフローでも、上限内の後続ラウンドで再確認は不要です。次のセッションでは、再開時に一度だけ再確認します。上限を超えるラウンドは停止します。チェックポイント方式では確認を求め、自律方式では未完了の項目を記載したレポートを作成します。最初の起動から、上限に対する実行回数を status.md に記録してください。

ドキュメントに基づく確認

これらのページにアクセスするには、antithesis-documentation スキルを使用してください。snouty docs を優先してください。

• プロパティとアサーション：https://antithesis.com/docs/concepts/properties_assertions/assertions.md
• SDK リファレンス：https://antithesis.com/docs/reference/sdk.md
• フォールトインジェクション：https://antithesis.com/docs/product/fault_injection.md

参考ファイル

参考資料	読むタイミング
references/mutation-harness.md	常に — フォーク、パッチの配置、タグ、ビルド、検証
references/catalog-reconstruction.md	スクラッチブックがない、またはコードに追いついていない場合 — 変異対象のカタログを再構築する
references/mutant-design.md	プロパティのミュータントを設計する場合 — 3 部構成のパッチ
references/static-validation.md	実行を開始する前に、キルチェーンをたどる
references/sweep-and-verdicts.md	スイープの開始、ポーリング、生存ミュータントの分類、反復ループ
references/evidence-and-report.md	判定の記録と最終レポート
references/resume.md	前回のスイープで作成した interview.md がある場合 — 再開する

推奨ワークフロー

初回のスイープ

1. ソースをスキャンして SDK アサーションの呼び出し箇所を探し、開始時のインタビューを実施して、回答を interview.md に記録します
2. references/mutation-harness.md を読み、ハーネスを antithesis/scratchbook/mutation-testing/ にコピーし、各スクリプトが受け取るパス（--source、--patches、--images、--fork）を解決して、フォークを作成します
3. このリポジトリからビルドした compose イメージ名を antithesis/scratchbook/mutation-testing/images.txt に記入します（references/mutation-harness.md の「Tags」を参照）
4. ベースラインのゲート条件を満たします（上記参照）
5. スクラッチブックにカタログがない場合は、references/catalog-reconstruction.md を読み、アサーションとベースラインの実行結果からカタログを再構築します
6. ベースラインのトリアージを使って、対象範囲内のプロパティを選択し、実行されていないものは除外します（下記の「対象範囲」を参照）
7. references/mutant-design.md と references/static-validation.md を読みます
8. 対象範囲内の各プロパティに対してミュータントを 1 つ設計します。対応している場合は、サブエージェント 1 つにつき 1 つのプロパティを委任します（references/static-validation.md を参照）。一括分をレビューし、弱い候補、クラッシュしやすい候補、またはキルできない候補は、配線する前に却下します
9. 承認されたミュータントをフォーク内で作成します。各ミュータントに mut/<id> ブランチを 1 つ作り、sync-patches.sh でエクスポートします
10. ベースラインとすべてのミュータントイメージをビルドし、verify-mutant.sh で各ミュータントをローカル検証します
11. references/sweep-and-verdicts.md を読み、スイープを開始します。実行は合意した上限まで並行させ、select-mutant.sh → 起動を 1 組ずつ行います
12. 各実行をポーリングし、トリアージして分類します
13. references/evidence-and-report.md を読み、判定を記録してレポートを作成します
14. スイープが収束したとき、または中断したとき、および失敗後に clean.sh を実行します — 再開する場合は実行しません。未完了のプロパティが残る上限停止は、再開予定として扱います。フォークにはエクスポートされていないミュータントブランチが保持され、再開時の差分比較にはその base_tree が使われます（references/resume.md）。先にクリーンアップする必要がある場合は、sync-patches.sh を実行します。その場合、再開時にフィンガープリントのずれは実際の変更として扱われ、ベースラインが再設定されます

スイープ後の反復

1. references/sweep-and-verdicts.md を読みます
2. すべての実行が完了し、残ったものをすべて分類するまで、何も変更せずに待ちます。実行中に実ツリーの修正を適用すると、その実行の基準が無効になります
3. そのラウンドで診断された修正をすべてまとめて適用します。ユーザーのツリーに影響するものについては、インタビューの質問 4 に従います
4. 再フォークする前に、sync-patches.sh ですべての修正済みミュータントをエクスポートします。そうしないと fork.sh は処理を拒否します。これを --force で回避してはいけません（references/mutation-harness.md の「When a script stops on an assumption」を参照）
5. 2 分岐ルールに従って再実行します。ミュータントパッチのみの変更では、変更したミュータントだけを再実行します。SUT、ワークロード、またはアサーションに変更がある場合は、新しいベースラインを取得して全件スイープを行います。すべてのミュータントを再ビルドして検証してから起動します。タグはフォーク間で変わらないため、古いイメージが気づかれないまま実行される可能性があります
6. レポートを更新し、スイープが完了したら clean.sh を実行します

停止したスイープを再開する

予算の使い切り、チェックポイントの拒否、セッションの終了など、停止理由にかかわらず、状態を再導出するのではなく、記録された状態から再開します。interview.md がない場合は、初回のスイープです。その場合は、最初のインタビューを実施します。それ以外の場合は references/resume.md を読み、手順に従います。この手順では、status.md とプラットフォームの状態を照合し、古いフォークから未エクスポートの作業を救出し、記録されたベースラインが引き続き適用されるかを判断したうえで、現在の base_tree においてすでに判定があるミュータントを再実行することなく、上記 2 つのワークフローの適切な手順から再開します。

対象範囲

アサーションのクラス	取り扱い
Always、AlwaysOrUnreachable、Unreachable	変異させます。 安全性プロパティがグリーンであることは、あくまで否定的な証拠です。このスキルが排除しようとしているのは、まさに自明な条件によるパスです
Sometimes(cond)	ベースラインのみ。 Sometimes が失敗するのは、その条件がすべてのタイムラインで一度も成立しない場合だけです。そのため、前提条件に依存する微妙なミュータントは、前提条件に到達しないタイムラインではグリーンのままです
Reachable	ベースラインのみ。 Reachable がグリーンであれば、ワークロードがすでにシステムをその状態まで動かしたことが証明されています

「対象範囲内」とは、カタログ内の安全性クラスのプロパティすべてを意味します。 ミュータントが作成されるかどうかにかかわらず、レポートで扱う必要がある集合です。2 種類はミュータントを作成せずに判定しますが、どちらもレポートに含めます。

• ベースラインで未実行。 Always と AlwaysOrUnreachable では、ベースラインの example_count が 0 なら、アサーションが一度も評価されていないことを意味します。何も到達しないミュータントをキルすることはできません。ただし、15 分間のランダム実行はサンプルであり、検証する価値が最も高い、深くまれな状態を特に十分に網羅できません。対象外にする前に、より長いベースラインで確認し、その後 antithesis-workload に回して、未解決 — ワークロードの不足として記録してください。この判定は暫定的なものです。ラダーと同じく不適切なワークロードの作業依頼であり、ほかの実際のツリーの修正と同様に、質問 4 と上限に従います。スコープ決定時に確認してください。 例外として、Unreachable では example_count が 0 であることが正常な状態です。 ガード領域が実行されるかどうかは、ミュータントのマーカーが示す内容そのものです。クラスはアサーションスキャンから取得してください。カタログのTypeフィールドでは 3 つの安全性クラスすべてが Safety にまとめられるため、カタログだけを参照すると、すべての Unreachable が対象外になってしまいます。
• 変異不能。 そのプロパティは、このリポジトリでソースからビルドされないコンポーネント（標準のデータベースイメージやマネージドキューなど）が所有しています。これはハーネスに関する事実であり、プロパティの欠陥ではありません。対象から外す理由にはなりません。
• カタログ未登録。 アサーションはソースに存在するものの、ベースラインのプロパティ一覧には現れませんでした。references/catalog-reconstruction.md にある計装の診断結果とともに、未解決 — カタログ未登録として記録してください。ただし、サービスがフォールバック SDK または JavaScript を使用している場合は、存在しないのが通常であり、他のプロパティと同様に変異させます（該当する結合テーブルを参照してください）。同じ判定は、verify-mutant.sh を一度も通過しないミュータントや、パッチが STALE になった場合にも当てはまります。スイープで結果を得られなかったことを、そのまま報告します。

スコープを決める際、条件が明らかに満たされる Sometimes（名前以外は Sometimes(true) と同じもの）がないか確認してください。該当する場合は、antithesis-workload の自己レビューで求められている Reachable(...) への書き換えとともに、カタログの所見として報告してください。人の確認なしに適用してはいけません。

一般的なガイダンス

• 変更は常にパッチとしてのみ存在し、フォーク内に限られます。 ミュータントのパッチをユーザーの作業ツリーに適用しないでください。オラクルとワークロードの修正は作業ツリーに反映しますが、ミュータントを反映することはありません。
• 各プロパティにつきミュータントは1つとし、現実的なミスをモデル化します。 ガードの削除、比較演算子の反転、オフバイワン、クランプの欠落などです。破壊行為のような変更は避けてください。
• ループを不正に操作しないでください。 ワークロードを狭い決定論的な経路に追い込んで得たキルや、ミュータントを明らかな破壊行為のように粗雑にしたキルは、キルできない候補を正直に記録するよりも悪い結果です。目標は、緑のチェックマークを並べることではなく、実際のバグを検出するカタログです。
• アサーションを、それを検証することになるミュータントに合わせて付け替えても、何の証明にもなりません。 再スイープでのキルは循環論法です。アサーションが本当に誤っている場合にのみ実施し、単なる反証ではなく、精緻化後に反証された と記録してください。
• 不適切なオラクルを明らかにするミュータントは、回り道ではなく成功です。 発見した問題を、そのプロパティのエビデンスファイルに記録してください。
• 承認された修正を先送りにするのは、スイープを未完了のままにすることです。 インタビューの質問4で適用すると回答された場合、不適切なオラクル と 不適切なワークロード の診断は所見ではなく作業指示です。まず、ミュータント側で可能な低コストの修正を繰り返し、安定したら、実際のツリーに修正を反映して再スイープを実施してください。実行上限内で行います（references/sweep-and-verdicts.md の「反復」を参照）。
• プロパティの撤回より精緻化を優先し、黙って撤回しないでください。
• ミュータントの実行では意図的にプロパティが失敗します。 ユーザーの実際のテスト履歴における回帰と誤認されないよう、必ず専用の --source と --ephemeral を指定して起動してください。

出力

• antithesis/scratchbook/mutation-testing/patches/ — ミュータントごとに1つのパッチ。パッチセットが、組み込まれたミュータントの一覧です。
• antithesis/scratchbook/mutation-testing/mutants/{id}.md — ミュータントごとのエビデンス：対象、ミス、キルに至る連鎖、予測された判定と実際の判定
• antithesis/scratchbook/mutation-testing/interview.md — 合意した進め方、回答、範囲。後のセッションで再開する際の基点です。
• antithesis/scratchbook/mutation-testing/status.md — スイープの状態、ベースラインの記録、実行 ID。スイープ中に再開できます。
• antithesis/scratchbook/mutation-testing/history.md — 完了したすべての実行の追記専用ログ：実行 ID、ミュータント、対象プロパティ、試行、診断、実施した対応
• antithesis/scratchbook/mutation-testing/report.md — 対象範囲内のすべてのプロパティの結果
• 各 antithesis/scratchbook/properties/{slug}.md に追加される ## 反証 セクション
• カタログがない状態から開始した場合に再構築された antithesis/scratchbook/property-catalog.md と、そのエビデンスファイル、および existing-assertions.md
• ユーザーの実際のツリーに適用されたアサーション、ワークロード、カタログの修正

セルフレビュー

このスキルが完成したと宣言する前に、以下の基準に照らして出力成果物を確認してください。サブエージェントが利用できる場合は、このスキルファイルへのパスを渡し、新しいコンテキストのレビュアーに確認を依頼してください。

• interview.md にパス、5つの回答、合意したスコープが記録され、再開時の変更も含め、ユーザーが実際に許可した内容と一致している
• ミュータントを設計する前に、報告された base_tree でグリーンなベースラインを確立し、その実行 ID が status.md に記録されている
• スコープ内の各プロパティに、references/evidence-and-report.md の「Verdicts and qualifiers」にある判定が正確に1つ付いている。falsified 以外のすべてに理由があり、その判定を得た base_tree も記載されている
• 各反証には、対象プロパティの反例が由来する履歴とミュータントのマーカーを結び付ける証拠、および実行 ID が記載されている。実行全体のカウントを2つ並べるだけでは不十分であり、付随的な損害だけを根拠にしてはならず、最初に発火したことをもって付随的な損害を評価してはならない
• 起動したすべての実行で、フォークの設定ディレクトリが使用されている
• 各ミュータントは、ちょうど1つのプロパティを対象とする現実的な開発者のミスをモデル化している。意図的な破壊行為に置き換えられたものはなく、ミュータントを確実に検出させるためにワークロードが縮小されていない
• 生存したミュータントは、「プロパティが検出できなかった」と一括りにせず、キルチェーンのどの段階で失敗したかに基づいて分類されている
• 実際のツリーへの修正は、インタビューの質問4に従って適用または提案されている。静的トレースだけを根拠に修正しておらず、修正後には新しいベースラインと全件スイープを実施している。ミュータントのみに対する修正では再実行していない。また、再ベースラインと再スイープに十分な上限の余裕があるのに、質問4で許可された修正を未適用のまま残していない
• not mutatable を理由にプロパティを取り下げていない。取り下げた項目には理由があり、証拠ファイルには注記を加えて削除しておらず、有効なプロパティが検証されないまま残った SDK アサーションがあれば、レポートに記載されている
• スイープは合意した予算と同時実行数の上限を守っており、select-mutant.sh から起動までの間に、2つのミュータントが同時に進行中になることはない。完了したすべての実行に history.md の行がある
• 起動したすべてのミュータントについて、起動前に告知内容をローカルで検証し、その実行自体のイベントでも確認している
• 再構築されたカタログは、その来歴で再構築されたものであると明記されている。インタビュー中にアサーションのスキャン結果をユーザーに提示しており、レポートには、スイープで検証したのは既存のアサーションのみであると記載されている
• report.md には、スコープ内のすべてのプロパティが判定とともに記載されており、反証された場合はそれを証明する実行 ID も記載されている
• フォークが削除され、ユーザーの作業ツリーにミューテーションが残っていない