Accepted(2026-09-12実装完了。checklist-v2-core.md参照)。markharness-v2-design.mdの再設計grillingセッション(2026-09-11)に基づく。0017§5「実行証跡と適用可能性」が定めるEvidence適用可能性モデルを、本ADRの範囲(TestCaseに付与する実行実績の記録)について置き換える。§1〜4(Scenario/共通手順/Case revision/分割・統合)は本ADRの対象外であり、そのまま有効。0025により型名はExecutionBindingへ変更されたが、本ADRの軽量化判断と保持情報は有効である。
0017は、実行結果・適用可能性・証跡の有無を分離し、Case UID・Case revision・対象ビルド・要求環境がすべて一致した場合のみ証跡を合格に採用する、という厳密なEvidence Applicabilityモデルを構想していた。これを土台に、後続のmarkharness-v2-design.md旧版はさらにEvidence/EvidenceSelection/Execution Manifest/Implementation revision/Environment matrixという重量級の型群へ拡張していた。
grillingセッションでNorth Star(このツールを使い終えた人が得たい答え)を改めて言語化した結果、実行結果について実際に必要なのは次の水準であることが分かった。
この水準は、0017§5が想定していたビルド・環境まで含めた厳密な突合よりも明確に小さく、Evidence/EvidenceSelection/Manifest/Implementation revision/Environmentという型群を新たに実装するコストに見合わない(YAGNI)。
TestCaseに付与する実行実績は、次の2フィールドのみを持つ。
ExecutionStatus {
mode: automated | manual,
reference: string (optional, free text — テストコードへのパスやURL等)
}
pass/fail/skip等の詳細結果、実行日時、実行者、対象ビルド、実行環境、証跡本体(スクリーンショット等)は保持しない。これらが必要な場合は、referenceが指す先(別ツール)を参照する。
TestCaseの参照は表示IDではなくCase UIDで行う(0013)。表示idのrenameで記録が切れないようにするためである。
用語上の注意：この記録は「実行された事実」ではなく検証手段(自動/手動)とその参照先を表す。実行日時・回数・合否を持たないため、値の存在を「最新のCase revisionで実行済み」と読んではならない。「Execution status」という名前はこの限界を含意しないため、実装時にフィールド名を変える場合も、意味は本節の定義を正とする。
0017§5が要求していた「Case UID・Case revision・対象ビルド・要求環境の一致」という厳密な適用可能性判定は導入しない。Change Impact/Release Coverageの算出では、TestCaseに紐づくExecution statusの有無とmodeだけを参照する。ビルド・環境単位での正確な合否管理が必要になった場合は、その具体的な要求が出た時点で別ADRとして再検討する。
Evidence本体の不変保存、EvidenceSelection、Execution Manifestという概念・型はmarkharnessに導入しない。CI連携による自動証跡取込も、要望が出た時点で改めて設計する後回し機能とし、MVPではExecutionStatusをCLIで人が記録する運用にとどめる。
自動テストツールへの直接連携(CI連携、reporter取込)はMVP範囲外とするが、mode: automatedかつreferenceにテストファイルパスを持つという形は、将来Playwrightのinventory/annotationと接続する際に無理なく対応づけられるよう意識する。ツール固有のフィールド(project、locator等)は現時点では追加しない。
src/execution.rsが持つtarget_revision・environmentフィールドは、本ADRの方針に沿って実装時に縮小対象となる(実装作業は別途チェックリスト化する)。