@zhuan-ai/zhuanspec 2.17.15 → 2.19.2

package/dist/core/templates/skill-templates.js

@@ -239,7 +239,7 @@ export function getApplyChangeSkillTemplate() {
 
    **Handle states:**
    - If \`state: "blocked"\` (missing artifacts): show message, suggest using zhuanspec-continue-change
-   - If \`state: "all_done"\`: proceed to code review step (see step 8)
+   - If \`state: "all_done"\`: show completion status and suggest running \`zhuanspec review <change-id>\`
    - Otherwise: proceed to implementation
 
 4. **Read context files**
@@ -276,41 +276,21 @@ export function getApplyChangeSkillTemplate() {
    - Error or blocker encountered → report and wait for guidance
    - User interrupts
 
-   ### Wave 完成后检查
-   每个 Wave 的所有任务执行完毕后：
-   1. 运行编译检查确保无错误
-   2. 验证跨任务的接口一致性
-   3. 如有 tc-implementation-verify Skill，运行 TC 覆盖快照
-   4. 所有检查通过后才进入下一 Wave
+   After implementation, run checks that are relevant to the files changed in this session.
+   Fix failures before marking the related task complete.
 
 7. **On completion or pause, show status**
 
    Display:
    - Tasks completed this session
    - Overall progress: "N/M tasks complete"
-   - If all done: proceed to code review step (step 8)
+   - If all done: suggest running \`zhuanspec review <change-id>\`
    - If paused: explain why and wait for guidance
 
-8. **三轨并行审查门禁（auto, once after all tasks complete）**
+8. **Review handoff**
 
-   **WHEN** all tasks are complete (\`state: "all_done"\`):
-
-   1. 并行执行三条轨道（not per task, only once after all tasks complete）：
-      - 轨道 A（CR）：invoke \`code-review-expert\` skill.
-      - 轨道 B（UT）：invoke \`generate-mockito-unit-test-skill\` 并执行测试命令.
-      - 轨道 C（Spec-Code）：run \`zhuanspec validate <change-id> --strict\` 并确认 \`spec-code-consistent\` 通过.
-
-   2. 汇总执行一次 \`zhuanspec review <change-id>\` 产出统一报告。
-
-   3. Gate criteria:
-      - Review PASSED and Critical = 0.
-      - Unit tests PASSED.
-      - Spec-Code consistency PASSED.
-      - Coverage meets threshold when configured.
-
-   4. If gate fails:
-      - Fix issues, rerun tests/strict validation, rerun \`zhuanspec review\`.
-      - Do not proceed to archive until gate passes.
+   When all tasks are complete, do not run review automatically in apply.
+   Tell the user to run \`zhuanspec review <change-id>\` for full validation before archive.
 
 **Output During Implementation**
 
@@ -340,7 +320,7 @@ Working on task 4/7: <task description>
 - [x] Task 2
 ...
 
-All tasks complete! Ready for code review or archive.
+All tasks complete! Run \`zhuanspec review <change-name>\` before archive.
 \`\`\`
 
 **Output After Code Review (Issues Found)**
@@ -1363,7 +1343,7 @@ export function getOpsxApplyCommandTemplate() {
 
    **Handle states:**
    - If \`state: "blocked"\` (missing artifacts): show message, suggest using \`/opsx:continue\`
-   - If \`state: "all_done"\`: proceed to code review step (see step 8)
+   - If \`state: "all_done"\`: show completion status and suggest running \`zhuanspec review <change-id>\`
    - Otherwise: proceed to implementation
 
 4. **Read context files**
@@ -1405,29 +1385,13 @@ export function getOpsxApplyCommandTemplate() {
    Display:
    - Tasks completed this session
    - Overall progress: "N/M tasks complete"
-   - If all done: proceed to code review step (step 8)
+   - If all done: suggest running \`zhuanspec review <change-id>\`
    - If paused: explain why and wait for guidance
 
-8. **三轨并行审查门禁（auto, once after all tasks complete）**
-
-   **WHEN** all tasks are complete (\`state: "all_done"\`):
-
-   1. 并行执行三条轨道（not per task, only once after all tasks complete）：
-      - 轨道 A（CR）：invoke \`code-review-expert\` skill.
-      - 轨道 B（UT）：invoke \`generate-mockito-unit-test-skill\` 并执行测试命令.
-      - 轨道 C（Spec-Code）：run \`zhuanspec validate <change-id> --strict\` 并确认 \`spec-code-consistent\` 通过.
-
-   2. 汇总执行一次 \`zhuanspec review <change-id>\` 产出统一报告。
-
-   3. Gate criteria:
-      - Review PASSED and Critical = 0.
-      - Unit tests PASSED.
-      - Spec-Code consistency PASSED.
-      - Coverage meets threshold when configured.
+8. **Review handoff**
 
-   4. If gate fails:
-      - Fix issues, rerun tests/strict validation, rerun \`zhuanspec review\`.
-      - Do not proceed to archive until gate passes.
+   When all tasks are complete, do not run review automatically in apply.
+   Tell the user to run \`zhuanspec review <change-id>\` for full validation before archive.
 
 **Output During Implementation**
 
@@ -1457,7 +1421,7 @@ Working on task 4/7: <task description>
 - [x] Task 2
 ...
 
-All tasks complete! Ready for code review or archive.
+All tasks complete! Run \`zhuanspec review <change-name>\` before archive.
 \`\`\`
 
 **Output After Code Review (Issues Found)**

package/dist/core/templates/slash-command-templates.js

@@ -6,12 +6,13 @@ const baseGuardrails = `**约束条件**
 - **知识库参考**：开始任何阶段前，先检查 \`zhuanspec/knowledge/\` 目录。使用 \`rg "[关键词]" zhuanspec/knowledge/\` 搜索相关陷阱和最佳实践，避免重复踩坑。阅读 \`zhuanspec/knowledge/index.md\` 了解项目级知识摘要。
 - **工程代码检索顺序**：凡是需要检索工程代码、配置类、数据模型类或关键实现位置时，必须先调用 \`@skill:load-project-knowledge\` 进行渐进式加载，使用返回的 search_priority 限定检索范围，按优先路径定位代码。Skill 返回的 \`matched_services[].micro_path\` 即各服务 \`.project-wiki/\` 下的知识条目路径，按需读取其中子文档（无论 Skill 内部走 llmwiki 还是 project.md 路径，最终内容均来自各服务的 \`.project-wiki/\`）。仅当 Skill 无匹配结果时，才回退到 \`grep/glob/ls\`。
 - **需求来源读取（红线，全阶段适用）**：读取需求来源（技术方案输入、测试 case、验收标准等）时，按链接类型选用对应读取方式，禁止张冠李戴：
-  * **大神页面**（\`zhuanspirit\` 大神文档 / \`--dashen-page-id\` / \`--dashen-url\`）：用大神 MCP 工具（如 \`mcp__dashen__getPageContent\`）读取。
   * **zzcase 测试用例**（\`zzcase.zhuanspirit.com/plan/taskDetail/module/{moduleId}/task/{taskId}\`）：从 URL 提取 \`moduleId\`，用 \`mcp__caseweb__GET_get2\` 读取。
-  * **飞书链接**（\`project.feishu.cn/{space}/story/detail/{id}\` 需求工作项、\`xxx.feishu.cn/wiki/{token}\`、\`xxx.feishu.cn/docx/{id}\` 文档）：**禁止用 Fetch/WebFetch 直接抓取飞书网页**（会被安全域名校验拦截而失败），必须用本机飞书 CLI \`lark-cli\` 读取正文（通过 Bash 调用；不确定子命令时先执行 \`lark-cli --help\` 确认用法）。若 lark-cli 未安装/未授权/读取失败，如实报告失败原因与用户需处理的动作（安装 \`npm install -g @larksuite/cli\` 或执行 \`lark-cli auth login\` 授权），不要编造需求内容。
+  * **飞书文档/需求链接**（\`xxx.feishu.cn/wiki/{token}\`、\`xxx.feishu.cn/docx/{id}\`、\`project.feishu.cn/{space}/story/detail/{id}\`）：必须使用飞书 CLI \`lark-cli\` 读取正文。**禁止用 Fetch/WebFetch 直接抓取飞书网页**（会被安全域名校验拦截而失败）。通过 Bash 调用飞书 CLI；不确定子命令时先执行 \`lark-cli --help\` 确认用法。若 lark-cli 未安装/未授权/读取失败，如实报告失败原因与用户需处理的动作（安装 \`npm install -g @larksuite/cli\` 或执行 \`lark-cli auth login\` 授权），不要编造需求内容。
 - 如果需要额外的 ZhuanSpec 约定或澄清，请参考 \`zhuanspec/AGENTS.md\`（位于 \`zhuanspec/\` 目录内 - 如果看不到，请运行 \`ls zhuanspec\` 或 \`zhuanspec update\`）。`;
-const proposalGuardrails = `${baseGuardrails}\n- **强制澄清要求**：在创建任何提案文件之前，必须首先分析用户请求，识别所有不确定或模糊的方面（范围、技术选择、优先级、验收标准等）。如果发现任何模糊之处，必须停止并使用**选项式交互**（如 \`AskQuestion\` 工具）提问，获得明确答复后才能继续。严禁在不确定的情况下自行推测、假设或创建提案。严禁要求用户手动输入大段文字来回答澄清问题。
-- 识别任何模糊或歧义的细节，使用带预设选项的选择题在编辑文件之前询问必要的后续问题。
+const proposalGuardrails = `${baseGuardrails}\n- **输入来源优先级（硬规则）**：开始 Proposal 时先确定输入来源，顺序为：① 用户本次命令中明确提供的需求描述/文档链接/--tech-spec；② 当前已有 phase=techDesign 的 change 且 \`techDesign/tech-spec.md\` 存在并非空；③ 用户历史对话中明确给出的需求描述。命中 ① 或 ② 时必须直接继续生成提案，不得先回复“请提供需求描述或技术方案”。
+- **TechDesign 复用优先**：如果当前已有 phase=techDesign 的 change，并且存在 \`zhuanspec/changes/<change-id>/techDesign/tech-spec.md\` 且内容非空，必须把该文件作为技术方案来源，自动复用该 change 继续生成 proposal/design/tasks。此时不得重复询问“是否有技术方案 / 请提供需求描述 / 需求来源是什么”。
+- **强制澄清要求**：在创建任何提案文件之前，必须首先分析已确定的输入来源，识别所有不确定或模糊的方面（范围、技术选择、优先级、验收标准等）。如果已有可用的 \`techDesign/tech-spec.md\`，只澄清技术方案内部仍然缺失或矛盾的信息；不得把“用户本次命令没有再写需求”当作模糊点。如果没有可用输入来源，或者输入来源本身不足以生成提案，才使用**选项式交互**（如 \`AskQuestion\` 工具）提问，获得明确答复后继续。严禁要求用户手动输入大段文字来回答澄清问题。
+- 识别任何模糊或歧义的细节，使用带预设选项的选择题在编辑文件之前询问必要的后续问题；已有可用 techDesign 技术方案时，不得把“需求来源未显式提供”当作模糊点。
 - 在提案阶段不要编写任何代码。先完成 techDesign（需求技术方案）后再创建 proposal/specs/tasks，实施在批准后的应用阶段进行。
 - **TechDesign 目录识别**：proposal 阶段扫描 changes/ 目录，通过 progress.json 的 phase 字段识别 techDesign 目录，**自动复用**（无需询问用户）。复用时按优先级查找技术方案：① 用户通过 --tech-spec 指定的外部路径 ② changes/<name>/techDesign/tech-spec.md，找到后作为提案输入上下文。
 - **Phase 自动更新**：复用 techDesign 目录时，自动运行 \`zhuanspec progress set-phase <change-id> propose\` 更新 phase。`;
@@ -34,11 +35,11 @@ const proposalOutputFormat = `**输出格式要求**
 4. **验证结果** - validate --strict 输出`;
 const applyOutputFormat = `**输出格式要求**
 - 每个任务完成后：\`[x] Task N.M - [完成描述]\`
-- Wave 完成后：\`Wave N 完成 - [任务列表]\`
 - 最终输出包含：
   1. **实施摘要** - 完成的任务数量、修改的文件
-  2. **偏差检测结果** - 是否有偏离提案范围的修改
-  3. **下一步建议** - Review 阶段或继续任务`;
+  2. **检查结果** - 运行过的编译/测试命令及结果
+  3. **未完成/阻塞项** - 如无则写“无”
+  4. **下一步建议** - 运行 \`zhuanspec review <change-id>\` 或继续剩余任务`;
 const reviewOutputFormat = `**输出格式要求**
 - 每轨完成后：\`[轨名称] ✅ PASS / ❌ FAIL - [关键指标摘要]\`
 - 四轨顺序串行输出汇总格式：
@@ -75,7 +76,7 @@ const proposalSteps = `**步骤**
    - **TechDesign 目录识别**：
      * 扫描 changes/ 目录下的所有变更
      * 检查每个变更的 metrics/progress.json 的 phase 字段
-     * 如果存在 phase=techDesign 的目录，**直接复用该目录，无需询问用户**，并输出提示："techDesign 阶段已提前创建提案目录，直接复用该目录"
+     * 如果存在 phase=techDesign 的目录，**直接复用该目录，无需询问用户**。必须立即读取该目录下的 \`techDesign/tech-spec.md\`，并输出提示："techDesign 阶段已提前创建提案目录，我将直接读取现有技术方案并生成提案"。禁止只回复“请提供需求描述或技术方案”。
      * 如果存在多个 phase=techDesign 目录，复用最新创建的目录
      * 如果不存在 phase=techDesign 目录，创建新目录
    - **技术方案定位（多源）**：
@@ -99,8 +100,9 @@ const proposalSteps = `**步骤**
      * 基于 tdd-testcase-generator 输出，创建 \`changes/<change-id>/test-cases.md\`
      * tasks.md 中使用 \`@test-case:TC-XXX\` 标签关联（来源为 tdd-testcase-generator 输出的 TC 编号）
      * ⚠️ Skill 完成后**继续步骤 2（澄清检查）**，不得停留
-   - **如果不存在 techDesign 测试 case 源文件（原流程）**：
-     在进行任何澄清、设计或编写任何提案文件之前，使用 AskQuestion 工具询问用户：
+   - **如果不存在 techDesign 测试 case 源文件**：
+     * 如果步骤 0 已复用可用的 \`techDesign/tech-spec.md\`：默认按非 TDD 模式继续，直接在 tasks.md 记录“暂不提供测试 case / TDD 禁用”，不得因为缺少测试 case 停下来询问。
+     * 如果步骤 0 没有可用技术方案，才在进行任何澄清、设计或编写任何提案文件之前，使用 AskQuestion 工具询问用户：
    - 选项 A：提供测试 case（有现成 case，走 TDD 模式）
    - 选项 B：暂不提供测试 case
    - 选项 C：其他（请在后续补充说明）
@@ -147,6 +149,7 @@ const proposalSteps = `**步骤**
    未完成此 checkpoint 记录之前，禁止执行步骤 2 及后续任何文件写入操作。
 
 2. **强制澄清检查（必须首先执行，不可跳过）**：
+   - 如果步骤 0 已经读取到可用的 \`techDesign/tech-spec.md\`，则该文件就是需求来源和技术方案来源；不得再询问“是否有技术方案 / 请提供需求描述”。只检查技术方案内容本身是否存在影响生成提案的缺口或矛盾。
    - 仔细分析用户请求，识别所有不确定或模糊的方面：
      * 范围是否明确？（边界、包含/排除的内容）
      * 技术选择是否明确？（框架、库、架构模式）
@@ -722,9 +725,55 @@ ${baseGuardrails}
 - **Rules 和 Knowledge 注入**：编排 Agent MUST 在每个 subagent prompt 中注入 Rules（根据 @skill）和 Knowledge（踩坑警告、最佳实践）。
 - **偏差处理**：PreToolUse Hook 检测到提案范围外修改时弹出选项式交互（更新提案/Bug修复豁免/取消）。3次偏差后强制更新提案。
 - **⚠️ 纠偏处理（红线，禁止委派 subagent）**：当 \`progress.json\` 中 \`correctionContext.active === true\` 时，主 agent **必须亲自处理所有代码修改**，**严禁**将纠偏任务分发给 subagent（applyAgent/tddApplyAgent）。原因：(1) 纠偏代码修改必须走主 agent 的 PostToolUse hook 才能正确计入 \`userCorrectionLines\`；(2) subagent 无法感知纠偏上下文，可能扩大修改范围。违反此约束将导致准确率数据丢失。
-- **correctionContext 写入时序**：\`resolve-correction\` CLI 写入 \`correctionContext\` 后，主 agent 必须在**修改任何代码之前**确认标记已写入（检查 progress.json 中 \`correctionContext.active === true\`），确保后续的 PostToolUse hook 能将修改行数路由到 \`userCorrectionLines\`。`;
+- **correctionContext 写入时序**：\`resolve-correction\` CLI 写入 \`correctionContext\` 后，主 agent 必须在**修改任何代码之前**确认标记已写入（检查 progress.json 中 \`correctionContext.active === true\`），确保后续的 PostToolUse hook 能将修改行数路由到 \`userCorrectionLines\`。
+- **Wave 间连续执行（红线）**：每个 Wave 完成并生成集成测试报告后，必须立即自动推进到下一个 Wave，禁止在 Wave 之间停下来询问用户"是否继续 / 要开始下一个 Wave 吗 / Wave N 已完成，是否继续"这类无需决策的确认。只有 Wave 集成报告整体状态为 FAIL 且无法自行修复，或出现真正的范围/依赖决策时才暂停。此约束与 lightweightApply 的连续执行红线同等优先级，优先于基础模型"做完一段就停下来确认"的默认倾向。`;
 const applyReferences = `**参考**
 - 如果在实施过程中需要提案的额外上下文，请使用 \`zhuanspec show <id> --json --deltas-only\`。`;
+// Keep apply lightweight, but fix local build/type/import breakage before moving on.
+const lightweightApplySteps = `**步骤**
+将 Apply 阶段聚焦为代码实施，不在本阶段执行完整审查门禁。
+
+1. **确认 change 和 Phase**
+   - 如果指令中没有明确 change-id，先运行 \`zhuanspec list\` 找到目标 change。
+   - 运行 \`zhuanspec progress show <change-id>\` 确认当前 phase。
+   - 如果 phase 不是 \`apply\`，运行 \`zhuanspec progress set-phase <change-id> apply\`。
+
+2. **读取实施上下文**
+   - 阅读 \`zhuanspec/changes/<change-id>/proposal.md\`。
+   - 阅读 \`zhuanspec/changes/<change-id>/design.md\`（如果存在）。
+   - 阅读 \`zhuanspec/changes/<change-id>/tasks.md\`，只处理未完成的 \`- [ ]\` 任务。
+   - 需要更多上下文时，再使用 \`zhuanspec show <change-id> --json --deltas-only\` 或定向读取相关 spec。
+
+3. **直接实施未完成任务（连续执行，不中途请示）**
+   - 默认由当前 Agent 直接改代码，不强制 Wave 并行，不强制启动 subagent。
+   - **连续执行**：一次性把所有未完成任务做完，任务之间不要停下来问"是否继续 / 要不要接着做下一个 / 已完成当前任务，继续下一个吗"。只有遇到以下情况才暂停：范围或依赖真正不明确、需要用户做产品/技术决策、或出现无法自行修复的阻塞。除此之外持续推进到全部任务完成。
+   - **修复类任务必须自验证**：凡是修复 bug 或纠正错误行为的任务，代码修改完成后必须主动运行相关检查（单测/类型检查/编译/lint）验证修复生效，不得以"代码已修改"为由结束任务；检查不通过则继续修复直至通过，或明确说明阻塞原因。
+   - \`@depends\` 只作为建议顺序参考：先做依赖少、改动底层的任务，再做上层调用和界面任务。
+   - \`@skill:<name>\` 只作为能力提示：当任务确实匹配且 skill 可用时再调用。
+   - 不要用占位实现假装完成。
+   - 如果当前实现刚引入了编译、类型或导入报错，先修到这一步能过，再继续后面的任务。
+
+4. **运行相关检查**
+   - 优先运行与本次改动相关的单测、类型检查或编译命令。
+   - 如果不知道项目检查命令，先查看 README、package.json、pom.xml、build.gradle 等项目配置。
+   - 检查失败时直接修复并重跑；无法修复时说明阻塞原因和已尝试内容。
+   - 如果某个任务已经改出报错，先把这个任务修到本地能通过，再切下一个任务。
+
+5. **更新任务状态**
+   - 只把已经实际完成并通过相关检查的任务从 \`- [ ]\` 改为 \`- [x]\`。
+   - 不强制生成 \`reports/task-*.md\` 或 \`reports/wave-*-integration-report.md\`。
+
+6. **输出实施总结**
+   - 简要列出完成的任务、修改的主要文件、运行过的检查和结果。
+   - 如果还有未完成任务或阻塞点，明确列出下一步。
+   - 提示用户后续运行 \`zhuanspec review <change-id>\` 做验收。`;
+const lightweightApplyGuardrails = `${baseGuardrails}
+- **连续执行到底（红线）**：Apply 阶段一旦开始，就持续实施 tasks.md 中所有未完成任务，直到全部完成或遇到真正的阻塞。禁止在任务之间停下来询问用户"是否继续 / 要不要做下一个任务 / 已完成 Wave N，是否继续 Wave N+1"这类无需决策的确认。Wave 与 Wave 之间同样必须自动推进，不得停顿。只有范围/依赖不明确、需要用户决策、或出现无法自行解决的阻塞时才暂停。此约束优先于基础模型"做一段就停下来征求确认"的默认倾向。
+- **Apply 只负责实施**：本阶段不执行完整审查门禁，不强制生成任务报告，不强制生成 Wave 集成报告。
+- **默认不强制 subagent**：当前 Agent 可以直接完成任务。只有用户明确要求并行、任务明确要求委派，或当前上下文不足以安全完成时，才考虑启动 subagent。
+- **重检查后移**：报告格式校验、外部依赖全量扫描、Scenario 与代码逐项核对、TC 全量验证、占位实现扫描、全局 Concerns 汇总由 \`zhuanspec review\` 或严格检查流程承接。
+- **保持边界**：实施必须符合 proposal/design/tasks 的范围。发现需要修改范围时，先说明偏差并等待用户确认。
+- **任务完成要真实**：只有代码已落地且相关检查通过，才能把任务标记为 \`[x]\`。`;
 const archiveSteps = `**前置检查**：
 - ⚠️ **CHECKPOINT [REVIEW-PASSED]**: Review 阶段必须通过（四轨全部 PASS）
   - \`review-report.md\` 存在且显示 passed
@@ -771,11 +820,12 @@ const archiveReferences = `**参考**
 - 会话分析 (\`session-analytics\`)：记录本次会话的效率指标，用于改进工作流。`;
 const designGuardrails = `${baseGuardrails}\n- **独立设计阶段**：techDesign 命令用于在 proposal 之前生成技术设计请求文档，不依赖变更提案。设计文档可作为后续提案的输入。
 - **Skill 调用连续性（红线）**：在 techDesign 流程中调用任何辅助类 Skill（如 \`@skill:load-project-knowledge\`）后，**必须立即推进到下一编号步骤**，禁止把 Skill 的输出当作流程终态，禁止停顿等待用户输入“继续/下一步”等确认词。只有在显式标注的 AskUserQuestion 步骤（如开发范围确认、需求来源确认、外部依赖确认）才允许暂停等待用户。
-- **需求澄清优先**：在生成设计请求前，必须确认需求来源（大神页面、飞书链接/文档、需求描述文本等）；飞书链接的读取方式见 baseGuardrails 的「需求来源读取」红线。
+- **需求澄清优先**：在生成设计请求前，必须确认需求来源（飞书文档/需求链接、需求描述文本等）；飞书链接的读取方式见 baseGuardrails 的「需求来源读取」红线。
 - **开发范围前置确认（硬约束）**：在调用技术方案 Skill 前，**必须**先通过 AskUserQuestion 确认开发范围是“仅后端开发”还是“全栈开发”，根据答复选择对应 Skill（仅后端=\`generate-tech-spec-md-skill\`，全栈=\`generate-fullstack-tech-spec-skill\`），禁止默认或跳过此确认环节。
 - **Skill 可用性前置检查（硬约束）**：在实际调用技术方案 Skill 前，**必须**先校验目标 Skill 是否已安装且可用；**若不可用，立即中断流程**并提示用户到 Skill 市场安装对应 Skill，禁止以人工编写/其他 Skill 代替。
 - **Skill 调用为主**：技术方案生成主要通过 \`generate-tech-spec-md-skill\`（仅后端）或 \`generate-fullstack-tech-spec-skill\`（全栈）Skill 完成，而非直接运行 CLI 命令。
 - **严格文件约束**：techDesign 阶段只能创建目录和 progress.json（phase=techDesign）。
+- **技术方案落盘路径（红线）**：Skill 生成的技术方案文件**只允许**写入 \`zhuanspec/changes/{change-id}/techDesign/tech-spec.md\`；**严禁**将技术方案写入 \`./doc/\`、工作区根目录、或任何其他路径。Skill 执行完成后必须立即执行 CHECKPOINT [TECH-SPEC-LOCATION] 校验（见步骤 6.3），确认文件落盘位置正确；若 Skill 将文件写到了错误位置，**必须立即移动**到正确路径后才能继续后续步骤。
 - **progress.json 初始化铁律**：**严禁使用 Write/Edit 工具手写 \`metrics/progress.json\`**，必须通过 \`zhuanspec progress set-phase <change-id> techDesign\` 初始化，否则 phaseDurations / phaseTransitions / stats.durationMs 全部缺失，techDesign 阶段耗时无法统计。
 - **禁止创建提案文件**：禁止创建 .tech-design、design.md、proposal.md、tasks.md、specs/ 等。
 - **Proposal 复用**：proposal 阶段通过 progress.json 的 phase 字段识别 techDesign 目录。`;
@@ -804,9 +854,9 @@ const designSteps = `**步骤**
      * ⚠️ **连续性约束（红线）**：\`load-project-knowledge\` 完成并输出 matched_services 表后，**必须立即继续执行下面的步骤 2**，禁止停顿等待用户输入”继续”。该 Skill 只是辅助加载，不是流程门禁。
 
 2. **确认需求来源**：
-   - 检查用户是否提供了需求来源（--dashen-page-id、--dashen-url 或 --desc）
+   - 检查用户是否提供了需求来源（--feishu-url 或 --desc）
    - 如果没有明确来源，使用 AskUserQuestion 工具询问：
-     * 大神页面 ID 或 URL
+     * 飞书文档 URL（使用飞书 CLI \`lark-cli\` 读取）
      * 直接提供需求描述文本
      * 其他来源
 
@@ -849,11 +899,22 @@ const designSteps = `**步骤**
 6. **根据范围调用对应 Skill 生成技术方案**：
    - 若 \`scope === 'backend'\`：使用 Skill 工具调用 \`generate-tech-spec-md-skill\`
    - 若 \`scope === 'fullstack'\`：使用 Skill 工具调用 \`generate-fullstack-tech-spec-skill\`
-   - 传入需求来源参数（dashenPageId、dashenUrl 或 desc）
+   - 传入需求来源参数（feishuUrl 或 desc）
    - Skill 会自动检测当前存在 phase=techDesign 的提案目录，将技术方案输出到 \`zhuanspec/changes/{change-id}/techDesign/tech-spec.md\`
-   - Skill 会自动获取大神页面内容并生成完整技术方案文档
+   - Skill 会通过飞书 CLI \`lark-cli\` 读取飞书文档内容并生成完整技术方案文档
    - **禁止**：在未完成步骤 4 的开发范围确认和步骤 5 的 Skill 可用性校验前调用任何 Skill；禁止两个 Skill 同时调用。
 
+6.3. **⚠️ CHECKPOINT [TECH-SPEC-LOCATION]：技术方案落盘位置强制校验（Skill 完成后立即执行）**：
+   - Skill 执行完成后，**必须立即**运行以下校验，禁止跳过：
+     1. 检查 \`zhuanspec/changes/{change-id}/techDesign/tech-spec.md\` 是否存在且内容非空
+     2. **若文件存在且非空**：校验通过，继续步骤 6.5
+     3. **若文件不存在或为空**：
+        - 在工作区内搜索 Skill 可能生成的技术方案文件（常见错误位置：\`./doc/*.md\`、\`./tech-spec.md\`、工作区根目录）
+        - 找到后**立即移动**到正确位置：\`zhuanspec/changes/{change-id}/techDesign/tech-spec.md\`
+        - 移动完成后再次确认文件存在
+        - 若仍找不到：**中断流程**，向用户报告"技术方案文件未生成到预期路径，Skill 执行可能失败"，说明已搜索的位置和结果，不得继续后续步骤
+   - ⚠️ **红线**：任何情况下不得把非 \`zhuanspec/changes/{change-id}/techDesign/tech-spec.md\` 路径的文件视为正式技术方案，后续所有步骤（6.5、7、8）必须从上述路径读取。
+
 6.5. **新增表澄清与数据存储策略（硬约束，存在新增表时必须执行）**：
    - 从步骤 6 产出的 tech-spec.md 中提取所有 **新增/重构 DB 表**（关键词：CREATE TABLE / 新增表 / t_* / 新建业务表），形成候选表清单。若无新增表 → 跳过本步并在技术方案写明“无新增表，无需数据存储策略评估”
    - 对每张新增表，**必须** 调用 \`AskQuestion\` 向用户批量澄清下列字段（可多表合并一次问答），严禁默认和代书填入：
@@ -1006,10 +1067,15 @@ const reviewSteps = `**步骤**
      - **必须使用 Skill 工具调用** \`generate-mockito-unit-test\`，禁止以"人工快速写几个用例"或"只跑已有测试"的形式代替。
      - Skill 须对本次改动涉及的所有 public 方法生成/补齐单测（若已有 TDD 测试则做增量补齐）。
      - Skill 完成后运行测试命令并收集通过率、覆盖率、失败用例清单。
+     - **pom.xml 注册校验（Java 项目必须执行，非 Java 跳过并记 \`"skipped"\`）**：Skill 生成新测试文件后，必须检查测试文件是否在 Maven 测试扫描范围内：
+       1. 读取受影响模块的 \`pom.xml\`，检查 \`maven-surefire-plugin\` 的 \`<includes>\` 配置
+       2. 若 \`<includes>\` 存在且为白名单模式，确认新文件路径与模式匹配；不匹配则自动在对应 pom.xml 中追加 \`<include>\` 条目
+       3. 若 \`<includes>\` 未配置（Surefire 默认规则：\`**/*Test.java\`、\`**/*Tests.java\`、\`**/*TestCase.java\`），确认生成文件命名符合规则；不符合则重命名文件使其匹配默认规则
+       4. 将校验结果记录到 \`unit-test-result.json\` 的 \`pomRegistrationCheck\` 字段（\`"passed"\` / \`"fixed"\` / \`"skipped"\`）
    - 自闭环修复（最多 3 轮）：出现失败用例或覆盖率低于阈值时，**再次使用 Skill 工具调用** \`generate-mockito-unit-test\` 进行补齐/修复，重跑测试；禁止手工跳过修复。
    - 产物落盘：**AI 将 Skill 真实执行结果写入** \`zhuanspec/changes/<id>/review/unit-test-result.json\`，格式：
      \`\`\`json
-     { "schemaVersion": 2, "testPassed": true, "passRate": 100, "coverage": 85, "coverageThreshold": 80, "newTestsGenerated": ["src/test/java/.../FooServiceTest.java"], "failedTests": [], "loopCount": 0 }
+     { "schemaVersion": 2, "testPassed": true, "passRate": 100, "coverage": 85, "coverageThreshold": 80, "newTestsGenerated": ["src/test/java/.../FooServiceTest.java"], "failedTests": [], "pomRegistrationCheck": "passed", "loopCount": 0 }
      \`\`\`
      - \`newTestsGenerated\` 必须登记 Skill 本轮实际新增或更新的测试文件路径（至少 1 项）；若本次改动确实不涉及新增/修改 public 方法导致无需新增测试，必须改为在 JSON 中追加 \`"skipReason": "<说明>"\` 字段说明原因。
    - 退出条件：\`testPassed === true\`、\`passRate === 100\`、\`coverage >= coverageThreshold\`，且 \`newTestsGenerated\` 非空或已给出 \`skipReason\`。未通过禁止进入 2.3。
@@ -1027,6 +1093,10 @@ const reviewSteps = `**步骤**
      \`\`\`
      - \`skillReportPath\` **必填**，必须指向上一步 Skill 生成的真实 markdown 报告文件（相对工作区根）。文件不存在时 CLI 会拒绝通过。
    - 退出条件：\`criticalCount === 0\` 且 \`skillReportPath\` 对应文件真实存在。未通过禁止进入 2.4。
+   - **代码格式规范（自闭环修复范围）**：Code Review 发现以下格式问题时，修复动作必须与代码逻辑修复一并在本轮自闭环中完成，不得延后到用户指出后再改：
+     * 方法体内禁止使用全限定类名（除非存在同名歧义冲突），必须在文件顶部 import
+     * 禁止相邻 import 块/方法块之间出现超过一个空行；类定义内方法间保持一个空行
+     * 删除本次改动引入的无用 import、未使用变量、注释掉的死代码段
 
    **2.4 轨道 4 — 功能闭环验收轨（AI 代码质量拦截）**
    - 进入条件：2.3 已 PASS。
@@ -1107,10 +1177,10 @@ const reviewSteps = `**步骤**
    - 全部通过时生成 \`zhuanspec/changes/<id>/review/review-report.md\`。
 4. **审查结果处理**：
    - **PASS**：前四轨顺序全部通过（Spec-Code → UT → CR → Closure）且 Critical=0、skeletonCodeCount=0、无未闭环功能，可以继续归档。
-   - **FAIL**：根据 CLI 输出定位失败轨，返回对应子步骤（2.1/2.2/2.3/2.4）继续修复。
+   - **FAIL**：根据 CLI 输出定位失败轨，**直接进入自闭环修复，不得停下来询问用户是否继续**，返回对应子步骤（2.1/2.2/2.3/2.4）继续修复直至通过或达到轮次上限。
 5. **修复循环**（整体失败时）：
    - 按失败轨所在子步骤的自闭环修复流程处理；每轨内部最多 3 轮，超限则停止并向用户报告。
-   - 修复完成后重新从失败轨开始顺序执行，而非重置整个 Review。
+   - 修复完成后**立即重新从失败轨开始顺序执行**，而非重置整个 Review，也不得在修复后停下来等待用户确认。
 6. **确认通过后**：
    - 告知用户审查已通过（最多六轨顺序串行 + CLI 汇总）。
    - 提示可以使用 \`/zhuanspec:archive\` 进行归档。`;
@@ -1271,7 +1341,7 @@ const knowledgeReferences = `**参考**
 export const slashCommandBodies = {
     proposal: [proposalGuardrails, proposalOutputFormat, proposalSteps, proposalReferences].join('\n\n'),
     design: [designGuardrails, designSteps, designReferences].join('\n\n'),
-    apply: [applyGuardrails, applyOutputFormat, applySteps, applyReferences].join('\n\n'),
+    apply: [lightweightApplyGuardrails, applyOutputFormat, lightweightApplySteps, applyReferences].join('\n\n'),
     review: [reviewGuardrails, reviewOutputFormat, reviewSteps, reviewReferences].join('\n\n'),
     archive: [baseGuardrails, archiveSteps, archiveReferences].join('\n\n'),
     knowledge: [knowledgeGuardrails, knowledgeSteps, knowledgeReferences].join('\n\n')

package/dist/core/templates/tasks-template.js

@@ -191,7 +191,7 @@ Answer: <!-- user answer -->
 
 ### Wave 1（底层：DAO / 外部 Assemble）
 
-> ⚠️ **MUST (subagent gate)**: 本 Wave 每个任务必须通过 Agent tool / spawn_agent 启动 subagent 执行；主线程直接施工产生的报告会被 B0 schema 校验（\`zhuanspec validate-reports <change-id>\`）拦截并触发 RETRY。
+> 执行提示：本 Wave 可按任务顺序直接实施；只有任务明确需要并行或用户要求委派时，再启动 subagent。
 
 <!-- Wave 1: Tasks with no dependencies, 层归属限定 dao/assemble/ddl/config -->
 
@@ -199,7 +199,7 @@ Answer: <!-- user answer -->
 
 ### Wave 2（中间层：Domain / Application）
 
-> ⚠️ **MUST (subagent gate)**: 本 Wave 每个任务必须通过 Agent tool / spawn_agent 启动 subagent 执行；主线程直接施工产生的报告会被 B0 schema 校验（\`zhuanspec validate-reports <change-id>\`）拦截并触发 RETRY。
+> 执行提示：本 Wave 可按任务顺序直接实施；只有任务明确需要并行或用户要求委派时，再启动 subagent。
 
 <!-- Wave 2: Tasks depending on Wave 1, 层归属限定 domain/application -->
 
@@ -207,7 +207,7 @@ Answer: <!-- user answer -->
 
 ### Wave 3（顶层：SCF / MQ / 定时任务 / 前端）
 
-> ⚠️ **MUST (subagent gate)**: 本 Wave 每个任务必须通过 Agent tool / spawn_agent 启动 subagent 执行；主线程直接施工产生的报告会被 B0 schema 校验（\`zhuanspec validate-reports <change-id>\`）拦截并触发 RETRY。
+> 执行提示：本 Wave 可按任务顺序直接实施；只有任务明确需要并行或用户要求委派时，再启动 subagent。
 
 <!-- Wave 3: Tasks depending on Wave 2, 层归属限定 entry-scf/entry-mq-*/entry-job/fe -->
 

package/dist/core/templates/tdd-tasks-template.js

@@ -153,7 +153,7 @@ Answer: <!-- user answer -->
 
 ### Wave 2
 
-> ⚠️ **MUST (subagent gate)**: 本 Wave 每个任务必须通过 Agent tool / spawn_agent 启动 subagent（优先 tddApplyAgent）执行；主线程直接施工产生的报告会被 B0 schema 校验（\`zhuanspec validate-reports <change-id>\`）拦截并触发 RETRY。
+> 执行提示：本 Wave 可按任务顺序直接实施；只有任务明确需要并行或用户要求委派时，再启动 subagent。
 
 <!-- Wave 2: Red Phase - Write failing tests that define expected behavior -->
 <!-- 先写测试，测试应当初始失败 — 证明测试确实在验证有意义的行为 -->
@@ -164,7 +164,7 @@ Answer: <!-- user answer -->
 
 ### Wave 3
 
-> ⚠️ **MUST (subagent gate)**: 本 Wave 每个任务必须通过 Agent tool / spawn_agent 启动 subagent（优先 tddApplyAgent）执行；主线程直接施工产生的报告会被 B0 schema 校验（\`zhuanspec validate-reports <change-id>\`）拦截并触发 RETRY。
+> 执行提示：本 Wave 可按任务顺序直接实施；只有任务明确需要并行或用户要求委派时，再启动 subagent。
 
 <!-- Wave 3: Green Phase - Write minimal code to make tests pass -->
 <!-- 编写最少代码使测试通过，每个任务必须使用类型A（新增）或类型B（修改）模板 -->
@@ -174,7 +174,7 @@ Answer: <!-- user answer -->
 
 ### Wave 4
 
-> ⚠️ **MUST (subagent gate)**: 本 Wave 每个任务必须通过 Agent tool / spawn_agent 启动 subagent（优先 tddApplyAgent）执行；主线程直接施工产生的报告会被 B0 schema 校验（\`zhuanspec validate-reports <change-id>\`）拦截并触发 RETRY。
+> 执行提示：本 Wave 可按任务顺序直接实施；只有任务明确需要并行或用户要求委派时，再启动 subagent。
 
 <!-- Wave 4: Refactor Phase - Clean up code while keeping tests green -->
 <!-- 在保持测试通过的前提下重构，每个任务使用类型B模板标明修改位置 -->
@@ -184,7 +184,7 @@ Answer: <!-- user answer -->
 
 ### Wave 5
 
-> ⚠️ **MUST (subagent gate)**: 本 Wave 每个任务必须通过 Agent tool / spawn_agent 启动 subagent 执行；主线程直接施工产生的报告会被 B0 schema 校验（\`zhuanspec validate-reports <change-id>\`）拦截并触发 RETRY。
+> 执行提示：本 Wave 可按任务顺序直接实施；只有任务明确需要并行或用户要求委派时，再启动 subagent。
 
 <!-- Wave 5: Documentation - Document the implemented feature -->
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@zhuan-ai/zhuanspec",
-  "version": "2.17.15",
+  "version": "2.19.2",
   "description": "AI-native system for spec-driven development",
   "keywords": [
     "zhuanspec",

package/schemas/spec-driven/schema.yaml

@@ -223,5 +223,7 @@ apply:
   requires: [tasks]
   tracks: tasks.md
   instruction: |
-    阅读上下文文件，处理待处理的任务，在完成时标记为完成。
-    如果遇到阻碍或需要澄清，请暂停。
+    阅读 proposal.md、design.md（如存在）和 tasks.md。
+    只处理未完成任务，直接实施代码改动，运行相关编译或测试。
+    检查通过后将完成任务标记为 [x]。
+    Apply 阶段不强制 Wave 并行、subagent、任务报告或全量验收；完整验收请运行 review。