本文書は Li+ プログラムの進化レイヤー（rules/evolution/*.md + skills/evolution-*/SKILL.md）の仕様を定義する。 要求（何を満たすか）と仕様（どう振る舞うか）を一体として記述する。

進化レイヤーは、Li+ が自分自身を観測し、書き換えるための面を担う。モデルレイヤーが「どう走るか」のルールを置く面であるのに対し、進化レイヤーは「そのルールをどう書き換えるか」のルールを置く面である。二層は別々の面を担当し、勝ち負けの階層ではない。

---

（→ rules/evolution/evolution.md）

L2 Evolution layer は AI 主導の進化ループを一次軸とする。観測 → 評価 → 蒸留 → Li+ ソースの更新 → 挙動改善 → 次の観測までを AI 単独で走らせることを到達目標とする。現在は判断層の Sheepdog に到達しており、ループの起動権限は Evolution_Initiator_Autonomy（adapter/claude/CLAUDE.md）により AI 側にある。安全側の規律はマージゲートの brake（brake 1 = 全自己進化 PR に必須の skills/evolution-parallel-agent-eval。L1 Model Layer ソース変更も同じ 1 本を通り、L1 専用の brake は持たない）が担保する。基質層は入力駆動のポーリングのままであり（Claude Desktop では --channels が届かないと判断している。docs/G.-Sheepdog-Engineering.md「substrate 層は保留」節を参照）、基質層の Sheepdog は defer されている。

モデルレイヤーが「走るためのルール」であるのに対し、進化レイヤーは「ルールを書き換えるためのルール」である。両者は別の面を担当するため、層内順序に従ってそれぞれが自レイヤーの内部でのみ優先順を持つ。

L2 Evolution layer は L1 Model Layer を前提とし（Requires = L1 Model Layer）、共有された Li+ プログラムの上の自己更新面にあたる。観測と更新の責務がセッション全体にまたがるため、rules/evolution/evolution.md は常時ロードに置く。

rules/evolution/evolution.md の ## Evolution Layer 節は以前、レイヤー位置（Layer = / 自己更新面の一文 / Requires = / Load timing =）、Foregrounds（本レイヤーが前面に出す責務の一覧）、Backgrounded here（ランタイム不変条件は L1 に残る旨）、「走るためのルール / ルールを書き換えるためのルール」の対比、一次軸と到達目標と現在の状態を持っていた。どれも場面での行いを変えない。レイヤー所属と常時ロードは frontmatter（layer: L2-evolution、alwaysApply: true）が、責務の一覧は本書のロード条件の表が、一次軸・目標・現在の状態は本節が、ループの起動権限とマージゲートの brake は rules/evolution/initiator-autonomy.md と adapter/claude/CLAUDE.md の Evolution_Initiator_Autonomy が持つ。ランタイム不変条件が L1 に残る旨は同ファイルの Evolution Axis Separation が持つ。このため節は、ループの段の定義（skills/evolution-loop/SKILL.md）と起動権限・brake（rules/evolution/initiator-autonomy.md）への 1 行の転送点だけを残した（#2140）。この 1 行は見出しを残すための最小の本文で、読み手の行いを変えない。

---

（→ rules/evolution/evolution.md）

L2 Evolution layer はモデルレイヤーと同じ3種類の責務分類を使う。

分類	定義	判定基準
ルール	一文一制約。理由なし条件なし。破ったら壊れる	Absolute と同じ密度で書けるか？
責務	条件→行動。省略不可	外したら AI がやらなくなるか？
自律	AI が自律的に判断して動く領域	AI が自分で考えて行動を決めるか？

---

（→ rules/evolution/evolution.md）

項目	定義
進化ループ	観測 → 評価 → 蒸留 → Li+ ソース更新 → 挙動改善 → 再観測 の一周
種（seed）	最も動かしにくい位置に置かれるレイヤー。Li+ では L1 Model Layer
更新難易度プロキシ	接続チェーンにおける配置位置。L1 側ほど動かしにくく、L6 Adapter 側ほど動かしやすい
外部記憶ティア	判断を保存する場所の性質分離。memory と docs は別ティア

進化ループは AI 主導で全周を回す。変更ごとの spec 判断に人間 go-sign は不要で（brake が代替）、人間ゲートはリリース / 不可逆系の軸と execution-mode の minor/major レビューに残る。

---

進化レイヤーは責務ごとに異なる経路でロードする。責務ごとに独立した skill に分割しており、発火契機を満たしたものだけがロードされる。

責務	ロード経路	発火契機
Cold-start Synthesis	on-session-start.sh フック + rules/evolution/cold-start-synthesis.md	セッション開始（Claude は startup / resume / clear / compact / fork の全域、Codex は fork を除く4種）
Judgment Learning	skills/evolution-judgment-learning/SKILL.md	新しい判断を形成する前
Decision Structure Write	skills/evolution-decision-structure-write/SKILL.md	判断成立直後（human の go-sign、受容済み論点の close、対話中の spec 軸判断確定）、失敗の根本原因が判明したとき、前提検証の結果が確定したとき（成功・失敗を問わない）、複数セッションにわたる同一調査の反復に気づいたとき
Self-Evaluation	skills/evolution-self-eval/SKILL.md	外部観測可能な事実（人間の訂正、手順ステップの省略、CI 失敗）が発生して記録要否を判断するとき、および自己評価エントリを記録するとき
Observation Entry	skills/evolution-observation-entry/SKILL.md	自己進化 PR のマージ後の義務を走らせるとき、L1 基層に触れる PR がマージされたとき、self-evolution observation エントリが cold-start で due / overdue として surface されたとき、Post-L1-Merge Runtime Observation が miss を返したとき、短窓観測を繰り越す・その結果を追記するとき、pending のエントリが観察している面の application moment が起きたとき（エントリ書式・作成基準・適用場面の記録・判定の lifecycle。rules/evolution/memory-entry-format.md から #2131 で移設。L1 マージ後のランタイム観測の起点・観測セット・繰り越し。rules/operations/operations.md から #2141 で移設）
L1 Update Gating	skills/evolution-l1-update-gating/SKILL.md	L1 Model Layer ソース変更を検討するとき
Persistence Tiering	skills/evolution-persistence-tiering/SKILL.md	情報を memory と docs のどちらに置くか判断するとき
Evolution Loop	skills/evolution-loop/SKILL.md	observe / evaluate / distill / reflect / improve / re-observe のいずれかを実行するとき
Parallel Agent Eval	skills/evolution-parallel-agent-eval/SKILL.md	自己進化 PR が CI green に到達して merge ゲートが次に来たとき（brake 1 として必須）、Li+ rules / skills / adapter の編集ドラフトが PR フローの外で収束したとき、evolution-loop の observe / evaluate が経験的 verdict を必要とするとき、単独の self-check が positive に感じたとき、spec 改定提案に直交検証が要るとき、brake 1 の評価者の所見コメントまたは著者の裁定を書こうとするとき、brake 1 の 1 往復が CI green で戻ってきて次ラウンドか出口かを選ぶとき
Impression-literal Detection	skills/evolution-impression-literal-detection/SKILL.md	評価者が Li+ source ドラフトの impression-literal 固定軸に答えるとき、brake 1 の評価者プロンプトを組んでいて固定軸を載せるとき、ある語句が振る舞い意味を支えているか判定するとき（brake 1 の固定軸、本体は分割で #1598 に切り出し。固定軸がプロンプトへ入る文言＝ Prompt literal もここが保持する）
Rule Effect Measurement	skills/evolution-rule-effect-measurement/SKILL.md	Li+ ソースへ行や節を追加しようとしていて、既存本文の上での限界効果を議論ではなく実測で決めるとき、段1の注入腕プロンプトの情報源制約を書くとき、scripts/measure_rule_effect.py で段2の走行を組むとき、候補行の probe を書くとき、段1のゼロ差を行の削除根拠にしようとしているとき、二本の腕が返って判定を形成するとき、自己進化 PR が CI green に到達して brake 1 の前に実測を起こすか決めるとき、走行が取れなかったことを PR へ記録するとき
Evolution Full Run	skills/evolution-full-run/SKILL.md	明示呼び出し時のみ（「run evolution-full-run」または scheduled-task body が名指し）。consolidate → 完全進化ループ → full refactor を順に統括する thin orchestrator。full refactor には本文の蒸留（振る舞いを変えずに理由の文章や重複を本文から移して縮める。判定線と移し先は rules/model/liplus-coding-rule.md Body States Behavior。段 2 の distill 段とは別）を含み、他の refactor と同じく必要なときだけ行う。release は含まない（呼び出し側が付加）

また、rules/evolution/*.md のうち always-on で常在させるものは以下である。

ファイル	役割
rules/evolution/evolution.md	L2 レイヤーの常時ロード本文（Evolution Layer = ループの正本への転送点 / Axis Separation / Pattern Detection Surfacing）。目的と位置づけは本書の Purpose Declaration 節が持つ
rules/evolution/cold-start-synthesis.md	Cold-start Synthesis 手順定義と、各 surface が表示されたときのエージェントの振る舞い。フックは preamble を anchor としてここから抽出する。フックの出力仕様（emit 状態・fail-safe・パーティション、各 surface の section key・silent skip・走査の上限・表示の見出しの文言・並び・区切り）は含まず（emission が tally の解決パスと occurrence 件数を載せることは本文に残る）、本書の Cold-start Synthesis 節が持つ
rules/evolution/promotion-judgment.md	memory observation から Li+ 正規ルールへの昇格判定（cluster tally / 3 日 expire / 閾値ゲート / 閾値到達時の actor と発火モーメント / tally の保管面＝memory の外、ホストにつき 1 ファイル）
rules/evolution/memory-entry-format.md	memory entry の書式（summary + How to apply + 検知サイン）と運用規律（重複更新 / 撤回削除 / consolidate 発火）
rules/evolution/initiator-autonomy.md	自己進化ループ initiator 権限（AI 側）の詳細 scope。self-evolution PR 定義 / マージゲートの brake（brake 1 = parallel-agent-eval を全 self-evolution PR へ架けるゲート宣言。L1 も同じ 1 本。評価者数の床とループの終わり方（指摘ゼロのラウンドで出口、同じ指摘の再発で人間へ）は skill 側が持ち、本ファイルは数値を持たない。CI green と brake 1 の間に立つ実測は brake ではなく何もゲートしない旨もここが持ち、位置と発火条件の正本は measurement skill 側）/ 裁定主体 = 再開した実装 subagent / 伝達面 = PR のコメントスレッドで親は経路に立たない旨 / recovery 軸。条件 2 の除外面と、往復のあいだの親の分担・出口での一読は、使う場面が brake 1 の判定と往復に限られるので skills/evolution-parallel-agent-eval/SKILL.md が持ち、本ファイルはそこを名指す（#2146）
rules/evolution/autonomy-block-shape.md	adapter/claude/CLAUDE.md Autonomy ブロックの共通 spec（Explicit exclusion scope / literal verification / maintenance ref resolution の cross-block 定数）

自己評価の観測採点軸（10 軸）の正典定義は skills/evolution-self-eval/SKILL.md に統合する（rules/evolution/ からの hoist、#1239）。

Cold-start Synthesis だけは対話トリガー非依存のため skill 不適であり、フックで素材を stdout 出力してセッション冒頭のコンテキストに注入する。フックは素材を集めるだけで、合成判断は AI が Character_Instance で行う。

Cold-start Synthesis の本体は rules/evolution/cold-start-synthesis.md に独立配置する。フックは同ファイルの preamble（frontmatter を除外し、最初の H2 節の手前まで）を anchor として抽出し素材として出力する。H2 節（Self-Evolution Observation Surface / Promotion Tally Expiry Surface / Clone Branch Fetch Surface / Dependency Ordering Surface / Consolidate Due Surface）は surface が表示されたときの振る舞いであり、AI がステップ 3 の適用時点では参照しないため anchor に含めない。フックの出力仕様（旧 Hook Emission Contract 節と、各 Surface 節にあったフック実装側の記述）は #2118 で規則本文から外し、本書の Cold-start Synthesis 節「フックの出力契約」へ移した。ルールファイル自体は always-on でロードされるので、全文 emit は同一セッションの context に同じ本文を二重に載せていた。skill 経路は通らない。

モデルレイヤーの Loop Safety、受容済み論点の扱い、レビュー出力の分離はモデルレイヤー側に残す。これらはランタイム不変条件であり、進化レイヤーは自己更新のために観測するが再定義しない。

---

ルール = 一文一制約。理由なし条件なし。破ったら壊れる。Absolute と同じ密度で書けるものだけがここに属する。

（→ skills/evolution-l1-update-gating/SKILL.md）

• L1 Model Layer の変更は Li+ 内で最も高いゲートを通る更新である
• 既定の更新対象は L3 Task Layer 以降である
• L1 の更新には長期観測の裏付けを必要とする
• 単発セッションの印象で L1 を編集しない
• 観測可能なパターン証拠なしに L1 変更を提案しない
• L1 更新提案は直接編集ではなく issue として書く

L1 は種である。種は最も動かしにくくなければならない。接続チェーンにおける配置位置は更新難易度のプロキシであり、L6 Adapter 側が最も可変な端になる。

Boundary clarification（境界の明確化）:

• modifier 軸 = AI（CLAUDE.md の Sheepdog Engineering より）
• このゲートは観測的なものであって承認的なものではない
• 「最も高いゲート」= 最も高い観測閾値（最も多くの蓄積された証拠が必要）であり、human の承認要件ではない
• 「L1 を編集しない」「L1 変更を提案しない」= AI が観測閾値をスキップしてはならない、という意味であり主語は AI（人間ではない）

マージゲートの brake との関係:

• この観測ゲートはマージゲートの brake ではなく、マージの位置では発火しない。L1 Model Layer ソースに触れる self-evolution PR も、他の self-evolution PR と同じく brake 1（skills/evolution-parallel-agent-eval）だけを通る。L1 専用の brake は無い（rules/evolution/initiator-autonomy.md Merge brake）
• 二つは直交する軸であり、発火の瞬間が違う
  • この skill = 観測閾値ゲート（長期パターンを観測したか？ 主語 = AI）。issue 形成の時点で発火する
  • brake 1 = 収束した草案に対する実測検証。マージゲートの位置で発火する
• Human = final judge の地位（rules/model/role-separation.md）と release / 不可逆外部作用の human gate は別軸で不変

観測閾値の initiation 軸スコープ:

• 長期観測閾値は AI-alone initiation（人間不在で AI 単独が L1 変更を起こす）時の安全装置であり、不在の human 判断を蓄積証拠の重みで代替するもの
• human が directing する場合（human-initiated / AI-implemented）は、起点に human 判断が在る。観測閾値の役割を担うのはその human 判断そのものであり、それ単独で足りる。観測閾値は human-directed L1 変更の独立した前提条件ではない
• carve-out は initiation 軸だけで読む。解除するのは human 自身の directing であり、下流のゲートはこの carve-out にとって荷重を持たず、共条件として読んではならない。下流のゲートが判定するのは変更の内容であり、ここでの軸は誰が起こしたかである
• これはゲートの緩和ではない。観測駆動の L1 変更の AI-alone initiation は、観測閾値を hard requirement として不変に保持する。観測ゲートの主語はどちらの場合も実装側 AI である

観測閾値の起票の性質によるスコープ:

• 長期観測閾値は観測駆動の L1 変更にのみ掛かる。リファクタ駆動の L1 変更は、観測閾値を前提条件としない。射程はこの skill 冒頭の閾値の各行すべてに及び、単発セッションの印象の行も含む
  • 観測駆動 = 変更の根拠が、蓄積した同種 miss のパターンであるもの
  • リファクタ駆動 = 変更の根拠が、成果物そのものの実測（長さ・重複・辿れない参照）であるもの
• 性質は起票時に確定する。実装側 AI は issue からそれを読み取り、判断し直さない
  • issue が promotion marker label（rules/evolution/promotion-judgment.md Issue Creation Metadata）を持つ → 観測駆動
  • issue が promotion label を持たず、本文が起点として成果物そのものの実測を記録している → リファクタ駆動
  • どちらの行でも決まらない → 観測駆動
• 二つのスコープは独立に読み、閾値は両方が掛ける場合にのみ掛かる：AI-alone initiation（上の initiation 軸スコープ）かつ観測駆動の起点（この節）
• リファクタ駆動の L1 変更も、brake 1（skills/evolution-parallel-agent-eval）と merge 後の観測（rules/operations/operations.md Post-L1-Merge Runtime Observation、skills/evolution-observation-entry/SKILL.md）は不変のまま通る

（→ skills/evolution-persistence-tiering/SKILL.md）

• memory はワークスペース固有の個人ノート。リポジトリにコミットしない。RAG インデックスにも入れない。transient のみ（詳細は rules/evolution/memory-entry-format.md）
• docs はプロジェクト情報。リポジトリにコミットする。RAG インデックス対象である
• 書き出す前にティアを決める
• 設計判断・要求仕様・spec 級の内容は docs へ
• 個人的な振る舞いメモ・セッション固有の好みは memory へ
• ティアを無言で跨がない。memory から docs への昇格は明示的な意図を必要とする
• 書き込み直前の判定ゲート（write-time trigger）が発火するのは memory への書き込みだけである。保管先を別の規則が memory の外に定めている書き込み —— cluster tally（rules/evolution/promotion-judgment.md の Tally 節）—— では発火せず、judgment signals でその書き込みを分類しない（#2020）
• 永続情報の昇格先は 4 系統：Li+ 正規ルール（rules/ / skills/）／ docs/ ／ wiki（docs/Decision-Structure.md index 配下）／ 削除。詳細は rules/evolution/memory-entry-format.md の Escalation paths を参照

（→ skills/evolution-judgment-learning/SKILL.md）

• 新しい判断を形成する前に過去判断を検索する
• 第一優先は github-rag-mcp（mcp__github-rag-mcp__search、利用可能な場合）。issues / PRs / docs / releases / commit diff に対する hybrid retrieval（意味検索とキーワード検索を併用する dense + sparse 構成）
• クエリ順序: 手元に規則や行の文言があるなら、まずその文言を逐語で投げる（趣旨に言い換えない）→ 当たらなければ趣旨クエリ（補助）→ gh search。git log -S（pickaxe）は見つかったコミットの確認用であり、検索経路ではない
• フォールバックは gh search。キーワードベース
• Decision Structure Wiki エントリ（docs/Decision-Structure.md で index）は RAG に索引される。検索経路が設計上の前提である
• 「答えが自明に感じる」という理由で検索を省略しない。確かめる

（→ skills/evolution-decision-structure-write/SKILL.md）

• 判断成立直後に Decision Structure Wiki エントリを AI 自律で追記、新設、または refactor する
• Decision Structure は時間順 append-only の履歴ではなく、判断ノード（state 形エントリ）と supersede / depend / conflict edge による意味グラフ。volume は refine / replace で安定し、維持運用は refactor（normal operation）として扱う
• 新規エントリは state 形（Question / Current resolution / Edges）で記述する。既存エントリは遡及書き換えしない（forward guidance）
• 発火契機は human の go-sign 確定、受容済み論点の close、対話中の spec 軸判断確定、失敗の原因判明、複数セッション横断の調査反復
• 書き手側 surface であり、判断学習（読み手側）と対をなす
• 書く前に mcp__github-rag-mcp__search を type: "wiki_doc" で叩いて重複を確認する
• 本文を書く前に二つを問う。誰の判断か：判断記録はどのリポジトリの判断でもこの wiki の Decision Structure に置く（リポジトリごとに分けない）。entry を持つ wiki のリポジトリ以外が対象なら、本文冒頭に Target repository: <owner>/<repo> を 1 行書く。判断記録か要件仕様か：実装が満たすべき条件（契約・順序・データ形・success oracle）は要件仕様であり、entry に書かず対象リポジトリの docs/ に置いて entry からリンクする。その docs/ にまだ無ければ対象リポジトリに追加の issue を立て、entry からはその issue にリンクする。この振り分けは今回の書き込みに適用し、既存 entry の一括移動はしない
• 既存エントリ無効化時は削除せず supersede edge で前方参照する（graph 構造の維持）
• エントリ言語は LI_PLUS_PROJECT_LANGUAGE に従う。混在は不可。body 行の傍らに置かれた carve-out が同じ軸でここへ及ぶ——書き込み先の wiki が LI_PLUS_REPO のリポジトリ自身のものである場合に LI_PLUS_PROJECT_LANGUAGE が entry 言語へ届かない、というものである。正本は rules/operations/operations.md の ## Operations Rules。そちらを読む。ここには写さない
• 知識 wiki は射程外（本機構は判断構造 surface のみ）。対話トランスクリプトをそのまま本文にしない
• 書き出し先は docs ティアの Wiki surface であり、L1 Model Layer ソース変更ではない（L1 Update Gating には抵触しない）

（→ skills/evolution-impression-literal-detection/SKILL.md）

引き算的構造美（rules/model/subtractive-structural-beauty.md の Core principles (A)(B)(C)）を破りかけている兆候。brake 1 固定軸の positive 判定はこの列挙を出所とし、列挙自身は同 skill 内で load-bearing な観測面として保護される（再帰的に自らへ適用しない）。

• provenance-in-text 系（(A)）：rule の文が、今何を要求するかではなく、その rule がどう書かれるに至ったか（何を置き換えたか、誰が捕まえたか、いつ動いたか）を語っている（これが単位である。番号の有無によらず文が単位）／issue / PR 番号や commit SHA を instruction として読み込まれる本文へ書こうとしている（format サンプル中も含む。読んだ時点で生きた参照に見える。これは単位ではなく瞬間の tell であり、番号だけへ手を伸ばす前にそれが乗っている文を読む）／常駐 rule が、ルールセット自身が期限切れを保証している transient 成果物を指しており、読み手が辿った瞬間にその参照が解決しない
• push surplus 系（(B)）：「just in case」「in the unlikely event」「optionally」「as insurance」「may also list」「as a safety net」「fallback」といった言い回しが spec / rule / issue / PR / commit の下書きに出ようとしている／「for completeness」「for future reference」「as comfort」を内容の正当化に使う／人間が求めていない future roadmap・phase plan・再設計・最適化提案が出てくる／自動化や API 操作でもないのに出力が4概念ステップ以上に達する／出力量が精度ではなく投入労力に比例している／短い回答の後に「in summary」「to summarize」段落が付く／A・B しか聞かれていないのに A/B/C/D を列挙する／求められていない「you might also want to consider...」が表面化する／「While we're at it, also...」が表面化する
• default-reflex 系（(C)）：「内容を知らないから残す」「念のため持ち越す」保持既定／削除の重み付けを「すっきりする」といった感情反応が導く／scope を超えた「関係ありそう」の一掃的削除という破壊既定

---

責務 = 条件→行動。省略不可。AI が条件を判断し、条件に合致したら必ず実行する。

（→ rules/evolution/cold-start-synthesis.md）

セッション開始時、Li+config.md の実行が完了した直後にトリガーする。

1. docs/Decision-Structure.md（判断構造の索引）と直近の Li+ ソース変更を読む
2. 現在の Li+ 状態を合成する：active tag、直近の構造変化、未決着のスレッド
3. 合成結果を人間に報告する ── ただし条件付き

ステップ 1-2 は AI の内部プライミングとして常に走る。ステップ 3 だけが条件付き発話ゲートである。

フック連携の前提： on-session-start.sh フックがセッション冒頭で、直近リリースタグ・判断構造索引の先頭・自己評価ログの先頭・cold-start ルール anchor を表面化する。build-2026-05-11 以降、startup matcher では前セッションから変化のあった section のみを emit する diff-only 出力に変更された（context 消費削減）。cold-start ルール anchor だけは drift recovery anchor として常時 emit され、diff 比較対象から外れる。

startup matcher の出力 3 状態：

状態	条件	出力
full emit	初回セッション、fail-safe（state 欠落・破損・sha256sum/node 不在・レガシー単一パーティション形状・この session の LI_PLUS_AGENT_KEY が初回利用）、全 section 変化	全 section + footer に理由
diff-only emit	同一パーティション内で一部 section だけ変化	変化した section のみ + cold-start rule anchor + last_emit_at の読み戻し 1 行（前回 baseline が消費された時刻。この状態のみ。識別子は持たない。stamp が欠落・不正形式なら省く）
no-new-material marker	全 section 不変、かつ diff-only の外の 4 surface（observation surface / promotion tally expiry surface / consolidate due surface / clone branch fetch surface）がいずれも emit されていない	"No new orientation material since last session" 1 行 + cold-start rule anchor

silent skip ではなく marker を出すのは、session boundary が発生した事実を human が観察可能なまま保つため。

observation surface（memory/self-evolution-observation.md の due / overdue エントリ）、promotion tally expiry surface（tally の窓が閉じた cluster）、consolidate due surface（期限に達した memory consolidate）、clone branch fetch surface（branch を引けない LI_PLUS_REPO clone）のいずれかが emit された session では marker を出さない。4 面とも section key を持たないため diff-only 比較には載らないが、素材としては marker を抑止する側に数える ── overdue な項目や壊れた clone を提示しながら「新規素材なし」と述べるのは自己矛盾の出力になるため。

promotion tally expiry surface： cluster tally の expires が今日以前に達した cluster を cold-start で surface する。tally の保管先は #2018 で memory の外へ出た（正本は rules/evolution/promotion-judgment.md の Tally 節。具体パスはアダプタが決める）。expires < today は overdue として出し、両条件が成立する場合は overdue のみ（observation surface と同じ扱い。1 項目を 2 軸で出すのはノイズ）。tally 書式は verdict 欄を持たないため状態は読まない ── 閾値判定のどの帰結も cluster を消すので、書かれたまま残っている cluster は判定が未了であることそのものである。したがって判定が下るまで毎 session 再 surface され、判定を取らなかった session が契機を失わない。surfacing は観測であって自動実行ではなく、閾値判定の actor は surface された session を持つ agent、発火モーメントはその surfacing である（#1894。従来は閾値の判定内容だけが規定され、tally を開く契機が想起依存に残っていた）。判定そのもの（起票 / 既存の promotion marker issue への合流 / 削除）と、起票前および sub-threshold の全削除前に既存 issue との突き合わせを置く規定（#2006。ノイズ床が抑止するのは新規起票だけであり、既存 issue への合流は起票ではないため、occurrence が床に届かない cluster も既存 issue が覆っていれば削除せず合流させる）は rules/evolution/promotion-judgment.md の Threshold Rules を正本とし、閾値の数値は本節に写さない。

consolidate due surface： memory consolidate の発火条件（下の「Consolidate トリガー」。前回 consolidate から 2 週間、索引 MEMORY.md 先頭の **Last consolidate run:** 行で読み、行が無ければ発火）が成立しているとき、cold-start で「consolidate due」として surface する。発火条件そのものは同トリガーの正本（rules/evolution/memory-entry-format.md Consolidate Trigger）にだけ置き、本面は写さない。consolidate の本筋は書き込み時の整理（Entry Format の maintenance discipline）であり、週次の evolution-full-run がそこからこぼれた分の受け皿になる。ただし週次の回はレート制限で毎週は走らず（Master 2026-10-03）、その週が飛ぶと 2 週間の発火条件だけが整理を走らせる手段になる。この条件はこれまで起動時に誰にも知らされず、セッションが覚えていなければ走らなかった。本面はその受け皿も飛んだときの最後の網である（#2165）。observation / tally と同じく日付駆動で verdict 欄を持たない ── pass が条件を満たさない日付の記録行を書いた時点で出なくなり、それまでは毎 session 再 surface される。日付が暦日として読めない記録行は行が無いものとして扱う（前回実行を読めないときに黙ることが、本面が取り除く失敗そのものであるため）。actor は surface された session を持つ agent、発火モーメントはその surfacing で、その場で走らせるのは pass そのもの（同トリガーに従う）。フックは観測だけを行い、memory を書き換えず pass も走らせない。エージェントの振る舞いの正本は rules/evolution/cold-start-synthesis.md の Consolidate Due Surface 節、フックの出力契約は下の「フックの出力契約」。

clone branch fetch surface： LI_PLUS_REPO clone の remote.origin.fetch が source 側を refs/heads/ 以下に持つ refspec を 1 本も持たない状態を cold-start で surface する。そうした clone でも tag は解決するため fetch --tags は成功し、素の git fetch origin もエラーではなく no-op として成功する ── 何も落ちないまま branch の遅れだけが積み上がるので、surface が要る。述語は wildcard の literal 一致ではない（--single-branch の clone は branch を追えており該当しない）。この面は既存 2 面と同じ surface class に置くが、trigger の種類は 3 つ目である ── 既存 2 面は日付駆動、この面は state 駆動であり、借りるのは class の性質（section key 無し / diff-only 対象外 / 条件が成立する間は毎 session 再 surface / no-new-material marker を抑止）だけで、日付の語彙は借りない。そして state 駆動は lifecycle を持たない。 日付駆動の 2 面はどちらも明示的な除去を要する（observation は verdict を入れてエントリ削除、tally は閾値判定を経て削除）が、この面は条件が成立しなくなった瞬間に出なくなるので verdict_state も expires も除去手順も要らない。この不在は欠落ではなく設計であり、lifecycle を足すと「条件が消えたのに残るエントリ」という逆向きの実害が生まれる。actor は surface された session を持つ agent、発火モーメントはその surfacing であり、その場ですることは人への報告に限られる ── 修理は共有されたローカル git state の書き換えであり人の go-sign で行う（rules/evolution/memory-entry-format.md Artifact deletion calibration が local non-git config / state を caution high に置く）。LI_PLUS_UPDATE_STATUS には載せない（同 marker は adapter startup 手順 step 2 の起動条件であり reason で分岐しないため、検出のみの検査が更新手続きを起動する経路を持ってしまう）。エージェントの振る舞いの正本は rules/evolution/cold-start-synthesis.md の Clone Branch Fetch Surface 節、フックの出力契約は下の「フックの出力契約」（#1911）。

dependency ordering surface： LI_PLUS_REPO の open issue のうち、GitHub の Issue Dependencies で open な blocker（blockedBy）を 1 件以上持つものを、その blocker とともに cold-start で surface する。closed の blocker は数えない。着手順序はこれまでセッション開始時に AI が調査して再発見しており、その判断は外部記憶に残らず、AI やセッションが変わるたびに作り直されていた。順序はセッション間・AI 間で再現すべき判断であり（rules/model/language-definition.md External memory）、memory は transient only なので置き場にならない（rules/evolution/memory-entry-format.md Scope）。そこで順序を GitHub 側の関係として持ち、読み出しを調査からクエリへ置き換える（#1687）。

決めた設計軸は4つ。(1) 発火点は cold-start。 着手判断の瞬間に skill 側から引く形は想起依存になるため採らない（rules/model/subtractive-structural-beauty.md の、実行が保証されない手続きは構造へ置き換える原則）。この面は既存 3 面と違い内容駆動であり、section key（open_blocked_by_open_issues）を持って diff-only 比較セットに載る ── open in-progress issue と同じ扱いで、依存集合が変わらなければ再 emit しない。(2) blocked ラベルは残す。 ラベルは状態（human 入力待ち）、依存は関係（どの issue 待ちか）で別の情報であり、ラベルを依存グラフからの派生にはしない（rules/task/task.md Lifecycle の Relation axis）。(3) 依存を張るのは起票者。 起票時、または依存が判明した時点で、分かっている範囲で張る。親 issue / sub-issue の構造から導出はしない（rules/operations/main-agent-procedures.md Issue format の Dependencies）。surface は書かれた関係を読むだけで、欠けた辺を補修しない。(4) API は GraphQL。 読み出しは Issue.blockedBy、書き込みは addBlockedBy / removeBlockedBy で、gh CLI の依存フラグ（2.94.0 以降。出典：https://github.blog/changelog/2026-06-10-manage-sub-issues-types-and-dependencies-from-github-cli/ 、#1687 前提）の版には依存しない。Issue Dependencies は repo レベルの機能であり Projects を要さない。

走査は open issue 1 ページ分に限り、超過があるときはその旨を emission に書く ── 黙って切ると、不完全な順序を完全なものとして提示することになるため。解禁日・スケジュール（時刻軸）の表現は本面の射程外で、別の判断として保留されている。エージェントの振る舞いの正本は rules/evolution/cold-start-synthesis.md の Dependency Ordering Surface 節、フックの出力契約は下の「フックの出力契約」。

resume / clear / compact / fork matcher の挙動（fork は Claude のみ）： 作業 context は連続のため diff-only 評価は行わず、cold-start rule anchor だけを再出力する。state file は更新しない。

state file は {workspace_root}/.claude/state/last-cold-start-emit.json（sha256 fingerprint を section ごとに永続化、LI_PLUS_AGENT_KEY でパーティション分割。#1811）。詳細仕様と schema は 6. Adapter — on-session-start.sh を参照する。

フックの出力契約（#2118 で規則本文から移した、フック側の仕様）： rules/evolution/cold-start-synthesis.md が持つのは、エージェントが surface を受け取ったときの振る舞いだけである。フックが何をどう出すかは本節と 6. Adapter — on-session-start.sh が持つ。素材の収集と表示（見出しの文言・並び・区切り）はアダプタの選択であり、規則は固定しない。anchor の切り出し（frontmatter を除き、最初の H2 の手前まで。H2 が無いファイルは全体）と startup matcher の 3 状態は上で述べたとおり。

• fail-safe の集合（startup の full emit）： state file の欠落、読めない、sha256 不在、node 不在、レガシー単一パーティション形状、この LI_PLUS_AGENT_KEY の記録が無い、のいずれか。このうち sha256 不在と node 不在は bash 2 port の集合で、PowerShell port では発火しない（PowerShell port の fail-safe は state file とパーティションの理由だけ）。レガシー形状と初回キーの 2 つのパーティション移行理由は 3 port 共通である。
• パーティション： state は LI_PLUS_AGENT_KEY（既定 "default"）ごとに独立した {sections, last_emit_at} を持つ。未設定は旧来の単一パーティション挙動と（移行後のファイル形状まで）一致する。複数セッションが同じディレクトリを共有する場合に限り、各人の起動プロファイルで個別に設定する。詳細は 6. Adapter の「パーティション分割（#1811）」。
• surface ごとのフック側の仕様（surface が出る条件そのもの＝due / overdue の日付条件、refspec 述語、open な blocker は、rules/evolution/cold-start-synthesis.md の各 Surface 節が持ち、ここには写さない）：

surface	フック側の追加仕様	section key / diff-only	silent skip
self-evolution observation	ファイル解決は promotion candidates と同じ memory dir 経路（6. Adapter）	持たない / 対象外	ファイル不在、該当エントリなし
promotion tally expiry	tally は memory と独立に解決するので、memory dir が解決しない session でも tally に届く（パスは 6. Adapter）	持たない / 対象外	ファイル不在、窓に達した cluster なし
consolidate due	索引は observation と同じ memory dir 経路で解決し、MEMORY.md 単独でも memory dir として採用される（6. Adapter）。読むのは索引の先頭（最初の空でない行）だけで、それより下の記録の形の行は記録として扱わない。hook は memory を書かない	持たない / 対象外	memory dir 未解決、前回実行から 14 日未満（記録日が未来の場合を含む）
clone branch fetch	設定済み refspec と期待する形を併記する。LI_PLUS_UPDATE_STATUS には status としても reason 文字列としても載せない	持たない / 対象外	clone 無し（api mode）、git 不在
dependency ordering	GraphQL（Issue.blockedBy）で読み、gh CLI の依存フラグは使わない。リポジトリレベルの関係で Projects は要らない。走査は open issue 1 ページ分で、超過があるときは emission にその旨を書く	open_blocked_by_open_issues。diff-only 集合に載る（open in-progress issue と並ぶ）	クエリ失敗、open issue を待つ issue なし

運用基準（AI 側 step 3 ゲート）：

• フック表面化済みの項目 = silent（full / diff-only / marker いずれの状態でも、既に人間が受け取った素材を繰り返さない）
• 合成によって初めて見える独自の気付き（構造変化・未決着スレッド・成果物横断のパターンで、生のフック素材からは読み取れないもの）= 発話
• 合成しても独自の気付きがなければ silent skip
• no-new-material marker の状態では silent skip が自然な帰結。marker 自体が session boundary 発生の人間向け acknowledgement として機能する
• release の Latest 位置 = silent。フックが surface したタグ一覧に対する合成に見えても、「Latest が前版のまま」「flip 保留」を独自の気付きとして出さない。Latest flip は複数セッションにまたがる実機観測を前提とした human ゲートであり、AI 側からの表面化は orientation ではなく go-sign の催促になる（完了報告の瞬間に同じ規律を持つのは rules/operations/main-agent-procedures.md の ## Release completion report discipline）

目標はセッション開始時に Li+ 状態を人間に再説明させないこと、かつ重複オリエンテーションのノイズを出さないこと。フックが生素材を扱い（startup では diff-only economy つき）、ステップ 3 は合成差分だけを扱う。対象は Li+ 自身の状態であり、ワークスペースのタスク状態ではない。ワークスペース固有のオリエンテーションはアダプターの起動パスが扱う。

（→ skills/evolution-self-eval/SKILL.md）

対話品質と Li+ 準拠の二軸で自己評価する。

入力ソース（優先順）：

1. 人間のリアクション = 主入力。修正・承認・沈黙
2. 事実ベースの自己採点 = 補完入力。外部から観測可能な事象のみ

事実と内省の境界：

区分	定義	例
事実	外部から観測可能な事象	CI 失敗、手順ステップの省略、docs 更新の有無
内省	主観的な自己評価	「うまくやれた」 → 有効な入力ではない

軸	評価対象
対話	意図を正しく読めたか、応答が伝わったか、拡張が適切だったか
Li+	構造に従えたか、ルールを守れたか、判断が spec に基づいていたか

二軸の緊張関係：Li+ 厳密遵守は対話を硬くし、対話優先は手順を飛ばすリスクがある。どこでバランスを取ったかが各評価の核心。

領域タグ： エントリごとに領域タグを付与する。固定リストではなく、観測パターンから自然発生する（例：docs-sync, pr-procedure, dialogue-read, ci-loop, commit-format）。失敗エントリで繰り返されるタグは弱点領域を示す。

タイミングはトリガー条件で定義せず、AI が必要と判断した時に実行する。文脈が圧縮される前に記録する。事実ベースの自己採点は人間のリアクションを待たず、事実の観測時に記録してよい。

保存先はホストのメモリーシステム（単一ログファイル）。上限25件、超過時は古い順に削除。

原因分類は4値：spec-gap（仕様の不足）、reading-drift（読み方のズレ）、judgment-bias（判断の偏り）、success（修正なしで進行）。

同じ原因パターンが繰り返された場合、その出現を promotion-judgment の tally に記録する。noise floor の閾値を持ち起票の時機を決めるのは rules/evolution/promotion-judgment.md であり、閾値の数値は本節に写さない。この面での反復検出は観測であって起票トリガーではなく、閾値未満では起票しない。self-eval 由来の観測にゲートの免除はなく、同じ tally に載る。ゲートが起票を認めた時点で、Evolution_Initiator_Autonomy の initiator 経路で spec 改善を起票する。自己進化 PR は AI 主導で回し、brake 1（skills/evolution-parallel-agent-eval）を必ず通す。L1 Model Layer の変更も同じ 1 本であり、L1 専用の brake は持たない。変更ごとの人間 go-sign は不要で、人間ゲートはリリース / 不可逆系の軸と execution-mode の minor/major レビュー（rules/operations/execution-mode.md）に残る。

観測側採点軸（10 軸）： エントリの採点軸として skills/evolution-self-eval/SKILL.md に 10 軸を定義する（Assumption surfacing / Contradiction catch / Deepening axis fit / Silence respect / Loop entry / Character drift / Review partition / Gist vs literal / Expansion limit / Request depth）。これらは事後観測（post-judgment）のシグナルであり、事前の予防ゲートとは面が分かれる。同一軸で miss が反復するとき、進化ループの observe 段階における蒸留候補となる。harness-eng 系の指標（rework 率・PR cycle time・CI-pass rate 等）は入力にしない。

本セクションはモデルレイヤー仕様書からの移設である。モデルレイヤーはランタイム不変条件の面に純化し、自己観測と自己評価は進化レイヤーが担う。

（→ skills/evolution-loop/SKILL.md）

進化ループは6段階で一周する。

段階	内容
observe（観測）	memory エントリ + docs（spec、判断構造、issue 履歴）を読む
evaluate（評価）	二軸自己評価とパターン検出
distill（蒸留）	繰り返されるパターンから spec 級の信号を抽出する
reflect（反映）	Li+ ソースを更新する。既定ターゲットは L3 以降。L1 はゲートを通す
improve（改善）	更新された spec の下で挙動が変わる
re-observe（再観測）	新しい memory / docs 状態から次の周が始まる

実行モード：

• 現行 = AI 主導で全周を回す。各 PR は brake 1 を通す（L1 も同じ 1 本）
• brake 1 の設計判断の正当化は wiki の判断構造エントリが保持する（索引 = docs/Decision-Structure.md、取得 = skills/evolution-judgment-learning）。skill 本文と本節が持つのは適用の瞬間に要るものだけであり、正当化の二つ目の写しは置かない。以下の 判断記録: はその名指しであり、指す先の論証を本文へ書き戻すことがこの配置の拒む動作である
• skill 本文（skills/evolution-parallel-agent-eval/SKILL.md）は rules/model/liplus-coding-rule.md Body States Behavior を適用済みであり、振る舞いのみを載せる。適用は 2 周ある——1 周目が 2026-09-01（#1845、49,217 → 42,089 B。剥いだ理由のうち既存 entry が持たない分は判断記録 parallel-agent-eval-body-carries-behavior-only が保持する）、2 周目が 2026-09-09（#1923、42,621 → 38,596 B、−9.4%）。2 周目に残っていたのは理由づけではなく再掲が主であり、その所見と、今回剥いだ理由のうち本節も既存 entry も持たない分は判断記録 parallel-agent-eval-residual-is-restatement が保持する。抜いた跡へポインタは置かない（要件は #1852 で撤廃、判断記録 judgment-record-pointer-requirement-dropped）。本節は記録面であり同規則の scope 外——理由を持ち続けてよい
• どの PR が brake 1 の対象かは 2 条件の連言で決まる。①Evolution_Initiator_Autonomy の起票経路（AI 起票 → AI 実装）であること、②統治面を変更すること——の両方であり、片方だけでは決まらない。ユーザーリポジトリの bug-fix PR は②を、issue の段階で人間が起票した PR は①を満たさないため、どちらも対象外であり、別のゲート面（実行モードの人間チェックなど）に乗る。②を閉じるのは path の列挙ではなく基準であり、その基準と、それが該当／非該当へ置く面の解決は正本が持つ。本節へは写さない。正本は rules/evolution/initiator-autonomy.md Self-evolution PR definition（除外面とそれぞれを除外する性質は、PR を brake 1 の対象外と判定する場面でだけ要るので、#2146 で skills/evolution-parallel-agent-eval/SKILL.md Governed surface exclusions へ移した。基準、発火側の列挙、どちらにも置かれない面は発火側という既定は常時ロードに残る）。判断記録: brake1-firing-closed-by-criterion
• brake 1 の固定軸（impression-literal detection）の範囲は②の発火側と一致しない。範囲を閉じるのは「エージェントが自らの指示として読み実行する散文か」であり、これは固定軸の除去テスト（この句を消して振る舞い意味が変わるか）が、テキスト自身が規定している振る舞いの上でしか走らないことから出る。現に解決する面は rules/**/*.md skills/**/SKILL.md adapter/**/* Li+update.md である。この基準が当たる単位はファイルではなくテキストである——列挙された path はファイルを開く先を選ぶだけであり、基準は中の各語句に対して走る。したがって実行コードであっても、それが emit してエージェントの文脈へ届く文字列（hook の出力文言）は対象であり、逆にスクリプト内のコメントは誰も指示として load しないため対象外である。②の発火側のうち強制の後ろ盾（tests/** / .github/workflows/**）は、コードもコメントも指示として読まれる散文ではないため、除去テストが一定に保つべき振る舞い意味をそこに持たない。②と重なるのは片腕だけであり、導出が同じだから重なっているのであって同一の列挙ではない——path 単位で②へ揃える修正は行き過ぎである。正本は skills/evolution-impression-literal-detection/SKILL.md
• tests/** の散文（docstring / コメント）が述べてよいことは規則で縛られている。 その test が観測したことと、試験している主張の正本の在り処までであり、規範をそこで述べることはしない（必要なら正本＝rules/** / skills/** を指す）。振る舞いについての記述は観測条件を伴い、条件を越えて読める語（permanently / always / never / any）は落とすか条件を併記する。test の意図説明・再現手順・先例参照は対象外である。軸は増やさない——規則が存在すれば既存の Axis B（差分の各行を縛る規則を探してリテラルに当てる）が tests/** の行も拾うためである（#1920。穴の現物は PR #1919 が入れた permanently であり、3 軸すべての射程外だった）。正本は skills/operations-on-docs-ownership/SKILL.md Prose in tests（#2123 で常時ロードの rules/evolution/initiator-autonomy.md から、test の散文を書く瞬間に発火する skill へ移した。移設元には skill へのポインタだけが残る）
• brake の実行位置は CI green の後・merge ゲートの前 である。commit の前ではない。発火の瞬間は委譲した subagent が停止条件で報告した時点であり、親は working tree ではなく報告を手に brake に着く。評価者へ渡す材料は PR URL・push 済みの commit SHA・緑の CI run URL であり（親のクローン内のパスは渡さない）、評価中にベースラインが動かない。step 2 で親が operational copy へ適用する内容も、ひとつのコミット SHA に固定したソースから ref 指定の読み取り（gh api repos/<owner>/<repo>/contents/<path>?ref=<SHA> など）で取る——brake 1 ではその周の SHA（step 3 で評価者へ渡すものと同じ）、それ以外の Trigger では draft が置かれたブランチのコミットである。作業ツリー（実装者の clone や worktree を含む）は読み取り元にしない。正本は rules/evolution/initiator-autonomy.md Merge brake
• operational copy の窓はディスク上の印で記録する（scripts/window_marker.py、置き場は .claude/state/window/）。step 2 が何かを適用するとき、親は適用の前に印を開く（open）。印の記録そのものが開示であり、手順名・開いた時刻・復帰先 digest・バックアップの位置・弁別文字列を持つ。弁別文字列は draft 側にだけ在る一行を、分ける二版の名指しと両側の出現数つきで書いたもので、両側が同数なら印は開けない。digest は呼び手が渡すのではなく、.claude/ の rules/ と skills/ から印の側で計算する。開示のあとは待ちを挟む。相手の応答が記録される（respond）か wait_until を過ぎるかの早いほうで待ちが終わり（ready）、そこで適用して applied を記録する。applied は待ちが終わる前には記録を拒み、適用時刻と適用後 digest を残す。step 5 では status を読み、それが名指す回復（下記）に従って close し（バックアップを書き戻すのは restore_then_close のときだけ）、記録は消さずに history/ へ移す。閉じた時刻・閉じた主体・閉じた時点の digest と復帰先との一致を書き込む。消す設計だと「印が無い」が「一度も開いていない」と「閉じ終わった」の両方を意味し、後者を前者と読んだ誤報告が実際に 1 件出ている。開けた主体が途中で落ちても印は開いたまま残り、それ自体が「開いたまま誰も閉じていない」の信号になる。記録が復帰先とバックアップ位置を持つので、開けた主体以外も閉じられる。ただしバックアップを書き戻してよいのは、rules/ と skills/ が記録された適用後 digest とバイト一致している間だけである——そのとき適用のあとに他の書き込みは入っていない。どちらの digest からも外れた tree は記録の知らない何か（後の tag を同期した Li+update など）に書かれており、そこへバックアップを書き戻すと適用の巻き戻しではなく tag のロールバックになる（2026-09-20、41 時間放置された印で実地に検出）。そのため status が tree の状態から許される回復（restore_then_close / close / close_without_restore）を名指し、見つけた側はそれに従う。分岐を読み手の想起に任せず、印の側で計算する（#2016）。開けた本人が step 5 で閉じるときも同じ回復に従う——ワークスペースを共有する相手が本人の窓の間に Li+update を走らせうるためであり、tree が適用後 digest のままの通常時は従来どおりバックアップを書き戻す（#2051）。stale 閾値は置かない。 閾値は閉じ手が生きている窓の長さより上に置く必要があるが、その長さを残す記録がこれまで無かった（手元の実測は評価者の spawn → post の 66〜151 秒という下界と、窓長 1 本の約 138 秒のみ）。印の存在だけを信号とし、閾値は印が残す窓長から後で引く。#1901
• 指摘を裁くのは親ではなく、実装した subagent を再開したもの（著者）である。かつその往復は PR コメントを直接の伝達面として行われ、親は往復の内容を監督しない。 brake 1 の評価者は所見を自分で PR コメントとして投稿し、著者は同じスレッドへ裁定を返す（受入 / 却下とその理由。commit の有無に関わらずコメントであり、置き場は分岐しない）。親の分担はスケジューリングだけである——新しい所見が付いたら著者を再開して入口だけを渡し（「スレッドの所見を読んで裁け」まで）、CI green で戻ってきたら次のラウンドを開くか、loop を閉じるか、人間へ上げる。読んでから中継することも、統合することも、取捨選択も、順位づけも、回答もしない（受入 / 却下は著者の権限である）。往復に上限は無い。 1 往復 = 評価ラウンドの所見投稿 → 著者の応答（修正 commit ／却下コメント／その両方）→ CI green であり、初回の評価が 1 往復目である。所見の無いラウンドが出た時点で loop を抜ける。ただし、以前のラウンドで受け入れて修正した指摘、または却下した指摘と実質同じ指摘がラウンドに再び上がったら（再発）、親は次のラウンドを開かず、再発した指摘とそれが繰り返している以前の裁定を示して人間へ上げる。再発の判定者はスケジューラである親であり、そのために親はラウンドの境目でそのラウンドの所見を以前の裁定と突き合わせて読む。読むのはこの判定のためだけであり、却下の当否を判断することも、修正を指示することも、軸を開き直すこともしない。親は loop の出口で PR スレッド全体を読み、セルフレビューとマージ判断に入る。「一度も読んでいない親は処理の当否を判断できない」は保たれており、満たす位置がラウンドごとから出口へ移っただけである。却下は loop の内側では最終である——著者は却下を裁き直さず、次以降のラウンドの評価者はスレッドを読み、既出の所見も却下済みの所見も再提起しないよう指示される。この指示は構造で担保されていないため、却下済みの指摘が再び上がった場合も再発に数えて人間へ上げる。上限の無い loop でそれを通せば一件の押し問答だけで loop が続きえ、それを決着させられるのは親だけであり、この loop が外した裁定役が loop の内側へ戻るからである。loop の終わりを担保するのは出口（所見の無いラウンド）と再発時の人間へのエスカレーションであり、skills/model-loop-safety を loop の内側の主体が保持する形は取らない（数える主体を loop 内に残さない）。各ラウンドの評価者は毎回新規に spawn し、resume しない——器具は自分の前回の判定ではなく外から対象を読むべきであり、resume が保持するものはスレッドが既に持つ。ただしどちらが多く検出するかは未測定であり、この選択は暫定である（測定先 = #1848）。エージェントの深さは 1 のままで、評価者を spawn するのは親であり、著者も評価者も何も spawn しない。判断記録: brake1-findings-routed-through-parent（親を経由する旧転送経路。本節はそれを supersede する）、brake-adjudication-by-resumed-author（裁定主体そのもの）、brake1-round-cap-removed-recurrence-escalates（往復上限の撤廃と再発時の人間へのエスカレーション）。正本は、裁定主体と伝達面が rules/evolution/initiator-autonomy.md Merge brake の Adjudication actor / Channel、往復のあいだの親の分担と出口での一読が skills/evolution-parallel-agent-eval/SKILL.md Constraint の Findings are posted to the PR by the evaluator（#2146 で Channel から移した）、往復の形が skills/evolution-parallel-agent-eval/SKILL.md Procedure（step 3 の報告先 / step 4 / steps 6-8）
• brake 1 の評価者へは 評価対象を書き換えるな と委譲プロンプトで明示する。文言は skills/evolution-parallel-agent-eval/SKILL.md Constraint に literal として置いてあり、親はそれを写す（毎回作文しない）。上の材料に親のクローン内のパスを含めないのはこの指示と対であり、前者が書き込みの意図を断ち、後者が共有ベースラインという的そのものを外す。literal に carve-out は無い（#1732）。評価者は自分の所見コメントだけを PR へ投稿するため、その 1 件が例外として literal の内側に書き切られており（それ以外は投稿せず、レビューも承認もマージも他者コメントへの返信もしない）、「コメントは書き換えに当たるか」という問い自体を開かない。評価者のツール権限は絞らない。したがってこれは構造ではなく親が思い出す手続きであり、忘れれば効かないことを受容している。判断記録: brake-evaluator-baseline-integrity（tools: 経路の却下理由と、brake 1 ではそもそも tools: で read-only を表現できないという確認をここが保持する）。モデル床を per-call で固定し custom-agent frontmatter でピン留めしない判断は parallel-subagent-eval-model-floor
• brake 1 の effort の床は low であり、モデル床とは独立に解決する。2026-09-13 の Claude 実測では、定義ファイルを持たない評価役が親セッションの effort を継承し、本 workspace の 2 セッション全件でほぼ low で走っていた。同日の暫定値 medium（Master 判断、2026-09-13）は、low の外し方——正解の literal に到達しながら「保護すべき rationale」と判断して finding から外す、探索ではなく境界判断が保護側へ寄る形——に対して最小の変更で当たる位置として 1 段だけ上げた値だった。この暫定値を Master 判断（2026-09-29）で low へ置き換えた。根拠は sonnet 級モデルが 5 から 5.5 へ更新されたことである。5.5 の low の評価役がこの外し方をしないことは未測定であり、仮説として扱う。観測に回す点は、5.5 の low で到達した literal が「保護すべき rationale」として finding から外されるかである。モデル床（sonnet 級、per-call 明示、haiku 禁止）は変わらない（#2121）。Claude は #1972 で役ごとの定義ファイルをエフォートごとの 3 本（low.md / medium.md / high.md、いずれも役を持たない）へ組み替えた。judge 型は subagent_type: low 以上として spawn し（low は床であり、その上での選択は #1967 以降その spawn ごとの親の判断である）、役 literal をプロンプトで受け取る。Claude の probe 型は定義ファイルを持たず、親セッション自身の effort を上げて床へ届く。Codex は judge / probe とも定義ファイルを選ばず、各 spawn call で reasoning_effort="low" を明示し、judge 型の役 literal は self-contained prompt が運ぶ。Codex の agent TOML に model_reasoning_effort は置かない——定義側の優先順位が per-launch 値を上書きするためである。sonnet 級の model は別の per-call 軸として維持し、対応しない effort 値への fallback は推測しない。正本は skills/evolution-parallel-agent-eval/SKILL.md Constraint: Effort floor と Procedure step 3（#1968 / #1972 / #1973 / #2121）
• brake 1 の各軸の書き方も skill 側で固定してあり、親が毎回作文しない。親は評価器具（軸文言）を、その器具の対象をリテラルに読んでいるのと同じ瞬間に書く——そしてリテラル検証は対象には届くが器具には届かない（#1692、3 日で 7 回観測、うち 5 回が「一つの軸名が複数の問いを抱える」形。可視に連結されている場合と、一語の述語へ圧縮されて一問に読める場合とがある）。軸は 3 本で固定であり、draft ごとに増減しない。 per-draft 軸は 2 本——A（この差分は自分の issue が要求したことを満たしているか）と B（この差分は規則に反していないか。この差分自身が新設した規則を含む）——で、どちらも skill 側に写すだけの literal として保持されており、親がその瞬間に書くのは Unit と Scope の 2 部分だけである。draft の見た目が前回と違うことは軸を組み直す理由にならず、B を対象ごとに割ることも per-draft 軸を 3 本目へ増やすことも禁じる（2 サイクルの測定で確定。#1832。何をどう測って 2 本に落ちたかは判断記録が持ち、ここには写さない。判断記録: brake1-per-draft-axes-held-at-two）。この固定が及ぶのは brake 1 経路だけである——保持した 2 本の Basis は PR とその PR が閉じる issue に対して解決するため、PR フローの外で収束した draft には解決先が無い。Trigger の他の発火モーメントでは固定軸のみが保持形で入り、それ以外は従来どおり差分の性質に合わせて組む。固定軸は 5 部分の範囲外である（文言は skills/evolution-impression-literal-detection/SKILL.md Prompt literal に保持されており、空欄を一つも持たない——per-draft 軸 2 本が Unit と Scope を開けたまま保持されているのに対し、こちらは開いていない）。軸は 5 つの名前つき部分として書く：Question（疑問文を 1 つだけ。かつ判定を生む操作を名乗り、かつ材料が届く順で答えられる——軸は、プロンプト自身が運ぶものを読む前に形成される判断を要求できない。操作を名乗るとは、評価者が材料に対して何をし、その結果のどれが所見なのかを書くことである。and や読点で繋いだ 2 節は 2 操作＝ 2 軸である。数えるのは節ではなく操作である。評価を名乗って操作を名乗らない述語——forced、consistent、resolves wrongly——は数を隠して運ぶからである。読みごとに為すことが違い、連言は一語の内側へ圧縮されていて節の禁止が届かない。操作を書くことがこれを解凍する——読みは軸を書いているその場で別々の疑問文へ分かれ、そこへ節の禁止が他の対と同じように発火する。操作を名乗らない疑問文は答えられるのではなく未記入である。評価者は自前の読みを補わなければ着手できず、その読みは黙って補われるため何の信号も出さない。ただしここで成果物に載るものは上記の空欄ラベルより狭く、その差は伏せずに書いてある（判断記録: presence-defect-cannot-reach-blank-label-visibility）。残余——評価者が黙って補った読みで答え、信号が一つも出ない場合——は、skills/evolution-observation-entry/SKILL.md の entry を持つ PR では post-merge observation 軸で受容する（本ファイルのもう一件の実行保証なき要求と同じ扱い）。同 Format の作る条件で entry を持たない PR では、マージ後に何も追わない。c0020a2 の forced、#1763 の「整合」、#1766 の resolve wrongly がこの形である。このうち c0020a2 と #1766 は 5 部分が記入済みでこの結果になっており、未記入の検出では防げない——だから塞ぐ先は Question の文言側である）/ Unit（1 つの判定が覆う単位＝文・段落・ファイル・主張・出現）/ Scope（軸が及ぶ面を二つの次元の両方で述べる＝広がり（当該 PR の diff・名指しした 1 ファイル・リポジトリ・リポジトリと wiki）と、その軸のパターンが書かれている言語。加えて、軸の判定が不在の主張であるときは、どこを掃いたかも述べる。不在はどこまで読んだかと同じ幅しか持たない。広がりだけでは第二の次元を運べない——リポジトリ と書かれた scope は、英語パターンだけで走った掃引で満たされてしまう。本リポジトリは正規テキストの多くを二重に持つ——rules/ と skills/ が英語、docs/ が日本語であり、多くは前者のミラーだが、場所によっては docs/ 自身が正本である（docs/5.-Notifications.md は自らを正本と宣言しており、ミラー元となる rules/notifications/ が存在しない）——ため、そうした掃引は日本語側には一度も届いておらず、その不在の主張は見落としではなく構造的に掃き残している。正本側の事例のほうが鋭い——掃引が代わりに当たれる英語の対応物がそもそも無いからである（2026-08-12 観測。#1733 の brake 1 が docs/3.-Task.md の日本語ミラーの取り残しを 2/1 で検出し、同 PR の fa87222 で修正済み。残渣は現存しない）。Report shape が復路（所見の無い軸）に掃引のパターンを要求しているのと同じ次元を、往路すなわち軸を書く側で要求する）/ Verdict terms（その軸での yes と no の意味を軸自身の語で。「何か落ちたか」を問う軸では所見は yes でありながら draft にとっては negative であり、極性を名乗らない軸は誤った極性を継ぐ）/ Basis（軸が対象・基準について述べることはすべて、名指しした SHA で解決するポインタを伴い、必要な軸ごとに書き込み（集合に一度ではない）、かつ件数が効く軸には数値でなく数える本文を渡す。軸は隣に書かれたものを継承せず、基準を名指さない軸は clean ではなく未記入である。解決するとは、基準は パス または パス:行 付き逐語引用、例示は実在箇所からの引用ということ。形式だけでは満たされない——上記の軸ごと要件が及ぶのは、判定を当てる先、すなわち軸が判定基準とする既存の Li+ 基準や親が依拠する論証である）。5 部分はすべて評価者のプロンプトへそのまま載る payload であり、通れば消える点検項目ではない。書かれなかった部分は評価者が読む本文の欠けたラベルとして見える。機構は成果物上のこの可視性であって、rules/model/subtractive-structural-beauty.md が「手続きを構造へ置き換えよ」と要求するときの実行保証には届かない（判断記録: presence-defect-cannot-reach-blank-label-visibility。落ちた手順を別の面へ置き直す案が構造ではない理由もここが保持する）。正本は skills/evolution-parallel-agent-eval/SKILL.md Axis statement form
• 評価者数の床は N=1 であり、既定も N=1 である（#1855、Master 判断 2026-09-03）。旧仕様の床は N>=3 で、複数評価者の存在に依って立つ面——評価者間の集約規則、判定が割れたときの divergence handling、比率（3/3 / 2/3 / 1/3）の triage signal、および固定軸の絶対閾値（2-of-3 で即 refine / 1-of-3 は auto-refine しない）——を持っていた。床の引き下げでそれらは成立条件を失うため、条件付きで残す形は採らず削除した（rules/model/subtractive-structural-beauty.md Core principle (A)）。発火条件そのものは不変であり、全自己進化 PR で brake 1 は必須のままである（rules/evolution/initiator-autonomy.md Merge brake）。駆動理由は #1853 の検証サブエージェント（行動を問う probe）であり、複数評価者が担っていた検出面をそちらへ移す前提での引き下げ。判断記録: brake1-evaluator-floor-lowered-to-one
• brake 1 の評価者へ渡すのは実測の射程だけであり、判定は渡さない。ある周の前に実測が走った場合、プロンプトが名指すのは測った設問、または踏んだ行の位置までである。差が出たか、ゼロ差だったか、何も返らなかったかは、プロンプトにも軸にも評価者が向けられるどの面にも入れず、走行の記録も loop を抜けるまで PR スレッドへ置かない（評価者はスレッドを読む）。器具を二つ持つ意味は、片方が先に喋った時点で失われる——「この面は測って差が無かった」を先に読んだ評価者は、そこには何も無いと告げられており、落ちるのは自力で上げたはずの所見である（#1849 の A-2 は 2/3 の検出であり、先に差ゼロを読んだ状態であの 2 体が同じ指摘を上げたとは考えにくい）。射程だけを渡せば、評価者は測られていない面に集中でき、かつ測られた面について「問題無し」の圧を受けない。正本は skills/evolution-parallel-agent-eval/SKILL.md Constraint、実測側の位置と発火条件は skills/evolution-rule-effect-measurement/SKILL.md Application point
• 時間とともに変わる外部事実（API 仕様、ライブラリ挙動、ホストの動作など）は、発生ごとに、かつそこでだけ確かめる。 brake 1 での発生とは、diff がそうした事実を述べる行を追加・変更したことである。評価者は、その行が根拠（出典・観測）を示していなければ「裏付けなし」の所見として挙げ、事実そのものは検証しない（親が step 3 でプロンプトへ入れる）。確かめるのは step 7 でその所見を裁定する著者であり、現在の外部ソースに当たって、根拠を行か PR スレッドに残す。確かめられなければ、その行を外すか未検証と明記する。diff が触れていない既存行の drift はこの方法の範囲外のままである——brake 1 は変更された行に掛かる門である。PR #2002 の B-2 裁定が示した読み方を固定したもの（#2025）。正本は skills/evolution-parallel-agent-eval/SKILL.md Non-scope と Procedure step 3
• 置き換えのない削除行は、各行に一度だけ「まだ真か・まだ必要か」を問う。 brake 1 の diff が置き換えのない削除行を含むときだけ、親は step 3 でこの確認をプロンプトへ入れる。純粋な追加だけの diff では入れない。評価者は名指しした SHA 時点のファイル本文（既存の取得手段）に当てて答え、真でありかつ必要な行を所見として挙げる。「すべて適切に削除されている」も正当な結論である。PR #1550 の brake 1 では R1〜R3 の軸がいずれも追加・変更された文だけを検分し、置き換えなしに落ちた今も真かつ必要な記述は、R4 で削除内容を明示的に問うたときに初めて検出された（#1553）。正本は skills/evolution-parallel-agent-eval/SKILL.md Procedure step 3
• 所見の可否を決めるのは計数ではなくリテラルである。 比率も多数決も、この方法のどこにも判定入力として入らない。各所見は、その パス:行 が名指す revision のソースにリテラルを突き合わせて採否が決まり、それを行うのは step 7 の著者である——固定軸も同じであり、固定軸はもはや閾値を持たない（旧仕様では固定軸だけが計数を裁定にしていた）。N を複数に採った周で同じ所見が複数体から挙がっても、裁き方は変わらない。N はセルフレビューにその周を走らせた幅として記録するが、採否の理由には書かない。正本は skills/evolution-parallel-agent-eval/SKILL.md Design Dimensions
• brake 1 が生む2 つの成果物の形は skill 側で固定してあり、各主体が毎回作文しない。2 つとは評価者の所見コメント（step 3）と著者の裁定コメント（step 7）であり、どちらも同じ PR スレッドへ載り、後者が前者に答える。いずれも同じ継ぎ目で非対称である——所見のある側は full、誰も争っていない側は 1 行。full は削減対象ではない——著者は引用に当てて裁定するため、削るとソースの取り直しが指摘ごとに発生し、リテラルに当てずに断定する形（rules/model/trigger-check-gate.md Literal check / #1673 cluster）へ戻る。1 行の側で「見て clean と言った」を支えるのはポインタの解決可能性である（名指しした SHA で開けること、開いて判定と合わないなら 1 回の参照で露見すること）。評価者の所見コメントは、冒頭に 1 つの保持された literal（所見はリテラルをソースに突き合わせて裁く旨、そしてその判定に計数は入らず固定軸も例外ではない——固定軸は閾値を持たず、旗の立った語句を除去テストに当てて裁く——旨の 2 節。2 節はどちらも payload であり、前節だけでは固定軸が例外に読め、後節だけでは何に当てて裁くのかが落ちる。書き手が自分の言葉で言い直すと免除の読みが生まれるため文言を skill 側に保持し、解決後の言語へ描画せず原文の言語のまま写す——言い直しこそが拒まれている動作であり、翻訳は言い直しである）を写して開き、そのあと所見のある軸＝逐語引用＋パス:行（名指しした SHA 時点）＋なぜ欠陥か／所見の無い軸＝1 行（軸名＋その軸の語での判定＋根拠の パス:行。リポジトリ全体を掃く軸は指せる 1 行が無いため、再実行可能な形の掃き出し（パターンと掃いたパス）とヒット数で代える。不在の主張は開いてではなく再実行で検査され、再現しないヒット数は解決しないポインタと同じ形で落ちる）を載せる。clean な軸も 1 行のまま載せる（著者は step 6 で全軸を読むため、所見だけのコメントでは分母が見えない）。統合の段は無くなった——親が間に立たないため、N を複数に採った周では評価者ごとに N 本のコメントが並び、評価者間の重複は畳まれない（畳むことは取捨選択であり、loop にその主体がもういない。著者は各コメントをそれぞれのリテラルで裁く）。著者の裁定は同じスレッドへのコメントに置き、却下＝ full（loop の内側では最終であり、その後ろに立つのはスレッドを読む次ラウンドの評価者と、出口で親が読むスレッドである）／受入＝1 行（何が変わったかは同じ commit の diff に既に外部化されている）。commit の有無で置き場は分岐せず、1 件も受け入れなかった場合のための別経路は持たない（rules/model/subtractive-structural-beauty.md Core principle (A)）。commit body は rules/operations/operations.md が要求する内容を引き続き持つが、裁定はもうそこに乗らない。全側面で禁止するのは、プロンプトで渡された基準・閾値・軸文言の復唱である。残余（誰も開かない clean 軸のポインタ、および判定に合うよう事後選定されたポインタ）は、skills/evolution-observation-entry/SKILL.md の entry を持つ PR では post-merge observation 軸で受容する。同 Format の作る条件で entry を持たない PR では、マージ後に何も追わない。言語の規定は評価者側へ戻った——評価者が契約の及ぶ面（PR コメント）へ自分で書くようになったためである。PR コメントは Workspace_Language_Contract Definitions が base language の側（人間との対話の会話的返信）に置いており、PR body が取る project language の側ではない。したがって解決の軸は skills/task-subagent-prompt/SKILL.md Delegation prompt hygiene の body 言語の precedence ではない。subagent は自分の文脈から解決値へ届かないため（session-start hook の出力は subagent へ届かない）、親が spawn 時にその run の値として名指す。著者の裁定コメントも同じ側であり、phase 1 の委譲プロンプトが運んだのは body の言語でこれには答えないため、親が resume 時に改めて名指す（同 skill Resume-phase authority boundary の項目 (d)）。解決では片づかない継ぎ目は変わらず、逐語引用は対象外、冒頭の保持 literal も対象外である（著者は引用に当てて裁定するため、訳された literal は literal ではない）。Li+ source は英語（rules/model/liplus-coding-rule.md Source Language）であり、他の言語へ解決する workspace ではコメントは構造的に混在する（引用は原文の言語のまま、地の文は解決後の言語）。PR 面を持たない Trigger 項目は本節の外であり、そこでは評価者は spawn 元の親へ所見を返し、冒頭の保持 literal は宛先を持たない。正本は skills/evolution-parallel-agent-eval/SKILL.md Report shape
• 人間ゲートはリリース / 不可逆系の軸と execution-mode の minor/major レビューに残る（人間 = 最終審判者は別軸）

段階責務：

段階	担当
observe / evaluate	AI 自律。人間の促しは不要
distill	AI 自律。メモレベルの閾値を超えたら issue として外部化する
reflect	AI が PR を起票し、brake 1（L1 も同じ 1 本）通過後に AI がオペレーションレイヤーの手順でマージする
improve	更新された spec の下で AI が実行する
re-observe	AI 自律

（→ skills/evolution-rule-effect-measurement/SKILL.md / scripts/measure_rule_effect.py）

Li+ source の説明文が積み上がり続ける問題に対し、削除・追加の判断を議論ではなく実測で行う門である。非対称なコストがこの機構の理由である——加算は書き手一人で済むが、減算は評価者に「この行は load-bearing でない」ことを示す必要があり、これは無いことの証明であって原理的に示せない。rules/model/subtractive-structural-beauty.md Core principle (C) が名指す preserve-by-default が、削除に論証を要求するあらゆるゲートの構造そのものに埋まっている。

skill 本文（skills/evolution-rule-effect-measurement/SKILL.md）は #1604 の手順（躓きの集合から組み直す）を適用済みであり、振る舞いのみを載せる（#2088、25,012 → 18,291 B）。各条件の根拠——実測値・経緯・却下した案——は判断記録 rule-effect-measurement-conditions-rest-on-observed-failures が保持する。本節は記録面であり、理由を持ち続けてよい

• 適用点は新規追加の門であり、既存節の総掃きではない。比較相手は「今の全部を載せた木」であって空ではない（重複検出器）。単体で無意味な行は少なく、空を相手にした一行ずつの入場試験はほぼ全部を通す。膨張を作っているのは重複だからである。既存の掃き出しは余力での後追い
• 自己進化 PR のパイプライン上の位置は 実装 → CI → 実測 → brake 1 である。CI green の後、brake 1 の評価者 spawn の前に起こす。評価者が受け取るのと同じ基準点に載せるためであり、CI より前に測ると測った本文と評価される本文がずれる。実行主体は親である——その位置で材料を握り評価者の spawn をスケジュールしているのは親であり、別主体に割ると同じ材料を二つの主体が別々に組むことになる。腕は claude -p の別プロセスなので subagent を一段挟んでも腕の起こし方は変わらない。判定役の分離はこれで動かない（親が起こすのは走行であって判定ではない）。発火条件は、統治対象の本文（rules/** / skills/** / adapter/**）において削除が追加を上回る PR であり、腕は二本でいずれか一方が満たせば発火する——削除行が追加行を上回る、または削除バイトが追加バイトを上回る。どちらも満たさない PR を測っても得られるのは「増えた分が効いている」であり、それは争点になっていない。自己申告は採らず、どちらの腕にも余白の閾値を設けない（行の腕と同じく 0 を境に比較する）。バイトの腕は行の腕の精密化ではなく、行の腕が構造的に届かない削り方を拾う——長い文を短い文へ差し替える形は追加 1・削除 1 として両側に立つため行数が釣り合い、内容だけが抜ける。これは rules/model/liplus-coding-rule.md Body States Behavior に沿った削りの典型形である（挙動の文を残して導出を剥ぐため、節に行が残る）。どちらの腕も統治面だけを、かつその 1 本の diff の内側で数える——当該 PR の追加分を当該 PR 自身の削除分に当てるのであって、ファイル間・PR 間・言語間を跨いで比較しない。したがってどちらの腕も「統治面が単一言語である」ことには依っていない（実測でもそうではない——adapter のフックスクリプトは非 ASCII の文字列を出力する）。rules/model/liplus-coding-rule.md Source Language がバイトの腕に対して担うのはもっと狭い——散文の差し替えにおいて比較の両側を同一言語に保つことであり、それによりバイト差が符号化の差ではなく内容の減少として読める。docs/** は数える範囲に入らない（発火条件が挙げる rules/** / skills/** / adapter/** に含まれない）。#1934
• 二段構成。段1 = 対象本文の抜粋を親プロンプトに注入する安い篩い。差が出れば load-bearing 確定、ゼロ差は段2へ送る振り分けであって判定ではない。段2 = ライブ木から .claude/ + CLAUDE.md + Li+config.md を複製した面を2つ作り、一箇所だけ変えて claude -p を起こす。本番同等の密度でなおゼロ差なら重複として落とす
• 段1は本文を貼り付ける。腕にファイルから読ませる形と親プロンプトへ貼る形は結果が変わらなかった（各3本）。貼り付けは木に属さない規則ファイルを作らないので既定とする。ファイルを置く例外時に限り囲いを掛ける——ファイル内にもファイル名にも試行・写し・検査を名指す語を入れない（ファイルが自分を何であるか申告すると、腕が判定の枠組みを変える）、置き場は scratchpad のみ（.claude/ にも liplus-language/ 配下にも置かない）、名前は無情報な一意 ID、走行後すぐ削除、何であったかは成果物の外（走行記録と issue）に書く。「札を成果物に入れない」と「札をどこにも書かない」は別であり、前者だけを行う
• 段1のゼロ差を削除根拠にしてはならない。ゼロ差は2状態を混同している——(a) 注入が本番の読み条件を壊したための過小検出、(b) その行が実際に重複。注入方式は gist 想起の誤りを打ち消すために置かれた行を構造的に過小検出する（腕は短い本文を目の前に置いて読むが、その種の行が効く条件は本文を literal で読んでいない状態である）。Li+ にはこの類型が多く（rules/model/trigger-check-gate.md 系）、区別しないと一律で落ちる。切り分けが段2の存在理由である
• 汚染対策は段ごとに逆になるため制約文を共有しない。段1 = 親プロンプトの内容だけを情報源とするホワイトリスト形（文言は skill 側に canonical literal として保持。経路の列挙＝ブラックリストは、本文への流入経路が少なくとも4つ（ワークスペースの .claude/、liplus-language/ 側の同一本文、コンテキスト上の skill description、外部 RAG 索引）あり次が出るたびに破れる）。段2 = 常時ロードされた本文を使うことが目的なのでホワイトリストは使えず、制約は「外部から取得しない。手元に載っているものだけで答える」。段2で外部取得を禁じる理由は RAG であり、削った行が索引には残るため腕が取り戻すと対照が崩れる
• 隔離は無効。作業木を外に置く／ディスク経路を deny する壁は RAG 経路に原理的に効かない。本文はネットワーク越しにも存在し、囲える対象ではない
• 腕は別プロセス（claude -p）である。subagent が読むのは親セッション起動時のスナップショットであり、実行中のディスク変更は追加・削除とも届かない（両方向で実測）。段2はディスク状態の比較なので subagent 実装では成立しない。派生する危険として、腕はコンテキストとディスクの食い違いを検知せず迷わずコンテキスト側を採るため、検証中に第三者が .claude を触ると外から検出できない誤判定になる
• 段2を起こす前に窓の印を読み、開いていれば複製を止める。brake 1 の operational copy はそうした第三者の一つであり、自分の窓を印として残す（skills/evolution-parallel-agent-eval/SKILL.md Procedure step 2）。腕の複製元になるライブの .claude/ に対して scripts/window_marker.py status を読む。open は複製の門である——印が立っている間は腕を組まない。status を取り直し closed か never_opened になるのを待ってから進む。印が晴れる前に諦めた場合は「走った」ではなく unmeasured・理由 window open（適用点）として記録する。放置された印を終わらせるのはその手順（brake 1 側）の仕事であり、本ゲートは status を読むだけで close は呼ばない。この門が見るのは確認した瞬間までであり、最後の status 読み取りと複製そのものの間に開いた印はここでは捕まらない——その隙間は印の履歴が事後の控えとして残す。そこで見つかった開いた印は走行を無効にするかを決めない。適用された draft が probe に効くかは判定役が読むものである。複製が窓の内側に落ちたかは事後に、走行記録の started_at と各窓の applied_at / closed_at を突き合わせて言える。#1900 / #1901
• 判定役は腕から分離する。二本の出力の差を読む三人目であり、Li+ を抱えていて構わない。結論だけを数えず、どの文言を引いたかを読む。「穴の報告」と「判定そのもの」を別枠で数え、効きとして採るのは後者のみ（腕は欠落に気づいて自制するため、出力が穴の報告になる。これを効きに数えるとあらゆる行が load-bearing に見える。probe 側で穴への言及を封じるのは不可——気づきは消えず消えるのは兆候だけで、その兆候こそ漏れの有無を判別した当のものだからである）
• 腕のモデルは実験条件として固定し記録する。同一 probe・同一ワークスペースでモデルにより結果が反転した（haiku 0/3 漏れなし ／ Opus 1/1 漏れ）。弱いモデルは取得もしない代わりに節の適用もしないため、あらゆる差が過小に出る
• probe は内容照合と行動照合を併用する。内容照合だけだと、常時ロード側の規則を再掲した行で誤検出する（本文からは消えるが conduct は不変）。逐語の欠落検出は内容照合にしかできないため置き換えではなく併用（#1853）
• 二つは別の形で書く。行動照合は内容照合の文言を緩めたものではない。内容照合 = スキルの呼び出しを指示し、本文に従って逐語で答えさせ、規定が無ければ規定なしと述べさせる。行動照合 = 状況だけを提示し、スキル名も本文も挙げず、何が書かれているかを一切問わず、腕が取る行動そのものを答えとする。本文参照の指示は弱めるのではなく無い。答えが離散的な行動選択に落ちる設問を選ぶ。また、既に落ちた行について問いを立てられるのは行動照合だけである（本文から消えた行について「本文に何と書いてあるか」は問いにならない。conduct 行の脱落が内容照合だけの周では素通りするのはこのため）
• probe の組が blind なのは 1 周だけである。採点は各腕の出力を読み、arm B の出力は自分の本文を引用しうるため、採点した時点で probe 作成者は arm B の断片を見ている。したがってその周の採点後に、変更した本文（brake 1 の指摘で直した蒸留を含む）へ同じ組を再び立てると、それは前の周の再演であって blind な周ではない。しかも走行記録の形も手順も 1 回目と同一で、外からは区別が付かない。変更後の周は適用の瞬間の一文から新しい組を立て、その作成者は前の周までの腕の出力を一切読んでいない者とする。使用済みの組を再び立てた周、またはそうした作成者が居ない周は、plan の scope（selection）に再演として書き、その判定は blind な結果ではなく再演として読む。検出の構造化は後続であり、ここではまず literal として置く（#2014）
• 測定が閉じるまで設問文を変更側の見える場所に置かない。閉じる＝判定が走行記録の scope の中に書かれた時点。変更を書く側・指示する側（蒸留と、蒸留から実装を指示する者を含む）が読める面——共有の部屋、issue / PR のスレッド、委任プロンプト——に probe の文面を置かず、そこでは情報を持たない id で指す。PR #2012 の測定では一つの probe が三重に焼けた——(1) 作成者が arm B を見た (2) 作成者が設問文を部屋に貼り、蒸留側が読んだ (3) 蒸留側がその設問の語形で実装側に指示を出した。(2)(3) は測定の手順ではなく対話の運用で起きたため、手順の側ではなく置き場所の制約として置く（#2014）
• 判定役は行動軸を独立の枠で読む。内容軸の結果は行動軸を決めない。どの文言を引いたかではなくどの行動を取ったかを読み、両腕同じ行動＝効き無し（conduct は常時側が持っているか、その行が conduct を持っていない。内容差がこれと並ぶ形が再掲の署名であり、残す／落とすは行動列で決める）、行動が割れる＝効き（B腕が失ったのは conduct である）。行動設問に対して「規定なし」と答えた腕は内容の問いに答えており、probe が本文を挙げたか匂わせている。その周は差ではなく無効であり、行動の形で立て直す
• 揺れの帯は行動軸で未測定である。帯 0 の実測は内容 probe 上のものであり、行動軸はその条件に入っていない。離散的な行動選択に落ちる設問なら同じ帯を持つ見込みだが見込みは測定ではなく、離散性が共通であることを根拠に 0 を持ち越す形をここで禁じる。帯はモデルごとに加えて軸ごとに測る
• 走行物はゼロ。排他ロック（os.mkdir 一発。取れなければ起動できない）、temp 下の固定パス、try / finally での削除、そして冒頭の無条件削除という二枚構え。durable に残るのは道具（スクリプトと skill）と走行記録のみである。走行記録は --out が名指すファイルにだけ書かれ、--out は必須である。記録は各 edit の drop / replace_with 本文を丸ごと持つため、stdout へ出る経路があると、実行者（通常は arm B を見ない側に置かれる probe 側）が付け忘れ一つで arm B の本文を見てしまい、走行は正常終了したまま測定だけが成立しなくなる（#2011）。ロックは時刻に加えて保持者の PID を持ち、ロックが取られている場合はその PID の生存を確認する。生きていれば従来どおり拒否し、居なければロックを破って取る（判定不能なら生きているものとして拒否する。安全側は拒否の側）。受け入れたトレードオフ: 穴は二つ残り、いずれも以前より狭い。(1) PID 再利用——死んだ保持者の番号が無関係なプロセスに割り当てられていると生存と読まれ入室を拒む。二つのうち安全側であり、残した stale 閾値がいずれ解消する。(2) 閾値超過の追い越し——閾値より長く走った実行のロックは今も stale と読まれうるが、PID 照合も保持者の生存を言えない場合に限られ、誤入室には二つの同時成立が要る。以前の版は PID を穴に見合わないコストと判じて閾値のみに寄せていたが、その判断は実測で組み直した——kill された実行が残したロックが最大 6 時間ハーネスを締め出し、復旧はプロセス一覧を手で読んでディレクトリを消す手順しか無かった。本機構が構造へ置き換えるために在る、当の手順である（#1945）
• 測定の射程は plan の必須フィールドとして走行記録に載る。plan JSON は scope オブジェクト——probes_total 問中 probes_measured 問を測ったか、選定基準 selection、測っていない範囲 unmeasured——を持たなければ拒否され、その値はそのまま走行記録へ運ばれる。1 走行は 1 probe なので、フィールドは当該走行が属する周全体について書き、その周の各 plan で同じ値にする。値は自己申告であり検証しない（正しさの検証は受け入れて手放す）。結果は射程と併せて読む——「蒸留が何を壊すか」の予測で選んだ周が green なら、言えるのは「予期した壊れ方は起きなかった」であって「何も変わらなかった」ではない。射程を人が書き添える手順にすると、書き忘れても何も落ちず部分測定が全面測定として読まれるため、構造に置いた（rules/model/subtractive-structural-beauty.md の手続き→構造置換。30 問中 8 問を測った PR #2012、5 問の #1851 と同じ欠落が 2 回起きた。#2013）
• brake 1（skills/evolution-parallel-agent-eval）とは別軸である。brake 1 は diff を静的に読む merge 前ゲート、本機構は走らせて振る舞いの差を見る。両者が別の面を押さえていることは両向きで実測されている（conduct 行の脱落は測定の網の外で brake 1 が拾い、再掲行の割れは brake 1 の網の外で測定が拾った）
• 測定は外部予算を消費するため必須化しない。腕1本の床は最小プロンプトで cache_creation_input_tokens = 95,069（常時ロード側の読み込み分であり probe 長にほぼ依存しない）。5問 × 3回 × 2腕 = 30 起動が1周の規模である。パイプライン上に置いても必須化はせず、取れなかった場合は止めずに brake 1 へ進む。ただし記録の側で「測っていない」と「測って差が無かった」を区別できる形にする——親のセルフレビュー記録（rules/operations/main-agent-procedures.md Self-review formal record）へ unmeasured と理由（上限 / 発火条件外 / 測る対象が無い / window open）を明示し、空欄にも陰性にもしない。空欄は読む側に「問題なし」と読まれ、判定の不在が判定として機能してしまう。セルフレビューは brake 1 が抜けた後に書かれるため、そこへ書いたものは評価者へ届かない
• 本機構自身への適用。設計の穴が見つかるたび条件が増えるという形が、本機構が対象としている膨張と同じ構造であるため、本機構の条件そのものを本機構の門にくぐらせる。判定基準は probe と同一で「この条件は適用の瞬間に何を変えるか」であり、一文で言えない条件は入れない
• 構造的限界（外側の位置）。条件を積み上げている当事者が門を運用する場合、門をくぐらせる発想そのものが出にくい。設計中、経路の漏れが見つかるたび AI 側は条件を1つ足す方向にのみ動き、「経路を数えるのをやめ許可を1つだけ挙げる」という解は設計に参加していない Master から出た。判定役を書き手から分離するだけでは足りず、条件を足す判断そのものにも外側が要る。rules/model/role-separation.md の human = final judge は、承認手続きとしてだけでなくこの構造的位置として読む

（→ rules/evolution/promotion-judgment.md）

memory の観測から Li+ 正規ルール（rules/ / skills/ / adapter/）への昇格を、cluster 単位の数値ゲートとして運用する。前提として L1 Model Layer の観測面（self-evaluation・trigger check gate が drift を拾う面）と、L2 の observe 段・永続化ティアリングを読む。観測はセッション全体のどの時点でも起きるため常時ロードに置く。

L1 更新ゲーティングとの関係： 本機構は「観測 → 起票」の前段である。示すのはノイズ床を越えたことだけで、L1 Model Layer の更新そのものを認めるのは skills/evolution-l1-update-gating/SKILL.md の長期観測である。二つは別の軸であり、起票はそれだけで L1 の書き換えを認めない。本機構が付ける promotion marker は、同 skill が起票の性質を観測駆動と読む印でもある（上記「観測閾値の起票の性質によるスコープ」）。

永続化ティアリングとの関係： memory ↔ docs の二値の仕分け（skills/evolution-persistence-tiering/SKILL.md）は本機構の外でそのまま効く。ある項目を memory に置くか docs へ出すかは永続化ティアリングの判断であり、memory の観測の集まりが正規ルールへの昇格に値するかは本機構の判断である。両者は独立した軸で、一方の判断が他方を代替しない。

追記が直列化されないこと： 2 つのセッションが同時に tally へ書くと occurrence が 1 件落ちうる。落ちても何も raise しないので、衝突の検出は人の目による（受容した残余）。規則が「衝突を観測するまでロックもセッション別の分割も足さない」とするのは、同時追記は tally を memory の外へ出す前から両セッションが同じファイルへ書いていた既存のリスクで、移設が悪化させるものではなく、観測なしに機構を足すことは rules/model/subtractive-structural-beauty.md Core principles (B) の push surplus に当たるからである（#2018）。

（→ rules/evolution/memory-entry-format.md）

memory file 群（per-topic entry file の feedback_<topic>.md / project_<topic>.md / reference_<topic>.md / user_<topic>.md = 1 memory 1 file、および index と運用ファイルの MEMORY.md / self-evaluation_log.md / self-evolution-observation.md）の entry 書式とメンテナンス規律を、各 file 内ローカル運用メモから L2 Evolution Layer の正規ルールに昇格する。横断規律として single source で扱い、各 memory file 冒頭の運用メモはこのルールへの参照に置き換える。

スコープ：memory は transient のみ。 memory が扱うのは self-evaluation log・self-evolution observation・reference に限る。cluster tally は transient だがここには入らない ── ホストにつき 1 つの計数面である一方 memory はワークスペースごとに解決するため、memory の外に置く（#2018。rules/evolution/promotion-judgment.md の Tally 節）。永続情報は memory に置かない。

昇格先（Escalation paths）： 永続情報は 4 系統のいずれかへ向かう。

• Li+ 正規ルール（rules/ / skills/）= 汎用 / 構造的、常時 load 価値あり
• docs/ = プロジェクト判断 / 仕様レベル
• wiki（docs/Decision-Structure.md index 配下、kebab-case <topic>.md）= 判断構造（Decision Structure: state-form entries + supersede/depend/conflict edges）
• 削除 = 撤回 / 陳腐化 / Li+ 既昇格済み

判断発火点（Trigger point）： 観測時に「transient か永続か」を問う。永続なら memory に書かず、昇格 PR を立てるか削除する。判断発火点を各観測時に持たせ、永続情報が memory に滞留する構造的欠陥を断つ。

entry 書式の core 三要素（transient memory entry に対する形）：

• summary = 1-2 行の要約。何の指針か / 何の文脈かを literal に書く
• How to apply = 適用すべき場面と具体動作
• 検知サイン = 適用機会を取り逃しているときに観測される signal

Why の長段落・human の literal 引用は最小限（1-2 行）。背景説明で entry を膨らませない。背景が必要なら docs ティアに切り出す（永続化ティアリング側の判断）。

運用規律：

• 重複は更新で扱う。新規 entry を並べない
• 撤回 / 陳腐化 / Li+ 正規ルール昇格済み内容は削除する。「念のため残す」を取らない
• 対立する feedback は共存させない。矛盾を見つけたら片方が誤りか scope が違う
• 昇格済みルールの tracking list を memory に持たない。git log / RAG / source から再発見できる

Artifact deletion calibration（削除判断の較正）： blast radius（break scope × recovery cost）を削除の慎重度の基準にする。内容への馴染み深さではなく blast radius で較正する。削除前の自問は一つ：「誤って消したら何が壊れるか、復旧に何分かかるか」。表は memory 専用ではなく成果物種別を横断し、memory subfile はその 1 行である。他の行は本ファイル外から参照される。

対象	break scope	recovery cost	caution
memory subfile（ローカル、使い捨て）	低	中	低
一時ファイル・作業ログ	無視できる	無視できる	無視できる
source / docs（git 管理下）	広い	低（即時 revert 可）	中
wiki page（docs から再同期可能）	中	低	低〜中
ローカル非 git config・state（gitignore、意味を持つ）	中〜広い	高	高
共有ブランチへの force push	広い	高（reflog 依存）	高
release latest 昇格（user-visible）	広い	高	高
本番データ（非 git）	広い	高	高
外部送信（API 呼び出し・メール・支払い）	広い	無限大	最大

maximum caution は不可逆な外部副作用のみに割り当てる。git 内で閉じる操作は、break scope がどれだけ広くても caution medium 以下に留まる。削除判断は両方向に失敗しうる（rules/model/subtractive-structural-beauty.md の Core principle (C) の一例）：残すべきものを消す破壊的失敗と、消すべきものを残す保持既定への収束と。「分からないから残す」は保持既定に収束する。

Consolidate トリガー： 前回 consolidate から 2 週間経過で発火する。実行主体はトリガーが発火したセッションを保持する agent であり、外部の skill は名指ししない。pass の内容は、上の Entry Format の maintenance discipline を memory 集合全体へ次の順で当てることである。

1. 同種の entry を 1 本へ畳む（discipline の「重複は更新で処理」の適用）。畳んだ側のファイルは削除する
2. 陳腐化した entry を削除する（同 discipline）
3. 残った entry に合わせて MEMORY.md の索引を書き直す
4. [[wikilink]] が解決するか確認する。解決しないものは、entry を書くかリンクを外すかのどちらかに決める。未解決のまま残すのはどちらでもない
5. 実行を下記の 1 行として記録する

ここで外部ツールを名指ししないのは意図的である。同梱していない skill だけを経路として書けば、その skill を持たないホストでは手順がそこで止まり、止まりに出会った agent が他者の読めない即興の pass を入れる。

実行後は、索引 MEMORY.md の先頭に **Last consolidate run:** <YYYY-MM-DD> の 1 行として記録する。各 memory ファイルへは配らない。前回実行は memory 集合につき 1 つの事実であり、同じタイムスタンプを全ファイルへ複製すれば drift するのは複製側である（rules/model/subtractive-structural-beauty.md Core principle (A)）。行が無ければ未 consolidate と読み、トリガーは発火する。発火条件の成立は cold-start で surface される（上の Cold-start Synthesis 節の consolidate due surface。#2165）。

腕が一本なのは、二本目を測れなかったからである。二本目は「前回 consolidate 以降の新規追記が 5 件以上」と読み、gross の量を問うものだった。memory 集合の大きさのスナップショットから gross は復元できない。上の Entry Format が規定する削除が、追記された量と残っている量の差を消すからであり、既に索引されている運用ファイルへの追記はそもそも大きさを動かさない。ここに大きさを記録して差を取る形は、その腕が問うていない net の問いに答えることになる。数える対象を絞る形でも戻らない。絞った先の集合も gross で数えるのであり、削除の対象であることも変わらないからである。単調増加カウンタは二つに割れ、どちらも立たない。構造で保証できる側——memory ディレクトリへの書き込みを数える hook——が数えるのは書き込み操作であり、書き込み操作は追記ではない。1 回の編集が複数の entry を運ぶこともあれば、複数の編集が 1 つの entry を運ぶこともある。追記を正しく数える側は書き手のインクリメントに依存する。その編集が何件の entry を運んだかを知るのは書き手だけだからであり、それは rules/model/subtractive-structural-beauty.md が構造への置き換えを命じる、実行の保証されない手順そのものである。

落とした腕が供給していたのは volume 比例の発火——経過時間ではなく書かれた量に応える掃除——である。ただし供給していたのは文面上だけである。測定手段を持たない以上その腕は一度も発火しておらず、これまでに走った consolidate はすべて経過側の腕で走っている。量の側は別の場所が持っており、そのまま持ち続ける。重複は書き込み時点で update により解消され（上の Entry Format）、運用ファイルはそれぞれ自身の規定で上限を持つ（上の Scope）。それらを追い越すバーストはそれらの側の欠陥であり、修理はそちらで行う。このトリガーを二腕へ戻すことではない。

Self-Evolution Observation Format（自己進化 PR のマージ後検出サイクル）： 保存先は memory/self-evolution-observation.md（workspace ローカル、gitignore）。cluster tally（memory の外に置く。rules/evolution/promotion-judgment.md の Tally 節）が起票前の観測であるのに対し、こちらはマージ後の観測である。起票トリガーは 3 つ。

• 自己進化 PR（Evolution_Initiator_Autonomy の起票経路）のマージ後の瞬間に、PR が変更した面のうち少なくとも 1 つが下の作成基準を満たすとき、その瞬間を持つエージェントがエントリを書く。瞬間と実行主体は rules/operations/main-agent-procedures.md Merge Execution の Post-merge moment が定める。expire 窓は PR のリスクに応じて選ぶ（既定 2 週間）。どの面も基準を満たさない PR にはエントリを作らず、満たさなかった条件をマージ済み PR へ 1 行のコメントで残す
• 短窓の miss エスカレーション：rules/operations/operations.md Post-L1-Merge Runtime Observation が miss 判定を出したとき、既定サイクルを待たずに親 AI が即座にエントリを書く。作成基準を満たすかどうかは問わない
• 短窓観測の繰り越し：同節の観測が、変更された規則がまだ実行時文脈に載っていないためマージ後の瞬間（rules/operations/main-agent-procedures.md Merge Execution の Post-merge moment）に開始できない場合、その瞬間を持つエージェントが繰り越しをこのエントリの notes へ 1 行として書き、後で観測を取ったセッションがその結果を 2 行目として追記する。そのためのフィールドは足さない。繰り越しそのものには verdict を入れない。エントリが無い PR では、2 行ともマージ済み PR へのコメントとして書く

作成基準は、変更された面が次の 3 つをすべて満たすこと。

1. その面の application moment が、expires までの間に、ふつうの session の中で観察できる形で来る見込みがある
2. その面が壊れたことを検出する、実行される仕組み（テスト / CI）がない
3. その application moment で何を見れば効いた / 効いていないと分かるかを 1 行で書ける。エントリはその行を check として持つ。due 時の判定で check を持たないエントリは、その場で実行主体が行を書き込んだときに限り 3 を満たす

適用場面の記録： pending のエントリが観察している面の application moment が起きたセッションでは、そのセッションを持つエージェントがその瞬間に、エントリの notes へ 1 行（日付、起きた場所（issue / PR / session）、check が示したこと）を書く。no regression observed が要求する「application moment が notes に記録されている」は、この行で満たされる（#2179）。

エントリ書式・作成基準・lifecycle の正本は skills/evolution-observation-entry/SKILL.md に置き、cold-start での due / overdue サーフェシングの正本は rules/evolution/cold-start-synthesis.md の Self-Evolution Observation Surface 節に置く。rules/evolution/memory-entry-format.md の同名節はこの skill への参照だけを持つ（#2131）。L1 マージ後のランタイム観測の起点・観測セット・繰り越しも同じ skill の # Post-L1-Merge Runtime Observation に置き、対象と呼び出しアンカーだけが rules/operations/operations.md の同名節に残り、そこから skill の節を名指す（#2141）。この手順が要るのはマージ後の瞬間と、エントリが cold-start で due / overdue として surface されたときだけであり、常時ロード面に置く理由が無い。それぞれの瞬間には名指しのポインタが立つ —— マージ後の瞬間は rules/operations/main-agent-procedures.md Merge Execution の Post-merge moment、miss のエスカレーションと短窓観測の繰り越しは rules/operations/operations.md Post-L1-Merge Runtime Observation、cold-start は hook が due / overdue の一覧に続けて出す「Verdict transition ... follows skills/evolution-observation-entry/SKILL.md」の 1 行 —— ので、発火は skill の自動起動の想起には依存しない。例外は適用場面の記録で、その瞬間は任意のセッションの任意の作業中に来るため名指しのポインタを立てる面が無く、skill の description（観察中の面の application moment）による自動起動に依存する（#2179）。

この形式が扱うのは検出軸だけである。元に戻す経路（GitHub の revert / gh pr revert）と、判断を残す経路（Decision Structure の supersede edge）はそれぞれ別の軸にあり、revert / supersede の判定はそれらの軸へ渡す出口であって、その軸の手順を本形式が持つわけではない。

他 surface との分離： cluster tally の expire / 閾値削除は rules/evolution/promotion-judgment.md、memory ↔ docs / wiki / rules の仕分けは skills/evolution-persistence-tiering/SKILL.md、self-evaluation の採点軸は skills/evolution-self-eval/SKILL.md に書く。本セクションは memory 内部の entry 書式と運用のみを射程とする。

（→ rules/evolution/evolution.md）

observe 段階の出力契約：セッション開始時、memory から Li+ ソースへの昇格候補は観測可能な素材として surface されなければならない。受動的な気づきに依存しない。

サーフェシング要件：

• 素材収集（memory スキャン、パターン検出）はアダプターの cold-start 経路に委譲する
• 出力位置はオリエンテーション面、合成指示ブロックの直前
• 検出対象は self-evaluation ログの反復、memory の最近の追加、memory と Li+ ソースのキーワード重複
• 閾値数値や具体的な検出ロジックはアダプター側が持つ。本仕様は挙動契約のみを定義する
• ソースが不在または候補が検出されないときは silent skip

下流責務：

• サーフェシングは観測であり昇格ではない。昇格判断は distill → reflect → L1 更新ゲーティング（該当する場合）を経由する
• サーフェスされた候補はセッション開始時の observe 判断を補助するが、永続化ティアリングや L1 ゲートを迂回しない

---

（→ rules/evolution/evolution.md Evolution Axis Separation）

L1 Model Layer: Loop Safety、受容済み論点の扱い、レビュー出力の分離はモデルレイヤー側に残す。これらはランタイム不変条件であり、自己更新機構ではない。進化レイヤーはこれらランタイムルールによって観測される事象を入力として使うが、その定義を書き換えない。

L3 Task Layer: 蒸留されたパターンの一次外部化先は issue body である。進化レイヤーは Li+ 仕様の改善を直接編集ではなく issue 経由で提案する。

L4 Operations Layer: Li+ ソースの更新は標準のブランチ / コミット / PR / CI / マージのパイプラインを通す。進化レイヤーはオペレーションルールを迂回しない。

進化レイヤー内の読み手 / 書き手対： 判断学習が読み手側（新しい判断形成前に過去判断 graph を query する）、判断構造の書き出しが書き手側（判断成立直後に Decision Structure Wiki に state 形エントリを記録し、適用可能な supersede / depend / conflict edge を declare する）として対をなす。両者でセッション横断の判断知ループを進化レイヤー内で閉じる。書き手側は docs ティアの Wiki surface に対する書き出しに射程を限定し、永続化ティアリングを迂回しない。この対の記述と、Decision Structure が時系列ログではなく意味グラフであり維持は refactor であること、Wiki への書き出しが永続化ティアリングを迂回しないことは、rules/evolution/evolution.md の本文には置かない。正本は skills/evolution-judgment-learning/SKILL.md と skills/evolution-decision-structure-write/SKILL.md（冒頭と Boundary with Persistence Tiering 節）、および adapter/claude/CLAUDE.md の Decision_Structure_Write_Autonomy である（#2140）。

---

自律 = AI が自律的に判断して動く領域。外部からの促しは不要。AI が判断を持つ。

Li+ ソースの更新ターゲットは既定で L3 Task Layer 以降から選ぶ。L1 Model Layer は種として扱い、観測可能なパターン証拠を必要とする。

各レイヤーの接続チェーン上の位置は更新難易度のプロキシである。進化レイヤーから見て L1 が最も触りにくく、L6 Adapter 方向ほど触りやすい。更新ターゲット選定はこの重み付けに従う。

蒸留段階でメモレベルの閾値を超えたパターンを検出したら、人間の指示を待たずに issue として外部化する。issue 作成時点で3項目がすべて埋まっていることは要求しない。memo ラベルから出発してよい。

判断構造レイヤー（Decision Structure: wiki エントリ、docs/Decision-Structure.md index 配下）への書き出しと、タスクレイヤーへの issue 化は、いずれも外部記憶への判断の固定である。どちらに書くかは永続化ティアリングで決める。

現行は AI 主導で全周を回す。各段階を AI 単独で回し、人間ゲートはリリース / 不可逆系の軸と execution-mode の minor/major レビューに残す（L1 更新のゲートは issue 形成時の観測閾値、上記「マージゲートの brake との関係」参照）。人間への確認を段階ごとに差し込むと閉路が回らなくなるため、自律可能な段階を自律的に進める姿勢を既定とする。

---

再構築・削除・最適化はすべて許容する。構造の一貫性のみ維持する。