Accepted(2026-10-08決定)。0027§5の「置換後の各要素は参照規則を満たさなければならない」が、置換されるproceduresをuse:で参照する他のScenarioに及ぶことを定める。
Scenarioのuse:ステップは、所属するBehaviorのproceduresに宣言された手順を名前で参照する(0017§2)。手順は独立したUIDを持たず、Behaviorの値である。そのためknowledge reconcileでproceduresを明示すると、collection全体が置換される(0027 §5)。
置換で手順を外す、または別名にすると、その手順をuse:していたScenarioの参照が解決しなくなる。ところが実装では、次の2つがそれを検出しなかった。
knowledge reconcileは、use:を、Intentに記載したScenarioについてしか検査しなかった。Intentに記載していないScenarioは、proceduresの置換後も未検査のまま保存された。markharness validateは、proceduresとuse:を突き合わせなかった。その結果、reconcileもvalidateも成功した後で、手順を展開するgenerate・verify・traceabilityがphase step references unknown procedureで失敗した。validateが通る状態と、後段が成功する状態が一致していなかった。
0027 §5の「置換後の各要素は参照規則を満たさなければならない」は、置換されたcollection自身の要素について述べた文で、置換される手順を参照する他のScenarioは対象に含むのか、明記されていなかった。
validateは、すべてのScenarioのuse:を所属Behaviorのproceduresと突き合わせるuse:が、所属Behaviorのproceduresにない名前を指していれば、そのScenarioファイルの問題として報告する。reconcileを経由しない手編集も、同じ規則で検出する。
reconcileは、proceduresが変わるBehaviorの、Intentに記載していないScenarioも検査する既存Behaviorのproceduresが現在の内容から変わる場合、そのBehaviorの下にあり、このIntentが記載していないScenarioのuse:を、置換後のproceduresに対して検査する。解決しなければinvalid_procedure_referenceで拒否し、何も書かない。検査の境界は次のとおり。
use:をやめるScenarioを書けば、手順を外せる。proceduresを省略したBehaviorと、proceduresの内容が変わらないBehaviorは、検査しない。手順が変わらないので、新たに壊れる参照がない。use:の自動書き換えは作らない手順の改名は、旧名を外して新名を足す置換と区別しない。参照するScenarioのuse:を追従して書き換える機能は作らない。拒否された場合、利用者は手順を残すか、同じIntentにScenarioの更新を記載する。要求されていない機能であり、必要になった時点でその要求に合わせて足す(YAGNI)。
use:が解決するかどうかの判定は、knowledgeモジュールの1つの関数(unresolved_procedure_uses)にまとめ、validateとreconcileの両方が同じ規則を使う。generateの展開時のエラーは、そのまま残す。
validateが新たに報告する。reconcileは今のままとし、validateだけで検出する: 壊れた状態が保存されてから気づくことになる。reconcileのfail-closedな原子的保存(0027)の方針にも合わない。use:を自動で書き換える: 手順は名前をキーとするvalueで、改名を表す操作が存在しない。追従のための機構を、要求がないまま足すことになる(YAGNI)。proceduresを明示したBehaviorを、内容が変わらなくても常に検査する: 手順が変わらないなら新たに壊れる参照はなく、既存の壊れた参照を、無関係な更新の拒否理由にしてしまう。