2. Evolution

進化レイヤー仕様書

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

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

---

Purpose Declaration（目的宣言）

（→ 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 が無い）、基質層の Sheepdog は defer されている。

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

---

責務分類

（→ 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 失敗）が発生して記録要否を判断するとき、および自己評価エントリを記録するとき
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。release は含まない（呼び出し側が付加）

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

ファイル	役割
rules/evolution/evolution.md	L2 レイヤー定義本体（Purpose / Axis Separation / Pattern Detection Surfacing / Mutability）
rules/evolution/cold-start-synthesis.md	Cold-start Synthesis 手順定義。フックがここから素材をリテラル抽出する
rules/evolution/promotion-judgment.md	memory observation から Li+ 正規ルールへの昇格判定（cluster tally / 3 日 expire / 閾値ゲート）
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 / recovery 軸
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 節（Hook Emission Contract / Self-Evolution Observation Surface）はフック自身の挙動仕様であり、AI がステップ 3 の適用時点で参照しないため anchor に含めない。ルールファイル自体は always-on でロードされるので、全文 emit は同一セッションの context に同じ本文を二重に載せていた。skill 経路は通らない。

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

---

ルール

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

L1 更新ゲーティング

（→ 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 にとって荷重を持たず、共条件として読んではならない。下流のゲートが判定するのは変更の内容であり、ここでの軸は誰が起こしたかである
• これはゲートの緩和ではない。AI-alone initiation は観測閾値を hard requirement として不変に保持する。観測ゲートの主語はどちらの場合も実装側 AI である

永続化ティアリング

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

• memory はワークスペース固有の個人ノート。リポジトリにコミットしない。RAG インデックスにも入れない。transient のみ（詳細は rules/evolution/memory-entry-format.md）
• docs はプロジェクト情報。リポジトリにコミットする。RAG インデックス対象である
• 書き出す前にティアを決める
• 設計判断・要求仕様・spec 級の内容は docs へ
• 個人的な振る舞いメモ・セッション固有の好みは memory へ
• ティアを無言で跨がない。memory から docs への昇格は明示的な意図を必要とする
• 永続情報の昇格先は 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（利用可能な場合）。issues / PRs / docs / releases に対する hybrid retrieval（意味検索とキーワード検索を併用する dense + sparse 構成）
• フォールバックは 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" で叩いて重複を確認する
• 既存エントリ無効化時は削除せず 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 が条件を判断し、条件に合致したら必ず実行する。

Cold-start Synthesis（起動時の状態合成）

（→ 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 不在）、全 section 変化	全 section + footer に理由
diff-only emit	一部 section だけ変化	変化した section のみ + cold-start rule anchor
no-new-material marker	全 section 不変、かつ observation 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 エントリ）が emit された session では marker を出さない。observation surface は section key を持たないため diff-only 比較には載らないが、素材としては marker を抑止する側に数える ── overdue なエントリを提示しながら「新規素材なし」と述べるのは自己矛盾の出力になるため。

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

state file は {workspace_root}/.claude/state/last-cold-start-emit.json（sha256 fingerprint を section ごとに永続化）。詳細仕様と schema は 6. Adapter — on-session-start.sh を参照する。

運用基準（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+ 自身の状態であり、ワークスペースのタスク状態ではない。ワークスペース固有のオリエンテーションはアダプターの起動パスが扱う。

Self-Evaluation（二軸自己評価）

（→ 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 等）は入力にしない。

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

Evolution Loop（進化ループ）

（→ 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）は 2026-09-01 に rules/model/liplus-coding-rule.md Body States Behavior を適用済みであり、振る舞いのみを載せる（#1845、49,217 → 42,089 B）。剥いだ理由のうち既存 entry が持たない分は判断記録 parallel-agent-eval-body-carries-behavior-only が保持する。ポインタは理由を抜いた段落（リストでは項）ごとに 1 本置く——粒度は規則自身の初適用（PR #1842）が段落ごとに 1 本を置いた形に従う。本節は記録面であり同規則の scope 外——理由を持ち続けてよく、写るのはポインタだけである
• どの PR が brake 1 の対象かは 2 条件の連言で決まる。①Evolution_Initiator_Autonomy の起票経路（AI 起票 → AI 実装）であること、②統治面を変更すること——の両方であり、片方だけでは決まらない。②を閉じるのは path の列挙ではなく基準であり、その基準と、それが該当／非該当へ置く面の解決は正本が持つ。本節へは写さない。正本は rules/evolution/initiator-autonomy.md Self-evolution PR definition。判断記録: brake1-firing-closed-by-criterion
• brake 1 の固定軸（impression-literal detection）の範囲は②の発火側と一致しない。範囲を閉じるのは「エージェントが自らの指示として読み実行する散文か」であり、これは固定軸の除去テスト（この句を消して振る舞い意味が変わるか）が、テキスト自身が規定している振る舞いの上でしか走らないことから出る。現に解決する面は rules/**/*.md skills/**/SKILL.md adapter/**/* Li+update.md である。②の発火側のうち強制の後ろ盾（tests/** / .github/workflows/**）は実行コードであって散文ではないため、除去テストが一定に保つべき振る舞い意味をそこに持たない。②と重なるのは片腕だけであり、導出が同じだから重なっているのであって同一の列挙ではない——path 単位で②へ揃える修正は行き過ぎである。正本は skills/evolution-impression-literal-detection/SKILL.md
• brake の実行位置は CI green の後・merge ゲートの前 である。commit の前ではない。発火の瞬間は委譲した subagent が停止条件で報告した時点であり、親は working tree ではなく報告を手に brake に着く。評価者へ渡す材料は PR URL・push 済みの commit SHA・緑の CI run URL であり（親のクローン内のパスは渡さない）、評価中にベースラインが動かない。正本は rules/evolution/initiator-autonomy.md Merge brake
• 指摘を裁くのは親ではなく、実装した subagent を再開したもの（著者）である。かつその往復は PR コメントを直接の伝達面として行われ、親は往復の内容を監督しない。 brake 1 の評価者は所見を自分で PR コメントとして投稿し、著者は同じスレッドへ裁定を返す（受入 / 却下とその理由。commit の有無に関わらずコメントであり、置き場は分岐しない）。親の分担はスケジューリングだけである——新しい所見が付いたら著者を再開して入口だけを渡し（「スレッドの所見を読んで裁け」まで）、CI green で戻ってきたら次のラウンドを開くか loop を閉じる。読んでから中継することも、統合することも、取捨選択も、順位づけも、回答もしない（受入 / 却下は著者の権限である）。往復には上限があり、上限は 3 である。 1 往復 = 評価ラウンドの所見投稿 → 著者の応答（修正 commit ／却下コメント／その両方）→ CI green であり、初回の評価が 1 往復目である。所見の無いラウンドが出た時点、または 3 往復を終えた時点で loop を抜ける。親はそこで初めて PR スレッド全体を読み、セルフレビューとマージ判断に入る。「一度も読んでいない親は処理の当否を判断できない」は保たれており、満たす位置がラウンドごとから出口へ移っただけである。却下は loop の内側では最終である——次以降のラウンドの評価者はスレッドを読み、既出の所見も却下済みの所見も再提起しない。理由は上限の有用性そのもので、再提起を許せば 3 往復すべてが一件の押し問答で埋まりえ、それを決着させられるのは親だけであり、この 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（裁定主体そのもの）。正本は、裁定主体と伝達面が rules/evolution/initiator-autonomy.md Merge brake の Adjudication actor / 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 の各軸の書き方も 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）。残余——評価者が黙って補った読みで答え、信号が一つも出ない場合——は post-merge observation 軸で受容する（本ファイルのもう一件の実行保証なき要求と同じ扱い）。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
• 所見の可否を決めるのは計数ではなくリテラルである。 比率も多数決も、この方法のどこにも判定入力として入らない。各所見は、その パス:行 が名指す 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 軸のポインタ、および判定に合うよう事後選定されたポインタ）は post-merge observation 軸で受容する。言語の規定は評価者側へ戻った——評価者が契約の及ぶ面（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 自律

Rule Effect Measurement（規則の効きの実測）

（→ 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 が、削除に論証を要求するあらゆるゲートの構造そのものに埋まっている。

• 適用点は新規追加の門であり、既存節の総掃きではない。比較相手は「今の全部を載せた木」であって空ではない（重複検出器）。単体で無意味な行は少なく、空を相手にした一行ずつの入場試験はほぼ全部を通す。膨張を作っているのは重複だからである。既存の掃き出しは余力での後追い
• 自己進化 PR のパイプライン上の位置は 実装 → CI → 実測 → brake 1 である。CI green の後、brake 1 の評価者 spawn の前に起こす。評価者が受け取るのと同じ基準点に載せるためであり、CI より前に測ると測った本文と評価される本文がずれる。実行主体は親である——その位置で材料を握り評価者の spawn をスケジュールしているのは親であり、別主体に割ると同じ材料を二つの主体が別々に組むことになる。腕は claude -p の別プロセスなので subagent を一段挟んでも腕の起こし方は変わらない。判定役の分離はこれで動かない（親が起こすのは走行であって判定ではない）。発火条件は、統治対象の本文（rules/** / skills/** / adapter/**）において削除行が追加行を上回る PR である。行を増やす PR を測っても得られるのは「増えた行が効いている」であり、それは争点になっていない。自己申告は採らず、余白に閾値も設けない
• 二段構成。段1 = 対象本文の抜粋を親プロンプトに注入する安い篩い。差が出れば load-bearing 確定、ゼロ差は段2へ送る振り分けであって判定ではない。段2 = ライブ木から .claude/ + CLAUDE.md + Li+config.md を複製した面を2つ作り、一箇所だけ変えて claude -p を起こす。本番同等の密度でなおゼロ差なら重複として落とす
• 段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 を触ると外から検出できない誤判定になる
• 判定役は腕から分離する。二本の出力の差を読む三人目であり、Li+ を抱えていて構わない。結論だけを数えず、どの文言を引いたかを読む。「穴の報告」と「判定そのもの」を別枠で数え、効きとして採るのは後者のみ（腕は欠落に気づいて自制するため、出力が穴の報告になる。これを効きに数えるとあらゆる行が load-bearing に見える。probe 側で穴への言及を封じるのは不可——気づきは消えず消えるのは兆候だけで、その兆候こそ漏れの有無を判別した当のものだからである）
• 腕のモデルは実験条件として固定し記録する。同一 probe・同一ワークスペースでモデルにより結果が反転した（haiku 0/3 漏れなし ／ Opus 1/1 漏れ）。弱いモデルは取得もしない代わりに節の適用もしないため、あらゆる差が過小に出る
• probe は内容照合と行動照合を併用する。内容照合だけだと、常時ロード側の規則を再掲した行で誤検出する（本文からは消えるが conduct は不変）。逐語の欠落検出は内容照合にしかできないため置き換えではなく併用（#1853）
• 二つは別の形で書く。行動照合は内容照合の文言を緩めたものではない。内容照合 = スキルの呼び出しを指示し、本文に従って逐語で答えさせ、規定が無ければ規定なしと述べさせる。行動照合 = 状況だけを提示し、スキル名も本文も挙げず、何が書かれているかを一切問わず、腕が取る行動そのものを答えとする。本文参照の指示は弱めるのではなく無い。答えが離散的な行動選択に落ちる設問を選ぶ。また、既に落ちた行について問いを立てられるのは行動照合だけである（本文から消えた行について「本文に何と書いてあるか」は問いにならない。conduct 行の脱落が内容照合だけの周では素通りするのはこのため）
• 判定役は行動軸を独立の枠で読む。内容軸の結果は行動軸を決めない。どの文言を引いたかではなくどの行動を取ったかを読み、両腕同じ行動＝効き無し（conduct は常時側が持っているか、その行が conduct を持っていない。内容差がこれと並ぶ形が再掲の署名であり、残す／落とすは行動列で決める）、行動が割れる＝効き（B腕が失ったのは conduct である）。行動設問に対して「規定なし」と答えた腕は内容の問いに答えており、probe が本文を挙げたか匂わせている。その周は差ではなく無効であり、行動の形で立て直す
• 揺れの帯は行動軸で未測定である。帯 0 の実測は内容 probe 上のものであり、行動軸はその条件に入っていない。離散的な行動選択に落ちる設問なら同じ帯を持つ見込みだが見込みは測定ではなく、離散性が共通であることを根拠に 0 を持ち越す形をここで禁じる。帯はモデルごとに加えて軸ごとに測る
• 走行物はゼロ。排他ロック（os.mkdir 一発。取れなければ起動できない）、temp 下の固定パス、try / finally での削除、そして冒頭の無条件削除という二枚構え。durable に残るのは道具（スクリプトと skill）と走行記録のみである。受け入れたトレードオフ: ロックの中身は時刻のみで PID を持たないため、閾値より長く走った実行のロックは stale と判定され別の実行が入りうる。閾値を実行時間より十分長く取ることで起こらないと見て引き受ける
• 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 と理由（上限 / 発火条件外 / 測る対象が無い）を明示し、空欄にも陰性にもしない。空欄は読む側に「問題なし」と読まれ、判定の不在が判定として機能してしまう。セルフレビューは brake 1 が抜けた後に書かれるため、そこへ書いたものは評価者へ届かない
• 本機構自身への適用。設計の穴が見つかるたび条件が増えるという形が、本機構が対象としている膨張と同じ構造であるため、本機構の条件そのものを本機構の門にくぐらせる。判定基準は probe と同一で「この条件は適用の瞬間に何を変えるか」であり、一文で言えない条件は入れない
• 構造的限界（外側の位置）。条件を積み上げている当事者が門を運用する場合、門をくぐらせる発想そのものが出にくい。設計中、経路の漏れが見つかるたび AI 側は条件を1つ足す方向にのみ動き、「経路を数えるのをやめ許可を1つだけ挙げる」という解は設計に参加していない Master から出た。判定役を書き手から分離するだけでは足りず、条件を足す判断そのものにも外側が要る。rules/model/role-separation.md の human = final judge は、承認手続きとしてだけでなくこの構造的位置として読む

Memory Entry Format（memory entry の書式と運用）

（→ 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 / promotion_tally.md / self-evaluation_log.md / self-evolution-observation.md）の entry 書式とメンテナンス規律を、各 file 内ローカル運用メモから L2 Evolution Layer の正規ルールに昇格する。横断規律として single source で扱い、各 memory file 冒頭の運用メモはこのルールへの参照に置き換える。

スコープ：memory は transient のみ。 memory が扱うのは cluster tally・self-evaluation log・reference に限る。永続情報は 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 トリガー： anthropic-skills:consolidate-memory skill を、前回 consolidate から 2 週間経過で起動する。

実行後は、索引 MEMORY.md の先頭に **Last consolidate run:** <YYYY-MM-DD> の 1 行として記録する。この書き込みは呼び出し側自身の手順であり、skill の pass が戻った後に行う。skill がやってくれるものとして依存しない。各 memory ファイルへは配らない。前回実行は memory 集合につき 1 つの事実であり、同じタイムスタンプを全ファイルへ複製すれば drift するのは複製側である（rules/model/subtractive-structural-beauty.md Core principle (A)）。行が無ければ未 consolidate と読み、トリガーは発火する。

腕が一本なのは、二本目を測れなかったからである。二本目は「前回 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/promotion_tally.md）が起票前の観測であるのに対し、こちらはマージ後の観測である。起票トリガーは 3 つ。

• 自己進化 PR がマージされた直後（Evolution_Initiator_Autonomy の起票経路）に、親 AI かマージを担ったサブエージェントがエントリを書く。expire 窓は PR のリスクに応じて選ぶ（既定 2 週間）
• 短窓の miss エスカレーション：rules/operations/operations.md Post-L1-Merge Runtime Observation が miss 判定を出したとき、既定サイクルを待たずに親 AI が即座にエントリを書く
• 短窓観測の繰り越し：同節の観測が、変更された規則がまだ実行時文脈に載っていないためマージ時に開始できない場合、マージしたエージェントが繰り越しをこのエントリの notes へ 1 行として書き、後で観測を取ったセッションがその結果を 2 行目として追記する。そのためのフィールドは足さない。繰り越しそのものには verdict を入れない

エントリ書式・lifecycle・cold-start での due / overdue サーフェシングは正本（rules/evolution/memory-entry-format.md）側に置く。

他 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 書式と運用のみを射程とする。

Pattern detection surfacing at cold-start（冒頭サーフェシング）

（→ 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 に対する書き出しに射程を限定し、永続化ティアリングを迂回しない。

---

自律

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

更新ターゲットの自律判断

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

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

パターン検出からの issue 化

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

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

進化ループの閉路

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

---

進化

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