Accepted(2026-09-11決定、2026-09-12実装完了。checklist-v2-core.md参照)。0017§1・§3が定めるnative Requirement(Feature⇄Requirementの多対多関連、Feature側が関係の正本)を維持したうえで、正本を外部仕様書に置くモードを追加する。
markharness-v2-design.mdの再検討(2026-09-11)では、仕様(Requirement)の正本をStrictDoc(.sdoc、Git管理)に置き、markharnessは固定参照(source_locator/source_revision)だけを保持する方針を確定した。しかし、この方針をrequirement.ymlの唯一の形として実装すると次の問題が生じる。
.sdocの取込・解析は同設計書のM3(将来)であり、M0〜M2では外部要件の実体を読まない。参照先が存在しないままsource_locatorを必須にすると、「誰も読まないファイルのblob OIDを固定するだけ」の状態になる。knowledge/requirements/<id>/requirement.ymlはlabel/description/axisとUIDを持つnative実体であり(src/knowledge.rs)、本リポジトリ自身を含め、StrictDocを併用していない利用が存在する。requirement.ymlにsourceを持たせるsource: native | externalを追加し、省略時はnativeとみなす。
label(必須)・description(任意)をmarkharnessが正本として保持する。source_locator/source_revisionは書けない。仕様側の変更検知はrequirement.yml自体のbase/head差分で行う(粒度はRequirement単位であり、外部ツールを必要としない)。
source_locator(markharnessと同一Gitリポジトリ内の.sdocパス)とsource_revision(固定したGit blob OID)が必須。label/descriptionは持てない(外部正本の複製禁止、markharness-v2-design.mdのP1)。仕様側の変更検知はsource_locatorが指す.sdoc blobのbase/head差分で行う。固定参照とheadのblob OIDの不一致はstale pinとして別に算出する。repinは仕様変更を打ち消さず、対応確認の代替にもならない(同設計書§6.1)。2026-09-11のレビュー修正により、従来の固定参照対headを変更検知に用いる規則を本規則へ訂正する。
両モードのフィールドを併せ持つ、あるいはどちらのモードとしても不完全なrequirement.ymlはvalidateで拒否する。
axisは両モードで保持するaxisはmarkharness自身の分類であり、外部正本の複製ではないため、externalモードでも保持する。
requirement.ymlはsource省略=nativeとしてそのまま有効であり、変換は不要。markharness requirement repin(固定参照の更新)はexternalモードのみに適用される。src/interactive.rs・knowledge_draft.rs)は、nativeでは現行のまま、externalを選んだ場合のみsource_locatorの入力へ切り替える。.sdoc解析がM3である以上MVP自体が成立しない。validateの分岐と変更検知の分岐に限られ、汎用化のための抽象化ではない。labelを残したままexternal参照も持たせる(両立)：外部正本の複製が発生し、どちらが正しいかを判定する規則が新たに必要になる。モードを排他にすることでその規則自体を不要にする。