Accepted(2026-09-11決定、2026-09-12実装完了。checklist-v2-core.md参照)。0020が定める「実行結果・証跡をmarkharnessの責務から外す」方針は維持したまま、「そのリリースで何を検証対象に選んだか」だけを記録する最小の型を追加する。0025により、将来のReleasePlanとは別のrecord kindとして維持し、完全な計画へ読み替えない。
markharness-v2-design.md§1の問い3は「前回リリースにおいて、どのテストが検証スコープに入っていたかを確認する」ことである。
0020のExecutionStatusは検証手段(automated/manual)とその参照先だけを持ち、日時もリリース番号も持たない。そのためGit refを指定して過去時点を再現しても、答えられるのは「その時点でKnowledgeに登録されていたTestCaseと検証手段」までであり、「そのリリースで実際に検証対象として選んだ集合」ではない。設計レビュー(2026-09-11、SP-05)はこの点を指摘し、登録状態と選定を混同しないことを求めた。
一方、旧v2設計のVerification Plan/EvidenceSelection/Execution Manifestのような重量級の契約オブジェクトは0020で明確に否定されている。必要なのは「選んだものの一覧」だけであり、選定の承認・履歴・結果ではない。
ReleaseScopeを追加するReleaseScope {
release_id, // リリースの表示名(Git tag名を推奨)
case_uids: [case_uid], // そのリリースで検証対象に選んだTestCase
}
TestCaseの参照は表示IDではなくCase UIDで行う(0013、rename耐性)。
選定日時、選定者、承認状態・ステータス遷移、合否、実行結果、対象ビルド、実行環境、選定理由の構造化フィールドは持たない。これらが必要な場合は別ツールの責務とする(0020と同じ線引き)。選定の経緯はGit履歴が記録する。
.markharness/releases/<release_id>.ymlとしてGit管理下に置く。これにより--at <ref>で過去時点の選定リストをそのまま再現でき、算出の再現性(設計書P3)が保たれる。
release_idはこのパスの単一の構成要素になるため、値を安全な範囲に制限する。ASCII小文字英数字・ハイフン・ドットのみを許し、空文字、.・..そのもの、先頭がドットの値、パス区切り(/・\)やドライブ指定を含む値は、ファイルを作る前に拒否する。これは現行src/generate.rsのrequire_valid_slugが、id:フィールドがgenerated/testcases/のディレクトリ構成要素になることを理由に同じ検証を課しているのと同じ扱いであり、.markharness/外への書き出しやディレクトリ横断を構造的に不可能にする。v1.2.0のような一般的なtag名は許可される。書き込みはsrc/fs_safety.rsの原子的置換経路を用いる。
markharness release scope setで人が選定リストを記録・置換する。markharnessは選定内容の妥当性を判定せず、自動生成もしない。選定リストが無いリリースについては、Release Coverageは従来どおり登録状態の一覧だけを返す。
ReleaseScopeに含まれることは「選んだ」という宣言に過ぎず、実行された事実でも合格した事実でもない。出力でも「選定済み」と「実行済み」を同一視しない。
markharness coverage --release <release-id>で、選定されたTestCaseの検証手段の有無、選定漏れ候補(対象Requirement/Feature配下にあるが選定リストに無いTestCase)、その時点のKnowledgeに存在しないCase UIDを一覧する(設計書§6.2)。ReleaseScopeが記録されているリリースについてのみ「何を選んだか」まで答えられる。記録の無いリリースでは登録状態の再現までである。