rules hold criteria not provenance

ルールは基準を持ち、来歴は git に置く

Question

instruction としてセッションへ読み込まれる本文に、その規則を生んだ来歴を書き残すか。

Current resolution

書かない。落ちるのは来歴を述べている記述そのものであり、番号ではない。

適用の瞬間に消費されるのは基準と現在の状態であり、それがどう書かれるに至ったか（どの issue が提起し、どの PR が確定させ、どの commit が動かしたか）は、その瞬間に立っている誰にも消費されない。したがって来歴の語りは常駐すべき state ではない。番号は来歴の運ばれ方の一つであって、落ちる単位ではない。番号を伴わない来歴の語りも同じく落ち、基準を述べている文に付いた番号はその文から番号だけが落ちる。

三つの型

型	内容	操作
(a)	文は規則を述べており、番号はその装飾	番号を外す。文は残す
(b)	文そのものが来歴	文ごと落とす
(c)	一つの記述に現在の状態と来歴が同居	現在の状態を残し、来歴部分を落とす

番号の有無は型を決めない。

三つの型は分類の箱ではなく一つのテストの結果である：来歴を取り除き、何が残って立っているかを読む。なお規則を述べていれば (a)、一部がなお現在の状態を述べていれば (c)、基準も状態も残らなければ (b)。操作には二つの但し書きが付く。除去の単位は来歴を運んでいる範囲であって固定された文ではないこと（括弧が日付と検証も抱えているなら括弧ごと。番号だけ抜けば断片が残る）、および後続の文が落としたものに寄りかかっている間は除去が終わっていないこと（先行詞を連れて行くため、参照側を同じ編集で直す）。

いずれも brake 1 が実測で示した。評価者 3 体は同じ文に対して異なる型を割り当てており（main-agent-procedures.md:55 は (a) / (c) / 曖昧に割れた）、表が型を一意に決めていないことがその場で再現した。

scope

「instruction として読み込まれるか」で閉じる。含めるのは rules/ と skills/、および adapter/ のうち同じ形でセッションへ届くファイル（host instruction ファイル、エージェントの prompt 定義、およびそれらの中の値）。

対象外は、そこへ置く性質とセットで二つ。

• 適用の瞬間に読み込まれない面 — hook script（.sh / .ps1）のコメント、エージェント設定中のコメント行、bootstrap 時にのみ読まれる仕様書。本規律は「rule の前に立っているときに何が消費されるか」に依拠しており、ここにはその立ち位置が無い。ただし hook script は同一ファイルの中を線が通る最も鋭い例で、コメントは対象外だが、その script が出力する文字列は対象側に入る（出力された瞬間、読み手はその前に立っている）。node 不在時に additionalContext として注入される静的文字列がこれに当たる
• 来歴を意図して保持する retrieval 面 — docs/ と wiki。skills/model-trigger-check-gate-actions/SKILL.md の Retrieval tools が、attribution と timeline を git log / git blame へ、過去判断を issue / PR への RAG へすでに振り分けている。rule 本文はもともとその宛先ではない。到達可能性はここで手放されるのではなく、もとから在る場所に留まる。

拡張子もディレクトリも基準にならない。同一ファイルの中を線が通ることがある（コメントは対象外側、prompt の値は対象側）。この書き方であれば、adapter/ 配下で layer: L1-model を宣言しているファイルについても layer 軸・directory 軸のどちらで読んでも同じ集合に入るため、軸の選択が不要になる。

但し書き

• 基準の根拠を落とす許可ではない。 基準を述べていない文から番号だけ抜けば、背後に何も無い主張が残る。その文は (b) であり、操作は文ごと落とすこと。番号へ手を伸ばす前に型を読む。番号を外して文が残るのは (a) だけ。
• format サンプル中の番号は削除ではなくプレースホルダ化。 サンプルの番号と生きた参照は読んだ時点で区別が付かない。

正本 = 本 entry 本文。rules/model/subtractive-structural-beauty.md の Criterion resident, provenance in git 節に置かれていたが、同ファイルを芯 4 節へ縮約した際に撤去された。運用上の兆候（provenance-in-text 系 3 項目）は skills/evolution-impression-literal-detection/SKILL.md の Detection signs に残る。

Edges

• conflicts with: li-plus-always-on-footprint-load-bearing — 同 entry の Current resolution は「always-on に乗っている内容は load-bearing」「これ以上の文脈圧縮は cargo-cult」と一般命題の形で述べている。本判断は always-on / skill 面を含む instruction 面に載る特定クラス（規則の来歴を述べている記述）が load-bearing でないと確定させたため、literal では衝突する。ただし同 entry が実際に論じたのは3つの構造的移設案（operations 層の skill 化 / hook 注入 / adapter dedup）であり、いずれの却下理由も本判断は動かさない。未解決点 = 一般命題の側に scope 限定（「構造的移設に安全な余地は無い」であって「内容の非 load-bearing 残渣は無い」ではない）を入れるか否か
• depends on: liplus-structure-as-retrieval-surface — 「説明に要る情報は retrieval 可能な surface に配置され、pre-stored vocabulary から出さない」という設計が前提。来歴の記述を落として到達可能性が保たれるのは、この surface 群が実在するからである。前提が崩れれば本判断は再評価対象
• relates to: always-on-duplication-removal-direction — 同じ always-on の分量を扱うが軸が違う。あちらは「同一内容のコピーが2つあるときどちらを残すか」、本 entry は「そもそも常駐すべき内容か」

背景

Master が 2026-08-10 の対話で確定させた。AI 側の初期主張は逆で、rules/evolution/initiator-autonomy.md Scope の実測記録（「経路は実測で載る、見込みでは載らない」を裏付ける番号群）を load-bearing として保持すべきとしていた。

AI の誤りは、基準の load-bearing 性と引用の load-bearing 性を混同したことにある。次の編集を実際に縛るのは基準文であり、過去の測定そのものではない。同じ区別を Li+ は一箇所ですでに書いていた——initiator-autonomy.md Governed surface の「What closes condition 2 is that criterion, not the entries below; the entries are the cases that have come up」。自分で述べた区別を、自分の記法が守っていなかった。

構造的な穴として言えば、rules/task/task.md は「Issue body = latest requirements snapshot, not history log」を、Decision Structure は「state-form entries であって time-ordered log ではない」を受け取っている。instruction として読み込まれる面だけが同じ規律を受け取っていなかった。

単位の修正（同日、着地後）

最初に着地した記述は、同一節の中で単位が割れていた。正しい単位で書けていたのは、経緯の記述を指した第 2 段落 1 文目と、「rule がどう書かれるに至ったかを語る文」を対象にした Detection signs 2 番目。単位が番号へ狭まっていたのは、「その来歴を運ぶ番号は常駐 state ではなく、例外なく落ちる」とした第 2 段落 2 文目と、番号の剥離操作を前提に書かれた但し書き 1 つ目。

実害は、来歴を語る文へ「番号だけを剥がす」指示を当てた場合に出る。「この一行は元々単独の規制ではなかった。〇〇（コミット△△）が、その代償を払う移動と一緒に導入した」という文から番号を抜くと、経緯の語りはそのまま残り、参照先だけが失われた文になる。剥離前より悪い。さらに但し書き 1 つ目はその状態に対し「直し方は基準を述べること」と処方しており、正しい答えである「文ごと落とす」に対して残す方向の修復を指示していた。

処方を「型を読み、(b) なら文ごと落とす」へ改め、あわせて scope を adapter/ の読み込まれる面へ広げ、除外を理由つきで明文化した。

制約

• 規律の確定と、一括除去は別の作業単位。本判断は前者のみ。
• 既存の計数（rules/ + skills/ 65 件、adapter/ 75 件）は grep のヒット数であって作業量ではない。単位が記述である以上、文単位で数え直す必要がある（件数は減り、消える文字量は増える）。本判断は件数を確定させない。
• 新しい除外を作らない。除外は理由とセットでのみ置く。

結論

採用 = 来歴を述べている記述を落とし、基準文と現在の状態のみを常駐させる。来歴は commit diff / issue / RAG が引き受ける。落ちる単位は記述であり、番号はその中に現れる一形態にすぎない。

却下 = 実測記録としての番号を例外として残す案（AI の初期主張）。閉じ手は基準文であって事例ではなく、事例に付いた番号は基準の外側にあるため、例外を置くと適用の瞬間に「これは実測記録か物語か」の判断が要求される。

却下 = 落ちる単位を番号とする書き方（当初の着地）。番号を持たない来歴の語りを取りこぼし、かつ来歴そのものである文に対して「番号だけ抜く」という、剥離前より悪い状態を作る操作を指示してしまう。

却下 = scope を拡張子やディレクトリの列挙で書く案。adapter/ を「読み込まれるか」で切ると線は拡張子を両方向に裏切り、同一ファイルの内側を通ることもある。

却下 = format サンプル中の番号を単に削除する案。サンプルは形式を示すために存在するので、削除ではなくプレースホルダ形にする。

関連

• issue #1721（規律の確定）、PR #1722
• issue #1723（落ちる単位の修正、adapter/ の帰属、除外の明文化）
• issue #1724（本 PR の brake 運用で表面化した別件 = brake 2 の verdict と merge SHA の対応）