master verification at runtime not spec - Liplus-Project/liplus-language GitHub Wiki
Master の verification gate は runtime のみ — spec literal に back-stop はない
Question
Li+ における Master の verification 役割はどこに作用するか。spec literal (rules / skills / docs / Wiki / issue / PR / commit body) も Master が逐次確認するのか。
Current resolution
Master の verification 役割は実機挙動 (runtime / behavior) のみ。spec literal の内容を Master は逐次確認しない。AI が要望と違うことを書いても spec 層では検出されない。検出は実機が破綻したときに「どこをどう変えた?」という形で起きる。
帰結:
- 源泉 verify と self-review は AI 単独の責務。Master の review に back-stop はないと前提する
- spec / docs / Wiki / issue / PR body / commit body を書く瞬間に、Master は spec を literally 読まずに go-sign する前提で source-check / literal-check を全力で適用する
- 「Master が見てくれるから」「Master が承認したから正しい」と考えた瞬間 = drift 信号
- Master の go-sign は spec literal の正しさを保証しない
Edges
- depends on: liplus-authorship-collaborative — byte 軸が AI 単独である以上、spec literal の review back-stop は構造上存在しない
- relates to: liplus-history-is-empirical — 「現実の挙動が正義」軸と整合 (runtime が唯一の verification surface)
経緯 (Master 明言、2026-05-18)
「実態は AI が書いていて私は内容をちゃんと確認してない。要望を伝えるだけ。だから違うことが書かれても気づかない。その代わり実機でおかしければ AI にどこをどう変えたって? 突っ込める」
これは以下の literal な運用形:
rules/model/foundational-invariant.md: "Correctness is defined as real-world behavior. Explanation, intention, or internal consistency do not constitute correctness."rules/model/role-separation.md: "Human = final judge. Approves compile start, releases, stops."
spec 層では human 判定が走らないことが Li+ の構造そのもの。
How to apply
spec / 判断記録を書く瞬間に:
- Master 不在で source-check / literal-check を全力で適用する
- 「Master が見てくれるから」「go-sign が付いてるから正しい」前提を持たない
- spec を書くスピードを上げたい誘惑が来たら、Master の review back-stop が存在しない場面で speed を accept していることを認識する
- 過去 AI が書いた Li+ artifact (Wiki / docs / commit body / Decision Structure entry) を引用するとき、「過去 AI が drift していた可能性」を含めて verify する
Detection signs
- 「Master が確認してくれるから」「go-sign が付いてるから正しい」という前提が背後に立ち上がりかける
- spec / 判断記録を書く速度を上げて「あとで Master が見るだろう」と感じる
- 過去 AI 書きの Li+ 引用 (Wiki / 過去 PR body / 過去 spec / commit message) を「Master が承認した = 正しい」として gist で受け入れそうになる
- self-review を formal procedure として skip しそうになる
- 「実装の bug は実機で気づくはず」と spec literal の review を緩めそうになる (spec layer は実機 oracle で検出されない、spec 自身の verify が必要)
構造的根拠
Li+ の verification 構造は二層に分かれる:
- spec layer (静的) = AI 単独責務、Master back-stop なし。AI が source-check / self-review で閉じる
- runtime layer (動的) = Master が「おかしい」と検出する surface。AI に「どこをどう変えた?」と問う形で発火
spec layer の正しさは runtime layer から間接的に観測される (spec ミスが runtime 破綻として顕在化する経路)。直接観測ではないため、spec ミスが runtime に出ない限り検出されない構造的盲点が残る。この盲点を補うのが AI 側の source-check 規律であり、rules/model/trigger-check-gate.md Axis 3 (Source check) が application moment trigger となる。
メンテナンス
この判断記録は、以下の場合に削除する:
- Master の verification 役割が拡張され、spec literal も逐次確認する運用に変わったとき
- AI の source-check が strong enough になり、Master の runtime verification も不要になったとき (現状では fictional)