Accepted（2026-09-11決定、2026-09-12実装完了。checklist-v2-core.md参照）。V2でStrictDoc→markharness→Playwrightの縦方向の流れを実運用し、その観測結果から必要な完全モデルだけを追加する方針を定める。0020の記録名をExecutionBindingへ改めるが、保持する情報とMVPの責務境界は変更しない。
V2は、RequirementとTestCaseの対応、修正漏れ、Release Scope、検証手段を小さなモデルで扱う。一方、将来設計は、選定理由、Case revision・build・環境に対する実行結果、判断の失効、完全なIdentity lifecycleまで扱い得る。V2の運用前にこれらを実装すると仮説に基づく複雑性を固定するが、V2の簡略記録を後から完全な事実として読み替えると、存在しない履歴や証拠を捏造することになる。
特に、検証手段の登録、リリースでの選定、実際の実行、合格は異なる事実である。また、V2期間中の単純な削除から、将来のretire・restore・ID予約解除の意図を決定的に復元することはできない。この区別は永続形式を実装する前に固定する必要がある。
ExecutionStatusをExecutionBindingへ改称するV2が記録するcase_uid、mode: automated | manual、任意のreferenceは、実行状態ではなくTestCaseと検証手段の対応宣言である。現在の意味を型名にも反映し、設計・用語・新規CLIではExecutionBindingを正とする。
ExecutionBindingは実行日時、結果、Case revision、build、環境、attempt、証跡を持たず、その存在を「実行済み」または「合格」と解釈しない。0020の軽量化判断は維持する。
次の関係を不変条件とする。
ExecutionBinding ≠ ExecutionFact
ReleaseScope ≠ ReleasePlan
Spec-Reviewed trailer ≠ structured ImpactDecision / HumanAttestation
Git上の削除・再登場 ≠ retire / restore event
永続レコードと公開JSONはschema_versionを持つ。複数種類のレコードを同じ保存領域または出力で扱う場合はrecord_kind等により種類を明示する。将来型を追加するときは旧型へ空の予約フィールドを足すのではなく、新しい型として追加する。読み取り側は旧型の不足情報をunknownまたはlegacyとして扱い、推測で補完しない。
将来モデルから逆算してV2で維持する契約は、型付きUID、1 Scenario = 1 TestCase、Case UIDとCase revisionの分離、Requirementとの関連をCase revisionへ混ぜないこと、StrictDocの固定参照、Case UIDによるPlaywright binding、再現に必要なGit refと規則versionを結果へ含めることである。
将来のrunner、証跡、承認、Identity lifecycleのための汎用plugin機構、空のDomain型、状態遷移は先行実装しない。二つ目の実在Adapterまたは具体的な運用要求が現れた時点でseamを導入する。
V2導入後、StrictDocの変更から影響TestCaseを特定し、Case UIDでPlaywright testへ接続する流れを実際に使用する。Requirement単位解析の必要性、bindingの0件・複数件、parameterized test、Playwright project、retry、対象commit、ReleaseScopeと実行集合の差などを観測する。
観測は直ちに完全なExecution FactとしてGitへ保存することを意味しない。必要な照合条件と保存単位が実データで確認されてから、対応するDomain型とAdapterを別ADRで決定する。
Execution Factの適用可能性や完全なIdentity lifecycleを将来導入する場合、保証開始commitを明示する。cutoverより前のV2記録は、保持していないCase revision・build・環境・削除意図を後から推定せず、legacyまたはunknownとして扱う。
Identityについては0021の単純化を維持する。将来retire・restore・ID予約を再導入する場合は、cutover時点のactive identityと必要なretired identityをmigration manifestで確定し、それ以降だけを完全なevent lifecycleとして保証する。
ExecutionBindingへの改称により、AIや利用者が登録状態を実行状態と誤認しにくくなる。