-
-
Notifications
You must be signed in to change notification settings - Fork 0
brake1 operational copy target conditional
brake 1(skills/evolution-parallel-agent-eval)の Procedure step 2 は、draft を live .claude/ へ写してから評価者を spawn する。この適用は常に必要か。適用がホストに拒否された場合はどうするか。
step 2 は target 条件付き。 判定基準は「draft が評価者の観測面に注入コンテキストとして届くか」の一点。
-
rules/**/*.md= 適用必須。本文まるごとが subagent コンテキストへ注入されるため、写さないと注入済みの旧 rule が draft を shadow する -
skills/<name>/SKILL.md= judge 型評価者には 適用不要。description のみ注入で本文は invoke 時 lazy-load のため、写しても観測面は変わらない。評価者を draft へ直接 Read させる。例外として、skill を invoke させる probe 型(invoke 時に本文が自動ロードされる)では適用必須
ホストの self-modification ゲートに apply を拒否された場合の fallback:
-
skills/*= 直接 Read へ退避し、deviation を PR self-review に記録 -
rules/*= 直接 Read で代替不可(注入コンテキストが依然 shadow する)。apply 可能な session から再実行するか、deviation を記録して reduced confidence を post-merge 観察へ回す
step 5 の restore と apply/restore pairing は「適用が無ければ vacuous」で整合させる。
-
depends on
parallel-subagent-eval-three-axis-decomposition— step 2 は ablation 前提を成立させる手続きであり、三軸の P(premise_variations)が何を指すかに依存する -
depends on
brake-evaluator-baseline-integrity— 評価者へ渡す材料をクローン内のパスから PR の URL へ寄せる判断と対を成す。step 2 の operational copy は「名指しするパス」ではなく自動注入コンテキストとして届くため、材料規則の影響を受けない - conflicts with (現時点で対立 entry なし)
注入面の source of truth は同 skill の Constraint「Character_Instance non-inheritance」にある。rules/**/*.md は本文まるごと注入、skills/*/SKILL.md は description のみで本文は lazy-load。この非対称は仕様として先に書かれていたにもかかわらず、step 2 の apply 手続き側は両者を区別せず「適用する」とだけ書いていた。
結果として二方向に外れる。skills/* の draft では観測面が一切変わらない apply を毎回走らせ、rules/* を扱う手続きだと信じたまま実質何も検証していない状態が成立しうる。逆に rules/* で apply を飛ばすと、注入済みの旧 rule が draft より上位に立ち、評価者は書き換え前の rule に対して答える。後者は subagent-eval-stale-context-judgment として観測された stale context 問題と同根。
2026-06-12 の scheduled 自律 run で、step 2 の live .claude/ 適用がホストの Self-Modification ゲートに拒否され、手続きが実行不能になった(occurrence 1)。ユーザーの明示認可を伴わない自律 run では apply 自体が通らない経路が存在する、という substrate 側の制約が判明した形。
このとき「拒否されたので step 2 を飛ばして続行」を許すと、上記の rules/* shadow がそのまま起きる。fallback を対象種別ごとに書き分けたのはこのため。skills/* は観測面が変わらないので直接 Read で等価、rules/* は等価にならないので confidence を下げるか session を替えるしかない、という非対称が fallback にもそのまま伝播する。
rules/* の apply が拒否された自律 run では、brake 1 が verdict を出せないか、reduced confidence のまま先へ進むかの二択になる。前者は run の中断、後者は検証強度の低下であり、どちらも無コストではない。
ホストの権限ゲートは Li+ 側から動かせないため、この対価は substrate gap として受容している。緩和は「apply 可能な session から再実行する」という運用側の退避路のみ。
- 注入面の仕様が変わったとき(
skills/*/SKILL.md本文が常時注入になる、adapter/*が注入リストに入る等)。判定基準そのものが「注入されるか」なので、注入面が動けば分岐も動く - ホストの self-modification ゲートの粒度が変わり、自律 run でも apply が通るようになったとき。fallback 節の存在理由が消える
docs/* / adapter/* を draft 対象とする場合の分岐が step 2 に無い。注入リスト自体がこれらを列挙していないため #1495 が作った穴ではないが、分岐の空白としては残っている。#1597 で追跡。
- 「step 2 は常に適用する手続きだ」と読まれた時 → 対象種別で条件分岐する。
skills/*の judge 型では適用が観測面を変えない -
skills/*の apply を飛ばしたことを deviation として記録しようとした時 → 規定どおりの分岐であって deviation ではない。deviation 記録が要るのはゲート拒否の fallback 経路のみ -
rules/*の apply 拒否を直接 Read で埋めようとした時 → 代替不可。注入コンテキストが shadow し続ける
この Wiki は、Li+ に基づく開発・運用を支えるための情報整理空間です。
数字で始まるページは、 Li+プログラムの各レイヤーの仕様を定義するページです。
- 要求(何を満たすか)と仕様(どう振る舞うか)を一体として記述する
- 実装前に作成または更新する
- issue群から採用された要件を集約する
これらのページは 安定性と一貫性を重視して管理されます。
アルファベットで始まるページは、 Li+の構想・設定・導入手順などの参照用ページです。
- 設計思想・背景
- 設定リファレンス・インストール手順
これらのページは 必要に応じて更新・拡張されます。
リポジトリ内の rules/**/*.md(L1–L4 の常時ロード分、subdir 含む)、skills/**/SKILL.md(トリガー起動分)、adapter/claude/CLAUDE.md、adapter/claude/hooks-settings.md、adapter/claude/hooks/*.sh、adapter/codex/AGENTS.md、およびルート直下の Li+config.md、Li+update.md は、
AIやランタイムが直接読む実行用プログラム / 定義ファイルです。
-
docs/は人間向けの仕様書・要求仕様・手順書 -
rules/,skills/および adapter / update は実行時に読み込まれる本体
両者は対応しているが、役割は同じではない。
Home | 1. Model | 2. Evolution | 3. Task | 4. Operations | A. Concept
要求仕様書 (1-6)
参考文書 (A-K)
- A. Concept
- B. Configuration
- C. Update
- D. Installation
- DiDD(対話駆動開発)
- E. Li+ language
- F. Behavior-First
- G. Sheepdog Engineering
- H. Roles and Evaluation
- K. Source File Format
判断構造
- Decision Structure
- layer reorg rationale
- github app user-to-server token expiration
- sheepdog engineering concept
- prerelease tag recovery procedure
- release flip drift patterns
- Li+ long-term vision (feedback only)
- Master role as client-architect
- current architecture as concession
- Li+ license Apache-2.0 rationale
- Character_Instance evolution history
- prompt as emotion vector controller
- agentic-search five-phase refactor
- Character_Instance output-styles migration
- Li+ lightening L1 gate override
- subagent state-machine label mechanism
- LSP integration out of scope
- Character_Instance opt-in and surface scope
- parallel-subagent-eval three-axis decomposition
- parallel-subagent-eval cost acceptance
- parallel-subagent-eval model floor
- release version rule always-on relocation
- bootstrap walkthrough skip and gh install relocation
- wiki sync sidebar integrity check
- decision structure rename rationale
- decision structure industry positioning
- subtractive structural beauty framing
- Li+ authorship is collaborative
- Li+ design intent vs current limit
- Li+ history is empirical
- Master verification at runtime not spec
- rules cache fetch address table
- dialogue-evaluator scoring redesign
- Li+ always-on footprint is load-bearing
- DiDD umbrella naming
- milestone subsystem removal
- L1 brake 2 root-criteria evaluator
- Hook-driven gate trigger
- dynamic-workflows non-adoption
- ACE context-engineering non-adoption
- memory GraphRAG SQLite exploration
- Li+ context-rot tension
- Li+ structure as retrieval surface
- 常時ロード分の重複を削る向き
- Li+ evaluation criterion
- Li+ self-evolution lineage
- Li+ judgment-learning telos
- Sheepdog Engineering publish intent
- Implementation always delegated
- brake evaluator baseline integrity
- brake1 single-round cap
- skill の発火条件は description 内に置く
- subagent parallel-width cap
- brake1 operational-copy target-conditional
- wiki sync code-notation strip
- wiki sync drift-targeted mirror
- decision structure writer surface activation
- decision structure state-form edge binding
- Neuron Graph RAG integrated prototype
- issue 完了条件フィールドの射程