@hupan56/wlkj 3.1.32 → 3.3.0

package/templates/qoder/skills/spec-generator/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: spec-generator
 description: "从已确认的 PRD 自动生成开发 Spec 文档（技术规格说明）。Auto-generate development Spec documents from confirmed PRDs. "
-trigger: "user invokes /wl-* command explicitly"
+trigger: "被 /wl-spec 内部调用(实现层)"
 ---
 
 
@@ -28,21 +28,46 @@ PY=$(python --version >/dev/null 2>&1 && echo python || echo python3)
   再 `$PY "$R/.qoder/scripts/foundation/core/paths.py" whoami`（输出开发者名；空=未初始化）。
   ⚠️ 勿用裸相对路径 `.qoder/.developer`（QoderWork 桌面端 cwd 不在仓库根，会读不到而误报未初始化）。
 - **活动任务**：当前任务（决定 spec 存到哪个 task 目录）。读法 `$PY "$R/.qoder/scripts/foundation/core/paths.py" current-task`（输出任务路径；空=无活动任务）。
-- 扫描 PRD 来源目录：`data/docs/prd/`（已发布）+ `workspace/members/{dev}/drafts/REQ-*.md`（草稿）
+- 扫描 PRD 来源目录：`data/docs/prd/`（已发布）+ PRD 所在的 REQ-ID 容器
+  （`workspace/members/{dev}/{drafts|outputs}/{YYYY}/{MM}/{Ww}/{REQ-ID}/`，用 `find_req_dirs` 跨桶查找）
   找出还没有对应 Spec 的 PRD
 - 风格/字段参考：`$PY "$R/.qoder/scripts/orchestration/wlkj.py" search --field <字段名>` 查现有字段命名约定
 - 团队 Java 约定（MyBatis Plus + RESTful + BigDecimal 金额）写在本 skill 的 Step 3
 
-## Step 1: 定位 PRD
+## Step 1: 定位 PRD（优先禅道 task，本地兜底）
+
+**核心：1 禅道 task ↔ 1 spec。PRD 真源是 task 关联的 story**（本地找不到别人提的 PRD 时，从禅道 story 读）。
+
+### 优先级 1：从禅道 task 读（解决"别人提的 PRD 本地没有"）
 
 ```bash
-# 列出已发布的 PRD
-ls data/docs/prd/REQ-*.md
-# 列出当前开发者的草稿 PRD
-ls workspace/members/{developer}/drafts/REQ-*.md
+# 当前活动任务（panel / /wl-task 指向的禅道 task）
+TASK=$($PY "$R/.qoder/scripts/foundation/core/paths.py" current-task)   # 或直接给 task_id
+```
+
+走 MCP 读 task → story：
+```python
+cap.mcp.call("get_task", {"task_id": 1453})          # 拿 task 详情，取 story 字段
+cap.mcp.call("get_story_detail", {"story_id": 761})   # 读 story.spec 字段 = PRD 数据源
 ```
+story.spec 即 PRD 正文（验收标准/字段/操作）。**本地无该 PRD 文件也能生成 spec。**
 
-找出"有 PRD 但无 Spec"的需求。如果有多份，问用户先做哪个。
+### 优先级 2：本地 PRD 兜底
+
+```bash
+# task 无 story 关联，或禅道不可达 → 扫本地
+ls data/docs/prd/REQ-*.md                                          # 已发布
+$PY "$R/.qoder/scripts/foundation/core/paths.py" whoami            # 取开发者
+# 草稿在 REQ-ID 容器: workspace/members/{DEV}/{drafts|outputs}/{桶}/{REQ-ID}/
+```
+跨桶找某 REQ：复用 `paths.find_req_dirs(req_id, DEV)`。
+
+### 决定
+
+找出"要生成 spec 的目标"后：
+- **禅道 task 来的**：spec 主标识用 `task_id`，契约头写 `zentao: task=X story=Y`，第 0 章"禅道关联"填实。
+- **本地 PRD 来的**：用 REQ-ID，`zentao:` 留空（后续 panel 回填 task 时补）。
+- 多份候选时问用户先做哪个。
 
 ## Step 2: 读取上下文
 
@@ -57,41 +82,73 @@ cap.mcp.call("context_pack", {"keyword": "..."}) <PRD里的模块关键词> --pl
 
 ### 同时并发补这几项（与 context_pack 无依赖，同回合并发）
 
-1. **PRD 文件**（必需）：需求源
-2. **历史 Spec**（推荐）：扫 `workspace/specs/` 看同类需求的写法，照着写
-3. **真实表结构**（强烈推荐）：context_pack 不含 DB schema，写 API 字段前单独查
+1. **PRD 数据源**（必需）：禅道 task 来的 = Step 1 读到的 story.spec；本地来的 = PRD 文件
+2. **spec 模板**（必需）：`$R/.qoder/templates/spec-template.md` —— **必须读它，照它的 6 章骨架逐节填，不自由发挥结构**
+3. **历史 Spec**（推荐）：扫 PRD 同容器或历史 REQ-ID 容器看同类需求的写法，照着写
+4. **真实表结构**（强烈推荐）：context_pack 不含 DB schema，写 API 字段前单独查
    - 先 `cap.mcp.call("list_envs", {})` 问环境，再 `query_schema(table='quality_case', db='fywl_ics_quality')`
    - 拿到真实列名/类型/注释（注释里常含枚举定义，如"0=小时,1=工作日"）
 
 > 数据字典 `data/docs/constitution/` 如存在顺手读，不存在跳过。
-> 以上 PRD/历史Spec/query_schema 三项相互独立 → **同一条消息并发发**，不要逐个等。
+> 以上 PRD源/模板/历史Spec/query_schema 四项相互独立 → **同一条消息并发发**，不要逐个等。
+
+## Step 3: 照模板分析（不自由发挥结构）
 
-## Step 3: 分析并生成
+**核心：读 `templates/spec-template.md` 的 6 章骨架，逐章节填空。** 不是从零生成结构。
 
-从 PRD 提取：
-- 每个用户故事 → 一个或多个 API 接口
-- 验收标准 → 接口入参/出参/错误场景
-- 数据需求 → 数据库表设计
-- 非功能性需求 → 约束章节
+从 PRD 提取并填入对应章节：
+- 每个用户故事 → 第 1 章一个或多个 API 接口
+- 验收标准 → 第 1 章入参/出参 + 第 3 章异常场景 + 第 5 章测试用例
+- 数据需求 → 第 2 章表设计（表名 `t_{module}_{entity}`，金额 BigDecimal）
+- **第 3 章异常矩阵 ★强制**：每个操作**系统性枚举所有失败场景**（参数/业务/权限/并发/外部依赖/数据不存在/边界值），这是写代码前必须想清楚的，不可遗漏
+- **第 4 章 AI 边界 ★强制**：明确划分 ✅可自动 / ⚠️必须人工确认 / 🚫禁止AI做
+- **第 5 章测试用例 ★强制**：每条 PRD 验收标准 ≥1 个用例，输入/预期/断言齐全
+- 第 6 章映射表：每条 PRD acceptance → 对应接口/数据/异常/用例，保证可追溯不漏
+
+★强制章节不适用时写"无"并附原因（例：纯查询页异常章写"无（仅查询，校验由前端处理）"）。
 
 ## Step 4: 输出
 
-写到 `workspace/specs/REQ-{ID}-{module}.spec.md`（或 task 目录 `workspace/tasks/{task-id}/spec.md`）
+**存储位置（按来源二选一）**：
+
+- **禅道 task 来的**（1 task ↔ 1 spec）：`workspace/tasks/{task_id}/spec.md`（复用现有 task 目录，task_id 即禅道 task id）
+- **本地 PRD 来的**：跟着 PRD 同容器，`workspace/members/{dev}/{drafts|outputs}/{YYYY}/{MM}/{Ww}/{REQ-ID}/REQ-{ID}-{module}.spec.md`
+  （复用 `paths.get_req_dir` / `find_req_dirs`，跨时间桶可查）
+
+**契约头**（status 初始为 draft；禅道来的带 zentao 字段）：
+```markdown
+<!-- @contract spec v1
+source-req: REQ-2025-0042
+platform: web
+module: policy
+endpoints: [POST /api/policy/amend, GET /api/policy/amend/{id}]
+status: draft
+zentao: task=1453 story=761
+-->
+```
+> `zentao:` 字段：禅道 task 来的必须填（task+story）；本地来的留空，待 panel 回填 task 时补。
+
+> 兜底：若本地 PRD 不在时间桶容器（老 PRD 在 `data/docs/prd/`），spec 写到 `workspace/specs/REQ-{ID}-{module}.spec.md`（向后兼容）。
 
-规则：
-- 每条 PRD 验收标准都映射到一个 Spec 测试用例
+规则（模板已固化，这里只强调重点）：
+- 每条 PRD 验收标准都映射到一个 Spec 测试用例（第 6 章）
 - API 路径遵循 RESTful 约定
 - 表名遵循 `t_{module}_{entity}`
 - 金额字段必须用 `BigDecimal`
 - 不写 PRD 未定义的功能
 - Entity → Mapper → Service → Controller 全栈结构
 
-## Step 5: 通知
+## Step 5: 通知并提交确认
 
-报告给被分配的开发者评审。
+生成后 `status: draft`。报告给被分配的开发者评审：
+1. 展示 spec 全文 + 列出关键决策点（接口设计 / 表结构 / 异常枚举 / AI 边界）
+2. 提示：可直接修改 spec 文件（路径见输出），改完告知
+3. **⚠️ status 保持 draft，不要自动改 confirmed** —— 用户在 `/wl-code` 的 spec gate 确认后才升级
+4. **不在此回填禅道** —— spec 回填禅道 task 的 `desc` 由 `/wl-code` 在用户确认后做（见 wl-code Step 1），本 skill 只负责生成
 
 ## 触发条件
 
 - 手动：用户说"生成 Spec"、"写技术规格"、"/wl-spec"
 - 任务驱动：PRD 评审通过后，下一步通常就是生成 Spec
+- `/wl-code` gate：无 spec 或 status≠confirmed 时，`/wl-code` 自动调本 skill 生成 draft
 - 子 agent：可被 prd-generator 在 PRD 确认后调度

package/templates/qoder/skills/test-generator/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: test-generator
 description: "从已实现代码和 Spec 自动生成单元测试。Auto-generate unit tests from implemented code and Spec. 需用户确认（DANGEROUS）。"
-trigger: "user invokes /wl-* command explicitly"
+trigger: "被 /wl-test quick模式内部调用(实现层)"
 ---
 
 

package/templates/qoder/skills/wl-code/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: wl-code
 description: "按开发 Spec 严格实现代码（/wl-code 命令入口）。Implement code following a Spec strictly. 需用户确认（DANGEROUS）。"
-trigger: "user invokes /wl-* command explicitly"
+trigger: "用户显式打 /wl-code; 或自然语言"写代码""实现这个功能""按spec开发"。需确认"
 ---
 
 
@@ -53,6 +53,18 @@ cap.mcp.call("context_pack", {"keyword": "..."}) <模块关键词> --platform <w
    - 拿真实列名/类型/注释（含枚举定义），别靠推断。
    - [QAS环境] 表结构与生产一致可放心用。
 
+### 排查/修 bug 类先对齐链路（kg 取证，1-2 步定位，禁止空转假设）
+
+> 遵守 wl-pipeline 规则 2.6：取证优先用 kg（`cap.mcp.call`），**不许"假设A→假设B→假设C"连环空转**。
+
+| 场景 | 对齐链路 | kg 先取证 | 最常见根因 |
+|------|---------|----------|-----------|
+| 后端报错/类型异常 | 前端格式→BO→Entity→DB列 | `query_schema`(DB列类型) + `context_pack`(BO/Entity文件) | String/Date/Long 不一致 |
+| 接口不通/400 | 路由→Controller→Service→Mapper→SQL | `code-api`(路由/参数) + `table_impact`(影响面) | 参数名不匹配/缺@RequestBody |
+| 前端白屏/NaN | 组件→API→响应→字段映射 | `context_pack`(组件/API) + `field_map`(字段映射) | null未处理/字段名拼错 |
+
+kg 取证后 Read 命中文件找**不一致点**，定位即动手，**别发散推理**。
+
 ## 执行
 
 1. **加载 Spec**：按 REQ-ID 找 spec；没参数就读 `.qoder/.current-task`

package/templates/qoder/skills/wl-commit/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: wl-commit
 description: "代码提交 + push + 同步，带质量门禁。Git commit + push + sync with pre-commit quality gate. 需用户确认（DANGEROUS）。"
-trigger: "user invokes /wl-* command explicitly"
+trigger: "用户显式打 /wl-commit; 或自然语言"提交代码""commit"。需确认"
 ---
 
 

package/templates/qoder/skills/wl-design/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: wl-design
-description: "设计工序入口: import 录入设计稿→spec.json(默认) / generate 按设计spec出原型 / review 评审原型。"
-trigger: "user invokes /wl-* command explicitly"
+description: "设计工序站: 预览(蓝湖稿→HTML预览,默认) / 扫描(看现有系统页面组件风格) / 评审(检查原型是否用系统真源)。"
+trigger: "用户显式打 /wl-design; 或自然语言"出原型""设计稿""预览设计""扫描页面风格""
 ---
 
 
@@ -28,12 +28,12 @@ PY=$(python --version >/dev/null 2>&1 && echo python || echo python3)
 
 | 用户说 | 模式 | 走哪个 skill |
 |--------|------|-------------|
-| "录入设计稿""Figma稿录入""把这个设计录入" | **import**（默认） | design-import |
-| "按设计出原型""按设计师规范出原型" | **generate** | prototype-generator |
-| "评审原型""设计稿看一下""检查交互稿" | **review** | design-review |
+| "预览""出预览""蓝湖链接""看看设计稿" 或 含 lanhuapp.com | **预览**（默认） | design-import |
+| "扫描""看系统""有哪些页面""什么风格" | **扫描** | 看现有系统页面/组件/风格 |
+| "评审""检查""合规""颜色对不对" | **评审** | design-review |
 | 模糊 | 先问意图 | — |
 
-默认 import（最常见入口）。
+默认 预览（最常见入口）。
 
 ## ⚙️ 自取上下文（Quest / QoderWork 无 hook 注入，必须自读）
 

package/templates/qoder/skills/wl-init/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: wl-init
 description: "初始化/切换开发者身份 + 环境体检。Initialize/switch developer identity + environment health check. "
-trigger: "user invokes /wl-* command explicitly"
+trigger: "用户显式打 /wl-init; 身份初始化"
 ---
 
 
@@ -63,7 +63,7 @@ $PY "$R/.qoder/scripts/orchestration/wlkj.py" doctor --fix
 
 ## 输出规则
 
-- 体检完打印一句总结：「环境健康，可以开始工作：/wl-prd-full <需求>」或「N 个问题待修，加 --fix 自愈」
+- 体检完打印一句总结：「环境健康，可以开始工作：/wl-prd <需求>」或「N 个问题待修，加 --fix 自愈」
 - 如果用户没给名字但 `.developer` 不存在：先问"你叫什么名字？角色是 pm/dev/design？"
 - 如果 git user.name 与开发者名不一致：在体检里 `[WARN]` 提示，`--fix` 会自动改
 

package/templates/qoder/skills/wl-insight/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: wl-insight
-description: "需求探索 + 外部调研 + 未来规划。流水线的'上游探索站'，负责发现需求、对标竞品、做 Gap 分析和 roadmap。把'该做什么、为什么做'想清楚，结论交给 /wl-prd-full 落地。"
-trigger: "user invokes /wl-* command explicitly"
+description: "需求上游探索站。默认澄清(产品听不懂时对焦,必要时出原型帮理解); discover(发现机会) / research(调研竞品) / plan(规划roadmap)。说'转PRD'落地。"
+trigger: "用户显式打 /wl-insight; 或自然语言需求澄清(产品听不懂时)"
 ---
 
 
@@ -38,7 +38,7 @@ insight（探索/调研/规划）→ [用户确认转PRD] → prd（落地）→
 ```
 
 **insight 不产 PRD，不画原型，不分配 REQ-ID。** insight 的产出是**洞察报告**（.md）。
-报告写完，提示用户"要把某个机会转成 PRD 吗？" → 是 → 自动进 `/wl-prd-full` 参考模式（mode: reference）。
+报告写完，提示用户"要把某个机会转成 PRD 吗？" → 是 → 自动进 `/wl-prd` 参考模式（mode: reference）。
 
 ---
 
@@ -154,12 +154,12 @@ OST     ├─ Opportunity（用户机会/痛点）─ discover ──┤  → i
 insight 报告末尾**永远**给一句：
 
 ```
-要把握住哪个机会？说"转 PRD"我把它作为现状输入，进 /wl-prd-full 参考模式落地成可执行 PRD。
+要把握住哪个机会？说"转 PRD"我把它作为现状输入，进 /wl-prd 参考模式落地成可执行 PRD。
 ```
 
 用户说"转 PRD"或指定某个机会 → 触发：
 ```
-/wl-prd-full 参考：{报告路径}#{机会编号}
+/wl-prd 参考：{报告路径}#{机会编号}
 ```
 prd 以 reference 模式（mode: reference）承接，读取 insight 报告作为现状背景，走"轻反思+批量确认"流程落地。
 

package/templates/qoder/skills/wl-prd/SKILL.md

@@ -0,0 +1,60 @@
+---
+name: wl-prd
+description: "需求: 完整(13章,新功能) / 快速(6章,小改动) / 评审(检查质量)。默认根据描述自动判断。先问平台！"
+trigger: "用户显式打 /wl-prd; 或自然语言'写需求''写PRD''这个需求怎么做'。⚠️铁律: 只要用户打了/wl-prd,不管描述含'报错/无法/bug'(如'养护计划无法提交,时间报错'这种修复型小需求),都必须走本skill产出PRD,绝不跨命令跑去/wl-test"
+---
+
+
+## 🔧 仓库根定位（QoderWork 桌面端 vs Qoder IDE/CLI）
+
+**后续脚本里的 `$R` 代表仓库根**，先确定它（QoderWork 桌面端工作目录不是仓库根，相对路径会失效）：
+```bash
+R=$(python ~/.qoderwork/repo_root.py 2>/dev/null || python3 ~/.qoderwork/repo_root.py 2>/dev/null) || R=.
+PY=$(python --version >/dev/null 2>&1 && echo python || echo python3)
+```
+> `repo_root.py` 从 `~/.qoderwork/mcp.json` 反推仓库根；失败回退 `.`（IDE/CLI 工作目录即仓库根）。找不到时先跑 `$PY "$R/.qoder/scripts/orchestration/wlkj.py" install-qw`。
+
+# wl-prd — 需求工序站（/wl-prd 命令入口）
+
+> 这是 `/wl-prd` 命令的 skill 入口（桥接 QoderWork 的 `/` 列表）。
+> 完整工作流见同名 command 文件 `.qoder/commands/wl-prd.md`，
+> 完整/快速模式实现见 `.qoder/skills/prd-generator/SKILL.md`，
+> 评审模式实现见 `.qoder/skills/prd-review/SKILL.md`。
+> **第一性原理：又快又准。**（快=并行+砍模式，准=语义归档+质量锁）
+> **定位：专注"已确定需求"的落地。** 探索/调研/规划/对标已移交 `/wl-insight`。
+
+## ⚠️ STEP 0: 必须先问平台（任何分析前，绝不自动判断）
+
+```
+这个需求是针对哪个平台？
+1. Web 管理端 (fywl-ui) - Ant Design Vue + VxeGrid 风格
+2. APP 移动端 (Carmg-H5) - Vant 风格
+3. 两端都要
+请选择 (1/2/3):
+```
+问完就停。平台未定时任何分析都是违规。
+
+## 🚦 三模式路由（看第一个词或描述特征）
+
+| 用户说 | 模式 | 走哪个 |
+|--------|------|--------|
+| "完整""深度""正经需求" 或 含"新模块/新业务/新流程" | **完整** | prd-full-template（13 章）+ EVA |
+| "快速""小改动""加个""改下" 或 加字段/按钮/文案/导出 | **快速** | prd-quick-template（6 章），不走 EVA |
+| "评审""检查""质量""合格吗" 或 给了 PRD 路径 | **评审** | 7 项 checklist + EVA 评分 |
+| 判断不了 | **问一句**：完整需求(新功能)还是小改动(加字段/按钮)？ |
+
+> 默认：没说模式 + 像新功能 → 完整；像小改动 → 快速；给了文件 → 评审。
+
+---
+
+## 详细流程
+
+完整的三模式流程（取上下文 / 产出路径 / 原型要不要画 / 质量门禁 / 埋点）
+**全部在 command 文件** `.qoder/commands/wl-prd.md`，本桥接不重复（避免臃肿/双源不同步）。
+
+调用时直接读 command 文件按所选模式执行即可。
+
+## 🔗 上游衔接
+
+- 来自 `/wl-insight` 的调研结论：`/wl-prd 参考:<报告路径>`
+- 衔接 `/wl-task`：PRD 发布后由 `/wl-task create` 落成任务

package/templates/qoder/skills/wl-report/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: wl-report
-description: "生成日报/周报，严格按当前开发者隔离。Generate daily/weekly work report, isolated by current developer. "
-trigger: "user invokes /wl-* command explicitly"
+description: "日报/周报,按当前开发者隔离。默认日报(今天); 说'周报'出本周。数据源: 任务+禅道工时+提交+PRD+日历(可选增强)。"
+trigger: "用户显式打 /wl-report; 或自然语言"写日报""周报""
 ---
 
 

package/templates/qoder/skills/wl-search/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: wl-search
 description: "查代码/业务/API/字段/PRD + 知识图谱(影响分析/覆盖矩阵/功能画像/业务流程/多跳遍历)的唯一入口。"
-trigger: "user invokes /wl-* command explicitly"
+trigger: "用户显式打 /wl-search; 代码/业务/API搜索专用"
 ---
 
 

package/templates/qoder/skills/wl-spec/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: wl-spec
-description: "从已确认 PRD 生成开发 Spec 文档（/wl-spec 命令入口）。Generate or review technical Spec from PRD + Design. "
-trigger: "user invokes /wl-* command explicitly"
+description: "从已确认 PRD 生成开发 Spec(技术规格)。默认生成; 带 review 评审现有 spec。/wl-code 按此 spec 实现。"
+trigger: "用户显式打 /wl-spec; PRD→技术规格"
 ---
 
 

package/templates/qoder/skills/wl-status/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: wl-status
-description: "项目状态/路线图/健康度。Project status: current sprint / roadmap / health score. "
-trigger: "user invokes /wl-* command explicitly"
+description: "项目状态看板。current(当前迭代进度,默认) / roadmap(路线图) / health(健康度,含工作流采纳分)。说哪个看哪个。"
+trigger: "用户显式打 /wl-status; 或自然语言"项目状态""健康度""路线图""
 ---
 
 

package/templates/qoder/skills/wl-task/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: wl-task
-description: "任务管理 + RICE 优先级 + 依赖排期。7 站流水线的'任务'站，产品在这里把 PRD 落成任务。Task management with RICE prioritization. "
-trigger: "user invokes /wl-* command explicitly"
+description: "任务管理 + 禅道同步。把 PRD 落成任务、看我的活、改状态、记工时(本地+禅道双写)。动作词: 建任务/我的任务/开始/完成/归档。自然语言问'我的Bug''看#301'直连禅道回答。"
+trigger: "用户显式打 /wl-task; 或自然语言"建任务""我的任务""开始任务""完成任务"。注意:"我的Bug/看需求#301"等禅道查询直接答不走本skill"
 ---
 
 
@@ -222,7 +222,7 @@ cap.mcp.call("sync", {"direction": "push"})
 ## 输出规则
 
 - `list` 结果用表格呈现（优先级 | 状态 | 任务 | 负责人 | 标题 | 备注），当前任务标 `*`
-- `create` 后告诉用户任务目录路径 + 下一步建议（"接 /wl-prd-full 写需求" 或 "/wl-code 写代码"）
+- `create` 后告诉用户任务目录路径 + 下一步建议（"接 /wl-prd 写需求" 或 "/wl-code 写代码"）
 - `finish` 后提示是否归档 + 看下个 `--ready` 的任务
 - 任何脚本非 0 退出 → 原样转述错误，不吞
 

package/templates/qoder/skills/wl-test/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: wl-test
-description: "测试工作流: 意图式用例 + Playwright MCP 执行 + 锚点缓存。触发: /wl-test 命令; 或自然语言里带'功能验证点'(如'测一下XX支不支持YY''验一下XX能不能ZZ''XX对不对')。纯随手看('打开XX页''看看登录')→不走本工作流。需确认(DANGEROUS)。"
-trigger: "user invokes /wl-* command explicitly"
+description: "测试: quick(意图式用例,默认) / browser(Playwright浏览器) / unit(单元) / coverage(测试覆盖矩阵)。触发: /wl-test 命令; 或自然语言带'功能验证点'(如'测一下XX支不支持YY')。需确认(DANGEROUS)。"
+trigger: "用户显式打 /wl-test; 或自然语言带功能验证点('测一下XX支不支持YY''验一下XX能不能ZZ')。⚠️边界: '写需求/写PRD'→/wl-prd; '报错/bug/无法提交'若是写需求场景→/wl-prd不归本skill; 纯排查bug不走任何wl工作流"
 ---
 
 # wl-test — 测试工作流（/wl-test 命令 或 带功能验证点的自然语言触发）

package/templates/qoder/templates/spec-template.md

@@ -0,0 +1,124 @@
+# REQ-{YYYY}-{NNN} {需求标题} - 开发规格
+
+<!-- @contract spec v1
+source-req: REQ-2025-0042
+platform: web
+module: policy
+endpoints: [POST /api/policy/amend, GET /api/policy/amend/{id}]
+status: draft
+zentao: task=1453 story=761
+-->
+
+> ⚙️ **如何用本模板**：spec-generator 读本文件**逐章节填空**，不自由发挥结构。
+> - 所有 **★强制** 章节必须填；不适用写"无"并附原因。
+> - 生成时 `status: draft`；经 `/wl-code` 的 spec gate **用户确认**后改为 `status: confirmed` 才可写码。
+> - **禅道对接**：`zentao:` 字段标识本 spec 对应的禅道 task（1 task ↔ 1 spec）。
+>   PRD 数据源 = task 关联的 story（经 `get_task → get_story_detail` 读，本地无 PRD 也能生成）；
+>   确认后 spec 摘要回填该 task 的 `desc`。
+> - 模块契约（输入/输出/校验）：`.qoder/contracts/spec.md`
+> - 团队技术约定：Java MyBatis Plus + RESTful + `BigDecimal` 金额 + JSR-303 + `Result<T>`；
+>   表名 `t_{module}_{entity}`；全栈 Entity→Mapper→Service→Controller；不写 PRD 未定义的功能。
+
+---
+
+## 0. 概述
+
+- **禅道关联**：task #{task_id} ← story #{story_id}（PRD 真源 = 该 story 的 spec 字段）
+- **需求来源**：REQ-{ID}（本地有 PRD 则链回；禅道 task 来的若无本地 PRD，标注"源=禅道 story #{story_id}"）
+- **本次改动一句话**：{用一句话说清本次交付什么——读 spec 的人 5 秒内能懂}
+- **涉及端**：{web / app / both}
+- **PRD 验收标准条数**：{N 条}（映射见第 6 章，必须逐条覆盖，不可漏）
+- **改动范围**：{新增 / 修改 / 删除了哪些模块文件，一句话}
+
+---
+
+## 1. 接口定义
+
+> 每个接口一行。RESTful + JSR-303 校验 + `Result<T>` 包装返回。
+> 无后端接口（纯前端/纯数据）写："无（本次纯 {前端组件/数据脚本}）"。
+
+| 方法 | 路径 | 说明 | 入参(关键字段) | 出参 | 错误码 |
+|------|------|------|----------------|------|--------|
+| POST | /api/{module}/{action} | {用途} | {field: Type} | Result<{DTO}> | 见第3章 |
+| GET | /api/{module}/{id} | {用途} | {id: Long} | Result<{DTO}> | 见第3章 |
+
+**入参校验（JSR-303）**：逐接口列出必填/格式约束。
+- `POST /api/{module}/{action}`：`{name @NotBlank(max=64), amount @NotNull @DecimalMin("0.01")}`
+
+---
+
+## 2. 数据结构
+
+> 表名 `t_{module}_{entity}`；金额字段**一律 BigDecimal**，禁用 double/float。
+> 无 DB 改动写："无（复用现有表，无 DDL）"。
+
+### t_{module}_{entity}  {— 用途说明}
+
+| 字段 | 类型 | 约束 | 说明 |
+|------|------|------|------|
+| id | BIGINT | PK, AUTO | 主键 |
+| {field} | VARCHAR(64) | NOT NULL | {含义} |
+| amount | DECIMAL(18,2) | NOT NULL | 金额，BigDecimal 映射 |
+
+**全栈结构**：`Entity(t_xxx) → Mapper(XxxMapper) → Service(XxxService) → Controller(XxxController)`
+
+---
+
+## 3. 异常处理矩阵 ★强制
+
+> **每个操作**枚举**所有**失败场景，不遗漏。这是写代码前必须想清楚的，不是写完补的。
+> 必须覆盖这些维度：参数校验失败 / 业务规则违反 / 权限 / 并发重复 / 外部依赖失败 / 数据不存在 / 边界值(0/空/超长/超大)。
+> 不适用写"无"并说明原因（例如纯展示页可写"无（仅查询，校验由前端处理）"）。
+
+| 操作 | 失败场景 | 错误码 | HTTP | 处理策略 |
+|------|----------|--------|------|----------|
+| {POST /api/x} | 参数缺失/格式错 | 40001 | 400 | JSR-303 拦截 → Result.fail(字段提示) |
+| {POST /api/x} | 业务规则违反 | 40901 | 409 | Service 校验 → Result.fail(原因) |
+| {POST /api/x} | 数据不存在 | 40404 | 404 | Result.fail("记录不存在") |
+| {POST /api/x} | 权限不足 | 40301 | 403 | Result.fail("无权限") |
+| {POST /api/x} | 重复提交/并发 | 40902 | 409 | 唯一索引拦截 → 提示已存在 |
+| {POST /api/x} | 边界: amount=0/超大 | 42201 | 422 | 前置校验拦截 |
+| {POST /api/x} | 外部依赖失败 | 50001 | 500 | 捕获 → 降级/重试 + 日志 |
+
+---
+
+## 4. AI 能力边界 ★强制
+
+> 明确划分三类，防止 AI 越界或该确认的不确认。**禁止 AI 做的**绝不能放进 `/wl-code` 执行清单。
+
+| 类别 | 范围 | 本次涉及项 |
+|------|------|-----------|
+| ✅ AI 可自动完成 | 标准 CRUD、模板代码、照 spec 填实现 | {例：Entity/Mapper/Service/Controller 全栈、Vue 表单页} |
+| ⚠️ 必须人工确认 | 有业务风险或不可逆的决策 | {例：DDL 建表/改表、删除类操作、金额计算逻辑、对接第三方} |
+| 🚫 禁止 AI 做 | 无授权或不该自动化的 | {例：直连生产库改数据、删生产数据、绕过权限校验、臆造 PRD 没有的字段/接口} |
+
+---
+
+## 5. 测试用例 ★强制
+
+> **每条 PRD 验收标准** → 至少一个用例。必须详细可复现（输入/预期/断言齐全），验收标准不漏一条。
+
+| 用例ID | 对应验收(见第6章) | 输入 | 预期 | 断言 |
+|--------|-------------------|------|------|------|
+| TC-001 | AC-1 | {合法完整入参} | 200 + Result.success | 状态码=200 且 data.id 非空 |
+| TC-002 | AC-1 | {非法: 缺必填字段} | 400 + 40001 | 状态码=400 |
+| TC-003 | AC-1 | {边界: amount=0} | 422 + 42201 | 状态码=422 |
+| TC-004 | AC-2 | {...} | {...} | {...} |
+
+---
+
+## 6. PRD 验收标准映射表
+
+> 每条 PRD acceptance 映射到本 spec 的接口/数据/异常/用例，**保证可追溯、不漏**。
+> 这是 /wl-code 完工自检的依据：每条 AC 都有实现着落。
+
+| PRD 验收标准 | 对应接口(§1) | 数据(§2) | 异常(§3) | 测试用例(§5) |
+|--------------|--------------|----------|----------|--------------|
+| AC-1 {验收点原文} | POST /api/x | t_xxx | 场景行 | TC-001~003 |
+| AC-2 {验收点原文} | ... | ... | ... | ... |
+
+---
+
+> 生成者：spec-generator（基于 `templates/spec-template.md`）
+> 状态流转：`status: draft` → 用户确认 → `status: confirmed` → `/wl-code` 放行写码
+> 禅道回填：confirmed 后，spec 摘要（接口清单/关键表/异常/AC 映射）+ 本地路径 → 回填禅道 task `desc`

package/templates/root/AGENTS.md

@@ -15,6 +15,18 @@
 
 ---
 
+## ⚠️ CRITICAL RULE #0: COMMAND ROUTE IS FINAL (highest priority, overrides memory/preferences)
+
+**When user explicitly types `/wl-X`, you MUST route to X. NEVER reroute.** This overrides any "user preference", "memory", "context hint", or your own assumption. The command name IS the final route; description content (even bug-sounding) does not change it.
+
+- User types `/wl-prd` (even if the description sounds like a bug: "无法提交，时间报错") → **MUST run PRD** (this is writing a requirement for the fix). **NEVER** reroute to `/wl-test`, `/wl-code`, or debugging.
+- User types `/wl-code` → run code. `/wl-test` → run tests. `/wl-task` → run task. (same for every command)
+- If routing is genuinely unclear → **ask the user one question**, do NOT guess from "preferences" or "memory".
+
+> 🚫 Failure case (forbidden, real): user typed `/wl-prd 快速，园林绿化养护计划无法提交，时间有问题报错`, AI rerouted to `/wl-test quick` based on a hallucinated "memory that user prefers wl-test for bugs". → VIOLATION. The command was `/wl-prd`; a bug-sounding description still goes to PRD. `wl-prd.md` lists this exact example as forbidden.
+
+---
+
 ## ⚠️ CRITICAL RULE #1: ALWAYS ASK PLATFORM FIRST
 
 **When user asks for PRD or prototype, you MUST ask this question FIRST:**
@@ -108,11 +120,11 @@ app/mobile/h5/移动端 -> Carmg-H5
 | Command | 工序站 | 模式参数（第一个词路由） | Auto | 背后 skill |
 |---------|--------|------------------------|------|-----------|
 | `/wl-init` | 身份 | （无） | YES | wl-init |
-| `/wl-prd` | 需求 | 语义路由: 完整档/小改动/评审 (原 wl-prd-full/quick/review 合并) | YES | prd-generator/prd-review |
-| `/wl-design` | 设计 | `import`/`generate`/`review` 或默认(import) | YES | design-import/prototype-generator/design-review |
-| `/wl-task` | 任务 | `create`/`list`/`start`/`finish` | YES | wl-task |
+| `/wl-prd` | 需求 | 语义路由: 完整/快速/评审 (原 wl-prd-full/quick/review 已合并) | YES | prd-generator/prd-review |
+| `/wl-design` | 设计 | `预览`/`扫描`/`评审` 或默认(预览) | YES | design-import/prototype-generator/design-review |
+| `/wl-task` | 任务 | `create`/`list`/`show`/`start`/`finish`/`archive`/`rank`/`plan` | YES | wl-task |
 | `/wl-code` | 编码 | （无，按 spec 实现） | NO | spec-coder |
-| `/wl-test` | 测试 | `quick`/`browser`/`unit` 或默认(quick) | NO | wl-test / test-generator |
+| `/wl-test` | 测试 | `quick`/`browser`/`unit`/`coverage` 或默认(quick) | NO | wl-test / test-generator |
 | `/wl-commit` | 提交 | （无） | NO | wl-commit |
 
 ### Optional Commands（长大了再开，非执行链路必经）
@@ -178,21 +190,20 @@ Style priority: Code > PDF > Default
 **独立性**：每个模块认文件不认流程。缺上游 → 手动喂个契约文件，或用自然语言 +
 `context_pack.py` 让 AI 自检索补全（见 `.qoder/contracts/fallback.md`）。
 
-## Qoder 全系列兼容（IDE / Quest / CLI / QoderWork）
+## Qoder 系列兼容（Desktop / QoderWork）
 
 This pipeline works on Windows + macOS, across the **whole Qoder family**.
 Each product loads rules from a different carrier — keep them in sync:
 
-| 产品/模式 | 规则载体 | 命令载体 |
-|-----------|---------|---------|
-| Qoder IDE 默认编辑器 | .qoder/rules/wl-pipeline.md (always_on) | .qoder/commands/wl-*.md |
-| Qoder Quest 模式 | .qoder/rules/ + .qoder/skills/ + .qoder/agents/ | 自然语言 -> skills |
-| Qoder CLI (qodercli) | 本文件 AGENTS.md | 自然语言 -> scripts |
-| QoderWork 桌面 Agent | 安装 .qoder/skills/ 下的技能 | 自然语言 -> skills |
+| 产品 | 定位 | 规则载体 | 命令载体 |
+|-----------|------|---------|---------|
+| Qoder Desktop/IDE 1.0（含 Quest 模式）| 主开发宿主 | .qoder/rules/wl-pipeline.md + .qoder/skills/ + .qoder/agents/ | .qoder/commands/wl-*.md；Quest 走自然语言→skills |
+| QoderWork 桌面 Agent | 办公（非开发者）| 安装 .qoder/skills/ 下的技能 | 自然语言→skills；~/.qoderwork/ 投影 |
 
-> 本流水线聚焦 Qoder 全系列，4 种载体功能等价。知识图谱 17 个能力（影响分析/
-> 覆盖矩阵/功能画像/业务流程/多跳遍历…）通过统一 CLI `python .qoder/scripts/domain/kg/kg.py`
-> 全系列触达；QoderWork 环境也可直接调 MCP 工具。
+> 本流水线聚焦 Qoder 系列（主开发 Desktop + 办公 QoderWork），载体功能等价。知识图谱 17 个能力
+> （影响分析/覆盖矩阵/功能画像/业务流程/多跳遍历…）通过统一 CLI
+> `python .qoder/scripts/domain/kg/kg.py` 全系列触达；Desktop/QoderWork 环境也可直接调 MCP 工具。
+> （Qoder CLI / Cloud Agents 后续按需对接。）
 
 ## QoderWork Integration: Optional Enhancement Only (Progressive Enhancement)
 
@@ -230,6 +241,22 @@ Each product loads rules from a different carrier — keep them in sync:
 code files + page examples + field specs + PRDs + APIs + style/icon pointers
 in ONE call. Use it FIRST; fall back to search_index.py for drill-down.
 
+## Thinking Discipline (思考链收敛 — 治"超长思考链")
+
+**痛点：AI 取证了（读了代码）却没抓住矛盾，在假设上连续空转，15+ 步才定位 3 步能找到的根因。**
+本段**只约束排查/修码/取证类**推理；探索/规划/写 PRD 类（feature/workflow/coverage/context 撒网理解业务）不受约束，反而要多用 kg。
+
+1. **先取证再推理（铁律）**：每个推断立刻验证，**不许"假设A→假设B→假设C"连环空转**；一轮工具调用 = 一轮推理，不许"无工具调用的纯思考"超 1 轮。
+2. **取证优先用知识层**（比 grep 快 10 倍，与 Fast Path 一脉相承）：
+   - 代码文件 → `context_pack`（**别** grep 全库）/ 字段类型 → `query_schema`·`field_map`（**别** Read 整个 Entity）/ 波及面 → `table_impact`（**别** 手动追踪）/ API → `code-api`（**别** grep Controller）
+   - kg 给了文件才 Read 那几个；kg 给了类型就不读全文。**kg 用得更准，不是闲置。**
+3. **排查/修码先对齐链路**（1-2 步对齐再动手；kg 一次对齐多环）：
+   - 后端类型异常：`query_schema`(DB列) + `context_pack`(BO/Entity) → 找类型不一致点（String vs Date 最常见根因）
+   - 接口不通/400：`code-api`(路由/参数) + `table_impact`(影响面)
+   - 前端白屏/NaN：`context_pack`(组件/API) + `field_map`(字段映射)
+
+> 正例：`query_schema`=Date + `context_pack` BO=String → 改BO（2步） ｜ 反例：假设null→Invalid Date→时区→disabledDate→…（15步空转，养护计划实录）
+
 ## Icons: NEVER emoji
 
 Prototypes use the projects' real icon systems (data/index/icon-reference.json):