Accepted(2026-09-12実装完了。checklist-v2-core.md参照)。markharness-v2-design.mdの再設計grillingセッション(2026-09-11)に基づく。0013のうち、retire・restore・release・reissue(同一UIDでの明示的な復元、旧idの予約解除)に関する部分を置き換える。UID発行、UIDとidの分離、rename時のUID維持など、それ以外の決定内容はそのまま有効。将来完全なlifecycleを再導入する場合のcutover原則は0025で補足する。
0013は、.markharness/identity-events/へのappend-only eventを唯一の正準情報源とし、retire・restore・release・reissueを含む厳密なidentity lifecycleを実装した(src/identity/配下、約9,000行)。これにより、退役した要素の同一UIDでの復元、退役後の人間向けIDの別UIDへの再割り当て(release)、それらの整合性監査(IdentityAuditor)が可能になっている。
grillingセッションで「既存の設計や概念に引っ張られない」前提でNorth Starから再検討した結果、次の判断に至った。
これはCLAUDE.mdのYAGNI原則(“いつか必要になるかもしれない”は実装理由にならない)に照らした判断である。
FeatureまたはTestCaseがknowledge/から削除された場合、それは単純にKnowledge treeから消えた要素として扱う。UIDの再利用禁止や、退役後の特別な状態遷移(retired)は管理しない。
削除した要素と同じ内容のFeature/TestCaseが再度追加された場合、それは新規の別要素として扱う。過去のUIDを引き継ぐ明示的なrestore operationは提供しない。過去の対応関係(feature.requirement_uids等)を新しい要素で必要とする場合は、人が新しい要素に対して設定し直す。削除前のUIDを引き継ぐ判定ロジックは持たない(内容一致による自動復元は、本節冒頭の「新規の別要素として扱う」と矛盾するため導入しない)。
本決定が保証するのは新規作成操作の側である。すなわち、CLIで新しい要素を作れば新しいUIDが発行され、内容が過去の要素と一致することを理由に旧UIDを推定することはない。一方、削除したKnowledgeファイルをGit履歴からそのまま復元した場合、ファイル内のuid:が戻るため当時のUID(およびScenario UIDから決定的に導出されるCase UID、0017§3)が復活する。これはmarkharnessの機能としての復元ではなくGit履歴操作であり、本ADRはこれを禁止も検出もしない。「同じ内容を再度追加すれば必ず別UIDになる」という、より強い主張はしない。rename(削除を伴わないid変更)時のUID維持は0013のまま有効であり、本ADRの対象外である。
release event・ID予約解除の仕組みは廃止する退役した要素が使っていた人間向けID(id:)を別要素へ再割り当てする際の、明示的なrelease操作・予約解除記録は不要とする。ID重複時の挙動(0013が定めるUID発行規則)は維持するが、退役済みIDの再利用可否を判定する専用ロジックは持たない。
.markharness/identity-events/のappend-only eventモデルは、UID発行・renameの範囲に縮小するIdentity lifecycleとしてeventで記録するのは、UIDの新規発行とrename(id変更時のUID維持)に限る。retire・restore・release・reissueのevent種別、およびそれらをreplayするIdentityAuditorの該当ロジックは実装しない。
src/identity/recovery.rs(742行)・src/identity/audit.rs(816行)のうち、retire/restore/release/reissueに関する部分は、本ADRの方針に沿って実装時に縮小対象となる(実装作業は別途チェックリスト化する)。UID発行・rename・migrationに関する部分は維持する。