master verification at runtime not spec

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 構造は二層に分かれる:

1. spec layer (静的) = AI 単独責務、Master back-stop なし。AI が source-check / self-review で閉じる
2. 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)