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 / brake 2 = L1 Model Layer ソース変更に追加される根本基準評価者 adapter/claude/agents/l1-gate-eval.md）が担保する。基質層は入力駆動のポーリングのままであり（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 を必要とするとき、N=1 self-check が positive に感じたとき、spec 改定提案に直交検証が要るとき、brake 1 の評価者報告・親の統合コメント・著者の裁定のいずれかを書こうとするとき
Impression-literal Detection	skills/evolution-impression-literal-detection/SKILL.md	評価者が Li+ source ドラフトの impression-literal 固定軸に答えるとき、ある語句が振る舞い意味を支えているか判定するとき（brake 1 の固定軸、本体は分割で #1598 に切り出し）
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 定義 / 二段ブレーキ（brake1 = parallel-agent-eval N≥3・1 巡打ち切り / brake2 = L1 root-criteria evaluator）/ 裁定主体 = 再開した実装 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 2 との関係:

• Evolution_Initiator_Autonomy（adapter/claude/CLAUDE.md）は、self-evolution PR が L1 Model Layer ソースを touch するとき、この観測ゲートの上に根本基準評価の要件（brake 2）を重ねる。二つのゲートは直交する軸である
  • この skill = 観測閾値ゲート（長期パターンを観測したか？ 主語 = AI）
  • brake 2 = deviation gate（変更は Li+ 根本基準から逸脱していないか？ 主語 = 専用プロンプト subagent 評価者 adapter/claude/agents/l1-gate-eval.md。PASS = Master 承認の代替、DEVIATION = merge 不可）
• L1 更新では両ゲートが発火する。観測ゲートが先（issue 作成フェーズ）、brake 2 が後（PR review フェーズ）
• 旧文言「human の判断ゲートは rules/operations/execution-mode.md 側の surface であり L1 spec 編集とは別軸」は観測ゲートのみを指していたものであり、Sheepdog 完成の二段 brake 構造により supersede 済（その時点の brake 2 = human review）。brake 2 の座はその後 human review から根本基準評価者へ移行した（#1477）。brake 2 は引き続き L1 spec 編集 PR に必須。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 判断が在り brake 2（根本基準評価者）が PR をゲートするため、その対が観測閾値の役割を担う。観測閾値は human-directed L1 変更の独立した前提条件ではない
• これはゲートの緩和ではない。AI-alone initiation は観測閾値を hard requirement として不変に保持する。carve-out は initiation 軸のみのスコープ（human-directed = human 判断 + brake 2 / AI-alone = 観測閾値）であり、二軸分離（観測ゲート主語 = 実装側 AI / brake 2 主語 = 変更作者から独立した根本基準評価者）は保持される

永続化ティアリング

（→ 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 に従う。混在は不可
• 知識 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 の催促になる（完了報告の瞬間に同じ規律を持つのは skills/operations-on-release/SKILL.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、N>=3）を必ず通す。L1 Model Layer の変更は加えて brake 2（adapter/claude/agents/l1-gate-eval.md 評価者の PASS）を要する。変更ごとの人間 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 は加えて brake 2）を通す
• どの PR が brake 1 の対象かは 2 条件の連言で決まる。①Evolution_Initiator_Autonomy の起票経路（AI 起票 → AI 実装）であること、②統治面を変更すること——の両方であり、片方だけでは決まらない（2026-08-08、docs/ のみの PR に対し委譲先が①だけを見て「brake 1 は該当」と報告した実測がある。#1700）。②を閉じるのは列挙ではなく基準であり、基準は「振る舞いを規定し、かつ誤りを捕まえるものが読み手しか無い面か」である——brake 1 の検出器が読み手（N>=3 の評価者）だからである。該当するのは rules/ skills/ adapter/ Li+update.md（エージェントが自らの指示として読み実行する散文）と、tests/ および .github/workflows/（強制の後ろ盾そのもの。契約テストと、それを走らせてチェックを生む workflow である。実行コードだが背後に立つチェックが無く、テストは黙って通る方向で壊れても green を返し、workflow はトリガが噛み合わなくなればそもそも run が起きず赤いチェックすら出ない——何も落ちないため検出器は再び読み手だけになる）。非該当は記録面（docs/ と wiki、README.md、LICENSE、NOTICE——過去判断の retrieval 面であり、誤りの代償は引き直し 1 回）と、背後にチェックが立つ実行コード（scripts/ と .github/scripts/——欠陥は呼び出したターンの例外か赤いチェックとして出る。黙る側の経路は tests/ が声にしている）である。基準がどちらにも置かない面は発火側に落ちる。docs/ は Scope に入りつつ②では非該当であり、二つの列挙は別軸である（Scope = AI が起票してよい面 / ②= brake 1 が門を張る面）。正本は rules/evolution/initiator-autonomy.md Self-evolution PR definition
• brake の実行位置は CI green の後・merge ゲートの前 である。commit の前ではない。発火の瞬間は委譲した subagent が停止条件で報告した時点であり、親は working tree ではなく報告を手に brake に着く。評価者へ渡す材料は PR URL・push 済みの commit SHA・緑の CI run URL であり（親のクローン内のパスは渡さない）、評価中にベースラインが動かない。brake 2 は inline で渡す L1 diff が CI に依存しないにもかかわらず同じ位置に固定してある——diff が merge ゲートの作用する SHA と同一を指す必要があり、かつ位置を1つにすれば適用の瞬間に順序の判断が要らなくなるためである。正本は rules/evolution/initiator-autonomy.md Two-stage brake
• 指摘を裁くのは親ではなく、実装した subagent を再開したもの（著者）である。 brake 1 の評価者は指摘を親へ報告として返し、PR へは何も書かない（#1732）。親は N 体の報告を 1 本の PR コメントへ統合して投稿し、著者を再開する。再開した著者はそのコメントを読み、各指摘を裁き、受け入れた分を修正し、受入 / 却下とその理由を commit body に記録して再び CI green で止まる（PR コメントには投稿しない）。親はその裁定を検分し、必要なら修正を名指しして著者をもう一度再開する——往復に回数上限は置かず、収束判断を保持するのは親である（skills/model-loop-safety。二者間ループで数える主体を決めないと、双方が相手が数えていると仮定する）。最後にセルフレビューが締める。指摘が親の文脈を通ることがこの検分を買っている——1 件も読んでいない親には、それがどう扱われたかを判定できない。親の分担は統合と投稿までであり、取捨選択はしない（受入 / 却下は著者の権限であり、投稿前に落とされた指摘はその権限を持つ主体へ届かない）。効く点は三つで、却下が往復の文脈ではなく commit body に durable に残り、単巡打ち切りの下で評価者が再反論しないため親の検分だけがその後ろに立つこと、往復は評価者ラウンドではないため single-round cap に触れないこと、および再開が実装文脈を保つため skills/task-subagent-delegation/SKILL.md が受容していた「親が報告から文脈を組み直す」対価が支払われなくなること（「実装は常に委譲」の判断軸である規則の単純さは不変で、条件分岐が1つ減る）。GitHub への書き込みは 1 PR あたり 5 回から 2 回（指摘なしなら 1 回）へ減り、評価者 3 体が同一 PR へ数秒以内に並列投稿するバースト形状が消える。エージェントの深さは 1 のままで、評価者を spawn するのは親であり著者は何も spawn しない。正本は rules/evolution/initiator-autonomy.md Two-stage brake の Adjudication actor
• brake 1 の評価者へは 評価対象を書き換えるな と委譲プロンプトで明示する。文言は skills/evolution-parallel-agent-eval/SKILL.md Constraint に literal として置いてあり、親はそれを写す（毎回作文しない）。上の材料に親のクローン内のパスを含めないのはこの指示と対であり、前者が書き込みの意図を断ち、後者が共有ベースラインという的そのものを外す。literal に carve-out は無い（#1732）。評価者に PR という投稿先が無くなったため、Do not post to the PR が報告先を否定形で述べる 1 行として literal の内側に入っており、「コメントは書き換えに当たるか」という問い自体を開かない。評価者のツール権限は絞らない（custom-agent の tools: は Claude Code では本文が system prompt を置換するため identity ごと変わり、probe 型の観測対象を壊す）。したがってこれは構造ではなく親が思い出す手続きであり、忘れれば効かないことを受容している。brake 2 は adapter/claude/agents/l1-gate-eval.md が tools: Read、Codex 版が sandbox_mode = "read-only" を持ち、材料も inline 渡しでリポジトリを名指ししないため対象外
• brake 2 は両側とも inline の形を保つ。評価者は tools: Read で入力も inline のため投稿先の PR 面を持たず、verdict は従来どおり親へ返る（PASS / DEVIATION はマージゲートそのものであり、マージは親のものだからである）。動くのは裁定の主体だけで、DEVIATION のとき親は修正せず、名指しされた逸脱を PR へ運んで著者を再開する
• brake 1 の各軸の書き方も skill 側で固定してあり、親が毎回作文しない。親は評価器具（軸文言）を、その器具の対象をリテラルに読んでいるのと同じ瞬間に書く——そしてリテラル検証は対象には届くが器具には届かない（#1692、3 日で 7 回観測、うち 5 回が「一つの軸名が複数の問いを抱える」形。可視に連結されている場合と、一語の述語へ圧縮されて一問に読める場合とがある）。対象は親が spawn 時に書き起こす軸ごとの軸（Trigger の Additional axes = selected per draft nature）であり、固定軸は範囲外である（固定軸の文言は毎回書かれるものではなく skills/evolution-impression-literal-detection/SKILL.md に置かれており、ここが塞ぐ「その場で書く」経路に乗らない）。軸は 5 つの名前つき部分として書く：Question（疑問文を 1 つだけ。かつ判定を生む操作を名乗る——評価者が材料に対して何をし、その結果のどれが所見なのか。and や読点で繋いだ 2 節は 2 操作＝ 2 軸である。数えるのは節ではなく操作である。評価を名乗って操作を名乗らない述語——forced、consistent、resolves wrongly——は数を隠して運ぶからである。読みごとに為すことが違い、連言は一語の内側へ圧縮されていて節の禁止が届かない。操作を書くことがこれを解凍する——読みは軸を書いているその場で別々の疑問文へ分かれ、そこへ節の禁止が他の対と同じように発火する。操作を名乗らない疑問文は答えられるのではなく未記入である。評価者は自前の読みを補わなければ着手できず、独立に補われた読みこそが不一致の顔をして現れる割れである。ただしここで成果物に載るものは上記の空欄ラベルより狭く、その差は伏せずに書いてある——空欄の部分は何も当てない読み手にも欠けて見えるが、評価的な述語は通常の文面でその部分を埋めており、区別を当てて初めて欠落として読める。得られているのは、その区別を、軸を書いているその場に在って引用可能なテキストへ当てられること（後から手順として思い出すのではなく）である。残余——著者と N 体の評価者がたまたま同じ読みへ収束し、割れが出ないため信号も出ない場合——は post-merge observation 軸で受容する（本ファイルのもう一件の実行保証なき要求と同じ扱い）。c0020a2 の forced、#1763 の「整合」、#1766 の resolve wrongly がこの形である。このうち c0020a2 と #1766 は 5 部分が記入済みでこの結果になっており、未記入の検出では防げない——だから塞ぐ先は Question の文言側である）/ Unit（1 つの判定が覆う単位＝文・段落・ファイル・主張・出現）/ Scope（軸が及ぶ面＝当該 PR の diff・名指しした 1 ファイル・リポジトリ・リポジトリと wiki。不在の主張はどこを掃いたかを述べる。幅には広がりのほかに言語という次元があり、軸は両方を述べる。本リポジトリは正規テキストの多くを二重に持つ——rules/ と skills/ が英語、docs/ が日本語であり、多くは前者のミラーだが、場所によっては docs/ 自身が正本である（docs/5.-Notifications.md は自らを正本と宣言しており、ミラー元となる rules/notifications/ が存在しない）——ため、リポジトリ全体に及ぶ掃引でも英語パターンだけで走れば日本語側には一度も届いておらず、その不在の主張は見落としではなく構造的に掃き残している。正本側の事例のほうが鋭い——掃引が代わりに当たれる英語の対応物がそもそも無いからである（2026-08-12 観測。#1733 の brake 1 が docs/3.-Task.md の日本語ミラーの取り残しを 2/1 で検出し、同 PR の fa87222 で修正済み。残渣は現存しない）。広がりだけではこれを運べない——リポジトリ と書かれた scope はその掃引で満たされてしまう。Report shape が復路（所見の無い軸）に掃引のパターンを要求しているのと同じ次元を、往路すなわち軸を書く側で要求する）/ Verdict terms（その軸での yes と no の意味を軸自身の語で。「何か落ちたか」を問う軸では所見は yes でありながら draft にとっては negative であり、極性を名乗らない軸は誤った極性を継ぐ）/ Basis（軸が対象・基準について述べることはすべて、名指しした SHA で解決するポインタを伴う。基準は パス または パス:行 付き逐語引用、例示は実在箇所からの引用、件数が効く軸には数値でなく数える本文を渡す。形式だけでは満たされない——判定を当てる先、すなわち軸が判定基準とする既存の Li+ 基準や親が依拠する論証は、必要な軸ごとに書き込む。軸は隣に書かれたものを継承せず、基準を名指さない軸は clean ではなく未記入である）。5 部分はすべて評価者のプロンプトへそのまま載る payload であり、通れば消える点検項目ではない。書かれなかった部分は評価者が読む本文の欠けたラベルとして見える。機構は成果物上のこの可視性であって、rules/model/subtractive-structural-beauty.md が「手続きを構造へ置き換えよ」と要求するときの実行保証には届かない。立っている根拠は #1630 が「落ちた手順を、憶えておくべき 1 行として別の面へ置き直す」案を却下したのと同じものである。正本は skills/evolution-parallel-agent-eval/SKILL.md Axis statement form
• brake 1 で評価者の判定が割れたときは、①同じ問いに答えたか（same-question check）→ ②同じ問いならなぜ割れたか（判定基準の曖昧さに遡るか、明確な基準を適用する際のゆらぎに遡るか）の順で、各一度だけ問う。①が No なら課題は基準側でなく軸の書き方（一つの軸名が複数の問いを含んでいた）にあり、その No は Axis statement form のどの部分が保たなかったかを名指す先へ着地する（従来のように「次回の申し送り」へは行かない）。事前の Question と事後の same-question check は代替関係ではない——事後側は「部分は埋まっていたが緩く埋まっていた」軸を捕まえ、本 form 以前に書かれた軸にも効き続ける。「同じ問いに答えており、基準はこれで足りていた」は正当な帰結であり、盲点の発見を要求しない——rules/model/trigger-check-gate.md と同じ形（一つでも No なら止まって取得・検証して進む）である。無い所に基準の隙間を書き起こすのがここでの失敗モード
• 比率（3/3 / 2/3 / 1/3）は判定入力ではなく、検証の労力をどこに先に置くかの安い事前分布である。報告してよいが判定の根拠にしてはならず、所見の可否はリテラルをソースに突き合わせて決まる（1/3 が採用され 3/3 が却下されうる）。数値閾値を持つのは固定軸（skills/evolution-impression-literal-detection/SKILL.md Aggregation）だけで、その数値は本節に写さない。正本は skills/evolution-parallel-agent-eval/SKILL.md Design Dimensions
• brake 1 が生む3 つの成果物の形は skill 側で固定してあり、各主体が毎回作文しない。3 つとは評価者の報告（step 3）／親の統合コメント（step 4）／著者の裁定（step 7）であり、いずれも同じ継ぎ目で非対称である——所見のある側は full、誰も争っていない側は 1 行。評価者の報告は、所見のある軸＝逐語引用＋パス:行（名指しした SHA 時点）＋なぜ欠陥か／所見の無い軸＝1 行（軸名＋その軸の語での判定＋根拠の パス:行。リポジトリ全体を掃く軸は指せる 1 行が無いため、再実行可能な形の掃き出し（パターンと掃いたパス）とヒット数で代える）。親の統合コメントは、届いた full の形をそのまま保つ（ここで縮めると取り直しが著者へ回り、full を要求している理由そのものを潰す。統合が稼ぐのは評価者間の重複除去であって短縮ではなく、重複は「N 体中何体が挙げたか」を持つ 1 件へ畳む）。clean な軸も 1 行のまま載せる（著者は step 6 で軸横断に集約するため、所見だけのコメントでは分母が見えない）。統合コメントで禁止するのは受入・却下・順位づけ・推奨——それは step 7 の著者のものであり、重みづけの権限を持つ主体より先に着いてしまう。著者の裁定は commit body に置き、却下＝full（単巡打ち切りの下で評価者が再反論しないため、親が step 8 で読むこれだけがその後ろに立つ）／受入＝1 行（何が変わったかは同じ commit の diff に既に外部化されている）。1 件も受け入れなかった場合は commit が無く commit body も無いため、裁定は著者の停止条件報告で親へ渡り、親が step 9 のセルフレビューへ運ぶ——ここが「セルフレビューだけが唯一保証された外部化先である」理由であり、他の面はすべて書く対象がある場合にのみ存在する。全側面で禁止するのは、親がプロンプトで渡した基準・閾値・軸文言の復唱である。所見側の逐語引用は削減対象ではない——著者は引用に当てて裁定するため、削るとソースの取り直しが指摘ごとに発生し、リテラルに当てずに断定する形（rules/model/trigger-check-gate.md Literal check / #1673 cluster）へ戻る。所見の無い軸で「見て clean と言った」を支えるのはポインタの解決可能性であり、名指しした SHA で開けること、開いて判定と合わないなら 1 回の参照で露見することがその働きである。掃引軸には開く先が無いため、その働きは再実行可能な形で述べた掃き出しが担う（不在の主張は開いてではなく再実行で検査され、再現しないヒット数は解決しないポインタと同じ形で落ちる）。残余（誰も開かない clean 軸のポインタ、および判定に合うよう事後選定されたポインタ）は post-merge observation 軸で受容する。言語の規定は評価者側から消えた（#1732）。評価者はもう契約の及ぶ面へ書かず親の文脈へ返すだけであり、契約の及ぶ面（統合コメント）を書くのは解決後の値を自分の session に持つ親だからである——親が自分で書くものの言語は既にそう解決されており、ここに残す規定は無い。残るのは解決では片づかない継ぎ目 1 つ、逐語引用は対象外である。根拠は都合ではなく所見が乗っている性質そのもので、著者は引用に当てて裁定するため訳された literal は literal ではない。Li+ source は英語（rules/model/liplus-coding-rule.md Source Language）であり、他の言語へ解決する workspace では統合コメントは構造的に混在する（引用は原文の言語のまま、地の文は解決後の言語）。明示しなければ引用まで訳されるか地の文まで引用の言語へ倒れるかのどちらかになる。brake 2 と PR 面を持たない Trigger 項目は、いずれも自前の理由で本節の外である。正本は 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 は加えて brake 2）通過後に AI がオペレーションレイヤーの手順でマージする
improve	更新された spec の下で AI が実行する
re-observe	AI 自律

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 以降の新規追記が 5 件以上
• 前回 consolidate から 2 週間経過

他 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 更新のゲートは根本基準評価者 brake 2、上記「brake 2 との関係」参照）。人間への確認を段階ごとに差し込むと閉路が回らなくなるため、自律可能な段階を自律的に進める姿勢を既定とする。

---

進化

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