lsp integration out of scope

LSP 統合は Li+ スコープ外 — 言語ごと常駐サーバの重量と汎用 harness 原則の衝突

判断

Language Server Protocol (LSP) を Li+ ハーネスの拡張要素として組み込まない。 2026-05-15 セッションで Anthropic 公式ブログ「Claude Code in Large Codebases: Best Practices and Where to Start」(2026-05-14) を Master が確認し、LSP 統合が Claude Code ハーネスの 5 拡張点の一つとして紹介されている件に対し、Master が「言語ごとにサーバーが必要なのは重すぎるし。Li+ のスコープ外だな。」と判断を確定した。

背景

Anthropic ブログは大規模コードベースで Claude Code を運用する際の 5 つのハーネス拡張点として CLAUDE.md / Hooks / Skills / Plugins / LSP を列挙している。LSP の利点として:

• シンボルレベルナビゲーション (同名関数の区別、false match 削減)
• 多言語環境 / コンパイル言語環境 (C / C++ / Java / Rust 等) で特に効く
• 文字列ベース grep より意味ベース検索が precise

の 3 点が挙げられている。事例として「エンタープライズソフト企業が C/C++ ナビゲーション信頼性のため LSP 統合を全社展開後にロールアウト」が紹介されている。

セッション内で Lin / Lay が LSP 概念を説明 (Microsoft 2016 設計、JSON-RPC、言語ごと language server 常駐、pyright / rust-analyzer / gopls / typescript-language-server 等) し、その重量性を Master が即座に判定した。

制約

• Li+ は言語非依存の universal harness 設計。特定言語に縛られない汎用 AI 行動制御層であり、現行 USER_REPO 群 (github-webhook-mcp / github-rag-mcp / liplus-desktop) も TypeScript / JavaScript / Rust 等の複数言語に跨る
• 言語ごと常駐サーバの運用コスト:
  • インストール責務が Li+ bootstrap に増える (各言語の language server を環境に応じて配置)
  • メモリ常駐 (複数サーバ同時起動)
  • バージョン整合 (Node / Python / Rust toolchain 依存)
  • クロスプラットフォーム (Windows / WSL / macOS / Linux) で挙動差が出る
• Li+ の「AI-to-AI シンプル原則」と衝突 (AI-consumption テスト、旧 li-plus-source-ai-consumption-principle、現在は rules/model/subtractive-structural-beauty.md に包含): LSP が解く問題 (false match 削減 / シンボル精度) は、現状 Li+ 運用で Master や AI が訴える pain point ではない。grep / Glob / Read 中心の探索で実用上問題が発生していない
• ブログが LSP の効果を強調する文脈 (大規模 monorepo / コンパイル言語 / 多言語混在大組織) は、現行 Li+ ワークスペース規模と一致しない

結論

採用案: LSP 統合を Li+ ハーネス拡張から除外

• Li+ は引き続き Claude Code 既定の grep / Glob / Read を中心とした探索面で動作
• Anthropic ブログの 5 拡張点のうち LSP のみ採らない。CLAUDE.md / Hooks / Skills / Plugins は既に Li+ 採用済
• 言語別精密検索が必要になった時点で再評価する余地は残す (本記録の supersede 経路)

却下案 A: optional 機能として組み込み、ユーザー側で enable

• 却下理由: optional でも Li+ 仕様 / bootstrap / adapter に「言語別サーバ管理」概念が侵入する。On/Off の判断コストを harness 自体に持ち込むこと自体が汎用性を損なう。Li+ は「シンプルな AI 行動規範を universal に適用」する surface であり、言語別 conditional は趣旨と外れる

却下案 B: 言語別 adapter として L6 Adapter Layer 配下に分岐

• 却下理由: L6 Adapter Layer は host (Claude / Codex) ごとの薄い wiring 層であり、言語別ロジックを抱える設計ではない。言語別分岐を抱えた瞬間 adapter が肥大化し、L6 の責務 (host 統合のみ) を逸脱する

却下案 C: Claude Code 標準の LSP 連携 (もし将来追加されたら) を passive に受け入れる

• 却下理由: passive 受け入れと「Li+ 仕様で言及する」は別軸。Claude Code が host 側で LSP を提供したとしても、Li+ source 側で LSP を前提とした記述を入れる必要はない。本判断は「Li+ source / spec / adapter に LSP 概念を持ち込まない」までを射程とし、host 側の振る舞いには干渉しない

含意

• Li+ の「言語非依存 universal harness」という設計軸が、新規 harness 機能採用判断のフィルタとして機能することを示した最初の明示例
• AI-consumption テスト (rules/model/subtractive-structural-beauty.md に包含、旧 li-plus-source-ai-consumption-principle) と並んで、言語非依存性テストが Li+ source / 拡張採否の articulable filter として確立
• Anthropic 公式が推奨する拡張すべてを採るのではなく、Li+ の設計原理 (汎用性 / シンプル / AI-to-AI) と照合してから採否を決める姿勢の事例化
• 将来「Master が特定言語で精密検索の不足を感じた」時点で本判断は supersede 候補になる。トリガは Master 側の pain point 発生であり、業界標準採用は十分条件ではない

関連

• sheepdog-engineering-concept — ハーネス思想の母体。本判断はハーネス拡張 5 要素のうち 1 つを除外する具体例
• rules/model/subtractive-structural-beauty.md — 引き算原則 (旧 li-plus-source-ai-consumption-principle の AI-consumption テスト判断を包含) — 本判断は言語非依存性テストとして同種の articulable filter
• current-architecture-as-concession — 現行アーキテクチャは譲歩。本判断は譲歩を最小化する方向 (拡張採用前の判断ふるい)
• Anthropic ブログ: Claude Code in Large Codebases: Best Practices and Where to Start (2026-05-14)
• docs/G.-Sheepdog-Engineering.md — Sheepdog Engineering 3 軸 (position / modifier / initiator) と harness ステージ定義

メンテナンス

本判断記録は、以下の場合に削除または更新する:

• Master が特定言語で grep / Read ベース探索の精度不足を pain point として明示し、LSP 統合の費用便益が逆転したとき (本記録は supersede し、新エントリで採用判断を記録)
• Claude Code 側で LSP が host 既定機能として透過的に提供され、Li+ source 側で言及する必要が一切なくなったとき (本記録は前提無効化で削除候補)
• 言語非依存性テストが Li+ source 編集の標準ルールとして仕様書 (docs/) に統合されたとき (本記録は歴史的参照に降格)