-
-
Notifications
You must be signed in to change notification settings - Fork 0
brake evaluator baseline integrity
brake 1 / brake 2 の評価者が評価対象を書き換え、他の評価者のベースラインを壊す事故を、何で防ぐか。
subagent のツール権限は変更しない。 brake の委譲プロンプトで評価対象を書き換えないよう明示的に指示し、あわせて評価者へ渡す材料を PR の URL に寄せて共有クローンのパスを名指ししない。
前者が書き込みの意図を断ち、後者が共有ベースラインという的そのものを外す。2つは合成して使う。
評価者区分だけツール権限を絞る設計（agent 定義の tools:）は採らない。
-
depends on
brake1-single-round-cap— 1巡制限下では1ラウンドの verdict がそのまま出荷判断になるため、そのラウンドのベースラインが汚れていることの代償が上がる。ラウンドを重ねる設計であれば次ラウンドで気づけた -
depends on
implementation-always-delegated— 実装が常に委譲され brake が CI green 後に走ることで、評価者へ渡す材料が push 済み SHA と緑の run URL に確定した。材料を PR の URL に寄せる余地はこの位置決定が作った - conflicts with （現時点で対立 entry なし）
PR #1581 の brake 1 で、評価者3体へ同一のローカルクローンのパスを渡した。評価者Aが mutation test でソースを差し戻して復元する間に評価者Cが走り、Cは「テストが非決定的に落ちた」と報告した。存在しない flakiness が実欠陥候補として上がる形で現れ、親が単独実行で安定を確認して初めて切り分いた。
同軸の先行例が PR #1560 にある。親が評価プロンプトへ古い main ref の diff コマンドを書き、無関係な2ファイルが混入した diff を渡していた。3体中2体が自力で除外したため実害は出なかったが、評価者が気づかなければ検出不能という性質は同じ。
観測 cluster は brake1-evaluation-baseline-not-isolated（occurrence 2）。
AI 側の推奨は当初「ツール権限で縛る」だった。評価者を tools: Read に絞れば物理的に書けなくなり、rules/model/subtractive-structural-beauty.md が求める「実行が保証される構造」に到達する。brake 2 の adapter/claude/agents/l1-gate-eval.md が既にその形で実装されている。
Master はこれを採らなかった。理由 = subagent の書き込み権限そのものを触りたくない。
この経路には副次的な重さもある。skills/evolution-parallel-agent-eval/SKILL.md Constraint が brake 1 評価者への custom-agent ファイル使用を禁じており（理由 = モデル床の固定方法と probe 型 identity の保全）、Claude Code では agent ファイル本文が system prompt を置き換えるため「ツールだけ縛って identity を触らない」ができない。probe 型の実運用実績を調べた上で型ごとに分岐する必要が生じる。ツール権限を採らない判断は、この分岐ごと降りることでもある。
指示は親が委譲プロンプトへ毎回書く手続きであり、忘れれば効かない。rules/model/subtractive-structural-beauty.md の procedure-vs-structure 判定では置き換え対象の側に立つ。強制する構造（hook / gate）は置かない。
緩和として、指示の literal は仕様側に置く。親が毎回文言を作文するのではなく写す形にすることで、「何を書くか」の負荷を消し「書くこと自体」の recall だけを残す。
PR #1583 の brake 1 では、親が手でこの指示を書いた状態で評価者3体を走らせ、3体とも書き込みゼロだった。指示は実際に守られている（n=1）。同 PR は brake の実行位置を CI green 後へ固定した最初の適用でもあり、材料が SHA と run URL に限定されていた効果と分離できていない点に注意。
PR URL 経路はリポジトリ外のディレクトリから実測済み。gh pr diff <n> --repo <owner>/<repo> は clone 無しで差分を返し、gh api repos/<owner>/<repo>/contents/<path>?ref=<SHA> は任意 SHA の任意ファイル本文を返す。弱点はリポジトリ全体の grep で、GitHub code search は本リポジトリで総ヒット 0 が返り当てにできない。全体掃きが要る軸では評価者が自分の作業ディレクトリへ clone することになるが、共有面ではないので隔離は保たれる。
この 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 完了条件フィールドの射程