-
-
Notifications
You must be signed in to change notification settings - Fork 0
li plus lightening l1 gate override
2026-05-11 セッション内で Li+ 軽量化提案 3 件 (adapter trigger table 削除 / rules-skills 分割 / cold-start hook diff-only 化) を同一セッション内で実装着手する判断を確定。うち (2) rules/ ↔ skills/ 分割 は L1 Model Layer の構造変更にあたり、skills/evolution-l1-update-gating/SKILL.md の long-horizon 観察要件を Master 明示判断で override する。
同一セッション内で以下の流れが発生した:
- AI が Li+ 全体に対する正直所感のうち「重い」点 (cold-start での context 消費、rule load = application moment 発火じゃない構造、自己評価ループの echo chamber 経路) を surfacing
- AI が軽量化 3 案を提案
- (1)
adapter/claude/CLAUDE.mdの trigger table 削除 (L6 adapter のルーティング重複) - (2)
rules/を「常時必要な不変則」と「発火タイミングで読めば十分な作法」に分け、後者をskills/化 (L1 Model Layer) - (3) cold-start hook 出力を session 跨ぎ diff-only 化 (L4 hook)
- (1)
- Master が「一旦全部やってみるか 😊」と go-sign
- AI が echo chamber 懸念 (AI 観測 → AI 蒸留 → AI implement の自己強化経路) を明示 surfacing し、選択肢 A (1 のみ先行 + 2,3 は observation 期間) / B (3 件並走 + (2) gate override 明示) を Master に open question
- Master が B を選択
- 完璧な観察積み上げを待つより、3 並走で挙動観測したほうが学習速度が速い という Master 判断
- echo chamber 防波堤は「観察積み上げを待つ」だけでなく「判断を外部記憶に残す」でも成立する。本エントリがその役割を担う (override の根拠と検証経路を後日再構成できる形で固定)
- 3 案は性質が異なる
- (1) L6 adapter のルーティング重複削除、可逆・低リスク
- (3) L4 hook の state-持たせ実装、中規模実装変更
- (2) のみ L1 spec の構造そのものを動かす — 性質差を認識した上で同時並走を選んだことを明示記録する
- 本判断は単発の override であり、
evolution-l1-update-gating自体のルール緩和ではない。次回以降の L1 変更提案には gate を通常通り適用する - 3 件の実装結果は、最低 1 セッション後 (理想は 1〜2 週間) の挙動観測に基づき検証する。観測対象 = 軽量化が「発火確度の低下」とどこでトレードオフしたか
- 観察期間中に regression (実際の rule 発火失敗、subagent の skill 不発火、cold-start orientation 欠落) が観測されれば、対象変更の revert 判断材料となる
- Master の go-sign 即承認に AI が応答する場面 (本ケース) は、application-moment judgment-vs-execution axis (
rules/model/master-interaction.md) において echo chamber 経路と判別困難なので、override 時は本記録のような外部化を必ず併発させる
-
skills/evolution-l1-update-gating/SKILL.md(override 対象 gate) -
rules/model/master-interaction.md(Application-moment judgment-vs-execution axis) -
rules/evolution/promotion-judgment.md(本来は本ケースの cluster tally tracking 対象だが、同一セッション内 1 回観測のため tally 経路には乗らない)
3 件全完走 (PR #1271 #1273 #1272 順に merge)。一方、本記録冒頭で予測した『AI 観測 → AI 蒸留 → AI implement の echo chamber』drift が PR #1272 (rules/skills 分割) の Master review で実演された。
具体的経緯:
- AI subagent が rule body / 新規 skill 本文を Master 元設定 (
LI_PLUS_PROJECT_LANGUAGE=ja) に倣って日本語で記述 - Master 1st CHANGES_REQUESTED: 「ソースファイルは英語にしたほうがコンテキスト削れるでしょ?」(Li+ source は AI-to-AI artifact、英語効率)
- AI main agent (Lin/Lay) が subagent prompt に「日本語 phrase literal も併記して Master との日本語対話発火を維持」と指示 — skill auto-invocation は semantic match であり literal 不要なのに、『発火確度を上げる safety net』として bilingual を持ち込んだ
- Master 2nd CHANGES_REQUESTED: 「判断はAIがするんだから英語だけでも大丈夫じゃない?」
- AI が bilingual phrase literal 撤去 → Master 「おk!」APPROVED
意味するもの:
-
skills/model-no-safety-net/SKILL.mdの止めるべき drift pattern ("may also list", "optionally", "safety net", "fallback"等の weak-modality safety net) を、AI が別 skill ファイルへの指示時に発動した皮肉な構造 - self-review (subagent 自己 + main agent oversight) では catch できず、Master の pattern recognition だけが捕捉した
- Decision Log で予測した echo chamber drift が 2 round-trip 分の review cycle として 物理観測された
Master の応答観察 (literal):
「やっぱAI任せでレビューやらせてると、まだこういうズレが出てきちゃうんだなぁ。。。」
structural takeaway:
- AI 提案 → AI implement → AI self-review の経路では、AI 側の framing bias が subagent への指示にそのまま伝播する。bias は self-review 軸では検出されにくい (同一 framing 内では「これは safety net である」と認識されない)
- Master の pattern recognition catch が echo chamber 防波堤として実効していたことの empirical 確認
-
evolution-l1-update-gatingの long-horizon 観察要件は、self-review 軸では catch できない bias を時間経過で外部視点に晒すための構造だったことが今回 dogfood で再確認された
-
evolution-l1-update-gating/SKILL.mdに「自セッション内 AI 提案 → 即 override → 実装」経路の取り扱い節を追記する材料として本観察を残す -
skills/model-no-safety-net/SKILL.mdの適用範囲を「自分が直接書く文章」だけでなく「subagent / 別 AI への指示プロンプト」まで拡張する判断材料として本観察を残す
本判断記録は、以下の場合に削除または更新する:
- 観察期間 (2026-05-11 起点、2 週間目安) を経て 3 件の軽量化の実効性が確定したとき (検証結果を関連エントリとして追記、本エントリは「観察済」状態に移行)
- 軽量化変更のいずれかが revert された場合、その記録を本エントリに追記
- 同種の「AI 提案 → 即 Master override → 実装」が複数回観測されるパターンと判明したら、
evolution-l1-update-gating側に「自セッション内提案の gate 取扱い」節を追加する材料とする (本記録は当該節への原典として残す)
この 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