decision structure state form edge binding - Liplus-Project/liplus-language GitHub Wiki

state 形の要求をエッジの有無に結合し、変換は書き込みの瞬間に行う

Question

判断構造エントリの state 形は全 entry に要求するのか。既存の event 形エントリはどう扱うのか。

Current resolution

エッジ（特に supersede / conflict）を宣言する entry は state 形必須。エッジを持たない確定 entry は event 形のまま可。 一括移行はしない。

変換は convert-on-touch: update 分岐と supersede 分岐で当該 entry に触れるとき、その編集の瞬間に state 形化とエッジ描画を済ませる。後日の移行パスに回さない。

Edges

depends on: 判断記録 artifact を「履歴」から「構造」へ rename + 意味 shift — state 形 / edge taxonomy を導入した判断。本 entry はその要求の適用範囲を条件付ける
relates to: Hook-driven gate trigger — 「後で思い出して実行する」手順を構造に置き換える同型の判断（#1413）

背景

wiki 監査（31 entry）で 26/31 が event 形だった（state 形は最新 5 件のみ）。当初「強制書き込みが量を生んだが構造を生まなかった」と診断したが、再検証で訂正した:

live ノード間に supersede / conflict エッジがゼロなのは、大半が「まだ supersession が起きていないだけ」であり、書き手の描き忘れとは限らない。当初診断は over-claim だった
実在するズレは state 形 / event 形の不一致のみ

state 形が event 形に勝つのは判断が更新されるときだけである。エッジを持たない確定 entry を state 形に変換しても情報量は不変で churn しか生まない。逆にエッジを宣言する entry では、最新の判断状態が主語でなければ supersede 経路が現在 state に収束しない。

convert-on-touch は、既に load-bearing な書き込みが発生している瞬間に変換をピギーバックする。一括移行や「後で思い出して移行」は recall 依存であり、recall が落ちる側であることは #1413 で観測済み。

制約

既存 26 件の event 形 entry を一括で state 形へ移行しない
既存 entry を遡及書き換えしない（forward guidance）
supersede / conflict エッジ語彙そのものの温存 / 削除判断は別軸（実 supersession が複数回起きてもエッジが描かれない場合に subtractive 判断する）
L2 Evolution のみ。L1 不触

結論

採用 = エッジ有無への条件結合 + convert-on-touch。Master go-sign「a」。

却下 = 全 entry へ state 形を一律要求（エッジ無し確定 entry では churn のみ）。却下 = 既存 26 件の mass-migration（同上、かつ遡及書き換えの禁止と衝突）。却下 = 変換を後日の移行パスに回す（recall 依存で実行されない）。