Repository navigation
parallel agent eval body carries behavior only
rules/model/liplus-coding-rule.md の Body States Behavior(#1838 で新設、PR #1842 で着地)は道具として立っただけで、既存の Li+ source 本文へは一度も適用されていなかった。最初の適用対象 skills/evolution-parallel-agent-eval/SKILL.md(49,217 B)から理由を剥ぐとき、剥いだ理由の行き先はどこか。そして判別線は、評価者が差分全体を見渡す位置ではなく著者が一文ずつ読む位置で実際に働くか。
**判別線は一文ずつの位置でも働いた。57 箇所を剥ぎ、49,217 → 42,089 B(−7,128、−14.5%)。**剥いだ理由の総量は 9,418 B、brake 1 の裁定で補ったポインタ 33 本が +2,293 B である。
剥いだ理由のうち、既存 entry が既に保持しているものはそちらへ合流させ、本文にはその slug へのポインタだけを残した(下の「合流先」)。既存 entry が持たないものを本 entry が保持する(下の「本 entry が保持する理由」)。
**行き先の割り振りは節単位ではなく句単位である。**同じ節から剥いだ 2 句が別々の entry へ行くことがあり、逆に離れた 3 節から剥いだ句が 1 つの entry へ合流することもある。
| 剥いだ位置 | 合流先 |
|---|---|
Trigger 軸選定の導出(A/B は同じ集合を形で読んだもの/固定が brake 1 経路で止まる根拠=保持 2 本の Basis が PR と issue に対して解決すること/測定が届いたのが brake 1 経路だけであること) |
brake1-per-draft-axes-held-at-two |
| Held per-draft axes の「なぜ 2 本か、なぜ保持か」 | 同上 |
| Procedure step 4「投稿前に落とした指摘は権限を持つ主体へ届かない」/step 8「往復は evaluator を再 spawn しないため cap に触れない」「毎回異なる欠陥は Loop Safety の射程外」/Constraint「親が findings を運ぶことが検分を買う」 | brake1-findings-routed-through-parent |
| Procedure step 5 の復元を怠った場合の帰結/step 2 の対象条件つき適用の導出 | brake1-operational-copy-target-conditional |
| Procedure step 7 の単巡打ち切りと再走査判定の導出 |
brake1-single-round-cap / brake1-rerun-gated-on-what-the-round-audited
|
| Axis statement form の artifact visibility と実行保証の差/Question パートの操作命名が届く範囲と残余 | presence-defect-cannot-reach-blank-label-visibility |
| Constraint モデル床の judge-type / probe-type 併存と agent file body = identity | parallel-subagent-eval-model-floor |
Constraint 評価者ツール権限と tools: 経路却下 |
brake-evaluator-baseline-integrity |
| Default pattern の N=3 が盲点被覆と分散頑健性を同時に取る旨 | parallel-subagent-eval-three-axis-decomposition |
Divergence handling(割れの扱い)。割れの多くは不一致ではない——2 体が軸の一つの読みを、3 体目が別の読みを検査しており、誰も誰にも反論していない。だから same-question check の No は判定基準ではなく軸の書き方へ着地する。同 check は rules/model/trigger-check-gate.md と同じ形(一つでも No なら止まって取得・検証し、そして進む)であり、何も間違っていないと確認することは正常な帰結である。答えの置き場を固定軸の 1/3 フラグと同じ面にしたのは、記録面を新設しないため。分岐の片方だけに「merge を止めない」と書けば、書かれなかった側へ圧力が戻る——だから両分岐に等しく書くか、どちらにも書かないかである(採ったのは後者:どちらの帰結も単独では merge を止めないと 1 文で述べ、分岐ごとの但し書きを持たない)。
**Ratio(比率)。**比率を捨てずに残すのは、全ての所見を等コストで検証することが実際的でなく、親自身のリテラル照合も無謬ではないため。閾値を持つ唯一の面である固定軸の数値は、判断の非対称性(load-bearing な仕様文言を削り過ぎる側が高コスト)から来ており、票を数えたものではない。per-judgment の aggregation rule も同じく非対称性から選ぶ——多数決はその選択肢に無い。
Procedure step 3(プロンプト payload)。Report shape の節そのものをプロンプトへ貼れば、この契約が削っている嵩をプロンプトへ戻すことになる。だから親が 1 文へ composes し、節の側は親の参照に留まる。報告形式を評価者の裁量に委ねると全軸が所見の長さで書かれる——これが形を契約として固定している理由である。掃引のクローン許可に理由が付いていたのは、GitHub コード検索が本リポジトリで当てにならないため(総ヒット 0)であり、掃引に他の行き場が無い。材料の規則が縛るのはプロンプトが名指すものであるため、step 2 の operational copy は影響を受けない——それは名指されたパスではなく自動注入される文脈として届く。取得コマンドを載せるのは、評価者がクローンを要ると仮定しないため。
**Axis statement form(軸の書式)。**この form が塞ぐ隙間は、親が評価器具を、その器具の対象をリテラルに読んでいるのと同じ瞬間に書いていること——リテラル検証は対象には届くが器具には届かない。2 本を保持形にしたことで Question はその瞬間から出ており、残るのは Unit と Scope の記入である。操作を書くことが多義な述語を解凍する——読みは軸を書いているその場で別々の疑問文へ分かれ、既存の節の禁止がそこへ発火する。操作を名乗らない疑問文が「未記入」なのは、評価者が自前の読みを補わなければ着手できず、独立に補われた読みこそが不一致の顔をして現れる割れだからである。Unit を書かない場合も同じ形で割れる。Scope の第二次元(言語)が要るのは、本リポジトリが正規テキストを二重に持ち(rules/ skills/ が英語、docs/ が日本語。多くはミラーだが docs/5.-Notifications.md は自らを正本と宣言し、ミラー元の rules/notifications/ を持たない)、英語パターンだけの掃引は日本語側へ一度も届かないため——その不在の主張は見落としではなく構造的に掃き残している。正本側の事例のほうが鋭く、掃引が代わりに当たれる英語の対応物がそもそも無い。Verdict terms が要るのは、Design Dimensions の集約語彙が draft への判定を語っているため、極性を名乗らない軸が誤った極性を継ぐこと。Basis の解決可能性は復路(Report shape)が既に依拠している性質と同一であり、除いているのは親が自分で書いた本文についての記憶からの断定=この form が断とうとしている gist 読みである。事後の same-question check とこの事前の form は代替関係になく、事後側は「部分は埋まっていたが緩く埋まっていた」軸を捕まえ、この form 以前に書かれた軸にも効き続ける。No の着地先が「次回の申し送り」(どこにも残らない)から form の部分(残る面)へ移ったことがこの form の効果である。
**Report shape(成果物の形)。**形を固定しなければ各主体が毎回作文し、全軸が所見の長さで書かれる。full が削減対象でないのは、次の主体が引用に当てて裁定するため、削るとソースの取り直しが争点ごとに発生し、リテラルに当てずに断定する形(rules/model/trigger-check-gate.md Literal check)へ戻るからである。1 行の側で「見て clean と言った」と「見ずに clean と言った」の差を支えているのはポインタの解決可能性——名指した SHA で開けること、開いて判定と合わなければ 1 回の参照で露見すること。引用の利点は同じ検査が無コストになることであり、その嵩に見合うのは同じ行が繰り返し裁かれる側、すなわち所見の側だけである。不在の主張が再実行で検査されるため、再現しないヒット数は解決しないポインタと同じ形で落ちる。基準の復唱を両側で禁じるのは、親が書き著者が写し元を読む以上、復唱は二つ目の写しであり、ずれるのは二つ目だからである。統合コメント冒頭の 3 節がすべて payload なのは、前 2 節だけでは固定軸の位置で偽になり(その軸は計数の triage 読みも、リテラル照合による判定経路も取らない)、第 3 節だけでは per-draft 軸の計数が票に読めるため。親が自分の言葉で言い直すことがまさに carve-out を跨いだ一般化を生む。clean な軸を載せるのは、著者が step 6 で軸横断に集約するため、所見だけのコメントでは分母が見えないこと。統合コメントで受入・却下・順位づけ・推奨を禁じるのは、それが重みづけの権限を持つ主体より先に着いてしまうため。言語の継ぎ目を明示しなければ、引用まで訳されるか地の文まで引用の言語へ倒れるかのどちらかに崩れる——著者は引用に当てて裁定するため、訳された literal は literal ではない。裁定の 1 件も受け入れなかった枝が「著者以外が書いた durable な artifact へ理由が着地する唯一の枝」であり、step 9 が唯一保証された外部化先と呼ばれる理由がそこにある(他の面はすべて書く対象がある場合にのみ存在する)。
**Constraint / Boundary。**N=1 が過信の源であるのは、N=1 で positive だった結論が独立サンプリングで反転するため。床の根拠はサンプル数であって軸の配置ではなく、M の構成が変わっても不変である。モデル床を暗黙継承させない理由は、床未満の親が評価の床を静かに下げること。no-write の literal と step 3 の材料規則が対であるのは、前者が書き込みの意図を断ち、後者が共有ベースラインという的そのものを外すこと。literal が carve-out を持たないのは、Do not post to the PR が報告先を否定形で述べることで「コメントは書き換えに当たるか」という問い自体を開かないため。並列幅 cap の免除を Boundary にも書いていたのは、cap の数値が skill の description 経由で全文脈へ届くのに対し、免除は同 skill の遅延ロード本文に在るため。
**働いた。**判別テスト(読んだ者の行いが変わるか)は、著者が一文ずつ読む位置でもほぼ迷わず切れた。迷いが出たのは 2 形だけである。
-
帰結記述(「怠れば X になる」)。行いは前段の指示で既に決まっており、変わるのは納得だけ——判定は理由。だが同じ形が検出サイン(その状態に陥ったことを読み手が気付ける記述)でもあり得る。採った線は、直前に禁止/指示が在れば理由、無ければ振る舞い。この線で
Character_Instance non-inheritanceの hollow prefix sleeping bug の記述だけは本文に残した(直前が「注入せよ」で完結しておらず、症状名が検出の唯一の手掛かりであるため)。 - 句の内側で振る舞いと理由が混ざる形。「A である。なぜなら B だから」ではなく「B であるがゆえに A せよ」の語順で書かれた文が多く、剥ぐには書き直しが要った。単純な削除(一箇所を切るだけ)で済んだのは 57 箇所中 26 箇所で、残る 31 箇所は文の書き直しを伴った。判別線そのものの欠陥ではないが、適用コストは削除より高い。
評価軸の訂正(2026-09-01、Master 指摘)。 本節は当初「読み味の変化」として書かれていた。これは誤りである——rules/model/liplus-coding-rule.md Purpose Declaration は「この文書は AI 間のものであり、誤読を消すために密である。人間の快適さは設計目標ではない」と定める。読み味は人間の読書体験の軸であり、Li+ source の評価軸ではない。observations は保持し、軸のみ差し替える。
正しい二軸:
- 解決可能性 = 適用の瞬間に、本文だけで義務が確定するか。確定しなければポインタを辿る操作が要る。AI にとってこれは安く正確な操作であり、「面倒」ではなく一手増えるという話である
- context 予算 = 注入・読み込みされるバイト。これが 24% の実際の意味であり、読みにくさの代価ではない
-
judgment record:の出現は 13 → 54。初回パスでは 20 に留めていたが、brake 1 が置き場所を指摘し、裁定で理由を抜いた全 33 単位へ補った(下の「ポインタの粒度」)。**issue が懸念した「本文が振る舞い一文+ポインタ一行の連続になる」形は、粒度を厳密に取ると実際に起きる。**剥ぎ取り 9,418 B に対しポインタが 2,293 B——**削減の 24% を食い戻している。**これは context 予算の軸で測られる代価である。 -
解決可能性が上がった箇所:
Procedurestep 5・step 8 とReport shapeThe asymmetry。剥ぐ前は 1 手順あたり 3〜5 文のうち指示が 1 文で、残りが導出だった。剥いだ後、その手順で何をするかは本文だけで確定する。 -
解決可能性が下がった箇所が 1 つ:
Axis statement formのScopeパート。日本語側の掃き残しという具体例が消え、要求(二次元で述べよ)だけが残った。要求としては完結しているが、**なぜ言語が次元なのかは本文だけでは確定せず、ポインタを辿る一手が要る。**判定は理由で正しく、本 entry が保持している。この形が積み上がると、適用の瞬間ごとに追加の retrieval が要る要求が増える——これが適用範囲を広げる際に測るべき残余であり、判別線の欠陥ではない。
Purpose Declaration が「誤読を消すために密であれ」と要求している以上、密度そのものは減らす対象ではない。本 issue が減らしたのは密度ではなく、本文が抱えていた導出である。両者は別の軸であり、混同すると「短くすれば良い」という誤った目標に倒れる。
at the place reasoning is taken out of の粒度 = 段落。リストでは項。
規則(rules/model/liplus-coding-rule.md Body States Behavior)はこの粒度を literal に持たない。brake 1(PR #1846)で評価者の判定が 1/3 対 1/3 に割れ、Divergence handling を実行した結果:
-
同じ問いに答えたか — 答えた。両者とも「理由が抜かれた単位の外に在るポインタは
at the placeを満たすか」に答えており、一方は No、他方は「ブロック末尾の slug がブロック全体を覆う慣行」として Yes。軸の文言側の欠陥ではない - なぜ割れたか — 判定基準の曖昧さに遡る。規則が粒度を固定していない
粒度を決めたのは規則自身の初適用である。Body States Behavior は理由を抜いた段落を 2 つ持ち、同一 slug のポインタを段落ごとに 1 本ずつ置いている(PR #1842)。加えて本 skill の Constraint は変更前から項ごとにポインタを持つ形だった(N=1 だけが理由をインラインで抱えていたため持っていない)。この 2 つが粒度を決めており、緩い読み(ブロック末尾 1 本)は採らない。
規則側に粒度の literal が無いこと自体は spec gap であり、rules/evolution/promotion-judgment.md の経路へ回す(merge を単独では止めない)。
Procedure 手順8 から剥いだ次の句は理由ではなく振る舞いだった——裁定で条件の側を本文へ戻した。
Accepted with it: a round trip that names a different real defect each time is a switched axis, which Loop Safety's own scope clause places outside the safeguard; what the safeguard reaches is the same correction pressed again
skills/model-loop-safety 自身は Persistence with axis switch is outside this safeguard を持つが、**「毎回別の実在欠陥を挙げる往復=軸の切り替え」という当てはめは持たない。**親が収束判断を保持する以上、この当てはめが無いと閾値に何を数えるかが決まらない。判別線の under which conditions 側である。
剥ぎ取りの失敗形はこれ 1 件のみ(57 箇所中)。受容の言い回し(Accepted with it:)は理由として移設したままにした。
- 適用対象は
skills/evolution-parallel-agent-eval/SKILL.md一ファイル(issue #1845 constraints)。他ファイルへの展開は観測を経てから -
docs/は本規則の scope 外(記録面)。ミラーは理由を持ち続けてよく、写るのはポインタだけ - ポインタ無しの抜き取りは禁止。57 箇所すべてが既存 slug か本 entry のいずれかを指す
-
depends on
source-body-behavior-only-reasoning-relocates— 判別線と移設ポインタの規則そのもの。本 entry はその最初の適用実例であり、規則側は不変 -
relates to
brake1-per-draft-axes-held-at-two— 剥いだ理由の主要な合流先の一つ -
relates to
brake1-findings-routed-through-parent— 同上 -
relates to
presence-defect-cannot-reach-blank-label-visibility— 同上。Axis statement form の残余の受け皿も同 entry - conflicts with (現時点で対立 entry なし)
- 同 skill 本文へ「なぜそうなっているか」を書き足そうとしている → 本 entry か合流先のいずれかへ書き、本文にはポインタを残す
- ポインタが指す先を読まずに本文だけで判断しようとして詰まった → その句は理由であり、判断には要らない。詰まったなら slug を引く
-
Scopeパートに日本語側の掃き残しの例を書き戻そうとしている → 判定は理由で正しい。動機が要るなら本 entry を引く。ただし同じ形が積み上がっていないかは観測対象
この 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-L)
- 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
- L. Hop Count Instrument
判断構造
- 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
- brake1 の再実行可否は監査内容で決める
- brake 指摘の裁定を再開した著者が持つ
- brake1 の発火条件を基準で閉じる
- skill の発火条件は description 内に置く
- subagent parallel-width cap
- brake1 operational-copy target-conditional
- brake1 findings は親を経由する
- brake1 の per-draft 軸を 2 本に固定する
- brake 2 の DEVIATION を人間が上書きする
- 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 完了条件フィールドの射程
- body 節と description の被覆ずれの解き方
- グラフエンジニアリング非採用
- Li+ の配布形式は GitHub 直配布
- 配布される source に config の解決値を書かない
- ルールは基準を持ち、来歴は git に置く
- 人間と AI の関係条項を absolute.md に置く
- 来歴を預けた retrieval 面が実際に答えるか
- 存在側の欠陥は空欄ラベルの可視性に届かない
- brake 2 の判定対象は変更の内容
- エージェント定義の判定基準を sentinel 区画で所有
- brake 2 を廃し L1 のゲートを brake 1 へ一本化
- 多セッションが効くのは入力が変わるとき
- source 本文は振る舞いのみ、理由は移設
- parallel-agent-eval 本文は振る舞いのみ
- agentic-search 蒸留版は full と同等(実測)
- 読みの除去テストが通した削除を実測が差し戻した
- brake1 の評価者数の床を N=1 へ
- Judgment record ポインタ要件を撤廃
- brake1 を上限 3 往復の収束ループへ
- 受け皿より先に縮んだ検出幅の窓を閉じる
- issue constraints の「対象ではない」は宣言
- クローン同一性は remote で解決
- tally は機構の名前の下に置く
- config 値比較は厳格に、外れた値は名指し
- webhook 到着通知の消去は確認を伴う
- 検索性能比較コーパスは既存リポジトリ内の path で隔離する
- MSYS のパス変換は argv だけに効く
- 観測不能な主張は書き手を替えても記録にならない
- parallel-agent-eval の 1 周目の跡に残っていたのは再掲
- 実装委譲エージェントに定義ファイルを与え effort を固定
- cold-start diff-only 状態は agent key でパーティション分割
- 観測不能の宣告はホストの母集団に対する主張
- 検出器は到達可能な位置にあって初めて検出器である
- ランタイムの rules はタグへ解決する
- 記録面の除外は読み直しで捕まる行にだけ成り立つ
- 再開プロンプトの注入項目は基準で閉じる
- 委譲プロンプトが運ぶのは境界であって手順ではない
- 規則の効きの実測の各条件は観測された失敗の上に置かれている
- parallel-agent-eval は蒸留で約 5,340 トークン、残りの超過は受容
- brake 1 の往復上限を撤廃し、同じ指摘の再発を人間へ上げる
- rules/evolution と rules/task の本文は振る舞いのみ
- rules/operations と adapter の本文は振る舞いのみ
- rules/model(L1)の本文は振る舞いのみ
- main-agent-procedures の常時ロード本文はメインの運用場面で行いを決める文のみ
- cold-start-synthesis の本文は振る舞いのみ、フックの仕様は docs へ
- initiator-autonomy の常時ロード本文は振る舞いのみ、tests の散文規則は skill へ
- operations.md の常時ロード本文は振る舞いのみ、索引と label 辞書の写しは持たない
- memory-entry-format.md の常時ロード本文は書式と保守のみ、observation 手順は skill へ
- promotion-judgment の常時ロード本文は振る舞いのみ、軸の関係の説明は docs へ
- execution-mode.md の常時ロード本文は、マトリクスを言い直さず、他の常時ロード面の写しも持たない
- task.md の常時ロード本文は issue とラベルの行いだけを持ち、写しと層の説明は持たない
- main-agent-procedures の場面に限られる手順は、名指しが届く skill へ
- evolution.md の常時ロード本文は振る舞いのみ、レイヤーの位置づけと他面の写しは持たない
- operations.md の場面に限られる節は、名指しが届く skill へ
- CLAUDE.md の常時ロード本文は振る舞いのみ、位置づけ・読込の説明・常時ロード面の写しは持たない
- initiator-autonomy の場面に限られる記述は、brake 1 の skill へ
- skill description の詰めは、場面を狭めない句だけを切る
- L1 の 5 本の 2 周目は内側の写しと位置づけの説明を外し、書く規律は常時ロードに残す
- subtractive-structural-beauty と trigger-check-gate の常時ロード本文は振る舞いのみ、言い直し・位置づけ・他所の再掲は持たない
- absolute.md の常時ロード本文は振る舞いのみ、Name prefix scope の言い直し・位置づけは持たない
- サブエージェント起動の着地点の目安と数値の出典