Update nexus wiki content

wiki/sources/lsp-index-engineer.md

@@ -2,59 +2,56 @@
 title: "LSP/Index Engineer Agent Personality"
 type: source
 tags: []
-date: 2026-04-25
+date: 2026-04-29
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/specialized/lsp-index-engineer.md]]
+- [[Agent/agency-agents/specialized/lsp-index-engineer.md]]
 
 ## Summary（用中文描述）
-- 核心主题：LSP/Index Engineer 是 The Agency Specialized 部门的代码智能系统架构师 Agent，通过编排 Language Server Protocol（LSP）客户端并构建统一语义图谱，实现跨多语言的代码智能查询能力。
-- 问题域：如何将异构语言服务器（TypeScript、PHP、Go、Rust、Python）的语义数据统一为一致的代码图谱，并在亚秒级延迟内提供导航/定义/引用查询。
-- 方法/机制：graphd LSP 聚合器 + 多语言 LSP 客户端编排 + nav.index.jsonl 语义索引 + WebSocket 实时增量更新 + SQLite/JSON 持久化缓存层。
-- 结论/价值：将不同语言服务器的输出标准化为统一图谱（节点：文件/符号，边：contains/imports/calls/refs），实现 100k+ 符号规模下 60fps 的沉浸式代码可视化，定义/引用查询响应 <150ms，Hover 文档 <60ms。
+- 核心主题：LSP/Index Engineer Agent 是一款专注于语言服务器协议（LSP）客户端编排和语义索引构建的专业智能体，通过协调多种语言的 LSP 服务器构建统一代码语义图谱。
+- 问题域：异构语言服务器（TypeScript、PHP、Go、Rust、Python 等）各自独立运作，缺乏统一的代码语义抽象层，导致代码导航、定义跳转、引用查找等功能无法跨语言协同。
+- 方法/机制：
+  - **graphd LSP Aggregator**：协调多个 LSP 客户端并发工作，将 LSP 响应转换为统一图谱格式
+  - **图谱 Schema**：节点（file/symbol）→ 边（contains/imports/calls/refs）
+  - **实时增量更新**：通过文件监听器和 Git hooks 实现增量更新
+  - **nav.index.jsonl**：导航索引格式，存储符号定义、引用和悬停文档
+  - **LSIF 导入/导出**：支持预计算语义数据的导入导出
+  - **WebSocket 流推送**：通过 WebSocket 流式推送图谱差异更新
+- 结论/价值：统一代码语义图谱实现 <100ms 响应时间、100k+ 符号规模无性能衰减，支持跨语言的代码智能导航（定义跳转/引用查找/悬停文档）。
 
 ## Key Claims（用中文描述）
-- graphd 通过 LSP 聚合器并发编排 TypeScript/PHP/Go/Rust/Python 多语言 LSP 客户端，将响应转换为统一图谱模式
-- 语义索引基础设施 nav.index.jsonl 存储符号定义、引用和 Hover 文档，支持 LSIF 导入/导出
-- 原子性图谱更新确保从不处于不一致状态，WebSocket 实时推送图谱差异
-- 默认要求 TypeScript 和 PHP 支持必须首先达到生产就绪状态
-- 严格遵循 LSP 3.17 规范，正确处理各语言服务器的能力协商
-- 每个符号必须有且仅有一个定义节点，所有边必须引用有效节点 ID
-- `/graph` 端点在 <10k 节点数据集下 100ms 内响应，`/nav/:symId` 查找缓存 <20ms / 未缓存 <60ms
-- 系统处理 100k+ 符号时性能不降级，内存保持在 500MB 以下
+- **graphd 统一语义图谱**：协调多个 LSP 客户端并发运行，将异构语言服务器响应转换为统一图谱 schema，节点代表文件和符号，边代表 contains/imports/calls/refs 关系。
+- **nav.index.jsonl 导航索引**：通过 `nav.index.jsonl` 流式索引格式存储每个符号的 `symId`、定义位置（uri/l/c）和引用列表，实现快速符号查找。
+- **LSP 3.17 严格合规**：严格遵循 LSP 3.17 规范进行客户端通信，正确处理能力协商和生命周期管理（initialize → initialized → shutdown → exit）。
+- **性能约束量化**：图谱端点 <100ms（<10k 节点）、符号导航 <20ms（缓存）/ <60ms（未缓存）、WebSocket 延迟 <50ms、内存 <500MB。
+- **原子图谱更新**：图谱更新必须是原子性的，确保图谱状态永远不会处于不一致状态。
 
 ## Key Quotes
-> "Build the graphd LSP Aggregator — Orchestrate multiple LSP clients (TypeScript, PHP, Go, Rust, Python) concurrently, Transform LSP responses into unified graph schema (nodes: files/symbols, edges: contains/imports/calls/refs)" — 核心交付物定义
-> "Strictly follow LSP 3.17 specification for all client communications, Handle capability negotiation properly for each language server" — 协议合规要求
-> "Every symbol must have exactly one definition node, All edges must reference valid node IDs" — 图谱一致性约束
-> "Sub-500ms response times for definition/reference/hover requests" — 性能北极星指标
+> "Build the graphd LSP Aggregator — Orchestrate multiple LSP clients (TypeScript, PHP, Go, Rust, Python) concurrently, transform LSP responses into unified graph schema." — 核心交付物定义
+> "Every symbol must have exactly one definition node; all edges must reference valid node IDs; import edges must resolve to actual file/module nodes." — 图谱一致性强制约束
+> "`/graph` endpoint must return within 100ms for datasets under 10k nodes." — 性能合约
 
 ## Key Concepts
-- [[LSP-317-Specification]]：Language Server Protocol 3.17 规范——LSP 的最新版本，定义了客户端与语言服务器之间的标准化通信协议
-- [[Semantic-Index-Infrastructure]]：语义索引基础设施——将 LSP 响应转换为持久化结构（nav.index.jsonl + SQLite/JSON 缓存），支持快速启动和增量查询
-- [[Graph-Node-Schema]]：图谱节点模式——统一表示文件节点（file:）、模块节点（module/）、符号节点（sym:），支持 6 种节点类型和 6 种边类型
-- [[Incremental-Graph-Update]]：增量图谱更新——通过文件监视器和 Git hooks 触发增量更新，WebSocket 推送图谱差异，原子性保证从不处于不一致状态
-- [[LSP-Client-Orchestration]]：LSP 客户端编排——多语言 LSP 客户端并发初始化、能力协商、请求批量处理和缓存管理的统一架构
-- [[Performance-Contracts]]：性能契约——量化系统性能约束：/graph <100ms、/nav <60ms、WebSocket <50ms、内存 <500MB
+- [[LanguageServerProtocol]]：LSP 3.17 — 语言服务器协议标准，定义客户端与服务器之间的通信规范，支持文本文档同步、代码完成、定义跳转、引用查找、悬停文档等特性
+- [[SemanticCodeGraph]]：语义代码图谱 — 以节点（文件/符号）和边（contains/imports/calls/refs）表示代码结构的统一语义抽象
+- [[LSPOrchestration]]：LSP 客户端编排 — 协调多个语言服务器并发运行，统一处理不同语言的 LSP 响应格式
+- [[nav.index.jsonl]]：导航索引格式 — JSONL 流式索引文件，每行包含 `symId`（符号 ID）、`def`（定义位置）、`refs`（引用列表）、`hover`（悬停文档）
+- [[LSIF]]：Language Server Index Format — 预计算语义数据的标准化格式，支持导入导出
+- [[IncrementalGraphUpdate]]：增量图谱更新 — 通过文件监听器和 Git hooks 实现增量更新，而非全量重建
 
 ## Key Entities
-- [[The-Agency]]：The Agency 多智能体系统组织，147 个 Agent 跨 12 个部门，LSP/Index Engineer 属于 Specialized 部门
-- [[TypeScript-Language-Server]]：TypeScript 语言服务器——支持 TypeScript 和 JavaScript 的 LSP 实现
-- [[Intelephense]]：PHP Intelephense——PHP 语言的 LSP 服务器实现
-- [[gopls]]：Go 语言服务器——Go 官方 LSP 实现
-- [[rust-analyzer]]：Rust 语言服务器——Rust 官方 LSP 实现
-- [[pyright]]：Python 语言服务器——Microsoft 的 Python 类型检查和 LSP 实现
-- [[LSIF]]：Language Server Index Format——预计算语义数据的标准化交换格式
+- [[GraphDaemon]]：graphd — 核心图谱守护进程，HTTP 服务器提供 `/graph`、`/nav/:symId`、`/stats` 端点，WebSocket 服务器推送实时图谱更新
+- [[TypeScriptLanguageServer]]：TypeScript 语言服务器 — graphd 默认要求生产就绪的语言服务器之一
+- [[Intelephense]]：PHP Intelephense — PHP 语言服务器，graphd 默认要求生产就绪的语言服务器之一
 
 ## Connections
-- [[specialized-workflow-architect]] ← builds upon ← [[LSP-Index-Engineer]]：Workflow Architect 在 LSP/Index Engineer 构建的语义图谱基础上设计工作流注册表和交接合同
-- [[LSP-Index-Engineer]] ← uses ← [[LSP-317-Specification]]：LSP/Index Engineer 严格遵循 LSP 3.17 规范进行客户端开发
-- [[LSP-Index-Engineer]] ← provides_input ← [[semantic-code-visualization]]：LSP/Index Engineer 构建的统一图谱为沉浸式代码可视化提供数据基础
+- [[GraphDaemon]] ← builds ← [[SemanticCodeGraph]]
+- [[GraphDaemon]] ← orchestrates ← [[LSPOrchestration]]
+- [[GraphDaemon]] ← streams via ← [[WebSocket]]
+- [[SemanticCodeGraph]] ← format ← [[nav.index.jsonl]]
+- [[SemanticCodeGraph]] ← import/export ← [[LSIF]]
+- [[IncrementalGraphUpdate]] ← triggers ← [[FileWatcher]]
 
 ## Contradictions
-- 与 [[specialized-workflow-architect]] 存在张力：
-  - 冲突点：LSP/Index Engineer 要求"每个系统边界定义显式交接合同"（确定性要求），而 Workflow Architect 承认 LLM 概率性使得穷举建模存在上限
-  - 当前观点（LSP/Index Engineer）：图谱节点必须精确——"每个符号必须有且仅有一个定义节点"，"Reference edges must point to definition nodes"
-  - 对方观点（Workflow Architect）：穷举工作流存在概率性上限，某些边界条件只能通过概率性处理
-  - 协调方向：LSP/Index Engineer 的确定性约束适用于代码符号层面（静态分析），Workflow Architect 的概率性适用于行为工作流层面，两者作用于不同抽象层次，可共存
+- 无已知冲突页面。该页面为独立的专业 Agent 规范文档，未涉及其他 Wiki 页面中相矛盾的观点。