liplus structure as retrieval surface - Liplus-Project/liplus-language GitHub Wiki

Li+ structure の目的 = 説明用情報の retrieval surface 配置

Question

Li+ の structure（rules / skills / GitHub 各面）は何のために在るか。named axis（L1-L6 / brake / mode）が目的か。

Current resolution

Li+ structure の目的は AI が説明するために必要な情報を、後から検索で引き出せる surface 配置。説明は pre-stored vocabulary から出すのでなく retrievable source から組み立てる。named axis は retrieval 後の説明組み立てを楽にする補助であって、目的そのものではない（順序を取り違えない）。

Edges

relates to: decision-structure-industry-positioning — wiki Decision Structure はこの retrieval surface 群の一面
relates to: liplus-selfevolution-lineage / sheepdog-engineering-concept — ポジショニング軸

背景

Master 発言（2026-05-28、要旨）: 別 session の AI は「前 version の変更どう変えた?」「昔の(今は無い)ファイルの説明して」に普通は答えられない。memory/会話履歴が残っても情報過多で追えない。GitHub に named tag で changelog / commit body / wiki / issue が残れば、後から retrieval で引ける。普通の AI が答えられない本質は context 持続限界でなく retrieval surface 不在。

retrieval surface 一覧:

surface	retrieval 用途
changelog / release notes	「前 version で何が変わったか」
commit body（append-only）	「この行の判断理由」
issue body（current spec snapshot）	「この task の今の仕様」
wiki Decision Structure（state + edges）	「この判断は何を supersede しているか」
GitHub history full text	「ずっと昔のファイル内容と削除理由」
github-rag-mcp index	上記すべての semantic search
grep	RAG ヒット後の文字列レベル深掘り
memory（transient）	cluster / observation tracking

制約（ポジショニング = 学習コストの横移動）

Li+ の差別化 = 学習コストを"消す"のでなく AI 側へ"横移動"（rules/skills の自己保守、Evolution_Initiator_Autonomy）。業界の loop engineering（prompt→context→harness→loop）はコストを人間側へ"上移動"（登るために登れ＝既存の強者を優遇）。Li+ も paradox の外には立てない（.claude の物量自体が高コスト）— 主張は cost-elimination でなく cost-placement、賭けは「AI が難所を担えること」のみ。Master 自身が体現（英語不可・CLI 嫌いで巨大 agentic stack を運用）。

結論

Li+ value を語るとき「AI が説明できる」では不十分、「AI が説明のための 情報を retrieve できる」と表現する。
別 session 問題を「context 持続限界」と説明しない（本質は retrieval surface 不在側）。
業界対比: AHE は machine-machine の change manifest verification、Li+ は AI-human の retrieval-driven explanation。github-rag-mcp + wiki + commit history + issue + RAG index を「AI-facing external memory」として一体で扱う。