add-coder 0.1.12 → 0.1.13

package/templates/core/templates/prd-incremental-template.md

@@ -0,0 +1,103 @@
+# {需求名称} PRD 增量更新 v{版本号}
+
+> PRD 增量模板：用于在已有 PRD 基础上追加/修改/删除需求。不是独立文档，是 PRD 的变更记录。
+> 新建 PRD 请使用 `prd-standard-template.md`。
+
+**创建时间**: {ISO 时间戳}
+**作者**: {作者标识}
+**状态**: 草稿 / 评审中 / 已确认
+**基于 PRD**: `docs/{项目}/knowledge/00-需求/{原PRD文件名}.md` v{原版本号}
+
+---
+
+## 变更摘要
+
+| 类型 | 数量 | 说明 |
+|------|:--:|------|
+| 新增 | N | {一句话} |
+| 修改 | N | {一句话} |
+| 删除 | N | {一句话} |
+
+---
+
+## 一、新增内容
+
+### 1.1 {新增项1标题}
+
+{新增的功能描述、用户场景、验收标准等，格式与标准 PRD 对应章节一致}
+
+### 1.2 {新增项2标题}
+
+{内容}
+
+---
+
+## 二、修改内容
+
+### 2.1 {修改项1标题}
+
+> 原 PRD §{章节号} "{原章节标题}"
+
+**变更前**：
+{原有内容摘要}
+
+**变更后**：
+{修改后内容}
+
+**变更原因**：{一句话}
+
+### 2.2 {修改项2标题}
+
+> 原 PRD §{章节号} "{原章节标题}"
+
+**变更前**：
+{原有内容摘要}
+
+**变更后**：
+{修改后内容}
+
+**变更原因**：{一句话}
+
+---
+
+## 三、删除内容
+
+### 3.1 {删除项1标题}
+
+> 原 PRD §{章节号} "{原章节标题}"
+
+**删除内容**：{被删除的内容摘要}
+
+**删除原因**：{一句话}
+
+---
+
+## 四、Plan 拆分影响
+
+> 本次变更是否影响了原 PRD 的 Plan 拆分建议？必填——增量改动可能改变 Plan 链路。
+
+**影响判定**：无影响 / 新增 Plan / 调整 Plan 依赖 / 废弃 Plan
+
+**变更后的 Plan 链路**：
+
+```text
+{更新后的 Plan 链路，格式与标准 PRD §10.1 一致}
+```
+
+---
+
+## 五、裁决层影响
+
+> 本次变更涉及哪些裁决规则的增删改？必填。
+
+| 操作 | 规则 | 裁决条目 | 说明 |
+|------|------|------|------|
+| 新增 / 修改 / 删除 | {规则描述} | `[[caijue]] id="{entry-id}"` | {一句话} |
+
+---
+
+## 六、关联文档
+
+| 类型 | 路径 | 说明 |
+|------|------|------|
+| 原 PRD | `docs/{项目}/knowledge/00-需求/{原PRD文件名}.md` | 本次更新基于的 PRD |

package/templates/core/templates/prd-incremental-template.schema.json

@@ -0,0 +1,32 @@
+{
+    "template": "prd-incremental-template.md",
+    "description": "增量 PRD 校验只验证 ADD 交互接口——Plan 拆分影响 + 裁决层影响。变更内容本身是人工写作，不做结构校验。",
+    "sections": [
+        {
+            "id": "plan-impact",
+            "heading": "## 四、Plan 拆分影响",
+            "required": true,
+            "description": "增量改动必须声明是否影响原 PRD 的 Plan 拆分链路。"
+        },
+        {
+            "id": "caijuehub-impact",
+            "heading": "## 五、裁决层影响",
+            "required": true,
+            "description": "增量改动必须声明涉及哪些裁决规则的增删改。"
+        }
+    ],
+    "placeholders": [
+        "{需求名称}",
+        "{版本号}",
+        "{ISO 时间戳}",
+        "{作者标识}",
+        "{原PRD文件名}",
+        "{原版本号}"
+    ],
+    "forbidden_terms": [
+        "TBD",
+        "Phase",
+        "Step",
+        "Task"
+    ]
+}

package/templates/core/templates/prd-standard-template.md

@@ -0,0 +1,219 @@
+# {需求名称} PRD v{版本号}
+
+> PRD 标准模板：用于新建产品需求文档。定义"做什么、为谁做、做到什么程度"。向下游 Plan/Review/Spec 提供唯一真值输入。
+> 适用场景：系统级规划 | 功能/模块级需求 | AI 智能体能力定义。
+> 修改已有 PRD 请使用 `prd-incremental-template.md`。
+> 可选章节（§五 §六 §七 §九）按场景选用，不适用则删除。
+
+**创建时间**: {ISO 时间戳}
+**作者**: {作者标识}
+**状态**: 草稿 / 评审中 / 已确认
+
+---
+
+## 一、背景与目标
+
+### 1.1 背景
+
+{一句话描述当前面临的问题或机会}
+
+### 1.2 目标
+
+- {目标1}
+- {目标2}
+
+### 1.3 范围
+
+| 维度 | 本次范围 | 明确不做 |
+|------|---------|---------|
+| {维度1} | {做} | {不做} |
+| {维度2} | {做} | {不做} |
+
+---
+
+## 二、目标用户与场景
+
+### 2.1 用户角色
+
+| 角色 | 描述 | 核心诉求 |
+|------|------|---------|
+| {角色1} | {一句话} | {诉求} |
+| {角色2} | {一句话} | {诉求} |
+
+### 2.2 核心场景
+
+| 场景 | 触发条件 | 预期行为 | 优先级 |
+|------|---------|---------|:--:|
+| {场景1} | {条件} | {行为} | P0 |
+| {场景2} | {条件} | {行为} | P1 |
+
+---
+
+## 三、功能需求
+
+### 3.1 功能清单
+
+| 编号 | 功能 | 描述 | 优先级 |
+|:----|------|------|:--:|
+| F1 | {功能名} | {一句话描述} | P0 |
+| F2 | {功能名} | {一句话描述} | P1 |
+
+### 3.2 功能详述
+
+#### F1: {功能名称}
+
+- **输入**: {用户输入/系统输入}
+- **处理逻辑**: {核心流程}
+- **输出**: {预期产出}
+- **交互说明**: {UI 交互要点，无 UI 则写"无"}
+
+#### F2: {功能名称}
+
+- **输入**: {用户输入/系统输入}
+- **处理逻辑**: {核心流程}
+- **输出**: {预期产出}
+- **交互说明**: {UI 交互要点}
+
+---
+
+## 四、非功能需求
+
+| 类别 | 要求 |
+|------|------|
+| 性能 | {如：页面加载 < 2s} |
+| 安全 | {如：所有 API 需认证} |
+| 可用性 | {如：支持主流浏览器} |
+| 数据 | {如：操作日志保留 90 天} |
+
+---
+
+## 五、智能体能力契约（仅 AI 智能体 PRD 时使用）
+
+> 本章节定义智能体的能力边界和裁决逻辑。非智能体需求可删除。
+
+### 5.1 能力清单
+
+| 能力 | 描述 | 触发条件 | 输出格式 |
+|------|------|---------|---------|
+| {能力1} | {描述} | {何时触发} | {输出 schema} |
+
+### 5.2 裁决规则
+
+当多个能力冲突时，按以下优先级裁决：
+
+1. {规则1}
+2. {规则2}
+
+### 5.3 能力边界
+
+- **能做**: {范围}
+- **不能做**: {边界约束}
+- **降级策略**: {能力不可用时的 fallback}
+
+---
+
+## 六、系统架构约束（仅系统级规划时使用）
+
+> 本章节定义顶层架构的硬约束。功能级需求可删除。
+
+### 6.1 子系统划分
+
+| 子系统 | 职责 | 边界 |
+|--------|------|------|
+| {子系统1} | {职责} | {边界} |
+
+### 6.2 技术选型约束
+
+| 层级 | 选型 | 约束条件 |
+|------|------|---------|
+| {前端/后端/数据} | {技术} | {条件} |
+
+---
+
+## 七、接口与数据（涉及 API / 数据模型时使用）
+
+> 本章节定义关键接口契约和数据模型。不涉及可删除。
+
+### 7.1 关键接口
+
+| 接口 | 方法 | 路径 | 说明 |
+|------|:--:|------|------|
+| {接口名} | GET/POST | `/api/...` | {说明} |
+
+### 7.2 核心数据实体
+
+| 实体 | 核心字段 | 关系 |
+|------|---------|------|
+| {实体1} | {字段列表} | {关联} |
+
+---
+
+## 八、验收标准
+
+- [ ] {验收条件1}
+- [ ] {验收条件2}
+- [ ] {验收条件3}
+
+---
+
+## 九、MVP 范围与迭代计划
+
+> 单次交付无需拆分时，写"本次全部交付"即可。需分阶段时填写。
+
+| 阶段 | 范围 | 交付物 | 预计工期 |
+|:----|------|------|------|
+| Phase 1 核心 | {核心功能集合} | {交付物} | {周数} |
+| Phase 2 增强 | {增强功能} | {交付物} | {周数} |
+
+---
+
+## 十、Plan 拆分建议
+
+> 本章节指导下游 AI 如何将本 PRD 拆分为 Plan。必填——没有这条，AI 拿到 PRD 不知道从哪下手。
+
+### 10.1 推荐 Plan 链路
+
+```text
+Plan 1: {plan名称} ── 聚焦: {子功能描述}
+            │  依赖: 无
+            ▼
+Plan 2: {plan名称} ── 聚焦: {子功能描述}
+            │  依赖: Plan 1 完成的 {产出物}
+            ▼
+Plan 3: {plan名称} ── 聚焦: {子功能描述}
+            依赖: Plan 2 完成的 {产出物}
+```
+
+### 10.2 Plan 间依赖说明
+
+| 依赖关系 | 原因 |
+|---------|------|
+| Plan 2 依赖 Plan 1 | {为什么必须先做 Plan 1} |
+| Plan 3 依赖 Plan 2 | {为什么必须先做 Plan 2} |
+
+---
+
+## 十一、裁决层关联
+
+> 本章节列出本 PRD 涉及的规则和边界，哪些建议集中到 `caijue.toml` 管理。必填——PRD 中的约束不进入裁决层，等于没有被强制执行。
+
+### 11.1 建议集中裁决的规则
+
+| 规则 | 类型 | 建议裁决条目 | 说明 |
+|------|------|------|------|
+| {规则描述} | edge / strategy / contract | `[[caijue]] id="{entry-id}"` | {一句话} |
+
+### 11.2 边界约束
+
+| 约束 | 说明 |
+|------|------|
+| {边界1} | {如：禁止跨 Expert 共享 Collection} |
+| {边界2} | {如：单次检索 topK 上限 20} |
+
+---
+
+## 十二、关联文档
+
+| 类型 | 路径 | 说明 |
+|------|------|------|
+| 相关需求 | `docs/{项目}/knowledge/00-需求/{关联PRD}.md` | {与本文档的关系} |

package/templates/core/templates/prd-standard-template.schema.json

@@ -0,0 +1,27 @@
+{
+    "template": "prd-standard-template.md",
+    "description": "PRD 校验只验证与 ADD 体系的交互接口——Plan 拆分建议 + 裁决层关联。内部需求章节是人工写作内容，不做结构校验。",
+    "sections": [
+        {
+            "id": "plan-split",
+            "heading": "## 十、Plan 拆分建议",
+            "required": true,
+            "description": "PRD 必须给出推荐 Plan 拆分链路和 Plan 间依赖关系。没有这个，AI 拿到 PRD 不知道如何落地为 Plan。"
+        },
+        {
+            "id": "caijuehub-link",
+            "heading": "## 十一、裁决层关联",
+            "required": true,
+            "description": "PRD 必须列出建议集中到 caijue.toml 管理的规则和边界约束。约束不进裁决层等于没有被强制执行。"
+        }
+    ],
+    "placeholders": [
+        "{需求名称}",
+        "{版本号}",
+        "{ISO 时间戳}",
+        "{作者标识}"
+    ],
+    "forbidden_terms": [
+        "TBD"
+    ]
+}

package/templates/core/templates/simple-plan-template.md

@@ -130,7 +130,7 @@ ORDER BY "createdAt" DESC;
 - grep 验证命令：
 
 ```bash
-grep -R "{关键字}" .qoder/
+grep -R "{关键字}" {{magicDir}}/
 ```
 
 ### 4.9 后置确认
@@ -163,4 +163,4 @@ Handoff 文档中 **禁止出现** 以下硬编码值：
 | 类型 | 路径 |
 |------|------|
 | Handoff | 见本文第四部分 |
-| Review | `.qoder/reviews/{name}-review-v{版本}.md` |
+| Review | `{{magicDir}}/reviews/{name}-review-v{版本}.md` |

package/templates/core/templates/standard-plan-template.md

@@ -8,9 +8,9 @@
 - **启动时间**: {ISO 时间戳}
 - **主导 AI**: {AI 助手标识}
 - **关联文档**:
-  - ADD Route: `.qoder/plans/{YYYY-MM}/{DD}/{需求域名}-{核心内容}-add-route-v{版本}.md`
-  - Handoff: `.qoder/plans/{YYYY-MM}/{DD}/{需求域名}-{核心内容}-handoff-v{版本}.md`
-  - Review: `.qoder/reviews/{需求域名}-review-v{版本}.md`
+  - ADD Route: `{{magicDir}}/plans/{YYYY-MM}/{DD}/{需求域名}-{核心内容}-add-route-v{版本}.md`
+  - Handoff: `{{magicDir}}/plans/{YYYY-MM}/{DD}/{需求域名}-{核心内容}-handoff-v{版本}.md`
+  - Review: `{{magicDir}}/reviews/{需求域名}-review-v{版本}.md`
 - **ADD-7 审计策略**:
 
 | 文件 | targetType | action | beforeState | afterState | 状态 |
@@ -88,9 +88,9 @@ Task 6 (编译/测试)
 
 | 文档 | 路径 |
 |------|------|
-| ADD Route | `.qoder/plans/...` |
-| Handoff | `.qoder/plans/...` |
-| Review | `.qoder/reviews/...` |
-| Spec | `.qoder/specs/{name}/spec.md` |
-| Tasks | `.qoder/specs/{name}/tasks.md` |
-| Checklist | `.qoder/specs/{name}/checklist.md` |
+| ADD Route | `{{magicDir}}/plans/...` |
+| Handoff | `{{magicDir}}/plans/...` |
+| Review | `{{magicDir}}/reviews/...` |
+| Spec | `{{magicDir}}/specs/{name}/spec.md` |
+| Tasks | `{{magicDir}}/specs/{name}/tasks.md` |
+| Checklist | `{{magicDir}}/specs/{name}/checklist.md` |

package/templates/core/tools/README.md

@@ -207,7 +207,7 @@ class AddToolProvider {
 
 **实现方式**：
 ```typescript
-// .qoder/tools/index.ts - 工具注册中心
+// {{magicDir}}/tools/index.ts - 工具注册中心
 export interface ToolDefinition {
   name: string
   description: string
@@ -358,4 +358,4 @@ export function integrateWithCopilot(executor: ToolExecutor) {
 - **互补关系**：Skill 定义"应该怎么做"，Tools 提供"怎么执行"
 
 通过 Tools 机制，可以让 AI 助手从"只能建议代码"升级为"可以直接执行开发操作"，形成真正的 AI 编程助手生态。</content>
-<parameter name="filePath">{{projectRoot}}/.qoder/tools/README.md
+<parameter name="filePath">{{projectRoot}}/{{magicDir}}/tools/README.md

package/templates/core/vocabulary/add-governance-vocabulary.md

@@ -16,19 +16,20 @@
 
 | 触发词 | LLM 默认操作 | 优先级 |
 |--------|-------------|--------|
-| `Plan` / `plan` | **二段式**: ①先读 `.qoder/plans/index.md` 按 planName 匹配路径（P0 优先）；②无匹配才全局 glob 搜索 `*-plan-v*.md`。**禁止跳过 index.md 直接 glob** | 🔴 P0 |
-| `Spec` / `spec` | 查 `.qoder/specs/{name}/spec.md` | 🔴 P0 |
-| `Tasks` / `tasks` | 查 `.qoder/specs/{name}/tasks.md` | 🟡 P1 |
-| `Checklist` / `checklist` | 查 `.qoder/specs/{name}/checklist.md` | 🟡 P1 |
-| `Review` / `review` | **二段式**: ①先读 `.qoder/plans/index.md` 定位 plan → 查其关联 Review；②无匹配才全局 glob `*-review*.md` | 🔴 P0 |
-| `review-implementation` | 查 `.qoder/reviews/` 下 `*-review-implementation*.md` | 🟡 P1 |
-| `review-runtime` | 查 `.qoder/reviews/` 下 `*-review-runtime*.md` | 🟡 P1 |
-| `Handoff` / `handoff` / `交接` | **二段式**: ①先读 `.qoder/plans/index.md` 按 planName 匹配路径 → 定位 handoff；②无匹配才全局 glob `*-handoff*.md` | 🔴 P0 |
-| `add-route` / `执行路线图` | **二段式**: ①先读 `.qoder/plans/index.md` 定位 plan → 查其 add-route；②调 `check_add_route_status`；③无匹配才全局 glob | 🔴 P0 |
+| `PRD` / `prd` / `需求文档` / `产品需求` | ①新建：读 `prd-standard-template.md` → 写 `docs/*/knowledge/00-需求/`；②增量：读 `prd-incremental-template.md` → 在已有PRD基础上追加/修改 | 🟡 P1 |
+| `Plan` / `plan` | **二段式**: ①先读 `{{magicDir}}/plans/index.md` 按 planName 匹配路径（P0 优先）；②无匹配才全局 glob 搜索 `*-plan-v*.md`。**禁止跳过 index.md 直接 glob** | 🔴 P0 |
+| `Spec` / `spec` | 查 `{{magicDir}}/specs/{name}/spec.md` | 🔴 P0 |
+| `Tasks` / `tasks` | 查 `{{magicDir}}/specs/{name}/tasks.md` | 🟡 P1 |
+| `Checklist` / `checklist` | 查 `{{magicDir}}/specs/{name}/checklist.md` | 🟡 P1 |
+| `Review` / `review` | **二段式**: ①先读 `{{magicDir}}/plans/index.md` 定位 plan → 查其关联 Review；②无匹配才全局 glob `*-review*.md` | 🔴 P0 |
+| `review-implementation` | 查 `{{magicDir}}/reviews/` 下 `*-review-implementation*.md` | 🟡 P1 |
+| `review-runtime` | 查 `{{magicDir}}/reviews/` 下 `*-review-runtime*.md` | 🟡 P1 |
+| `Handoff` / `handoff` / `交接` | **二段式**: ①先读 `{{magicDir}}/plans/index.md` 按 planName 匹配路径 → 定位 handoff；②无匹配才全局 glob `*-handoff*.md` | 🔴 P0 |
+| `add-route` / `执行路线图` | **二段式**: ①先读 `{{magicDir}}/plans/index.md` 定位 plan → 查其 add-route；②调 `check_add_route_status`；③无匹配才全局 glob | 🔴 P0 |
 | `devlog` / `开发日志` | **双触发**: ①用户说"devlog 记录下"→ 立即写；②Step 8 收敛通过 → 自动写（无需提醒）| 🔴 P0 |
-| `index.md` / `Plan索引` | 读 `.qoder/plans/index.md`（匹配依赖优先）。**当用户问及任何 doc 类型（Plan/Review/Handoff/add-route）但未给明确路径时，此条优先于上述所有 doc 类型触发词执行** | 🔴 P0 |
-| `gateway.md` / `gateway报告` / `运行时报告` | 读 `.qoder/reports/{{projectName}}-runtime-report/gateway.md` | 🟡 P1 |
-| `report-handoff` / `report交接` | 读 `.qoder/templates/report-handoff-template.md` | 🟡 P1 |
+| `index.md` / `Plan索引` | 读 `{{magicDir}}/plans/index.md`（匹配依赖优先）。**当用户问及任何 doc 类型（Plan/Review/Handoff/add-route）但未给明确路径时，此条优先于上述所有 doc 类型触发词执行** | 🔴 P0 |
+| `gateway.md` / `gateway报告` / `运行时报告` | 读 `{{magicDir}}/reports/{{projectName}}-runtime-report/gateway.md` | 🟡 P1 |
+| `report-handoff` / `report交接` | 读 `{{magicDir}}/templates/report-handoff-template.md` | 🟡 P1 |
 
 ---
 
@@ -132,7 +133,7 @@ LLM: "所有 checklist 项 [x]，RAHS ≥ 90，add-route 闭环。验收通过
 LLM: "所有 checklist 项 [x]，RAHS ≥ 90，add-route 闭环。验收通过！"
 
 ① 写 devlog日志(走mcp) → Edit handoff 写入验收记录（本轮改了什么 + 验收结果 + 遗留项）
-② 更新 handoff → Write(".qoder/plans/{date}/xxx-handoff-v1.md", "handoff 模板内容")
+② 更新 handoff → Write("{{magicDir}}/plans/{date}/xxx-handoff-v1.md", "handoff 模板内容")
 ③ 架构文档回看 → Read 相关 specs，确认文档不落后于代码
 
 [LLM 执行完以上三步后才算真正结束]
@@ -147,7 +148,7 @@ LLM: "让我搜索所有 plan 文件..." [全局 Grep 所有 *.md，慢且可能
 
 **正确输出**：
 ```
-LLM: "先查索引 → Read('.qoder/plans/index.md') 查找相关 Plan 条目"
+LLM: "先查索引 → Read('{{magicDir}}/plans/index.md') 查找相关 Plan 条目"
 [如有匹配 → 直接定位文件；无匹配 → 再用 Grep 全局搜索]
 ```
 
@@ -163,7 +164,7 @@ LLM 词汇匹配: "plan" 命中 → 第 19 行 → Glob("**/*-plan-v*.md") / fin
 **正确输出**：
 ```
 LLM 词汇匹配: "plan" 命中 → 第 19 行二段式:
-  ① Read('.qoder/plans/index.md') — 搜索 "three-tier-reasoning-graph"
+  ① Read('{{magicDir}}/plans/index.md') — 搜索 "three-tier-reasoning-graph"
      → 命中 06/29/{{projectName}}-three-tier-reasoning-graph-plan-v3.md
      → 命中 06/29/{{projectName}}-three-tier-reasoning-graph-handoff-v3.md
      → 命中 06/29/{{projectName}}-three-tier-reasoning-graph-add-route-v3.md
@@ -244,7 +245,7 @@ LLM: "验收通过 → 自动写 devlog日志(走mcp)（无需用户提醒）→
 > **消费者**: IDE 侧 LLM + 未来治理 AI
 > **设计意图**: 将 ADD 范式专有词汇和操作惯例预埋到 always-on 上下文中，使 LLM 听到触发词时零额外 prompt 执行正确操作。
 > **优先级**: P0 = 日常高频，LLM 必须本能响应；P1 = 开发流程频繁涉及，应预埋；P2 = 低频但易误解，可选预埋。
-> **维护**: 单一真值源，被 `.qoder/rules/project_rules.md` 和 `AGENTS.md` 引用。
+> **维护**: 单一真值源，被 `{{magicDir}}/rules/project_rules.md` 和 `AGENTS.md` 引用。
 
 ---
 
@@ -252,18 +253,19 @@ LLM: "验收通过 → 自动写 devlog日志(走mcp)（无需用户提醒）→
 
 | 优先级 | 触发词 | LLM 默认操作 |
 |:--:|------|-------------|
-| P0 | `index.md` / `Plan索引` / `看依赖` / `依赖哪个plan` / `看下计划` / `相关计划` / `某个plan` | **Plan 查询入口** — 先读 `.qoder/plans/index.md` 按 planName/主题精确匹配 plan 路径，无结果再全局搜索 |
-| P0 | `Plan` / `plan` | **二段式**: ①先读 `.qoder/plans/index.md` 按 planName 匹配路径；②无匹配才全局 glob。**index.md 优先** |
-| P0 | `Spec` / `spec` | 查 `.qoder/specs/{name}/spec.md` |
-| P1 | `Tasks` / `tasks` | 查 `.qoder/specs/{name}/tasks.md` |
-| P1 | `Checklist` / `checklist` | 查 `.qoder/specs/{name}/checklist.md` |
-| P0 | `Review` / `review` | **二段式**: ①先读 `.qoder/plans/index.md` 定位 plan → 读关联 Review；②无匹配才全局 glob |
-| P0 | `Handoff` / `handoff` / `交接` | **二段式**: ①先读 `.qoder/plans/index.md` 定位 plan → 读 handoff；②无匹配才全局 glob |
-| P0 | `add-route` / `执行路线图` | **二段式**: ①先读 `.qoder/plans/index.md` 定位 plan → 读 add-route；②调 `check_add_route_status`；③无匹配才全局 glob |
+| P0 | `PRD` / `prd` / `需求文档` / `产品需求` | ①新建：读 `prd-standard-template.md` → 写 `docs/*/knowledge/00-需求/`；②增量：读 `prd-incremental-template.md` → 在已有PRD基础上追加/修改 |
+| P1 | `增量更新 PRD` / `修改PRD` / `PRD变更` | 读 `prd-incremental-template.md` → 在原 PRD 上追加/修改/删除 |
+| P0 | `Plan` / `plan` | **二段式**: ①先读 `{{magicDir}}/plans/index.md` 按 planName 匹配路径；②无匹配才全局 glob。**index.md 优先** |
+| P0 | `Spec` / `spec` | 查 `{{magicDir}}/specs/{name}/spec.md` |
+| P1 | `Tasks` / `tasks` | 查 `{{magicDir}}/specs/{name}/tasks.md` |
+| P1 | `Checklist` / `checklist` | 查 `{{magicDir}}/specs/{name}/checklist.md` |
+| P0 | `Review` / `review` | **二段式**: ①先读 `{{magicDir}}/plans/index.md` 定位 plan → 读关联 Review；②无匹配才全局 glob |
+| P0 | `Handoff` / `handoff` / `交接` | **二段式**: ①先读 `{{magicDir}}/plans/index.md` 定位 plan → 读 handoff；②无匹配才全局 glob |
+| P0 | `add-route` / `执行路线图` | **二段式**: ①先读 `{{magicDir}}/plans/index.md` 定位 plan → 读 add-route；②调 `check_add_route_status`；③无匹配才全局 glob |
 | P0 | `devlog` / `开发日志` / `devlog记录` | **两种触发**: ①用户说即写 → 调用 `record_dev_operation` 落库审计 + 更新 handoff 的验收记录（本轮改了什么/验收结果/devlog查询语句/遗留项）；②Step 8 收敛通过后 → **必须自动写**（无需用户提醒） |
 | P0 | `增量更新` / `增量` / `incremental` / `修改文档` / `调整文档` | 修改已有 Plan/Spec/Review/handoff/task/checklist 文档时，**必须在原有内容基础上插入或扩展**，禁止删除已有内容后全量重写。具体：保留原文结构 → 插入新段落 → 更新修订时间 → 变更对照表标注增量范围 |
-| P1 | `review-implementation` | 查 `.qoder/reviews/` 下 `*-review-implementation*.md` |
-| P1 | `review-runtime` | 查 `.qoder/reviews/` 下 `*-review-runtime*.md` |
+| P1 | `review-implementation` | 查 `{{magicDir}}/reviews/` 下 `*-review-implementation*.md` |
+| P1 | `review-runtime` | 查 `{{magicDir}}/reviews/` 下 `*-review-runtime*.md` |
 | P1 | `计划` / `规划` | 同 `Plan`——二段式查 index.md → Plan 文件 |
 | P1 | `规格书` / `spec文档` | 同 `Spec`——查 specs/{name}/spec.md |
 | P1 | `任务清单` / `task列表` | 同 `Tasks`——查 specs/{name}/tasks.md |