brake1 operational copy target conditional - Liplus-Project/liplus-language GitHub Wiki
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 し続ける