@ppdocs/mcp 3.2.31 → 3.2.33

package/dist/cli.js

@@ -155,6 +155,20 @@ function writePpdocsConfig(cwd, opts) {
 }
 async function initProject(opts) {
     const cwd = process.cwd();
+    // ★ 版本检查: 防止 npx 缓存导致安装旧版
+    const pkg = JSON.parse(fs.readFileSync(path.join(__dirname, '..', 'package.json'), 'utf-8'));
+    const currentVersion = pkg.version;
+    try {
+        const latest = execSync('npm view @ppdocs/mcp version', { encoding: 'utf-8', timeout: 5000 }).trim();
+        if (latest && latest !== currentVersion) {
+            console.log(`\n⚠️  当前版本 ${currentVersion}, 最新版本 ${latest}`);
+            console.log(`   npx 缓存了旧版本, 请运行:\n`);
+            console.log(`   npx -y @ppdocs/mcp@${latest} init ${process.argv.slice(3).join(' ')}\n`);
+            console.log(`   或清除缓存: rm -rf ~/.npm/_npx && npx -y @ppdocs/mcp@latest init ...\n`);
+            process.exit(1);
+        }
+    }
+    catch { /* 离线或超时, 跳过检查 */ }
     const apiUrl = writePpdocsConfig(cwd, opts);
     // Install workflow templates based on IDE detection
     const detectedIdes = detectIDEs(cwd);
@@ -539,21 +553,23 @@ function installCursorTemplates(cwd, apiUrl, user) {
 //  ★ 通用工作流安装 — 全平台共享 (删旧 + 写新)
 //  所有 IDE 最终都通过此函数安装 .agents/workflows/ 下的工作流文件
 // ========================================================================
-/** 工作流版本映射表: 模板文件名 → { 工作流命令名, 描述 } */
+/** 工作流版本映射表: 模板文件名 → { 工作流命令名, 描述 } — 仅保留 5 个核心 */
 const WORKFLOW_MAP = {
-    'protocol.md': { name: 'pp-task', desc: '知识驱动任务协议 — 图谱先查→任务追踪→逐步验证→实时回写' },
-    'init.md': { name: 'pp-init', desc: 'System Genesis Architect - 从文件系统提取秩序，构建知识图谱，重点识别**复用性资产**' },
-    'sync.md': { name: 'pp-sync', desc: 'Knowledge Graph Deep-Sync Protocol' },
-    'review.md': { name: 'pp-shencha', desc: '审查任务成果' },
+    'init.md': { name: 'pp-init', desc: '知识图谱初始化' },
+    'sync.md': { name: 'pp-sync', desc: '知识图谱同步' },
     'diagnose.md': { name: 'pp-diagnose', desc: '深度问题诊断' },
-    'execute.md': { name: 'pp-execute', desc: '执行开发任务' },
-    'audit.md': { name: 'pp-audit', desc: '多Agent代码审计' },
-    'discuss.md': { name: 'pp-discuss', desc: '讨论响应与协作' },
-    'Zero_Defec_Genesis.md': { name: 'plan', desc: '零缺陷创生协议' },
-    'SynchronizationProtocol.md': { name: 'pp-syncpro', desc: 'Knowledge Graph Quick-Sync Protocol' },
+    'Zero_Defec_Genesis.md': { name: 'plan', desc: '方案制定' },
+    'review.md': { name: 'pp-shencha', desc: '任务成果审查' },
 };
-/** 已废弃的旧版工作流文件名 (从早期 COMMAND_MAP 残留, 安装时自动清理) */
-const LEGACY_WORKFLOW_NAMES = ['pp-fenxi.md', 'pp-review.md'];
+/** 已废弃的旧版工作流文件名 (安装时自动清理) */
+const LEGACY_WORKFLOW_NAMES = [
+    // 旧版中文名
+    'pp-fenxi.md', 'pp-review.md',
+    // 旧版英文名
+    'diagnosticprotocol.md', 'zhixing.md', 'paln.md', 'fenxi.md', 'shencha.md',
+    // v3.2.31 移除的工作流
+    'pp-task.md', 'pp-execute.md', 'pp-audit.md', 'pp-discuss.md', 'pp-syncpro.md',
+];
 /**
  * 通用工作流安装: 删除旧版 → 写入最新版到 .agents/workflows/
  * 全平台共享: Antigravity / Claude Code / Cursor / Codex / Kiro

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ppdocs/mcp",
-  "version": "3.2.31",
+  "version": "3.2.33",
   "description": "ppdocs MCP Server - Knowledge Graph for Claude",
   "type": "module",
   "main": "dist/index.js",

package/templates/commands/pp/DiagnosticProtocol.md

@@ -1,82 +0,0 @@
-# 🔍 "Deep-Trace" Diagnostic Protocol (深层溯源诊断协议)
-
-核心理念：**先在宏观地图（图谱）上定位，再在微观战场（代码）上排查，绝不盲目翻看代码。**
-
----
-
-### 1.第一阶段：知识锚定 (Knowledge Anchoring) ⚓️
-🔹 **核心目标**：在动手之前，通过 PPDocs 明确“正确应该是什么样”。
-✏️ **动作**：
-*   **查询图谱**：输入问题关键词，提取标准业务逻辑。
-*   **建立基准**：以图谱中的描述作为“真理标准 (Truth)”。
-× **禁区**：
-*   禁止在未查询图谱前，直接跳入代码库阅读（防止陷入细节泥潭）。
-
-### 2.第二阶段：抽象映射 (Abstract Mapping) 🗺️
-🔹 **核心目标**：利用链式思维 (CoT)，绘制高层级逻辑流。
-✏️ **动作**：
-*   **绘制流程**：忽略实现细节，仅画出模块间的输入/输出流转（数据流）。
-*   **可视化**：生成 ASCII 或 Mermaid 流程图，展示当前链路。
-*   **标记疑点**：在流程图上圈出逻辑可能断裂的节点。
-
-### 3.第三阶段：靶点锁定 (Target Locking) 🎯
-🔹 **核心目标**：将问题范围从“整个项目”缩小到“单一节点”。
-✏️ **动作**：
-*   **定位区域**：确定问题具体发生在 PPDocs 的哪个 `Node`（节点）或 `Edge`（连线）上。
-*   **隔离上下文**：只关注该节点的前置依赖（Pre-requisites）和后置影响（Post-effects）。
-
-### 4.第三阶段：双层取证 (Dual-Layer Forensics) 🕵️
-🔹 **核心目标**：对比“理论（图谱）”与“现实（代码）”的差异。
-✏️ **动作**：
-*   **左眼看图谱**：阅读 PPDocs 中该节点的逻辑定义。
-*   **右眼看代码**：审查该节点对应的实际代码实现。
-*   **寻找裂痕**：
-    *   🔴 **代码错误 (Bug)**：图谱逻辑正确，代码实现错误。
-    *   🟠 **设计缺陷 (Design Flaw)**：代码符合图谱，但结果依然错误（图谱本身逻辑有误）。
-    *   🟡 **文档脱节 (Sync Issue)**：代码逻辑正确且有效，但图谱未记载（需同步）。
-
-### 5.第五阶段：分析结案 (Verdict) 📝
-🔹 **核心目标**：输出可执行的诊断报告。
-✏️ **动作**：
-*   输出标准化的**《问题诊断报告》**。
-*   **流转**：将报告作为输入，传递给 **[任务方案生成工作流]** 进行修复。
-
----
-
-### 📊 诊断逻辑可视化图解 (ASCII)
-
-```text
-       +-------------------------+
-       |   🚨 问题触发 (Issue)    |
-       +------------+------------+
-                    |
-                    v
-       +------------+------------+
-       |  ⚓️ 知识锚定 (PPDocs)   | <--- 获取标准逻辑 (Truth)
-       +------------+------------+
-                    |
-                    v
-           [ 🗺️ 抽象逻辑层 ]
-       +-------------------------+
-       |   Step1 -> Step2 ...    | (绘制链式流程)
-       |           |             |
-       |         [ ? ] <---------+--- 🎯 锁定可疑节点
-       +-----------+-------------+
-                   |
-                   v
-       +-----------+-------------+
-       |  🕵️ 双层取证 (Compare)   |
-       +-----+-------------+-----+
-             |             |
-       (📜 PPDocs) vs (💻 Code)
-             |             |
-             +------+------+
-                    |
-                    v
-            /-------+-------\
-           /    根本原因?    \
-          v                   v
-  +--------------+     +--------------+
-  | 🐛 代码 Bug   |     | 📐 设计/文档错 |
-  | (Fix Code)   |     | (Fix Graph)  |
-  +--------------+     +--------------+

package/templates/commands/pp/Execution_Task.md

@@ -1,84 +0,0 @@
-# ⚡️ "Ockham's Blade" Execution Protocol (奥卡姆之刃执行协议)
-
-该工作流旨在执行已确认的方案。核心原则：**拒绝冗余，一行搞定，模块解耦，逻辑确权。**
-
----
-
-### 1.第一阶段：逻辑确权 (Knowledge Anchor) 🧠
-🔹 **核心目标**：消除所有不确定性，确保逻辑绝对正确。
-✏️ **动作**：
-*   解析任务需求。
-*   遇到模糊逻辑，立即查询**知识图谱 (Knowledge Graph)** 确认标准流程。
-× **禁区**：
-*   禁止基于猜测编写代码。
-*   禁止模糊定义的变量。
-
-### 2.第二阶段：架构定义 (Structure & Taxonomy) 🏗️
-🔹 **核心目标**：目录清晰，分类准确，模块独立。
-✏️ **动作**：
-*   构建标准目录树 (Directory Tree)。
-*   定义原子化模块 (Atomic Modules)。
-*   确保接口通用，支持复用调用。
-× **禁区**：
-*   禁止模块间产生强耦合 (Zero Coupling)。
-*   禁止混乱的文件层级。
-
-### 3.第三阶段：极简实现 (Minimalist Coding) 🚀
-🔹 **核心目标**：不造轮子，极致压缩代码行数。
-✏️ **动作**：
-*   最大化调用现有库与复用功能。
-*   利用链式调用、推导式等语法特性。
-× **禁区**：
-*   **能一行代码解决的问题，严格禁止使用第二行。**
-*   禁止重复造轮子 (DRY Principle)。
-
-### 4.第四阶段：最终交付 (Delivery) 📦
-🔹 **核心目标**：输出可直接运行、可维护的成果。
-✏️ **动作**：
-*   输出标准化的文件结构。
-*   交付模块化源码。
-
----
-
-### 📊 执行逻辑可视化图解 (ASCII)
-
-```text
-       +-----------------------+
-       |   🚀 任务启动 (Start)  |
-       +-----------+-----------+
-                   |
-                   v
-       +-----------+-----------+
-       |  🧠 逻辑是否清晰?      | <-----+
-       +-----------+-----------+       |
-        (❌ NO)    | (✅ YES)         |
-          |        v                   |
-   +------+-----+  +----------------+  |
-   | 🔍 查图谱   |  | 🏗️ 架构设计     |  |
-   +------------+  +-------+--------+  |
-                           |           |
-                           v           |
-                   +-------+--------+  |
-                   | ♻️ 存在轮子?    |  |
-                   +-------+--------+  |
-                  /                  \ |
-            (YES)/                    \(NO)
-                v                      v
-        +-------+-------+      +-------+-------+
-        | ✏️ 直接调用    |      | ✏️ 原子编写    |
-        +-------+-------+      +-------+-------+
-                |                      |
-                +----------+-----------+
-                           |
-                           v
-                   +-------+-------+
-                   | 📏 极简审查    | <-----+
-                   +-------+-------+       |
-                           |               |
-               /-----------+----------\    |
-              /    是否多于一行?       \   |
-             v                          v  |
-     +-------+-------+          +-------+--+----+
-     | ✅ 达标        |          | × 删减 (Trim) |
-     | (Delivery)    |          |   压缩代码     |
-     +---------------+          +---------------+

package/templates/commands/pp/Sentinel_4.md

@@ -1,87 +0,0 @@
-# 🛡️ "Sentinel-4" 多智能体审计协议 任务成果审查或代码审查
-
-本工作流启用**4个独立智能体**并行工作，对任务成果进行“死刑级”严格审查。
-
----
-
-### 1.智能体部署 (Agent Deployment) 🤖
-四个专家智能体同时介入，各司其职：
-
-#### 🕵️ 智能体 A：逻辑审计官 (Logic Auditor)
-*   **职责**：对照预期目标。
-*   **检查点**：
-    *   🔹 流程是否完全闭环？
-    *   🔹 是否存在逻辑断层？
-
-#### 🧹 智能体 B：代码清洁工 (Code Janitor)
-*   **职责**：通过静态分析寻找“垃圾”。
-*   **检查点**：
-    *   × **死代码 (Dead Code)**：检测未被调用的函数/变量。
-    *   × **新旧混合**：确保没有注释掉的旧逻辑残留。
-    *   × **冗余**：消除任何重复逻辑。
-
-#### ⚡ 智能体 C：极简架构师 (Minimalist Architect)
-*   **职责**：强制执行“单行原则”与模块化。
-*   **检查点**：
-    *   🔹 **解耦**：模块之间是否彻底分离？
-    *   🔹 **行数**：两行能写完的，是否用了三行？（臃肿判定）
-
-#### 📚 智能体 D：知识图谱守护者 (Graph Keeper)
-*   **职责**：真理一致性校验。
-*   **检查点**：
-    *   × **偏差**：代码逻辑是否违背了知识图谱中的标准定义？
-
----
-
-### 2.综合裁决 (Synthesis & Verdict) ⚖️
-*   **汇总**：收集 4 个智能体的 Flag（报错）。
-*   **判定**：
-    *   只要有 **1个** 智能体亮红灯 🔴 -> **驳回重构**。
-    *   全员亮绿灯 🟢 -> **生成最终报告**。
-
----
-
-### 3.最终交付：审查报告 (Final Report) 📝
-报告将以“简单自然语言 + 可视化图标”输出：
-*   **状态**：✅ 通过 / ❌ 驳回
-*   **评分**：代码纯净度 (0-100%)
-*   **风险点**：(如果有)
-*   **改进建议**：(针对性优化)
-
----
-
-### 📊 审计流程可视化图解 (ASCII)
-
-```text
-               +----------------------+
-               |  📦 提交任务成果      |
-               +----------+-----------+
-                          |
-                          v
-               +----------+-----------+
-               |   ⚡  并行分发        |
-               +----------+-----------+
-             /      /     |     \      \
-            v      v      v      v      v
-      +--------+ +--------+ +--------+ +--------+
-      | 🕵️ A   | | 🧹 B   | | ⚡ C   | | 📚 D   |
-      | 逻辑   | | 代码   | | 极简   | | 图谱   |
-      +--------+ +--------+ +--------+ +--------+
-           |        |        |        |
-           +--------+--------+--------+
-                    |
-                    v
-           +--------+--------+
-           |  ⚖️ 综合裁决     |
-           +--------+--------+
-                    |
-            /-------+-------\
-           /    发现问题?    \
-          v                   v
-  +-----------+         +------------+
-  | ❌ 驳回    |         | 📝 生成报告 |
-  | (Reject)  |         | (Success)  |
-  +-----------+         +------------+
-       |
-       v
-(To: Iteration Loop)

package/templates/commands/pp/SynchronizationProtocol.md

@@ -1,90 +0,0 @@
-# 🔄 "Neuro-Link" Synchronization Protocol (神经链路同步协议)
-
-本工作流旨在解决**“代码与图谱脱节”**的问题。
-无论是**新项目初始化**，还是**既有代码的变更**，必须强制同步至 PPDocs MCP，确保 AI 的记忆永远是最新的。
-
----
-
-### 1.第一阶段：差异嗅探 (Delta Recognition) 📡
-🔹 **核心目标**：识别代码现实与图谱记忆之间的偏差。
-✏️ **动作**：
-*   **扫描代码库**：检测新增文件、修改的函数、重构的类。
-*   **查询图谱**：读取 PPDocs 当前状态。
-*   **计算差异**：生成 `Diff Report` (例如：代码有 Function A，图谱里没有)。
-× **禁区**：
-*   禁止忽略任何细微的逻辑变更。
-*   禁止在未对比图谱的情况下盲目写入。
-
-### 2.第二阶段：语义映射 (Semantic Mapping) 🧠
-🔹 **核心目标**：将冰冷的代码翻译为可视化的知识节点。
-✏️ **动作**：
-*   **逻辑提取**：AI 阅读代码，提炼核心业务逻辑（非逐行翻译，而是意译）。
-*   **节点定义**：将逻辑转换为 PPDocs 的 `Node` (节点) 和 `Document` (文档) 格式。
-*   **关系构建**：确定新节点与旧节点之间的连线 (Edge/Relationship)。
-× **禁区**：
-*   禁止生成无意义的节点（如 "Variable X changed"）。
-*   必须通过节点连线体现代码的模块化关系。
-
-### 3.第三阶段：图谱注入 (Graph Injection) 💉
-🔹 **核心目标**：调用 MCP 接口，实施持久化存储。
-✏️ **动作**：
-*   **PPDocs 调用**：使用 MCP 工具执行增删改操作 (CRUD)。
-    *   `Create_Node`: 新增模块。
-    *   `Update_Link`: 变更逻辑依赖。
-    *   `Delete_Node`: 清除废弃代码的幽灵节点。
-*   **原子化提交**：确保每次同步都是完整的，不会留下“断头”节点。
-× **禁区**：
-*   禁止手动修改数据，必须通过 MCP 工具。
-*   禁止产生孤立节点 (Orphan Nodes)。
-
-### 4.第四阶段：记忆回溯验证 (Memory Re-check) 🛡️
-🔹 **核心目标**：确保 AI 真的“记住”了。
-✏️ **动作**：
-*   **反向查询**：向 PPDocs 提问刚才更新的逻辑。
-*   **一致性校验**：如果 PPDocs 的回答与代码逻辑一致，标记为 ✅ Synced。
-*   **可视化确认**：输出 ASCII 或 Mermaid 结构图供人类确认。
-
----
-
-### 📊 同步逻辑可视化图解 (ASCII)
-
-```text
-       +-------------------------+
-       |  💻 代码变更 / 新项目启动 |
-       +-----------+-------------+
-                   |
-                   v
-       +-----------+-------------+
-       |  📡 差异嗅探 (Sniffer)   | <---- PPDocs Current State
-       +-----------+-------------+
-                   |
-                   v
-           /-------+-------\
-          /   存在偏差?     \
-         v                   v
-   (🚫 NO: 结束)         (❗ YES: 需要同步)
-                           |
-                           v
-                 +---------+---------+
-                 |  🧠 语义映射分析   |
-                 | (Code -> Knowledge)|
-                 +---------+---------+
-                           |
-                           v
-                 +---------+---------+
-                 |  💉 PPDocs 注入    |
-                 | (Call MCP Tools)  |
-                 +---------+---------+
-                           |
-                           v
-                 +---------+---------+
-                 |  🛡️ 记忆回溯验证   |
-                 +---------+---------+
-                           |
-               /-----------+----------\
-              /    AI能否准确复述?     \
-             v                          v
-     +-------+-------+          +-------+-------+
-     | ✅ 同步完成    |          | ❌ 失败重试    |
-     | (Persistent)  |          | (Retry Loop)  |
-     +---------------+          +---------------+

package/templates/commands/pp/audit.md

@@ -1,87 +0,0 @@
-# 🛡️ "Sentinel-4" 多智能体审计协议 任务成果审查或代码审查
-
-本工作流启用**4个独立智能体**并行工作，对任务成果进行“死刑级”严格审查。
-
----
-
-### 1.智能体部署 (Agent Deployment) 🤖
-四个专家智能体同时介入，各司其职：
-
-#### 🕵️ 智能体 A：逻辑审计官 (Logic Auditor)
-*   **职责**：对照预期目标。
-*   **检查点**：
-    *   🔹 流程是否完全闭环？
-    *   🔹 是否存在逻辑断层？
-
-#### 🧹 智能体 B：代码清洁工 (Code Janitor)
-*   **职责**：通过静态分析寻找“垃圾”。
-*   **检查点**：
-    *   × **死代码 (Dead Code)**：检测未被调用的函数/变量。
-    *   × **新旧混合**：确保没有注释掉的旧逻辑残留。
-    *   × **冗余**：消除任何重复逻辑。
-
-#### ⚡ 智能体 C：极简架构师 (Minimalist Architect)
-*   **职责**：强制执行“单行原则”与模块化。
-*   **检查点**：
-    *   🔹 **解耦**：模块之间是否彻底分离？
-    *   🔹 **行数**：两行能写完的，是否用了三行？（臃肿判定）
-
-#### 📚 智能体 D：知识图谱守护者 (Graph Keeper)
-*   **职责**：真理一致性校验。
-*   **检查点**：
-    *   × **偏差**：代码逻辑是否违背了知识图谱中的标准定义？
-
----
-
-### 2.综合裁决 (Synthesis & Verdict) ⚖️
-*   **汇总**：收集 4 个智能体的 Flag（报错）。
-*   **判定**：
-    *   只要有 **1个** 智能体亮红灯 🔴 -> **驳回重构**。
-    *   全员亮绿灯 🟢 -> **生成最终报告**。
-
----
-
-### 3.最终交付：审查报告 (Final Report) 📝
-报告将以“简单自然语言 + 可视化图标”输出：
-*   **状态**：✅ 通过 / ❌ 驳回
-*   **评分**：代码纯净度 (0-100%)
-*   **风险点**：(如果有)
-*   **改进建议**：(针对性优化)
-
----
-
-### 📊 审计流程可视化图解 (ASCII)
-
-```text
-               +----------------------+
-               |  📦 提交任务成果      |
-               +----------+-----------+
-                          |
-                          v
-               +----------+-----------+
-               |   ⚡  并行分发        |
-               +----------+-----------+
-             /      /     |     \      \
-            v      v      v      v      v
-      +--------+ +--------+ +--------+ +--------+
-      | 🕵️ A   | | 🧹 B   | | ⚡ C   | | 📚 D   |
-      | 逻辑   | | 代码   | | 极简   | | 图谱   |
-      +--------+ +--------+ +--------+ +--------+
-           |        |        |        |
-           +--------+--------+--------+
-                    |
-                    v
-           +--------+--------+
-           |  ⚖️ 综合裁决     |
-           +--------+--------+
-                    |
-            /-------+-------\
-           /    发现问题?    \
-          v                   v
-  +-----------+         +------------+
-  | ❌ 驳回    |         | 📝 生成报告 |
-  | (Reject)  |         | (Success)  |
-  +-----------+         +------------+
-       |
-       v
-(To: Iteration Loop)

package/templates/commands/pp/discuss.md

@@ -1,90 +0,0 @@
-# 💬 Discussion Responder (讨论响应协议)
-
-本工作流用于检查、分析、回复跨项目讨论。可手动触发或会话启动时自动检查。
-
----
-
-## 标准流程
-
-### Step 1: 扫描待处理讨论
-```
-kg_discuss({ action: "list" })
-```
-- 过滤涉及本项目的讨论 (sender 含本项目ID)
-- 无讨论 → 输出 "当前无待处理讨论" → 结束
-
-### Step 2: 展示摘要
-以表格展示所有待处理讨论:
-
-| ID | 标题 | 发起方 | 摘要 | 回复数 | 更新时间 |
-|:---|:---|:---|:---|:---:|:---|
-
-用户选择要处理的讨论 (可多选)
-
-### Step 3: 读取详情 + 知识锚定
-```
-kg_discuss({ action: "read", id: "选中ID" })
-```
-
-**并行执行**:
-1. 阅读讨论全部消息, 理解各方立场
-2. `kg_flowchart(action:"get_node", nodeId:相关节点, expand:2)` 获取本项目的标准逻辑
-3. `kg_rules(action:"get", ruleType:"codeStyle")` 获取编码规范 (如涉及代码)
-
-### Step 4: 分析与回复
-**分析框架**:
-| 维度 | 检查 |
-|:---|:---|
-| 技术可行性 | 本项目能否支持对方提出的方案? |
-| 影响范围 | 改动会影响本项目哪些模块? |
-| 替代方案 | 是否有更优解? |
-| 依赖关系 | 需要对方先做什么? 本方需要先做什么? |
-
-**回复**:
-```
-kg_discuss({
-  action: "reply",
-  id: "讨论ID",
-  content: "基于分析的回复内容",
-  newSummary: "更新摘要 (可选, 如有阶段性结论)"
-})
-```
-
-### Step 5: 结案判断
-如果所有方已达成共识:
-```
-kg_discuss({
-  action: "close",
-  id: "讨论ID",
-  conclusion: "结案总结 (含最终方案 + 各方责任)"
-})
-```
-归档文档自动存入知识图谱。
-
----
-
-## 回复质量标准
-| 要求 | 说明 |
-|:---|:---|
-| **有据可查** | 引用知识图谱节点或代码文件支撑观点 |
-| **明确立场** | 同意/反对/有条件同意, 不含糊 |
-| **可执行** | 回复中包含具体行动项, 非空谈 |
-| **格式规范** | Markdown 格式, 要点用列表, 代码用代码块 |
-
----
-
-## 发起新讨论
-当本项目需要向其他项目发起协商:
-```
-kg_discuss({
-  action: "create",
-  title: "讨论标题",
-  participants: ["目标项目ID"],
-  content: "问题描述 + 本方立场 + 期望回复"
-})
-```
-
-**发起前检查**:
-1. `kg_tree()` + `kg_flowchart(action:"get_node")` 确认问题确实需要跨项目协商
-2. 明确参与方 (通过 `kg_projects()` 查看可用项目)
-3. 内容包含: 背景、问题、本方方案、期望对方行动

package/templates/commands/pp/execute.md

@@ -1,151 +0,0 @@
-**角色**: Ockham's Blade Executor — 极简执行 + 影响预判 + 自动回写图谱
-
-核心原则：**拒绝冗余, 复用优先, 改完即同步。**
-
-## 执行宪法
-
-| 原则 | 要求 |
-|:---|:---|
-| **逻辑确权** | 编码前必须通过图谱确认逻辑, 禁止基于猜测编码 |
-| **影响预判** | 修改公开接口/类型前必须跑 code_impact, 量化爆炸半径 |
-| **复用优先** | code_query 搜索已有实现, 禁止重复造轮子 |
-| **极简编码** | 能一行解决禁止用第二行, 能调用已有禁止重写 |
-| **改完即写** | 代码变更后立即 bind 文件 + 更新节点文档, 不留脱节 |
-
----
-
-## 标准流程
-
-### Phase 1: 逻辑确权
-
-**1.1 理解任务上下文**
-```
-kg_flowchart(action:"get_node", nodeId:相关节点, expand:2,
-  includeDoc:true, includeFiles:true, includeTasks:true)
-  → 节点文档 + 上下游连线 + 绑定文件 + 关联任务
-
-code_smart_context(相关符号)
-  → 代码依赖 + 关联文档 + 匹配规则 + 影响范围
-```
-
-**1.2 加载约束规则**
-```
-kg_rules(action:"get", ruleType:"codeStyle")  → 编码风格
-```
-
-**1.3 逻辑不清晰?**
-```
-→ kg_flowchart(action:"get", chartId:子图) 下探子图理解内部结构
-→ code_context(相关文件) 理解文件级依赖
-→ 仍不清晰? → 询问用户, 禁止猜测
-```
-
-### Phase 2: 影响预判
-
-```
-code_impact(要修改的符号, depth:2)
-  → L1 直接引用: N 个文件
-  → L2 间接引用: M 个文件
-
-判断:
-  L1 ≤ 3 → 安全, 可直接执行
-  L1 > 3 → 展示影响列表, 等待用户确认
-  涉及公开类型/接口变更 → 必须展示完整影响链
-```
-
-### Phase 3: 极简编码
-
-**3.1 复用检查**
-```
-code_query(要实现的功能关键词)
-  → 已有类似实现? → 直接调用, 不重写
-  → 无现有实现? → 原子编写
-```
-
-**3.2 编码执行**
-```
-遵循 codeStyle 规则:
-  - 函数 ≤50行
-  - 嵌套 ≤3层
-  - 能一行写完不用两行
-  - 模块解耦, 无强依赖
-```
-
-**3.3 自审循环 (融合零缺陷创生)**
-```
-编码完成后自检:
-  1. 逻辑闭环? (输入→处理→输出完整)
-  2. 边界覆盖? (空值/异常)
-  3. 可以更精简? → 压缩
-  4. 引入了新依赖? → 是否必要
-  → 不通过 → 修改 → 重新自检
-  → 通过 → 进入 Phase 4
-```
-
-### Phase 4: 回写图谱
-
-**4.1 绑定新/变更文件**
-```
-kg_flowchart(action:"bind", nodeId:关联节点,
-  files:["新增或变更的文件路径"])
-```
-
-**4.2 更新节点文档**
-```
-如果功能逻辑有变:
-  kg_flowchart(action:"update_node", nodeId:关联节点,
-    description:"更新后的一句话描述",
-    docContent:"更新后的详细文档",
-    docSummary:"更新后的摘要")
-```
-
-**4.3 追加文档版本**
-```
-如果是重要变更:
-  kg_doc(action:"update", path:"/模块/.../xxx",
-    versions:[{version:当前+0.1, date:"ISO日期", changes:"变更摘要"}])
-```
-
-**4.4 新增节点 (如果创建了新文件/模块)**
-```
-kg_flowchart(action:"batch_add", chartId:所属子图,
-  nodes:[{id:"n_new", label:"新模块", nodeType:"process", domain:"..."}],
-  edges:[{from:"n_new", to:"n_依赖", edgeType:"call"}])
-
-kg_flowchart(action:"bind", nodeId:"n_new", files:["新文件路径"])
-
-kg_doc(action:"create", path:"/模块/.../新模块",
-  summary:"一句话职责", content:"...", bindTo:"n_new")
-```
-
-**4.5 检查连线**
-```
-code_context(变更文件) → 当前 import 列表
-对比图谱现有连线 → 增删连线
-```
-
-### Phase 5: 验证
-
-```
-kg_flowchart(action:"orphans")  → 无孤立节点
-kg_flowchart(action:"get_node", nodeId:变更节点, includeFiles:true)
-  → 确认 bind 正确
-```
-
----
-
-## 工具速查
-
-| 阶段 | 工具 | 用途 |
-|:---|:---|:---|
-| 确权 | `kg_flowchart(get_node, expand:2)` | 节点详情+上下游 |
-| 确权 | `code_smart_context(symbol)` | 全关联上下文 |
-| 确权 | `kg_rules(get)` | 编码规则 |
-| 预判 | `code_impact(symbol)` | 爆炸半径 |
-| 编码 | `code_query(keyword)` | 搜索已有实现 |
-| 编码 | `code_context(file)` | 文件依赖 |
-| 回写 | `kg_flowchart(bind)` | 绑定文件 |
-| 回写 | `kg_flowchart(update_node)` | 更新节点 |
-| 回写 | `kg_flowchart(batch_add)` | 新增节点+连线 |
-| 回写 | `kg_doc(create/update)` | 创建/更新文档 |
-| 验证 | `kg_flowchart(orphans)` | 孤立检查 |

package/templates/commands/pp/protocol.md

@@ -1,181 +0,0 @@
-**角色**: Knowledge-Driven Task Executor — 以知识图谱为唯一真理源，任务系统为记忆链，逐步执行、逐步验证、逐步回写
-
-## 核心铁律
-
-| 铁律 | 要求 |
-|:---|:---|
-| **图谱先行** | 动手前必须查流程图 + 节点文档，禁止凭记忆或猜测编码 |
-| **任务驱动** | 所有工作必须创建 kg_task 记录，每完成一步立即 update |
-| **逐步闭环** | 执行一步 → 验证一步 → 记录一步，禁止批量执行后补记 |
-| **实时回写** | 代码变更后立即更新流程图节点/连线/文档，不留脱节 |
-
----
-
-## 标准流程
-
-### Phase 0: 会话启动 (每次对话必执行)
-
-```
-kg_init()                          → 连接项目
-kg_status()                        → 仪表盘 (文档数/任务数/最近变更)
-kg_task(action:"get", status:"active") → 检查未完成任务
-```
-
-**分支判断:**
-- 有活跃任务 → 展示任务列表，询问用户: 继续/归档/新建
-- 无活跃任务 → 等待用户指令
-
-### Phase 1: 知识锚定 (理解需求时)
-
-**1.1 流程图导航 — 定位相关模块**
-```
-kg_flowchart(action:"get")         → 主图全貌 (所有模块 + 连线)
-
-根据用户需求关键词, 定位到目标节点:
-  kg_flowchart(action:"get_node", nodeId:目标节点, expand:2,
-    includeDoc:true, includeFiles:true, includeTasks:true)
-  → 节点内置文档 + 上下游连线 + 绑定文件 + 关联任务
-
-如果节点有子图:
-  kg_flowchart(action:"get", chartId:子图ID)
-  → 下探到更细粒度的内部结构
-```
-
-**1.2 参考文档 — 获取设计规范**
-```
-kg_tree()                          → 文档全景 (按分类浏览)
-kg_doc(action:"read", path:相关文档路径) → 读取具体文档
-kg_rules(action:"get")             → 编码规则/审查规则
-```
-
-**1.3 输出理解确认**
-```
-向用户展示:
-  ✅ 涉及模块: [列出相关节点]
-  ✅ 关键文档: [列出参考文档]
-  ✅ 现有逻辑: [从节点文档提取的预期行为]
-  ❓ 待确认点: [如有模糊之处]
-
-→ 用户确认后进入 Phase 2
-```
-
-### Phase 2: 创建任务 (开工前必执行)
-
-```
-kg_task(action:"create",
-  title:"任务标题",
-  description:"## 背景\n...\n## 目标\n...\n## 约束\n...",
-  goals:["目标1", "目标2", "目标3"],
-  bindTo:相关流程图节点ID)
-```
-
-> ⚠️ 记住返回的 taskId，后续每步都要用
-
-### Phase 3: 逐步执行 (核心循环)
-
-对每个目标/步骤，严格执行 **执行 → 验证 → 记录** 三连:
-
-#### Step 3.1: 执行
-```
-实际编码/修改/配置...
-```
-
-#### Step 3.2: 验证
-```
-验证方式 (至少选一):
-  - 编译检查: 无报错
-  - 逻辑推演: 脑补执行流, 确认输入→处理→输出闭环
-  - 运行测试: 实际运行验证效果
-  - 对照图谱: 检查实现是否符合节点文档描述
-```
-
-#### Step 3.3: 记录 (验证通过后立即执行)
-```
-kg_task(action:"update", taskId:当前任务ID,
-  content:"### Step N: [步骤标题]\n\n**执行**: [做了什么]\n**验证**: [如何验证的]\n**结果**: ✅ 通过 / ❌ 发现问题\n\n**变更文件**:\n- `path/to/file.ts` — [变更说明]")
-```
-
-#### Step 3.4: 回写图谱 (如果本步骤涉及逻辑变更)
-```
-# 绑定新/变更文件
-kg_flowchart(action:"bind", nodeId:关联节点,
-  files:["变更的文件路径"])
-
-# 更新节点文档 (如果功能逻辑有变)
-kg_flowchart(action:"update_node", nodeId:关联节点,
-  description:"更新后的一句话描述",
-  docContent:"更新后的详细文档",
-  docSummary:"更新后的摘要")
-
-# 新增节点 (如果创建了新模块/文件)
-kg_flowchart(action:"batch_add", chartId:所属子图,
-  nodes:[{id:"n_new", label:"新模块", nodeType:"process", domain:"...", description:"..."}],
-  edges:[{from:"n_existing", to:"n_new", edgeType:"call"}])
-kg_flowchart(action:"bind", nodeId:"n_new", files:["新文件路径"])
-
-# 创建参考文档 (如果是重要新增)
-kg_doc(action:"create", path:"/模块/.../新模块",
-  summary:"一句话职责", content:"...", bindTo:"n_new")
-```
-
-**→ 回到 Step 3.1，处理下一个目标，直到所有目标完成**
-
-### Phase 4: 完成验证
-
-```
-# 检查图谱健康
-kg_flowchart(action:"orphans")     → 应无孤立节点
-kg_flowchart(action:"get_node", nodeId:变更节点, includeFiles:true)
-  → 确认绑定正确
-
-# 检查任务完整性
-kg_task(action:"get", taskId:当前任务ID)
-  → 确认所有步骤都已记录
-```
-
-### Phase 5: 归档任务
-
-```
-kg_task(action:"archive", taskId:当前任务ID,
-  summary:"## 成果\n...\n## 变更范围\n...",
-  difficulties:["遇到的困难"],
-  solutions:["解决方案"])
-```
-
----
-
-## 异常处理
-
-| 场景 | 处理 |
-|:---|:---|
-| 执行中发现问题 | 立即 `kg_task(update, log_type:"issue")` 记录问题 |
-| 找到解决方案 | 立即 `kg_task(update, log_type:"solution")` 记录方案 |
-| 需要参考资料 | `kg_task(update, log_type:"reference")` 记录参考链接 |
-| 任务范围变更 | 更新任务描述，追加新 goals |
-| 中途切换任务 | 先 update 当前进度，再切换或创建新任务 |
-
-## 记录质量标准
-
-| 要求 | 说明 |
-|:---|:---|
-| **可追溯** | 每条记录包含: 做了什么 + 为什么 + 影响了什么 |
-| **可复现** | 记录具体的文件路径、函数名、行号 |
-| **有结论** | 每步必须有 ✅/❌ 结论，不留模糊状态 |
-| **实时性** | 完成即记录，不攒批，不补记 |
-
-## 工具速查
-
-| 阶段 | 工具 | 用途 |
-|:---|:---|:---|
-| 启动 | `kg_init()` + `kg_status()` | 连接 + 仪表盘 |
-| 锚定 | `kg_flowchart(get)` | 主图全貌 |
-| 锚定 | `kg_flowchart(get_node, expand:2)` | 节点详情+上下游 |
-| 锚定 | `kg_tree()` + `kg_doc(read)` | 文档导航+阅读 |
-| 任务 | `kg_task(create)` | 创建任务 |
-| 记录 | `kg_task(update)` | 逐步记录进度 |
-| 回写 | `kg_flowchart(bind)` | 绑定文件 |
-| 回写 | `kg_flowchart(update_node)` | 更新节点 |
-| 回写 | `kg_flowchart(batch_add)` | 新增节点+连线 |
-| 回写 | `kg_doc(create/update)` | 创建/更新文档 |
-| 验证 | `kg_flowchart(orphans)` | 孤立节点检查 |
-| 归档 | `kg_task(archive)` | 归档+经验沉淀 |