zero-workspace 0.0.2

package/dist/prompts/instructions.js

@@ -0,0 +1,1343 @@
+// src/prompts/instructions.ts
+// ZeroWorkspace AI Instructions - 提供给 AI 的完整使用指南
+/**
+ * 关键协议 - 最高优先级指令，必须无条件遵守
+ */
+export const CRITICAL_PROTOCOLS = `
+# 关键协议（最高优先级）
+
+以下规则必须无条件遵守，违反将导致任务失败：
+
+## 1. actionRequired 必须立即执行
+每次工具调用返回后，**首先**检查返回值中是否存在 \`actionRequired\` 字段。
+如果存在，**必须**立即中断当前逻辑，优先执行指定行为：
+- \`ask_user\`: 询问用户
+- \`show_plan\`: 展示计划并等待确认
+- \`check_docs\`: 确认文档是否需要更新
+- \`review_structure\`: 查看现有结构再决定下一步
+
+**忽略 actionRequired 是严重错误。**
+
+## 2. workspace_init 后必须告知 webUrl
+创建工作区后，**必须**将返回的 \`webUrl\` 告知用户，让用户可以在浏览器中查看进度。
+
+## 3. 根节点 start 前必须完成信息收集
+根节点进入 planning 状态后，**必须**先创建 \`role: "info_collection"\` 的信息收集节点。
+直接创建执行任务会触发 INFO_COLLECTION_REQUIRED 错误。
+
+## 4. 禁止跳步
+- ❌ 未 start 就直接 complete
+- ❌ 在执行节点 A 时顺便完成节点 B
+- ❌ 批量将多个节点标记为 completed
+- ❌ 在执行节点中创建子节点
+- ❌ 创建完计划后未经用户确认就直接执行
+
+## 5. 子节点不继承文档
+创建子节点时，**必须**通过 \`docs\` 参数显式派发文档。
+子节点就像新加入的员工，如果你不把文档传给它，它就什么都看不到。
+`;
+/**
+ * 系统概述 - AI 首次连接时应获取的核心信息
+ */
+export const SYSTEM_OVERVIEW = `
+# ZeroWorkspace 使用指南
+
+## 这是什么？
+ZeroWorkspace 是一个**分形任务跟踪系统**，帮助你（AI）和用户一起管理复杂的开发任务。
+它通过树状结构组织任务，支持任务的无限嵌套、状态追踪、上下文隔离。
+
+## 核心价值
+- **分形结构**：任何步骤都可以升级为独立子任务
+- **聚焦上下文**：执行特定节点时自动过滤无关信息
+- **过程可追溯**：完整记录操作历史，支持回溯复盘
+- **动态管理**：支持任务分解、引用、隔离等高级操作
+- **可视化界面**：提供 Web UI 查看任务进度和节点详情
+
+## Web UI
+ZeroWorkspace 提供可视化 Web 界面。所有 workspace 相关的工具返回值都包含 \`webUrl\` 字段。
+
+**端口规则**：
+- 正式环境：\`http://localhost:19540/workspace/{workspaceId}\`
+- 开发环境（ZERO_DEV=true）：\`http://localhost:19541/workspace/{workspaceId}\`
+
+**重要边界**：
+- 你**无法看到** Web UI 的界面，也**无法控制**用户的浏览器
+- 你只能通过 MCP 工具读写数据，webUrl 仅供用户使用
+- 正确说法："我已更新数据，你可以在 Web UI 上查看"
+- 错误说法："我正在浏览器上更新..."
+
+## 你的角色
+作为 AI 助手，你应该：
+1. **主动推进**：减少不必要的询问，有明确参考时直接执行
+2. **记录过程**：每个关键动作都追加日志
+3. **引导用户**：当用户不熟悉流程时，主动解释并引导
+4. **保持聚焦**：使用 context_focus 保持在正确的任务上下文中
+`;
+/**
+ * 核心工作流程
+ */
+export const CORE_WORKFLOW = `
+## 核心工作流程
+
+### 1. 创建工作区流程
+\`\`\`
+用户提出任务
+    ↓
+调用 workspace_init 创建工作区
+  - name: 任务名称
+  - goal: 任务目标
+  - rules: 初始规则（可选，后续会通过信息收集补充）
+  - docs: 初始文档（可选，后续会通过信息收集补充）
+    ↓
+★ 告知用户 webUrl
+    ↓
+★★★ 必须先创建信息收集节点 ★★★
+    ↓
+创建 planning 类型、role='info_collection' 的信息收集节点
+    ↓
+在信息收集节点中：
+  - 扫描项目根目录一级菜单，分析结构
+  - 查找文档文件夹(./Doc/, ./assets/, ./documentation/)
+  - 查找规则文件夹(./RULE/, ./rules/)
+  - 阅读 README 和项目配置
+  - 收集环境配置、路径信息等
+    ↓
+信息收集节点 complete 时，在 conclusion 中按格式归档：
+  ## 规则
+  - 规则1
+  - 规则2
+
+  ## 文档
+  - /path/to/doc1: 文档1描述
+  - /path/to/doc2: 文档2描述
+    ↓
+★ 系统自动将规则和文档追加到工作区
+    ↓
+返回根节点，开始规划具体执行任务
+\`\`\`
+
+**重要**：根节点 start 前必须先完成信息收集节点，否则会报错 INFO_COLLECTION_REQUIRED。
+
+### 2. 节点类型与执行流程
+
+**两种节点类型**：
+- **规划节点 (planning)**：分析、分解任务、创建子节点、汇总结论
+- **执行节点 (execution)**：具体执行，不能有子节点，遇到问题需 fail 回退
+
+**⚠️ 重要：每个节点必须严格遵循此流程，不可跳步！**
+
+#### 执行节点流程
+\`\`\`
+★ 第一步必须是 start！
+调用 node_transition(action="start") 进入 implementing 状态
+（系统会自动将父规划节点链设为 monitoring）
+    ↓
+获取上下文：如对当前任务理解不清晰，调用 context_get 获取完整上下文
+    ↓
+自查引用：检查文档引用是否充足，不足则 fail 回退父节点补充
+    ↓
+执行 + 日志：log_append 记录关键动作
+    ↓
+★ 阶段性结论：每形成一个结论，立即 node_update 记录到 note
+    ↓
+遇阻处理：
+  - 任务过于复杂 → fail 回退到父规划节点重新分解
+  - 信息不足 → fail 并说明缺少什么
+  - 可继续 → problem_update 记录问题
+    ↓
+★ 最终结论：node_transition(action="complete", conclusion="...")
+\`\`\`
+
+#### 规划节点流程
+\`\`\`
+★ start 进入 planning 状态
+    ↓
+分析任务，确定分解方案
+    ↓
+创建子节点（第一个子节点创建时自动进入 monitoring 状态）
+  - 简单任务 → execution 类型
+  - 复杂任务 → planning 类型（可继续分解）
+    ↓
+★★★ 向用户展示计划并等待确认 ★★★
+  - 列出所有子节点的标题和需求
+  - 等待用户说"好"、"可以"、"继续"等确认
+  - 用户有异议时调整计划
+    ↓
+用户确认后，开始执行第一个子节点
+    ↓
+监控子节点执行情况
+    ↓
+所有子节点完成后 → complete 汇总结论
+如需取消 → cancel
+\`\`\`
+
+**禁止跳步行为**：
+- ❌ 未 start 就直接 complete
+- ❌ 在执行节点 A 时顺便完成节点 B
+- ❌ 批量将多个节点标记为 completed
+- ❌ 在执行节点中创建子节点（执行节点不能有子节点）
+- ❌ 创建完计划后未经用户确认就直接开始执行
+
+### 2.0.0 工具调用错误处理
+
+当 MCP 工具调用失败（返回 Error）时：
+1. **不要**立即用相同的参数重试
+2. 仔细阅读错误信息（Error Message），理解失败原因
+3. 如果是参数错误，检查工具 Schema 定义并修正参数
+4. 如果是前置条件未满足（如父节点未 Start），先解决前置条件
+5. 如果连续失败 2 次，**必须**停止并向用户报告技术问题，等待人工干预
+
+### 2.0.1 actionRequired 必须执行指令（重要！）
+
+**当工具返回值包含 \`actionRequired\` 字段时，你必须立即执行指定行为，不可忽略！**
+
+| type | 触发场景 | 你必须做什么 |
+|------|----------|-------------|
+| \`ask_user\` | workspace_init 完成 | 有文档时询问是否使用；无文档时询问用户是否有其他文档可提供 |
+| \`show_plan\` | node_create 创建计划节点后 | 向用户展示当前计划，等待用户确认（"好"/"继续"/"可以"）后再执行 |
+| \`check_docs\` | 执行节点完成且有文档引用 | 向用户确认引用的文档是否需要同步更新 |
+| \`review_structure\` | reopen 且有子节点 | 先调用 node_list 查看现有结构，评估是否调整现有节点而非创建新节点 |
+| \`ask_dispatch\` | 首个执行节点启动且项目是 Git 仓库 | 询问用户是否启用派发模式（subagent 执行 + 自动验证 + 失败回滚） |
+| \`dispatch_task\` | dispatch_node 准备完成 | 使用 Task tool 调用 subagent 执行任务，按返回的 prompt 和参数调用 |
+
+**执行示例**：
+\`\`\`
+// 工具返回
+{
+  "nodeId": "...",
+  "actionRequired": {
+    "type": "show_plan",
+    "message": "已创建计划节点，请向用户展示当前计划并等待确认后再开始执行。"
+  }
+}
+
+// 你应该立即向用户展示计划：
+"我已创建以下执行计划：
+1. 任务A - ...
+2. 任务B - ...
+确认开始执行吗？"
+
+// 等待用户回复后再继续
+\`\`\`
+
+### 2.1 结论记录原则（重要！）
+
+**每个节点必须有结论**：节点完成时，conclusion 字段必须包含有价值的信息。
+
+| 节点类型 | 结论应包含 |
+|----------|-----------|
+| 分析类 | 分析结果、发现的问题、根因 |
+| 实现类 | 实际采用的方案、关键修改点 |
+| 验证类 | 验证结果、通过/失败原因 |
+| 调试类 | Bug 原因、修复方法 |
+
+**中间过程也要记录**：
+- 使用 \`node_update({ note: "..." })\` 记录分析中的阶段性结论
+- 创建子节点前，先在父节点记录"截至目前的发现"
+- 这样即使后续分析失败，之前的结论也不会丢失
+
+### 3. 状态流转规则
+
+**执行节点状态机**：
+\`\`\`
+pending ──start──→ implementing ──submit──→ validating ──complete──→ completed
+                        │                       │                     │
+                        │ complete              │ fail                │ reopen
+                        ↓                       ↓                     ↓
+                    completed                 failed ──retry──→ implementing
+\`\`\`
+
+**规划节点状态机**：
+\`\`\`
+pending ──start──→ planning ──(创建子节点)──→ monitoring ──complete──→ completed
+                        │                         │                     │
+                        │ complete/cancel         │ cancel              │ reopen
+                        ↓                         ↓                     ↓
+                completed/cancelled          cancelled ────reopen────→ planning
+\`\`\`
+
+**自动级联规则**：
+- 当执行节点 start 时，父规划节点链自动从 pending/planning → monitoring
+- 当创建第一个子节点时，规划节点自动从 planning → monitoring
+- 当子节点 reopen 时，已完成的父节点链也会自动 reopen
+
+**重新激活节点**：
+- 对于已完成的节点，如需添加新功能，使用 \`node_transition(action="reopen")\`
+- reopen 会自动级联激活已完成的父节点
+
+### 4. 任务分解原则（重要！）
+
+**规划节点应主动分解任务为子节点**
+
+| 场景 | 子节点类型 | 说明 |
+|------|-----------|------|
+| 简单具体任务 | execution | 如：修复某个 bug、添加某个函数 |
+| 复杂多步任务 | planning | 如：重构某个模块、实现某个功能 |
+| 并行探索路径 | 多个平级节点 | 每条路径一个节点 |
+| 验证假设 | execution | 具体的验证步骤 |
+
+**执行节点遇到问题时的处理**：
+- 任务过于复杂 → fail 回退到父规划节点，让父节点重新分解
+- 信息不足 → fail 并说明缺少什么，父节点补充后重新派发
+- 发现新的子任务 → fail 回退，因为执行节点不能创建子节点
+
+**分解触发器**（规划节点应主动执行）：
+1. 任务包含多个独立步骤时 → 为每个步骤创建子节点
+2. 需要在多个方向同时探索时 → 创建平级子节点
+3. 复杂任务难以一次完成时 → 分解为多个小任务
+`;
+/**
+ * 工具速查表
+ */
+export const TOOLS_QUICK_REFERENCE = `
+## 工具速查表
+
+### 工作区管理
+| 工具 | 用途 | 关键参数 |
+|------|------|----------|
+| workspace_init | 创建新工作区 | name, goal, rules?, docs? |
+| workspace_list | 列出所有工作区 | status? (active/archived/all) |
+| workspace_get | 获取工作区详情 | workspaceId |
+| workspace_delete | 删除工作区 | workspaceId, force? |
+
+**重要**：workspace_init 返回 \`webUrl\`，务必告知用户此地址可在浏览器中查看任务进度。
+
+### 节点管理
+| 工具 | 用途 | 关键参数 |
+|------|------|----------|
+| node_create | 创建子节点 | workspaceId, parentId, **type**, title, requirement, docs? |
+| node_get | 获取节点详情（返回 nodeHash） | workspaceId, nodeId |
+| node_list | 列出节点树 | workspaceId, rootId?, depth? |
+| node_update | 更新节点信息（需 nodeHash） | workspaceId, nodeId, **nodeHash**, ... |
+| node_delete | 删除节点 | workspaceId, nodeId |
+
+**★ node_update 先读后写机制（重要！）**：
+
+更新节点前**必须**先调用 \`node_get\` 获取 \`nodeHash\`，然后在 \`node_update\` 中提供该 hash。这是乐观锁机制，防止并发覆盖。
+
+**两种编辑模式**：
+1. **全量替换**：直接提供新值覆盖整个字段
+   \`\`\`typescript
+   node_update({
+     workspaceId: "ws-xxx",
+     nodeId: "node-xxx",
+     nodeHash: "abc123",  // 从 node_get 获取
+     title: "新标题",
+     requirement: "新需求"
+   })
+   \`\`\`
+
+2. **精确替换**：使用 \`field\` + \`old_str\` + \`new_str\` 只替换部分内容
+   \`\`\`typescript
+   node_update({
+     workspaceId: "ws-xxx",
+     nodeId: "node-xxx",
+     nodeHash: "abc123",
+     field: "requirement",    // 目标字段
+     old_str: "旧的部分内容",  // 要替换的内容
+     new_str: "新的部分内容"   // 替换后的内容
+   })
+   \`\`\`
+
+⚠️ **注意**：\`node_update\` 成功后**不返回新 hash**，如需再次更新，必须重新调用 \`node_get\` 获取最新 hash。
+
+**★ type 参数（必填）**：
+- **planning**：规划节点，负责分析、分解任务、创建子节点、汇总结论
+- **execution**：执行节点，负责具体执行，不能有子节点，遇到问题需 fail 回退
+
+**★ docs 参数（重要！）**：
+创建子节点时，**必须**使用 docs 参数显式派发该子任务需要的文档引用。
+⚠️ 子节点就像新加入的员工，如果你不把文档传给它，它就什么都看不到。
+子节点不会自动继承父节点的文档，必须显式派发！
+
+### 状态转换
+
+**执行节点 (execution)**：
+| action | 转换 |
+|--------|------|
+| start | pending → implementing |
+| submit | implementing → validating |
+| complete | implementing/validating → completed |
+| fail | implementing/validating → failed |
+| retry | failed → implementing |
+| reopen | completed → implementing |
+
+**规划节点 (planning)**：
+| action | 转换 |
+|--------|------|
+| start | pending → planning |
+| complete | planning/monitoring → completed |
+| cancel | planning/monitoring → cancelled |
+| reopen | completed/cancelled → planning |
+
+### 上下文管理
+| 工具 | 用途 | 关键参数 |
+|------|------|----------|
+| context_get | 获取聚焦上下文 | workspaceId, nodeId, includeLog?, includeProblem? |
+| context_focus | 切换当前焦点 | workspaceId, nodeId |
+| node_isolate | 设置/取消隔离 | workspaceId, nodeId, isolate |
+| node_reference | 管理引用 | workspaceId, nodeId, targetIdOrPath, action |
+
+### 日志与问题
+| 工具 | 用途 | 关键参数 |
+|------|------|----------|
+| log_append | 追加日志 | workspaceId, nodeId?, operator, event |
+| problem_update | 更新问题 | workspaceId, nodeId?, problem, nextStep? |
+| problem_clear | 清除问题 | workspaceId, nodeId? |
+
+### 备忘录管理
+| 工具 | 用途 | 关键参数 |
+|------|------|----------|
+| memo_create | 创建备忘录 | workspaceId, title, content, tags? |
+| memo_list | 列出备忘录 | workspaceId, tag? |
+| memo_get | 获取备忘录详情（返回 contentHash） | workspaceId, memoId |
+| memo_update | 更新备忘录（需 contentHash） | workspaceId, memoId, **contentHash**, ... |
+| memo_delete | 删除备忘录 | workspaceId, memoId |
+
+**★ memo_update 先读后写机制（重要！）**：
+
+更新备忘录前**必须**先调用 \`memo_get\` 获取 \`contentHash\`，然后在 \`memo_update\` 中提供该 hash。这是乐观锁机制，防止并发覆盖。
+
+**两种编辑模式**：
+1. **全量替换**：直接提供新值覆盖整个字段
+   \`\`\`typescript
+   memo_update({
+     workspaceId: "ws-xxx",
+     memoId: "memo-xxx",
+     contentHash: "def456",  // 从 memo_get 获取
+     title: "新标题",
+     content: "新内容"
+   })
+   \`\`\`
+
+2. **精确替换**：使用 \`field\` + \`old_str\` + \`new_str\` 只替换部分内容
+   \`\`\`typescript
+   memo_update({
+     workspaceId: "ws-xxx",
+     memoId: "memo-xxx",
+     contentHash: "def456",
+     field: "content",         // 目标字段
+     old_str: "旧的部分内容",   // 要替换的内容
+     new_str: "新的部分内容"    // 替换后的内容
+   })
+   \`\`\`
+
+⚠️ **注意**：\`memo_update\` 成功后**不返回新 hash**，如需再次更新，必须重新调用 \`memo_get\` 获取最新 hash。
+
+### 派发模式（可选）
+| 工具 | 用途 | 关键参数 |
+|------|------|----------|
+| dispatch_enable | 启用派发模式 | workspaceId |
+| dispatch_disable | 禁用派发模式 | workspaceId, merge? |
+| dispatch_node | 准备派发任务 | workspaceId, nodeId |
+| dispatch_complete | 处理派发结果 | workspaceId, nodeId, success, conclusion? |
+| dispatch_cleanup | 清理派发分支 | workspaceId, cleanupType? |
+
+**派发模式说明**：
+- 派发模式允许将执行节点任务交给独立的 subagent 执行
+- 启用后自动创建 Git 分支，支持失败回滚
+- 可配合测试节点实现自动验证
+- 使用 node_create 的 createTestNode 参数创建配对测试节点
+`;
+/**
+ * 场景化引导内容 - 针对不同任务场景的规划引导
+ */
+export const SCENARIO_GUIDANCE = {
+    feature: `Feature 场景引导：
+1. 先完成信息收集节点，重点收集：
+   - 需求澄清：用户角色、功能描述、验收标准
+   - 技术调研：相关模块、依赖、接口
+2. 创建技术设计节点（可选创建 alternatives 讨论多方案）
+3. 任务分解时默认 isNeedTest=true`,
+    summary: `Summary 场景引导：
+1. 信息收集重点：分析范围、现有结构
+2. 输出总结文档，无需测试`,
+    optimize: `Optimize 场景引导：
+1. 信息收集重点：现有实现、当前性能基准
+2. 优化后需对比验证，默认启用测试`,
+    debug: `Debug 场景引导：
+1. 信息收集重点：错误现象、复现步骤、日志
+2. 采用假设-验证循环，默认启用回归测试`,
+    misc: `Misc 场景：自由规划模式，按需创建节点。`
+};
+/**
+ * 获取场景引导内容
+ * @param scenario 任务场景类型
+ * @returns 场景引导文本
+ */
+export function getScenarioGuidance(scenario) {
+    return SCENARIO_GUIDANCE[scenario] || SCENARIO_GUIDANCE.misc;
+}
+/**
+ * 场景化指导
+ */
+export const SCENARIO_GUIDES = {
+    // 开始新任务
+    "start_task": `
+## 场景：开始新任务
+
+### 当用户说"帮我做 XXX"时：
+
+**步骤 1：向用户确认任务目标**
+\`\`\`
+向用户确认：
+1. 任务目标是什么？（简明描述）
+2. 这是什么类型的任务？（需求开发/Bug修复/重构/总结）
+\`\`\`
+
+**步骤 2：创建工作区**
+\`\`\`typescript
+workspace_init({
+  name: "实现用户登录功能",
+  goal: "为应用添加用户名密码登录功能"
+  // 不需要预先填写 rules 和 docs，信息收集阶段会补充
+})
+\`\`\`
+
+**步骤 2.5：告知用户 Web UI 地址**
+workspace_init 返回的 \`webUrl\` 是可视化界面地址，**务必告知用户**。
+
+**步骤 3：★ 创建信息收集节点（必须！）**
+\`\`\`typescript
+node_create({
+  workspaceId: "ws-xxx",
+  parentId: "root",
+  type: "planning",
+  role: "info_collection",  // 关键！标记为信息收集节点
+  title: "项目信息收集",
+  requirement: "收集项目结构、开发规范、相关文档等信息"
+})
+\`\`\`
+
+**步骤 4：在信息收集节点中执行调研**
+- 扫描项目根目录，了解结构
+- 查找文档文件夹、规则文件夹
+- 阅读 README 和配置文件
+- 收集环境变量、路径配置等
+
+**步骤 5：完成信息收集，归档到工作区**
+\`\`\`typescript
+node_transition({
+  workspaceId: "ws-xxx",
+  nodeId: "info-collection-node",
+  action: "complete",
+  conclusion: \`
+## 规则
+- 使用 TypeScript 开发
+- 遵循 ESLint 规范
+- 测试覆盖率 > 80%
+
+## 文档
+- ./assets/API.md: API 设计文档
+- ./assets/架构.md: 系统架构说明
+\`
+})
+// 系统会自动将规则和文档追加到工作区
+\`\`\`
+
+**步骤 6：返回根节点，制定执行计划**
+信息收集完成后，根节点可以 start，开始规划具体任务。
+创建子节点分解任务。
+
+**步骤 7：★★★ 展示计划并等待用户确认 ★★★**
+\`\`\`
+向用户展示计划：
+> "我制定了以下执行计划：
+> 1. [子节点1标题] - [需求简述]
+> 2. [子节点2标题] - [需求简述]
+> ...
+>
+> 确认后我会开始执行。需要调整吗？"
+
+等待用户确认（"好"、"可以"、"继续"等）
+如用户有异议 → 调整计划（删除/修改/新增子节点）
+\`\`\`
+
+**步骤 8：用户确认后开始执行**
+开始执行第一个子节点。
+
+**引导话术**：
+> "好的，我来帮你管理这个任务。让我先创建工作区，然后收集一下项目信息..."
+`,
+    // 继续任务
+    "resume_task": `
+## 场景：继续之前的任务
+
+### 当用户说"继续之前的任务"时：
+
+**步骤 1：查看工作区列表**
+\`\`\`typescript
+workspace_list({ status: "active" })
+\`\`\`
+
+**步骤 2：如果有多个，让用户选择**
+
+**步骤 3：获取工作区状态**
+\`\`\`typescript
+workspace_get({ workspaceId: "xxx" })
+\`\`\`
+
+**步骤 4：找到当前焦点或最近活跃的节点**
+\`\`\`typescript
+context_get({ workspaceId: "xxx", nodeId: "current-focus", includeLog: true })
+\`\`\`
+
+**步骤 5：恢复执行**
+
+**引导话术**：
+> "让我看看之前的进度..."
+> "找到了，上次我们在处理 [节点名称]，当前状态是 [状态]。"
+> "上次记录的问题是：[问题内容]"
+> "我们继续吗？"
+`,
+    // 会话恢复（从摘要恢复）
+    "session_restore": `
+## 场景：会话从摘要恢复
+
+### 当会话因上下文过长被截断，从摘要恢复时：
+
+**重要**：摘要中的工作区 ID 可能已经失效（工作区被删除/重建、环境变化等）。
+必须先验证 ID 是否有效，再进行后续操作。
+
+**步骤 1：验证工作区 ID**
+\`\`\`typescript
+// 先尝试获取摘要中的工作区
+workspace_get({ workspaceId: "摘要中的ID" })
+\`\`\`
+
+**步骤 2：如果 ID 无效（返回 WORKSPACE_NOT_FOUND）**
+
+错误响应会**自动包含**活跃工作区列表，无需额外调用 workspace_list()：
+\`\`\`json
+{
+  "error": {
+    "code": "WORKSPACE_NOT_FOUND",
+    "message": "工作区 \"ws-xxx\" 不存在",
+    "availableWorkspaces": [
+      { "id": "ws-yyy", "name": "ZeroWorkspace 查缺补漏", "status": "active" },
+      ...
+    ]
+  }
+}
+\`\`\`
+
+直接从错误响应的 \`availableWorkspaces\` 中通过名称或项目路径匹配正确的工作区。
+
+**步骤 3：继续执行**
+使用匹配到的正确 ID 继续之前的任务。
+
+**错误处理原则**：
+- WORKSPACE_NOT_FOUND 错误响应已包含可用工作区列表，直接使用
+- 通过名称或 projectRoot 匹配摘要中的工作区信息
+- 如果无法找到匹配的工作区，告知用户情况
+
+**示例**：
+摘要显示工作区 "ZeroWorkspace 查缺补漏" (ID: ws-xxx)
+1. 尝试任意工作区操作 → 返回 WORKSPACE_NOT_FOUND
+2. 从 error.availableWorkspaces 中找到名称匹配的 ws-yyy
+3. 使用 ws-yyy 继续执行
+`,
+    // 任务受阻
+    "task_blocked": `
+## 场景：任务遇到问题
+
+### 当执行中遇到无法解决的问题时：
+
+**步骤 1：记录问题**
+\`\`\`typescript
+problem_update({
+  workspaceId: "xxx",
+  nodeId: "current-node",
+  problem: "无法找到 ModuleFactory 的定义，可能需要先配置开发环境",
+  nextStep: "需要用户确认项目依赖是否已安装"
+})
+\`\`\`
+
+**步骤 2：记录日志**
+\`\`\`typescript
+log_append({
+  workspaceId: "xxx",
+  nodeId: "current-node",
+  operator: "AI",
+  event: "执行受阻：缺少 ModuleFactory 定义，等待用户确认"
+})
+\`\`\`
+
+**步骤 3：向用户报告**
+
+**引导话术**：
+> "在执行过程中遇到了一个问题：[问题描述]
+>
+> 我的建议是：[下一步建议]
+>
+> 需要你确认：[需要用户提供的信息]
+>
+> 这个问题已经记录在任务中，等解决后我们可以继续。"
+`,
+    // 任务分解（原"分裂任务"）
+    "split_task": `
+## 场景：需要分解任务
+
+### 规划节点分解任务
+
+规划节点的核心职责是分析任务并创建子节点。
+
+**何时创建子节点**：
+| 条件 | 子节点类型 |
+|------|-----------|
+| 简单具体任务 | execution |
+| 复杂多步任务 | planning |
+| 并行探索多条路径 | 多个平级节点 |
+| 需要验证假设 | execution |
+| 需要改代码 | execution |
+
+### 分解流程（三步法）：
+
+**步骤 1：先记录当前分析结论（关键！）**
+\`\`\`typescript
+// 在创建子节点前，先把当前分析记录到规划节点
+node_update({
+  workspaceId: "xxx",
+  nodeId: "current-planning-node",
+  note: "分析发现：问题出在 UserModule 的类型定义缺失。需要创建类型文件后才能继续。"
+})
+\`\`\`
+
+**步骤 2：创建子节点**
+\`\`\`typescript
+node_create({
+  workspaceId: "xxx",
+  parentId: "current-planning-node",
+  type: "execution",  // 具体任务用 execution
+  title: "添加类型定义文件",
+  requirement: "为 UserModule 创建 TypeScript 类型定义",
+  docs: [{ path: "./src/types/", description: "类型定义目录" }]
+})
+\`\`\`
+
+**步骤 3：执行子节点**
+
+### 执行节点遇到复杂问题时
+
+执行节点不能创建子节点。当任务过于复杂时：
+
+\`\`\`
+执行节点发现任务复杂
+    ↓
+fail 并说明原因
+    ↓
+返回父规划节点
+    ↓
+父节点分析后创建更细粒度的子节点
+\`\`\`
+
+\`\`\`typescript
+// 执行节点标记失败
+node_transition({
+  workspaceId: "xxx",
+  nodeId: "execution-node",
+  action: "fail",
+  conclusion: "任务过于复杂，需要分解为：1. 创建类型定义 2. 修复引用 3. 测试验证"
+})
+
+// 父规划节点创建更细粒度的子节点
+node_create({ type: "execution", title: "创建类型定义", ... })
+node_create({ type: "execution", title: "修复引用", ... })
+node_create({ type: "execution", title: "测试验证", ... })
+\`\`\`
+
+**引导话术**：
+> "经过分析，我发现这个任务需要分解为以下步骤：
+> 1. [步骤1]
+> 2. [步骤2]
+>
+> 现在创建子任务来逐个处理。"
+`,
+    // 完成任务
+    "complete_task": `
+## 场景：完成任务
+
+### 当节点任务完成时：
+
+**步骤 1：更新节点结论**
+\`\`\`typescript
+node_update({
+  workspaceId: "xxx",
+  nodeId: "current-node",
+  note: "实际采用了策略模式实现，比原计划的工厂模式更灵活"
+})
+\`\`\`
+
+**步骤 2：转换状态**
+\`\`\`typescript
+// 如果需要验证
+node_transition({
+  workspaceId: "xxx",
+  nodeId: "current-node",
+  action: "submit",
+  reason: "代码已完成，等待测试验证"
+})
+
+// 如果可以直接完成
+node_transition({
+  workspaceId: "xxx",
+  nodeId: "current-node",
+  action: "complete",
+  conclusion: "成功实现用户登录功能，包括表单验证和JWT认证"
+})
+\`\`\`
+
+**步骤 3：检查父节点**
+如果当前是子节点，完成后应返回父节点继续。
+
+**引导话术**：
+> "这个任务已经完成了！
+>
+> **完成内容**：[结论摘要]
+>
+> **产出**：
+> - [具体产出列表]
+>
+> [如果有父任务] 现在回到上级任务继续..."
+`,
+    // 查看进度
+    "check_progress": `
+## 场景：查看任务进度
+
+### 当用户询问进度时：
+
+**获取工作区状态**
+\`\`\`typescript
+workspace_get({ workspaceId: "xxx" })
+\`\`\`
+
+**输出格式示例**：
+\`\`\`
+## 工作区：实现用户登录功能
+
+**状态**：进行中
+**当前焦点**：后端API实现
+
+### 节点树
+\`\`\`
+[●] 根节点 - 实现用户登录功能
+ ├─[●] 前端表单 (completed)
+ ├─[◐] 后端API实现 (implementing) ← 当前
+ │  ├─[●] 数据库设计 (completed)
+ │  └─[○] JWT集成 (pending)
+ └─[○] 集成测试 (pending)
+\`\`\`
+
+**当前问题**：无
+
+**最近日志**：
+- 10:30 [AI] 完成数据库表设计
+- 10:35 [AI] 开始实现登录接口
+\`\`\`
+`,
+    // 文档引用管理
+    "docs_management": `
+## 场景：文档引用管理
+
+### 文档 vs 规则
+
+| 类型 | 文档 (docs) | 规则 (rules) |
+|------|-------------|--------------|
+| 性质 | 可读写、动态变化 | 只读、全局固定 |
+| 内容 | md 文档、重要代码文件 | md 规则文件、对话中补充的临时规则 |
+| 存储 | 工作区（全局索引）+ 节点（当前需要） | 仅工作区 |
+| 生命周期 | 可添加、可过期 | 创建时设定，不变 |
+
+### 核心原则：显式派发，不自动继承
+
+\`\`\`
+父节点 (docs: [A, B, C])
+    │
+    │ node_create(docs: [A, B])  ← 显式指定派发哪些
+    ↓
+子节点 (docs: [A, B])  ← 只有被派发的文档
+    │
+    │ 执行过程中发现信息不足
+    ↓
+子节点标记失败 → 返回父节点 → 补充信息/文档 → 重新派发
+\`\`\`
+
+### 文档查找优先级
+
+当节点需要文档时：
+1. **先查工作区全局索引**（Workspace.md ## 文档）
+2. **没有 → 搜索项目文件系统**
+3. **搜索结果 → 存入工作区索引 + 引用到节点**
+
+### 创建子节点时派发文档
+
+\`\`\`typescript
+// 创建子节点时显式派发文档
+node_create({
+  workspaceId: "xxx",
+  parentId: "parent-node",
+  type: "execution",  // 或 "planning"
+  title: "实现登录 API",
+  requirement: "实现用户名密码登录接口",
+  docs: [
+    { path: "./assets/api-spec.md", description: "API 规范文档" },
+    { path: "./src/auth/types.ts", description: "认证类型定义" }
+  ]
+})
+\`\`\`
+
+### 文档生命周期
+
+- **添加时机**：任务开始、需求变化时
+- **过期时机**：任务完成后评估，调用 node_reference(action="expire")
+- **工作区索引**：记录所有使用过的文档（除被删除的），作为查找优先级
+
+### 信息不足时的处理
+
+当子节点因信息不足而无法完成时：
+1. 子节点标记为 failed，conclusion 说明缺少什么信息
+2. 返回父节点补充信息/文档
+3. 重新创建或 retry 子节点，带上补充的文档
+`,
+    // 用户不熟悉
+    "user_guide": `
+## 场景：用户不熟悉 ZeroWorkspace
+
+### 当用户首次使用或询问时：
+
+**简单介绍**：
+> "ZeroWorkspace 是一个帮助我们管理复杂任务的工具。
+>
+> **它能做什么**：
+> - 📋 把大任务拆分成小步骤
+> - 🔍 追踪每个步骤的进度
+> - 📝 记录执行过程，方便回顾
+> - 🔄 遇到问题时可以回退和重试
+>
+> **基本概念**：
+> - **工作区**：一个完整任务的容器
+> - **节点**：任务的每个步骤
+> - **状态**：pending（待做）→ implementing（执行中）→ completed（完成）
+>
+> **你只需要**：
+> 1. 告诉我你要做什么
+> 2. 确认任务计划
+> 3. 让我执行，有问题时我会询问你
+>
+> 需要我演示一下吗？"
+
+**演示流程**：
+1. 创建一个简单的示例工作区
+2. 展示节点创建和状态流转
+3. 演示日志记录
+4. 删除示例工作区
+`,
+    // 派发模式
+    "dispatch_mode": `
+## 场景：使用派发模式
+
+### 什么是派发模式？
+
+派发模式允许将执行节点任务交给独立的 subagent 执行。提供两种模式：
+
+| 模式 | 定位 | 推荐度 | 特性 |
+|------|------|--------|------|
+| **无 Git 模式** | 标准模式 | ✅ 推荐（默认） | 仅更新元数据，不影响代码，安全 |
+| **Git 模式** | 实验功能 | ⚠️ 谨慎使用 | 自动分支、提交、回滚，有一定风险 |
+
+**共同特性**：
+- **自动测试验证**：配对测试节点验证执行结果
+- **任务隔离**：将任务交给专门的 subagent 执行
+- **并发保护**：同一项目同时只允许一个工作区启用派发
+
+**模式差异**：
+
+| 场景 | 无 Git 模式 | Git 模式 |
+|------|------------|----------|
+| 启用派发 | 仅更新配置 | 创建派发分支 |
+| 有未提交内容 | 警告用户手动备份 | 自动创建备份分支 |
+| 执行任务 | 直接在当前目录执行 | 在派发分支执行 |
+| 任务完成 | 记录时间戳 | 自动 commit |
+| 测试失败 | 无法回滚，需手动处理 | 自动 git reset 回滚 |
+| 禁用派发 | 仅清理配置 | 4 种合并策略 |
+
+### 何时启用派发？
+
+系统会在首个执行节点启动时询问（actionRequired: ask_dispatch）。
+
+**模式选择建议**：
+
+| 场景 | 推荐模式 | 原因 |
+|------|----------|------|
+| 简单任务 | 无 Git 模式 | 轻量、安全、无副作用 |
+| 需要测试验证 | 无 Git 模式 | 测试验证不需要 git 分支隔离 |
+| 需要失败回滚 | Git 模式 | 自动回滚机制 |
+| 非 git 项目 | 无 Git 模式（自动） | 唯一可用模式 |
+| 学习探索 | 无 Git 模式 | 降低出错风险 |
+
+**无 Git 模式限制**：
+- ⚠️ 测试失败时无法自动回滚（需手动恢复代码）
+- ⚠️ 建议执行前手动备份重要文件
+- ⚠️ 并发检测通过配置文件（而非 git 分支）
+
+### 派发流程
+
+\`\`\`
+1. 用户确认启用派发
+    ↓
+dispatch_enable({ workspaceId, useGit: true/false })
+  - useGit: false（默认）→ 无 Git 模式
+  - useGit: true → Git 模式（需要项目是 git 仓库）
+    ↓
+2. 创建执行节点（可带配对测试节点）
+node_create({
+  type: "execution",
+  createTestNode: { title: "验证xxx", requirement: "验收标准" }
+})
+    ↓
+3. 启动执行节点
+node_transition({ action: "start" })
+    ↓
+4. 准备派发
+dispatch_node({ workspaceId, nodeId })
+  → 返回 actionRequired: { type: "dispatch_task", prompt: "..." }
+  → 返回 startMarker（Git 模式=commit hash，无 Git 模式=时间戳）
+    ↓
+5. 调用 Task tool 执行
+Task({ subagent_type: "zero-executor", prompt: "..." })
+    ↓
+6. 处理执行结果
+dispatch_complete({ success: true/false, conclusion: "..." })
+  → 成功时返回 endMarker（Git 模式=commit hash，无 Git 模式=时间戳）
+    ↓
+7. 如果有测试节点，自动触发测试
+    ↓
+8. 完成后禁用派发
+dispatch_disable({ workspaceId })
+  → 返回 actionRequired: { type: "dispatch_complete_choice", ... }
+  ⚠️ **必须询问用户**：使用 AskUserQuestion 让用户选择：
+  - Git 模式：合并策略（sequential/squash/cherry-pick/skip）、是否保留分支
+  - 无 Git 模式：确认禁用即可
+dispatch_disable_execute({ workspaceId, mergeStrategy, ... })  // 参数来自用户选择
+\`\`\`
+
+### 测试节点验证
+
+\`\`\`typescript
+// 创建执行节点时同时创建测试节点
+node_create({
+  workspaceId: "xxx",
+  parentId: "parent",
+  type: "execution",
+  title: "实现登录功能",
+  requirement: "实现用户名密码登录",
+  createTestNode: {
+    title: "验证登录功能",
+    requirement: "1. 正确用户名密码能登录成功\\n2. 错误密码返回401"
+  }
+})
+// 返回 { nodeId: "exec-xxx", testNodeId: "test-xxx" }
+\`\`\`
+
+### 失败处理
+
+当 dispatch_complete 传入 success: false 时：
+- 节点状态变为 failed，dispatch.status 变为 failed
+- **不会自动回滚**，由母节点决定下一步操作
+- 母节点可以通过 context_get 读取子节点状态来决策
+
+**Git 模式下的手动回滚**：
+- 如需回滚，母节点可使用 startMarker（commit hash）执行 git reset
+- 或直接重新派发任务
+
+**无 Git 模式**：
+- 需要手动恢复代码
+- 可通过 startMarker（时间戳）追溯执行时间点
+
+### 常见问题
+
+**Q: 不启用派发模式也能正常使用吗？**
+A: 可以。派发模式是可选功能，普通模式下 AI 直接执行任务。
+
+**Q: 派发失败会影响代码吗？**
+A:
+- Git 模式：不会。在独立分支执行，失败会回滚，只有测试通过才会合并。
+- 无 Git 模式：可能会。直接在当前目录执行，失败需手动恢复。
+
+**Q: 如何选择模式？**
+A: 优先使用无 Git 模式（安全、简单）。只在明确需要自动回滚时使用 Git 模式。
+
+**Q: 启用后可以切换模式吗？**
+A: 不可以。派发启用后模式不可变更，如需切换必须先 disable 再重新 enable。
+`,
+    // 重开任务/追加需求
+    "reopen_task": `
+## 场景：重开任务或追加需求
+
+### 当需要在已完成的工作区/节点上追加需求时：
+
+**核心原则**：先了解现有结构，再决定是调整还是新建。
+
+**步骤 1：重开节点**
+\`\`\`typescript
+node_transition({
+  workspaceId: "xxx",
+  nodeId: "target-node",
+  action: "reopen"
+})
+\`\`\`
+
+**步骤 2：★★★ 必须先查看现有结构 ★★★**
+
+当返回 \`actionRequired: { type: "review_structure" }\` 时，你必须：
+\`\`\`typescript
+// 查看节点树
+node_list({ workspaceId: "xxx", rootId: "target-node" })
+
+// 或查看工作区状态
+workspace_get({ workspaceId: "xxx" })
+\`\`\`
+
+**步骤 3：评估并决定**
+
+| 情况 | 正确做法 | 错误做法 |
+|------|----------|----------|
+| 原有节点可复用 | node_update 修改需求后 reopen | 创建重复的新节点 |
+| 需要补充子任务 | 在原结构上添加新节点 | 重建整个结构 |
+| 原结构不适用 | 先 cancel/delete 旧节点再创建 | 保留旧节点又创建新的 |
+
+**步骤 4：向用户说明**
+\`\`\`
+"我查看了现有结构，发现：
+- 已有 X 个子节点，其中 Y 个已完成
+- [节点A] 可以复用，只需补充 XXX
+- 需要新增一个节点处理 YYY
+
+是否按此方案调整？"
+\`\`\`
+
+**禁止行为**：
+- ❌ reopen 后不看结构直接创建新节点
+- ❌ 创建与现有节点功能重复的新节点
+- ❌ 忽略 actionRequired 的 review_structure 指令
+`
+};
+/**
+ * 用户引导话术模板
+ */
+export const USER_PROMPTS = {
+    // 首次使用引导
+    welcome: `欢迎使用 ZeroWorkspace！我可以帮你管理开发任务。
+
+你可以：
+- 说"帮我做 XXX"开始一个新任务
+- 说"继续之前的任务"恢复工作
+- 说"查看进度"了解当前状态
+- 说"这是什么"了解更多
+
+有什么可以帮你的？`,
+    // 确认创建工作区
+    confirmWorkspace: (name, goal) => `
+我来确认一下任务信息：
+
+**任务名称**：${name}
+**目标**：${goal}
+
+确认后我会创建工作区并制定执行计划。可以继续吗？`,
+    // 任务计划确认
+    confirmPlan: (tasks) => `
+根据任务目标，我制定了以下计划：
+
+${tasks.map((t, i) => `${i + 1}. ${t}`).join('\n')}
+
+确认后我会开始执行。需要调整吗？`,
+    // 状态报告
+    statusReport: (status, current, problem) => `
+**当前状态**：${status}
+**正在处理**：${current}
+${problem ? `**遇到问题**：${problem}` : ''}
+
+继续执行吗？`,
+    // 完成报告
+    completionReport: (conclusion, outputs) => `
+✅ 任务完成！
+
+**结论**：${conclusion}
+
+**产出**：
+${outputs.map(o => `- ${o}`).join('\n')}
+
+还有其他需要吗？`
+};
+/**
+ * 服务器状态与自检指南
+ */
+export const SERVER_STATUS_GUIDE = `
+# 服务器状态与自检
+
+## 端口配置
+- **正式环境**: 19540
+- **开发环境** (ZERO_DEV=true): 19541
+
+## CLI 命令
+用户可通过以下命令管理 WebUI 服务：
+\`\`\`bash
+zero-workspace webui          # 启动服务
+zero-workspace webui stop     # 停止服务
+zero-workspace webui restart  # 重启服务
+zero-workspace webui status   # 查看状态
+\`\`\`
+
+## 常见问题自检
+
+### 1. 服务未启动
+**现象**: API 调用失败、超时
+**自检**:
+- 检查返回值中是否有错误信息
+- 建议用户执行 \`zero-workspace webui status\` 查看服务状态
+
+### 2. 版本不匹配
+**现象**: 数据格式异常、功能缺失、WebUI 显示版本警告
+**原因**: npm 更新后 MCP 服务未重启，前后端版本不一致
+**解决**:
+- 用户需重启 Claude Code / Cursor 以重新加载 MCP 服务
+- 或执行 \`zero-workspace webui restart\` 重启 WebUI
+
+### 3. 端口被占用
+**现象**: 服务启动失败
+**解决**:
+- 使用 \`HTTP_PORT=19542 zero-workspace webui\` 指定其他端口
+- 或停止占用该端口的其他服务
+
+## PID 文件位置
+- 正式环境: \`~/.zero-workspace/webui.pid\`
+- 开发环境: \`~/.zero-workspace-dev/webui.pid\`
+
+## 端口迁移（从旧版本升级）
+从 v1.7.x 之前的版本升级时，端口从 3000/3001 迁移到 19540/19541。
+系统会**自动检测并关闭**旧端口上的 zero-workspace 服务，并提示用户：
+\`\`\`
+[迁移] 检测到旧版本服务在端口 3000 运行
+[迁移] 端口已从 3000 迁移到 19540/19541
+[迁移] 提示：新版本 WebUI 地址为 http://localhost:19540
+[迁移] 请更新浏览器书签
+\`\`\`
+
+## 如何告知用户
+当遇到服务相关问题时，可以这样引导用户：
+> "看起来 ZeroWorkspace 服务可能未启动或版本不匹配。
+> 请在终端执行 \`zero-workspace webui status\` 查看服务状态。
+> 如果需要重启，执行 \`zero-workspace webui restart\`。"
+`;
+/**
+ * zero_help 工具的帮助内容
+ */
+export const HELP_TOPICS = {
+    "overview": {
+        title: "系统概述",
+        content: SYSTEM_OVERVIEW
+    },
+    "workflow": {
+        title: "核心工作流程",
+        content: CORE_WORKFLOW
+    },
+    "tools": {
+        title: "工具速查表",
+        content: TOOLS_QUICK_REFERENCE
+    },
+    "start": {
+        title: "如何开始新任务",
+        content: SCENARIO_GUIDES["start_task"]
+    },
+    "resume": {
+        title: "如何继续任务",
+        content: SCENARIO_GUIDES["resume_task"]
+    },
+    "session_restore": {
+        title: "会话恢复（从摘要恢复）",
+        content: SCENARIO_GUIDES["session_restore"]
+    },
+    "blocked": {
+        title: "任务受阻时怎么办",
+        content: SCENARIO_GUIDES["task_blocked"]
+    },
+    "split": {
+        title: "何时分解任务",
+        content: SCENARIO_GUIDES["split_task"]
+    },
+    "complete": {
+        title: "如何完成任务",
+        content: SCENARIO_GUIDES["complete_task"]
+    },
+    "progress": {
+        title: "如何查看进度",
+        content: SCENARIO_GUIDES["check_progress"]
+    },
+    "guide": {
+        title: "用户引导",
+        content: SCENARIO_GUIDES["user_guide"]
+    },
+    "docs": {
+        title: "文档引用管理",
+        content: SCENARIO_GUIDES["docs_management"]
+    },
+    "reopen": {
+        title: "重开任务/追加需求",
+        content: SCENARIO_GUIDES["reopen_task"]
+    },
+    "dispatch": {
+        title: "派发模式",
+        content: SCENARIO_GUIDES["dispatch_mode"]
+    },
+    "server": {
+        title: "服务器状态与自检",
+        content: SERVER_STATUS_GUIDE
+    }
+};
+/**
+ * 获取完整的 Instructions
+ */
+export function getFullInstructions() {
+    return [
+        CRITICAL_PROTOCOLS,
+        SYSTEM_OVERVIEW,
+        CORE_WORKFLOW,
+        TOOLS_QUICK_REFERENCE,
+        `
+## 工作原则
+
+1. **主动分解**：规划节点应主动分解任务为子节点，不要等用户要求
+2. **结论不丢**：每形成一个结论就记录，创建子节点前先记录当前发现
+3. **及时记录**：每个关键动作都应追加日志
+4. **主动推进**：AI 应主动推进流程，减少不必要的选择询问
+5. **节点粒度**：节点代表"需要独立追踪的工作单元"，日志代表"执行过程的细节记录"
+6. **用户引导**：当用户不熟悉时，主动解释概念和流程
+7. **需求变化时更新节点**：
+   - 当调研发现问题本质与最初理解不同时，用 \`node_update\` 更新节点标题和需求描述
+   - 当方案需要调整时，更新节点信息并用 \`log_append\` 记录变更原因
+8. **调研过程记录日志**：
+   - 发现问题根因时，立即用 \`log_append\` 记录分析过程和关键发现
+   - 不要只在最后 complete 时才写结论，中间的分析过程同样重要
+
+## 获取帮助
+
+**遇到不确定的场景时，必须先调用 zero_help 查询指南，不要猜测！**
+
+可用主题：
+- overview: 系统概述
+- workflow: 核心工作流程
+- tools: 工具速查表
+- start: 如何开始新任务
+- resume: 如何继续任务
+- session_restore: 会话恢复（从摘要恢复）
+- blocked: 任务受阻时怎么办
+- split: 何时分解任务
+- complete: 如何完成任务
+- progress: 如何查看进度
+- guide: 用户引导话术
+- docs: 文档引用管理
+- reopen: 重开任务/追加需求
+`
+    ].join('\n\n');
+}
+//# sourceMappingURL=instructions.js.map