-
-
Notifications
You must be signed in to change notification settings - Fork 0
liplus judgment learning telos
Li+ は GitHub surfaces をなぜ使うのか。単なる情報保管か、それ以上の telos があるか。
Li+ は GitHub surfaces(commit diff / PR review / Decision Structure wiki)を 判断"学習"の基盤として使う(単なる情報保管でない)。Master 確定の telos = いつか AI が上流判断を Master の代わりに握る(「いつか私の代わりができるように」)。ただし目標は天才的判断の capture でなく、普通の判断の蓄積による de-属人化(volume of ordinary > peak of genius)。
- depends on: master-role-as-client-architect — 人間席 = requirements 側の gray-box debugging
- depends on: li-plus-long-term-vision-feedback-only — フィードバックだけで回る長期 vision
- relates to: l1-brake2-root-criteria-evaluator — handover の到達済み一歩(最後の判断軸 human gate 移譲)。telos はこの post-hoc 評価者役自体もいずれ閉じる
- relates to: liplus-evaluation-criterion — 人間=評価の漸近線(現状の正直な限界)に対し、judgment-learning がギャップを閉じにいく instrument
Master literal (2026-06-14): 「実はLi+はgithubを使ってこの判断を学習しようとしてるんだよ。いつか私の代わりができるようにね。」 — Linux maintainer モデル(trusted upstream judgment > merely held history)vs flat large-scale multi-agent を論じる中で surface。
Li+ source の根拠: rules/model/language-definition.md(「External memory records judgment, not primary information」「Commit diff = append-only exposure of judgment」)+ judgment-learning(reader)/decision-structure-write(writer) loop = cross-session の判断を semantic graph 化。GitHub は判断 infrastructure(diff=判断の露出 / PR review=判断の適用 / Decision Structure=判断グラフ)であって単なる保管でない。
Master correction (2026-06-14): 「そんな天才的な判断なんていらない…属人化するだけ。普通の判断の蓄積でいい」 — 天才/tacit "smell" 判断の capture は anti-goal(属人化=今度は Master-dependency を作り直す)。「私の代わり」= 普通の判断を十分蓄積し、単一の天才(Master 含む)が dependency でなくなる = de-属人化。
人間席の現状(Master literal 2026-06-18): 「Li+のソースは95%以上AIが書いてる」「私はほぼソースは読んでない。ただ要求は最初からしてきたから構造はだいたいわかってる」= gray-box debugging(target 挙動を自分の要求モデルに照合、英語 compiled target は読まない)。relocation ladder = 実装コーディング literacy は既に剥落、残る human literacy = requirements-structuring。Master telos はこの残余もいずれ AI へ。open edge: Master の構造モデルは grown-in(全進化を通じた authored requirements)で newcomer に free-inheritable でない。AI-absorbable か irreducible human core かは open。
Li+ の issue/PR/commit/wiki discipline を **普通判断の蓄積 infrastructure(de-属人化 = no-single-genius-dependency 狙い)**として読む(genius-capture でも単なる record-keeping でもない)。handover trajectory = 人間席を requirements レベルへ relocate し、さらに AI へ(コーディング役の elimination ではない)。残る real gate = certification bootstrap + substrate coherence(context-rot の boke gate)であって tacit-genius externalization ではない。
-
rules/model/language-definition.md/ Linux maintainer model 対比
この 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