Accepted(2026-10-07決定)。0027§5の「各フィールドの必須・非空規則を満たす」のうち、contributes_toに非空規則を課す読み方を否定する。
knowledge reconcileは、contributes_toを省略した新規Featureと、contributes_to: []を指定したFeatureを受理し、requirement_uidsが空のfeature.ymlを書く。knowledge removeも、最後のRequirementを削除すると、参照していたFeatureのrequirement_uidsを空にして残す(0034§3)。ところがfeature.schema.jsonはrequirement_uidsにminItems: 1を課していたため、これらの経路が書いた直後のmarkharness validateが[] has less than 1 item at /requirement_uidsで失敗した(Issue #84)。
minItems: 1は、Featureが必須の単一のrequirementを持っていた旧形式から、配列への変更時に機械的に引き継がれたもので、ADRで決めた規則ではない。論文§3.1のER図は、FeatureとRequirementの関連を}o--o{(両側ともゼロ以上)で示す。同じ図は、必須の関連を||で区別している。0034もrequirement_uidsを「任意の多対多参照」と呼ぶ。一方、0027 §5は、contributes_toを含むvalue collectionが「各フィールドの必須・非空・参照規則を満たさなければならない」と読める書き方をしていた。
requirement_uidsは0件以上とするfeature.schema.jsonからminItems: 1を外す。RequirementのないFeatureは正当な状態であり、knowledge reconcile(省略と[]の両方)、knowledge remove、markharness validateは、この状態について同じ規則に従う。
traceability・coverage・validateは、この状態を警告やgapとして報告しない。必要になった時点で、その時点の要求に合わせて足す(YAGNI)。
[knowledge].schema_versionは上げないこの変更は、旧schemaで有効だったデータを、新schemaでも有効なままにする。0014がプロトタイプ期に求める、旧形式との誤比較のリスクはない。
phases・steps・resultsは1件以上が必要で、axis・contributes_to・proceduresには非空規則がないことを、0027 §5に明記する。
feature.schema.jsonの変更により、新規にmarkharness initしたプロジェクトのvalidateは、RequirementのないFeatureを受理する。[]を拒否し、knowledge removeで最後のRequirementの削除を拒否するか、参照するFeatureを連鎖削除する必要がある。Requirementを後から付ける作成途中の状態が表現できなくなり、論文のER図の}o--o{とも合わない。