add-coder 0.1.12 → 0.1.14

package/templates/core/specs/{farm-agent-add-coder-npm-package → add-coder-npm-package}/tasks.md

@@ -9,7 +9,7 @@
 
 ## Forbidden
 
-- 禁止修改 farm-agent 业务代码（`src/`、`docs/` 等）
+- 禁止修改 add-coder 业务代码（`src/`、`docs/` 等）
 - 禁止引入第三方模板引擎（Handlebars/EJS 等）
 - 禁止在模板代码中保留 `process.env.X || "兜底值"` 反模式
 
@@ -30,23 +30,23 @@
     - [x] 已有 `add.prisma` 时：交互三选一（跳过/覆盖/diff+备份）
 
 - [x] Task 1.1: 清理硬编码 + 参数化 core 模板 — 验证: `grep -r "farm.agent\|farm_secure_pass\|大田精准\|/home/xmm\|/Users/milkytea" templates/` 返回空
-  - [x] 15 个 `.md` 模板（plan/spec/tasks/checklist/handoff/review/add-route 等）：`docs/大田精准耕播智能决策系统/` → `{{docsDir}}/`、`farm-agent-*` → `{{projectName}}-*`
+  - [x] 15 个 `.md` 模板（plan/spec/tasks/checklist/handoff/review/add-route 等）：`docs/大田精准耕播智能决策系统/` → `{{docsDir}}/`、`add-coder-*` → `{{projectName}}-*`
   - [x] 15 个 `.schema.json`：检查确认无硬编码
-  - [x] `skills/add-paradigm/SKILL.md`：`/home/xmm/ai/farm-agent/` → `{{projectRoot}}/`
-  - [x] `skills/session-init/SKILL.md`：`farm-agent-*` → `{{projectName}}-*`
+  - [x] `skills/add-paradigm/SKILL.md`：`/home/xmm/ai/add-coder/` → `{{projectRoot}}/`
+  - [x] `skills/session-init/SKILL.md`：`add-coder-*` → `{{projectName}}-*`
   - [x] `agents/add-flow-guardian.md`：检查确认
   - [x] `agents/add-orchestrator.md`：检查确认
-  - [x] `rules/project_rules.md`：`farm-agent` → `{{projectName}}`、`src/agents/` → `{{sourceDir}}/agents/`
+  - [x] `rules/project_rules.md`：`add-coder` → `{{projectName}}`、`src/agents/` → `{{sourceDir}}/agents/`
   - [x] `rules/theory-practice-map.toml`：检查确认
   - [x] `vocabulary/add-governance-vocabulary.md`：检查确认
   - [x] `scripts/mcp-server.ts`：`DATABASE_URL || "postgresql://..."` → `process.env.DATABASE_URL`（无兜底值）、`.env.development` → `{{envFilePath}}`
   - [x] `scripts/add-coder-mcp-server.ts`：同上
-  - [x] `.qoder/settings.json`：hook 脚本绝对路径 → `{{projectRoot}}/.qoder/hooks/`
-  - [x] `.qoder/mcp.json`：`DATABASE_URL` 硬编码密码 → `process.env.DATABASE_URL`
-  - [x] `.qoder/sync-policy.json`：检查确认
-  - [x] `.qoder/hooks/` 下 14 个 `.sh` + `lib/`：项目名提取逻辑 → 使用 `$CLAUDE_PROJECT_DIR` 或 `{{projectRoot}}`
+  - [x] `{{magicDir}}/settings.json`：hook 脚本绝对路径 → `{{projectRoot}}/{{magicDir}}/hooks/`
+  - [x] `{{magicDir}}/mcp.json`：`DATABASE_URL` 硬编码密码 → `process.env.DATABASE_URL`
+  - [x] `{{magicDir}}/sync-policy.json`：检查确认
+  - [x] `{{magicDir}}/hooks/` 下 14 个 `.sh` + `lib/`：项目名提取逻辑 → 使用 `$CLAUDE_PROJECT_DIR` 或 `{{projectRoot}}`
   - [x] `.vscode/` 下 4 个文件：MCP 配置中的项目特定路径 → `{{projectRoot}}`
-  - [x] `reports/` 下 7 个文件：`farm-agent`、绝对路径 → `{{projectName}}`、`{{projectRoot}}`
+  - [x] `reports/` 下 7 个文件：`add-coder`、绝对路径 → `{{projectName}}`、`{{projectRoot}}`
   - [x] `tools/README.md`：检查确认
   - [x] 创建 `src/core/renderer.ts`：接收 config 对象，执行 `"{{key}}".replace("{{key}}", config.key)`
 
@@ -66,10 +66,10 @@
   - [x] 迁移 `scripts/` → `templates/core/scripts/`
   - [x] 迁移 `reports/` → `templates/core/reports/`
   - [x] 迁移 `tools/` → `templates/core/tools/`
-  - [x] 迁移 `.qoder/hooks/`（14 个 .sh + lib/） → `templates/adapters/qoder/hooks/`
-  - [x] 迁移 `.qoder/settings.json` → `templates/adapters/qoder/settings.json`
-  - [x] 迁移 `.qoder/mcp.json` → `templates/adapters/qoder/mcp.json`
-  - [x] 迁移 `.qoder/sync-policy.json` → `templates/adapters/qoder/sync-policy.json`
+  - [x] 迁移 `{{magicDir}}/hooks/`（14 个 .sh + lib/） → `templates/adapters/qoder/hooks/`
+  - [x] 迁移 `{{magicDir}}/settings.json` → `templates/adapters/qoder/settings.json`
+  - [x] 迁移 `{{magicDir}}/mcp.json` → `templates/adapters/qoder/mcp.json`
+  - [x] 迁移 `{{magicDir}}/sync-policy.json` → `templates/adapters/qoder/sync-policy.json`
   - [x] 迁移 `.vscode/`（4 个文件） → `templates/adapters/vscode/`
   - [x] 迁移 `debug-dump/`、`repowiki/` → `templates/shared/`（空目录占位）
   - [x] 创建 `templates/adapters/claude/` 目录（空壳）
@@ -100,7 +100,7 @@
     - [x] `doc-format-guard.sh`
   - [x] 实现 `src/adapters/claude/renderer.ts`
 
-- [x] Task 3.1: Qoder 适配器实现 — 验证: `npx add-coder init --adapter qoder` 生成正确的 `.qoder/` 目录
+- [x] Task 3.1: Qoder 适配器实现 — 验证: `npx add-coder init --adapter qoder` 生成正确的 `{{magicDir}}/` 目录
   - [x] 确认 `templates/adapters/qoder/` 下文件已清理 hardcode（第1轮 Task 1.1 已做）
   - [x] `settings.json` 的 matcher 适配：`Write|write_to_file|create_file|CreateFile` 等双套工具名
   - [x] 实现 `src/adapters/qoder/renderer.ts`
@@ -124,7 +124,7 @@
   - [x] `src/cli/commands/init.ts`：init 命令（七步流程：检测 IDE → 加载配置 → 渲染 core → 渲染 adapter → Prisma 注入 → 写入 → 摘要）
   - [x] `src/cli/commands/sync.ts`：sync 命令（只同步缺失文件）
   - [x] `src/cli/commands/status.ts`：status 命令（检查完整性）
-  - [x] `src/cli/detect.ts`：IDE 环境检测（扫描 `.qoder/` `.claude/` `.vscode/` 存在性）
+  - [x] `src/cli/detect.ts`：IDE 环境检测（扫描 `{{magicDir}}/` `.claude/` `.vscode/` 存在性）
   - [x] `src/cli/config-loader.ts`：配置加载 + Zod 校验 + 优先级合并（交互式 > 配置文件 > 自动检测 > 默认值）
   - [x] `src/cli/writer.ts`：智能写入（四种模式：交互 / `--yes` / `--force` / `--dry-run`）
   - [x] `bin/add-coder.js` 改为加载 `dist/cli/index.js`
@@ -195,7 +195,7 @@
 - [x] `grep -r "process.env.*||" dist/` 返回空
 - [x] `npx add-coder init` 在空白项目中零配置生成完整 ADD 模板
 - [x] `npx add-coder init --adapter claude` 生成 `.claude/` 目录
-- [x] `npx add-coder init --adapter qoder` 生成 `.qoder/` 目录
+- [x] `npx add-coder init --adapter qoder` 生成 `{{magicDir}}/` 目录
 - [x] `npx add-coder init --adapter vscode` 生成 `.vscode/` 目录
 - [x] `npm pack` 产出包含 `dist/` + `templates/` + `bin/`，不包含 `src/`
 - [x] `prisma migrate dev --schema=prisma/` 成功创建 DevOperation + AuditLog 表

package/templates/core/templates/01-/346/236/266/346/236/204//343/200/212ADD/345/274/200/345/217/221/345/267/245/344/275/234/350/267/257/345/276/204/344/270/216/346/226/207/346/241/243/345/215/217/345/220/214/350/247/204/350/214/203/343/200/213.md

@@ -21,9 +21,9 @@ ADD 不是"写代码时顺便打日志"，而是一套覆盖全开发周期的
 │            │  🚪 0.6.5 Review 结论回流至 Plan 与 Specs（强制卡位）               │
 │            │  🚪 0.7 原子闭包判定（Plan 级 + 轮次级）                           │
 │            │  产物：docs/*/knowledge/ 下的规划说明书、架构文档、规范文档           │
-│            │        .qoder/plans/{需求域名}-plan-v{n}.md                        │
-│            │        .qoder/plans/{需求域名}-add-route-v{n}.md                   │
-│            │        .qoder/reviews/{需求域名}-review-v{n}.md                    │
+│            │        {{magicDir}}/plans/{需求域名}-plan-v{n}.md                        │
+│            │        {{magicDir}}/plans/{需求域名}-add-route-v{n}.md                   │
+│            │        {{magicDir}}/reviews/{需求域名}-review-v{n}.md                    │
 │            │  阈值：check_dps（DPS ≥ 85 方可进入 Step 1）                        │
 ├────────────┼─────────────────────────────────────────────────────────────────┤
 │  Step 1    │  功能分析与审计阶段定义                                            │
@@ -42,8 +42,8 @@ ADD 不是"写代码时顺便打日志"，而是一套覆盖全开发周期的
 ├────────────┼─────────────────────────────────────────────────────────────────┤
 │  Step 3.5  │  实现审查（ADD-10 意图与实现的语义鸿沟）                              │
 │  实现审查   │  运行 spec checklist [T] 项 → 跨项目联调检查                         │
-│            │  产物：.qoder/reviews/{需求域名}-review-implementation-v{n}.md       │
-│            │        .qoder/reviews/{需求域名}-review-runtime-v{n}.md              │
+│            │  产物：{{magicDir}}/reviews/{需求域名}-review-implementation-v{n}.md       │
+│            │        {{magicDir}}/reviews/{需求域名}-review-runtime-v{n}.md              │
 ├────────────┼─────────────────────────────────────────────────────────────────┤
 │  Step 4    │  审计数据验证                                                      │
 │  审计验证   │  运行功能 → 收集审计数据 → check_phase_symmetry → check_failure_path │
@@ -89,7 +89,7 @@ ADD 流程中有四个强制卡位，在任何情况下都不可跳过：
 | **每轮原子闭包** | 不是按文件数量拆分，而是按"可独立提交、验证、审计、恢复"的最小业务闭包拆分 |
 | **人类评审节点** | 每轮 spec 必须经过人类 review（spec-review.md），AI 不擅自越过评审进入代码实现 |
 | **三件套不可跳过** | spec.md + tasks.md + checklist.md 三者齐备才能开始写代码 |
-| **日志代理用户 ID** | 所有 `AuditLog` 写入及业务表 `createdBy`/`createdById` 字段统一使用项目日志代理用户 ID 函数（禁止硬编码 `"system"` 等字符串）。详见 `.qoder/rules/project_rules.md` ADD-4 §日志代理用户 ID |
+| **日志代理用户 ID** | 所有 `AuditLog` 写入及业务表 `createdBy`/`createdById` 字段统一使用项目日志代理用户 ID 函数（禁止硬编码 `"system"` 等字符串）。详见 `{{magicDir}}/rules/project_rules.md` ADD-4 §日志代理用户 ID |
 | **四层审查** | 方案审查（ADD-9 方向验证）→ 实现审查（ADD-10 语义对齐）→ 运行时纠偏（ADD-11 证据持久化）→ 验收闭环（ADD-12 漂移校准），四道关卡覆盖全生命周期 |
 | **检查项 [T]/[R] 分拆** | checklist 中 [T] = 编译期可验证（AI 直接检查），[R] = 运行时验证（部署后确认，自动流转到 review-runtime.md）。[T] 全部通过时自动生成 review-runtime.md |
 | **跨对话接续** | 下一轮通过 `query_audit_logs` 恢复上游审计上下文，无需人类复述 |
@@ -125,12 +125,12 @@ ADD 不是万能范式。用错了阶段反而拖慢迭代速度。
 | `docs/哲学理论/` | 哲学理论基础文章 | 公开 |
 | `{{docsDir}}/` | 项目文档（需求/架构/规范） | 公开 |
 | `TODO/` | 开源协作 TODO，与 docs/ 平级 | 公开 |
-| `.qoder/plans/` | 需求方案 + 任务拆分 + 轮间交接手册 | 开发内部 |
-| `.qoder/reviews/` | 方案评审 + 逐轮 spec 评审 | 开发内部 |
-| `.qoder/specs/` | 每轮 spec + tasks + checklist（三件套） | 开发内部 |
-| `.qoder/rules/` | 项目规则文件（权威约束） | 开发内部 |
-| `.qoder/skills/` | SKILL 行为定义（AI 助手的标准行为模式） | 开发内部 |
-| `.qoder/scripts/` | 工具脚本 + MCP 服务器 | 开发内部 |
+| `{{magicDir}}/plans/` | 需求方案 + 任务拆分 + 轮间交接手册 | 开发内部 |
+| `{{magicDir}}/reviews/` | 方案评审 + 逐轮 spec 评审 | 开发内部 |
+| `{{magicDir}}/specs/` | 每轮 spec + tasks + checklist（三件套） | 开发内部 |
+| `{{magicDir}}/rules/` | 项目规则文件（权威约束） | 开发内部 |
+| `{{magicDir}}/skills/` | SKILL 行为定义（AI 助手的标准行为模式） | 开发内部 |
+| `{{magicDir}}/scripts/` | 工具脚本 + MCP 服务器 | 开发内部 |
 
 ### 目录层级决策原则
 
@@ -138,12 +138,12 @@ ADD 不是万能范式。用错了阶段反而拖慢迭代速度。
 公开可见 = docs/  + TODO/
           ↑ 面向社区、贡献者、学术引用者
 
-开发内部 = .qoder/
+开发内部 = {{magicDir}}/
           ↑ 面向 AI 助手 + 核心开发者（不影响外部用户克隆体验）
 ```
 
 - `TODO/` 与 `docs/` 平级而非嵌套在 `docs/` 下：TODO 是**行动清单**（"我们计划做什么"），docs 是**知识资产**（"我们做了什么、是什么"），语义不同不应混放
-- `plans/` + `reviews/` + `specs/` 三者都在 `.qoder/` 下：它们是 ADD 开发流程的产物，面向 AI 和开发者，不属于公开文档
+- `plans/` + `reviews/` + `specs/` 三者都在 `{{magicDir}}/` 下：它们是 ADD 开发流程的产物，面向 AI 和开发者，不属于公开文档
 - `plans/` 下同时放 plan + add-route + handoff：三者属于"需求理解与任务拆分"这个完整的大阶段，放在同一个目录保证阶段内文件的连续性
 
 ---
@@ -204,13 +204,13 @@ ADD 不是万能范式。用错了阶段反而拖慢迭代速度。
 ## 五、工作流三大阶段与目录映射
 
 ```
-需求理解 + 任务拆分  →  .qoder/plans/      （plan + add-route + handoff）
+需求理解 + 任务拆分  →  {{magicDir}}/plans/      （plan + add-route + handoff）
     │
     ↓
-评审                  →  .qoder/reviews/    （plan-review + roundN-spec-review）
+评审                  →  {{magicDir}}/reviews/    （plan-review + roundN-spec-review）
     │
     ↓
-Spec 执行             →  .qoder/specs/       （三件套：spec + tasks + checklist）
+Spec 执行             →  {{magicDir}}/specs/       （三件套：spec + tasks + checklist）
 ```
 
 每个阶段的产物只放在一个目录下，不在多个目录重复存放。
@@ -223,12 +223,12 @@ Spec 执行             →  .qoder/specs/       （三件套：spec + tasks + c
 
 | 阶段 | 文件 | 说明 |
 |------|------|------|
-| 需求方案 | `.qoder/plans/{{projectName}}-多轮对话能力专家链路优化统一状态管理-plan-v1.md` | 总体设计 |
-| 拆分拓扑 | `.qoder/plans/{{projectName}}-多轮对话能力专家链路优化统一状态管理-7轮原子事务拆分-add-route-v1.md` | 7 轮依赖拓扑 |
-| 方案评审 | `.qoder/reviews/{{projectName}}-多轮对话能力专家链路优化统一状态管理-方案评审-review-v1.md` | 可行性验证 |
-| 交接手册 | `.qoder/plans/{{projectName}}-多轮对话能力专家链路优化统一状态管理-7轮原子事务交接-handoff-v1.md` | 轮间输入输出 |
-| 第1轮 spec | `.qoder/specs/{{projectName}}-type-convergence-v1/` | 类型收敛三件套 |
-| 第1轮评审 | `.qoder/reviews/{{projectName}}-多轮对话能力专家链路优化统一状态管理-round1-类型收敛-thinkingLevel路由-spec-review-v1.md` | spec 人工 review |
+| 需求方案 | `{{magicDir}}/plans/{{projectName}}-多轮对话能力专家链路优化统一状态管理-plan-v1.md` | 总体设计 |
+| 拆分拓扑 | `{{magicDir}}/plans/{{projectName}}-多轮对话能力专家链路优化统一状态管理-7轮原子事务拆分-add-route-v1.md` | 7 轮依赖拓扑 |
+| 方案评审 | `{{magicDir}}/reviews/{{projectName}}-多轮对话能力专家链路优化统一状态管理-方案评审-review-v1.md` | 可行性验证 |
+| 交接手册 | `{{magicDir}}/plans/{{projectName}}-多轮对话能力专家链路优化统一状态管理-7轮原子事务交接-handoff-v1.md` | 轮间输入输出 |
+| 第1轮 spec | `{{magicDir}}/specs/{{projectName}}-type-convergence-v1/` | 类型收敛三件套 |
+| 第1轮评审 | `{{magicDir}}/reviews/{{projectName}}-多轮对话能力专家链路优化统一状态管理-round1-类型收敛-thinkingLevel路由-spec-review-v1.md` | spec 人工 review |
 | ... | ... | 第2-7 轮同理 |
 
 ---
@@ -237,7 +237,7 @@ Spec 执行             →  .qoder/specs/       （三件套：spec + tasks + c
 
 本文档内容同时体现在：
 
-- **`.qoder/rules/project_rules.md`** 中的 ADD-8 规则（权威约束，AI 助手强制执行）
+- **`{{magicDir}}/rules/project_rules.md`** 中的 ADD-8 规则（权威约束，AI 助手强制执行）
 - **`README.md`** 中的三、ADD 编程范式章节（面向外部读者的简明版本）
 - **本文档**（面向开发者的完整版本，包含案例和决策说明）
 
@@ -383,4 +383,4 @@ Step 8 收敛判断
 | `check_dps({ planKeyword })` | Step 0 末尾（进入 Step 1 前） | `"dps": { "enabled": true, "severity": "block", "threshold": 85 }` |
 | `check_rahs({ planKeyword })` | Step 4 末尾 + Step 8 收敛 | `"rahs": { "enabled": true, "severity": "block", "threshold": 90 }` |
 
-策略文件位于 `.qoder/sync-policy.json`，重型 add-route 模板已内置对应的 §0.8 / §4.6 闸门段落。
+策略文件位于 `{{magicDir}}/sync-policy.json`，重型 add-route 模板已内置对应的 §0.8 / §4.6 闸门段落。

package/templates/core/templates/TERMINOLOGY.md

@@ -1,7 +1,7 @@
 # ADD 模板术语权威规范
 
 > **定位**：项目所有 ADD 模板的术语唯一真相源。模板修改、守卫校验、LLM prompt 均以此为准。
-> **消费方**：16 个模板、`doc-format-guard.sh`、`pre-tool-use.sh`、`AGENTS.md`、`.qoder/hooks/lib/vocabulary.sh`
+> **消费方**：16 个模板、`doc-format-guard.sh`、`pre-tool-use.sh`、`AGENTS.md`、`{{magicDir}}/hooks/lib/vocabulary.sh`
 > **关联 Plan**：`{{projectName}}-add-template-standardization-plan-v1.md`
 
 ---

package/templates/core/templates/checklist-template.md

@@ -65,7 +65,7 @@
 > 当所有 `[T]` 编译期检查项均为 `[x]` 时（`[R]` 项可保持 `[ ]`），AI 必须执行：
 >
 > 1. **读取** `review-implementation-template.md`，逐项填写实现审查内容
-> 2. **读取** `review-runtime-template.md`，复制为 `.qoder/reviews/{project}-review-runtime.md`
+> 2. **读取** `review-runtime-template.md`，复制为 `{{magicDir}}/reviews/{project}-review-runtime.md`
 >    - 替换占位符（标题、关联文档路径）
 >    - §1 发现列表初始化为 "尚无运行时发现"
 >    - §1 末尾自动插入本 checklist 中所有 `[R]` 项的清单，标记为 "待运行时验证"

package/templates/core/templates/handoff-multi-round-template.md

@@ -51,7 +51,7 @@
 ### 交接手册与 spec 的优先级
 
 - 本 handoff 是新对话的入口索引，负责说明Round位置、上下游依赖、文件边界、高风险误区、恢复关键词和审计闭环。
-- 具体实现细节以对应 `.qoder/specs/{spec-name}/spec.md`、`tasks.md`、`checklist.md` 为准。
+- 具体实现细节以对应 `{{magicDir}}/specs/{spec-name}/spec.md`、`tasks.md`、`checklist.md` 为准。
 - 如果 handoff 摘要与 spec/tasks/checklist 存在颗粒度差异，以 spec/tasks/checklist 为准，不允许按 handoff 的简写自行简化实现。
 - 每轮完成后的 ADD-7 不只写入 `record_dev_operation`，还必须用 `query_audit_logs` 按 action/targetId/keyword 回查确认落库。
 
@@ -114,9 +114,9 @@ query_audit_logs({ keyword: "{ACTION_2}" })
 1. session-init SKILL（强制前置）
 2. query_audit_logs({})                                    → 查看最近所有操作
 3. query_audit_logs({ keyword: "{汇总关键词}" })            → 看本轮所有记录（应该返回 {N} 条）
-4. read ".qoder/specs/{spec-name}/spec.md"
-5. read ".qoder/specs/{spec-name}/tasks.md"
-6. read ".qoder/specs/{spec-name}/checklist.md"
+4. read "{{magicDir}}/specs/{spec-name}/spec.md"
+5. read "{{magicDir}}/specs/{spec-name}/tasks.md"
+6. read "{{magicDir}}/specs/{spec-name}/checklist.md"
 ```
 
 Step 3 搜索 `"{汇总关键词}"` 可以一次性拉取全部本轮审计记录，是最快的一键恢复方式。
@@ -127,9 +127,9 @@ Step 3 搜索 `"{汇总关键词}"` 可以一次性拉取全部本轮审计记
 
 ### spec 文件
 
-- `.qoder/specs/{spec-name}/spec.md`
-- `.qoder/specs/{spec-name}/tasks.md`
-- `.qoder/specs/{spec-name}/checklist.md`
+- `{{magicDir}}/specs/{spec-name}/spec.md`
+- `{{magicDir}}/specs/{spec-name}/tasks.md`
+- `{{magicDir}}/specs/{spec-name}/checklist.md`
 
 ### 架构文档
 
@@ -258,9 +258,9 @@ query_audit_logs({ keyword: "{汇总关键词}" })
 
 1. 执行 session-init SKILL
 2. 执行 add-paradigm SKILL（含 Step 0 文档先行）
-3. 读本轮对应 .qoder/specs/{spec-name}/spec.md（含其中的「文档先行三步闭环」章节，按 spec 的指示更新架构文档）
-4. 读本轮对应 .qoder/specs/{spec-name}/tasks.md
-5. 读本轮对应 .qoder/specs/{spec-name}/checklist.md
+3. 读本轮对应 {{magicDir}}/specs/{spec-name}/spec.md（含其中的「文档先行三步闭环」章节，按 spec 的指示更新架构文档）
+4. 读本轮对应 {{magicDir}}/specs/{spec-name}/tasks.md
+5. 读本轮对应 {{magicDir}}/specs/{spec-name}/checklist.md
 6. 按 tasks.md 顺序执行代码修改
 7. 每完成一个 Task：读 checklist.md → 逐项验证 → **附可验证证据** → 勾选
 8. 每完成一个文件修改：record_dev_operation 写入 ADD-7 审计

package/templates/core/templates/handoff-single-round-template.md

@@ -120,7 +120,7 @@ ORDER BY "createdAt" DESC;
 - grep 验证命令：
 
 ```bash
-grep -R "{关键字}" .qoder/specs/
+grep -R "{关键字}" {{magicDir}}/specs/
 ```
 
 ---

package/templates/core/templates/index.md

@@ -6,6 +6,8 @@
 
 **我要做…** | **用这个模板** | **为什么**
 --|--|--
+| 写产品需求文档 | `prd-standard-template.md` | 含 Plan 拆分建议 + 裁决层关联 |
+| 增量更新 PRD | `prd-incremental-template.md` | 在原 PRD 上追加/修改 |
 | 新建开发任务（需要架构设计） | `standard-plan-template.md` | 含方案选型、架构设计、依赖图，适合复杂改动（**默认**）
 | 新建开发任务（简单修复） | `simple-plan-template.md` | 内联 Handoff，无需独立 spec 文件（仅小修改/用户主动提）
 | 定义功能需求 | `spec-template.md` | Why/What/Impact/Requirements
@@ -20,12 +22,14 @@
 | 运行时评审 | `review-runtime-template.md` | 发现列表、流程改进
 | 写代码审查报告 | `report-template.md` | Issue 总览、分类统计
 | 写运行时异常报告 | `runtime-report-template.md` | 发现列表、关联 Issue
-| 写修复验证报告 | `fix-verification-template.md` | 逐条对照、修复趋势
+| 写修复验证报告 | `fix-verification-template.md` | 逐条对照、修复趋势 |
 
 ## 模板→Schema 索引
 
 | 模板 | Schema |
 |------|------|
+| `prd-standard-template.md` | `prd-standard-template.schema.json` |
+| `prd-incremental-template.md` | `prd-incremental-template.schema.json` |
 | `standard-plan-template.md` | `standard-plan-template.schema.json` |
 | `simple-plan-template.md` | `simple-plan-template.schema.json` |
 | `spec-template.md` | `spec-template.schema.json` |

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` | {与本文档的关系} |