@zhuan-ai/zhuanspec 2.2.5 → 2.4.8

package/dist/core/templates/index.d.ts

@@ -14,4 +14,5 @@ export declare class TemplateManager {
 }
 export { ProjectContext } from './project-template.js';
 export type { SlashCommandId } from './slash-command-templates.js';
+export { getTestCasesTemplate, getMinimalTestCasesTemplate, formatFetchedTestCases, TestCasesTemplateOptions } from './test-cases-template.js';
 //# sourceMappingURL=index.d.ts.map

package/dist/core/templates/index.js

@@ -34,4 +34,5 @@ export class TemplateManager {
         return getSlashCommandBody(id);
     }
 }
+export { getTestCasesTemplate, getMinimalTestCasesTemplate, formatFetchedTestCases } from './test-cases-template.js';
 //# sourceMappingURL=index.js.map

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

@@ -37,7 +37,7 @@ export function getNewChangeSkillTemplate() {
    Use the **AskUserQuestion tool** to let the user choose a workflow:
    - Present each schema with its description
    - Mark \`spec-driven\` as "(default)" if it's available
-   - Example options: "spec-driven - proposal → specs → design → tasks (default)", "tdd - tests → implementation → docs"
+   - Example options: "spec-driven - techDesign(design) → proposal → specs → tasks (default)", "tdd - tests → implementation → docs"
 
    If user doesn't have a preference, default to \`spec-driven\`.
 
@@ -169,7 +169,7 @@ The artifact types and their purpose depend on the schema. Use the \`instruction
 
 Common artifact patterns:
 
-**spec-driven schema** (proposal → specs → design → tasks):
+**spec-driven schema** (techDesign(design) → proposal → specs → tasks):
 - **proposal.md**: Ask user about the change if not clear. Fill in Why, What Changes, Capabilities, Impact.
   - The Capabilities section is critical - each capability listed will need a spec file.
 - **specs/*.md**: Create one spec per capability listed in the proposal.
@@ -265,8 +265,7 @@ export function getApplyChangeSkillTemplate() {
    - Parse the task text for \`@skill\` tags (format: \`@skill:name1,name2\`)
    - If \`@skill\` tags found, invoke the corresponding skill(s) for guidance before making changes
    - Make the code changes required
-   - If the task mentions unit tests ("单元测试", "UT", "unit test"), AFTER code generation you MUST invoke \`generate-mockito-unit-test\` (or \`generate-mockito-unit-test-skill\`) to generate tests
-   - Run unit tests and verify they pass (e.g., \`mvn -Dtest=<TestClass> test\` or module-level \`mvn test\`); do not mark task complete until tests pass
+   - Apply 阶段不生成单元测试文件；仅完成功能实现并保持任务状态准确
    - Keep changes minimal and focused
    - Mark task complete in the tasks file: \`- [ ]\` → \`- [x]\`
    - Continue to next task
@@ -285,80 +284,26 @@ export function getApplyChangeSkillTemplate() {
    - If all done: proceed to code review step (step 8)
    - If paused: explain why and wait for guidance
 
-8. **Code Review (when all tasks complete)**
+8. **三轨并行审查门禁（auto, once after all tasks complete）**
 
    **WHEN** all tasks are complete (\`state: "all_done"\`):
-   
-   a. **Prompt for code review**
-   
-      Use the **AskUserQuestion tool** with options:
-      - "是，进行代码审查" / "Yes, perform code review"
-      - "跳过，直接归档" / "Skip, proceed to archive"
-      
-      Wait for user selection before proceeding.
-   
-   b. **If user selects "Yes, perform code review"**:
-      
-      1. **Read code files related to the change**
-         - Based on context files from apply instructions
-         - Scan the change directory for code files (e.g., \`*.java\`, \`*.ts\`, \`*.py\`, etc.)
-         - Read all relevant code files that were modified or created for this change
-      
-      2. **Perform code review**
-         
-         Review code for:
-         - **Code standards and conventions compliance**: naming, formatting, structure
-         - **Logic correctness**: edge cases, error handling, business logic
-         - **Performance issues**: inefficient algorithms, unnecessary operations, potential bottlenecks
-         - **Security concerns**: input validation, authentication, authorization, data exposure
-         - **Best practices adherence**: design patterns, SOLID principles, maintainability
-         
-         **For Java code specifically**, pay special attention to:
-         - Java-specific patterns and conventions (e.g., builder pattern, factory pattern)
-         - Common Java pitfalls:
-           - Null handling (NullPointerException prevention)
-           - Exception handling (proper try-catch, resource management)
-           - Resource management (try-with-resources, closing streams/connections)
-         - Performance considerations:
-           - Collections usage (ArrayList vs LinkedList, HashMap vs TreeMap)
-           - Streams vs loops (when to use each)
-           - Concurrency (thread safety, synchronization)
-      
-      3. **Generate review report**
-         
-         Create a structured report listing:
-         - **Issues found** (if any):
-           - Severity (Critical, High, Medium, Low)
-           - Location (file path and line number)
-           - Description
-           - Suggestion for improvement
-         - **Suggestions for improvement** (even if no critical issues)
-         - **Positive findings** (good practices observed)
-      
-      4. **Handle review results**
-         
-         - **If issues are found**:
-           
-           Display the review report with all issues.
-           
-           Use **AskUserQuestion tool** with options:
-           - "是，现在修复" / "Yes, fix now"
-           - "稍后修复" / "Fix later"
-           - "跳过" / "Skip"
-           
-           - If user chooses "Yes, fix now": proceed with fixing the issues one by one
-           - If user chooses "Fix later" or "Skip": continue to archive workflow
-         
-         - **If no issues are found**:
-           
-           Display: "代码审查完成，未发现问题。" (or "Code review complete. No issues found.")
-           Proceed to suggest archive workflow.
-   
-   c. **If user selects "Skip, proceed to archive"**:
-      
-      Skip the code review step.
-      Proceed directly to suggesting archive workflow.
-      The workflow SHALL NOT be blocked.
+
+   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.
 
 **Output During Implementation**
 
@@ -710,8 +655,8 @@ Main specs are now updated. The change remains active - archive when implementat
 export function getProposeChangeSkillTemplate() {
     return {
         name: 'zhuanspec-propose-change',
-        description: 'Create a complete ZhuanSpec change proposal in one step. Use when the user wants to propose a new feature, fix, or modification. Generates proposal, specs, design, and tasks all at once.',
-        instructions: `Create a complete change proposal in one step - proposal, specs, design, and tasks.
+        description: 'Create a complete ZhuanSpec change proposal in one step. Use when the user wants to propose a new feature, fix, or modification. Generates design, proposal, specs, and tasks all at once.',
+        instructions: `Create a complete change proposal in one step - design, proposal, specs, and tasks.
 
 **Input**: The user's request should describe what they want to build or change. Can include a change name (kebab-case) or a natural language description.
 
@@ -766,7 +711,7 @@ export function getProposeChangeSkillTemplate() {
       zhuanspec status --change "<name>" --json
       \`\`\`
 
-   b. **For each artifact in dependency order** (proposal → specs → design → tasks):
+   b. **For each artifact in dependency order** (techDesign(design) → proposal → specs → tasks):
       - Get instructions: \`zhuanspec instructions <artifact-id> --change "<name>" --json\`
       - Read any completed dependency files for context
       - **For proposal artifact**: When filling Skill Mapping section, analyze each skill's description and match based on actual functionality (not just module names). Simple changes like enum modifications should map to general coding standards, not architecture-level skills.
@@ -1057,7 +1002,7 @@ export function getOpsxProposeCommandTemplate() {
 4. **Generate all planning artifacts** in dependency order:
    - For each artifact: \`zhuanspec instructions <id> --change "<name>" --json\`
    - Read dependencies, create artifact, show progress
-   - Artifacts: proposal.md → specs/ → design.md (if needed) → tasks.md
+  - Artifacts: design.md（techDesign 阶段产物）→ proposal.md → specs/ → tasks.md
 
    ⚠️ **CHECKPOINT [SKILL-TAGGING]**:
    1. You MUST run \`zhuanspec skills list\` first and record discovered skills in the Skill Mapping table
@@ -1195,7 +1140,7 @@ export function getOpsxNewCommandTemplate() {
    Use the **AskUserQuestion tool** to let the user choose a workflow:
    - Present each schema with its description
    - Mark \`spec-driven\` as "(default)" if it's available
-   - Example options: "spec-driven - proposal → specs → design → tasks (default)", "tdd - tests → implementation → docs"
+   - Example options: "spec-driven - techDesign(design) → proposal → specs → tasks (default)", "tdd - tests → implementation → docs"
 
    If user doesn't have a preference, default to \`spec-driven\`.
 
@@ -1327,7 +1272,7 @@ The artifact types and their purpose depend on the schema. Use the \`instruction
 
 Common artifact patterns:
 
-**spec-driven schema** (proposal → specs → design → tasks):
+**spec-driven schema** (techDesign(design) → proposal → specs → tasks):
 - **proposal.md**: Ask user about the change if not clear. Fill in Why, What Changes, Capabilities, Impact.
   - The Capabilities section is critical - each capability listed will need a spec file.
 - **specs/*.md**: Create one spec per capability listed in the proposal.
@@ -1424,8 +1369,7 @@ export function getOpsxApplyCommandTemplate() {
    - Parse the task text for \`@skill\` tags (format: \`@skill:name1,name2\`)
    - If \`@skill\` tags found, invoke the corresponding skill(s) for guidance before making changes
    - Make the code changes required
-   - If the task mentions unit tests ("单元测试", "UT", "unit test"), AFTER code generation you MUST invoke \`generate-mockito-unit-test\` (or \`generate-mockito-unit-test-skill\`) to generate tests
-   - Run unit tests and verify they pass (e.g., \`mvn -Dtest=<TestClass> test\` or module-level \`mvn test\`); do not mark task complete until tests pass
+   - Apply 阶段不生成单元测试文件；仅完成功能实现并保持任务状态准确
    - Keep changes minimal and focused
    - Mark task complete in the tasks file: \`- [ ]\` → \`- [x]\`
    - Continue to next task
@@ -1444,80 +1388,26 @@ export function getOpsxApplyCommandTemplate() {
    - If all done: proceed to code review step (step 8)
    - If paused: explain why and wait for guidance
 
-8. **Code Review (when all tasks complete)**
+8. **三轨并行审查门禁（auto, once after all tasks complete）**
 
    **WHEN** all tasks are complete (\`state: "all_done"\`):
-   
-   a. **Prompt for code review**
-   
-      Use the **AskUserQuestion tool** with options:
-      - "是，进行代码审查" / "Yes, perform code review"
-      - "跳过，直接归档" / "Skip, proceed to archive"
-      
-      Wait for user selection before proceeding.
-   
-   b. **If user selects "Yes, perform code review"**:
-      
-      1. **Read code files related to the change**
-         - Based on context files from apply instructions
-         - Scan the change directory for code files (e.g., \`*.java\`, \`*.ts\`, \`*.py\`, etc.)
-         - Read all relevant code files that were modified or created for this change
-      
-      2. **Perform code review**
-         
-         Review code for:
-         - **Code standards and conventions compliance**: naming, formatting, structure
-         - **Logic correctness**: edge cases, error handling, business logic
-         - **Performance issues**: inefficient algorithms, unnecessary operations, potential bottlenecks
-         - **Security concerns**: input validation, authentication, authorization, data exposure
-         - **Best practices adherence**: design patterns, SOLID principles, maintainability
-         
-         **For Java code specifically**, pay special attention to:
-         - Java-specific patterns and conventions (e.g., builder pattern, factory pattern)
-         - Common Java pitfalls:
-           - Null handling (NullPointerException prevention)
-           - Exception handling (proper try-catch, resource management)
-           - Resource management (try-with-resources, closing streams/connections)
-         - Performance considerations:
-           - Collections usage (ArrayList vs LinkedList, HashMap vs TreeMap)
-           - Streams vs loops (when to use each)
-           - Concurrency (thread safety, synchronization)
-      
-      3. **Generate review report**
-         
-         Create a structured report listing:
-         - **Issues found** (if any):
-           - Severity (Critical, High, Medium, Low)
-           - Location (file path and line number)
-           - Description
-           - Suggestion for improvement
-         - **Suggestions for improvement** (even if no critical issues)
-         - **Positive findings** (good practices observed)
-      
-      4. **Handle review results**
-         
-         - **If issues are found**:
-           
-           Display the review report with all issues.
-           
-           Use **AskUserQuestion tool** with options:
-           - "是，现在修复" / "Yes, fix now"
-           - "稍后修复" / "Fix later"
-           - "跳过" / "Skip"
-           
-           - If user chooses "Yes, fix now": proceed with fixing the issues one by one
-           - If user chooses "Fix later" or "Skip": continue to archive workflow
-         
-         - **If no issues are found**:
-           
-           Display: "代码审查完成，未发现问题。" (or "Code review complete. No issues found.")
-           Proceed to suggest archive workflow.
-   
-   c. **If user selects "Skip, proceed to archive"**:
-      
-      Skip the code review step.
-      Proceed directly to suggesting archive workflow.
-      The workflow SHALL NOT be blocked.
+
+   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.
 
 **Output During Implementation**
 

package/dist/core/templates/slash-command-templates.d.ts

@@ -1,4 +1,4 @@
-export type SlashCommandId = 'proposal' | 'apply' | 'archive';
+export type SlashCommandId = 'proposal' | 'design' | 'apply' | 'review' | 'archive' | 'knowledge';
 export declare const slashCommandBodies: Record<SlashCommandId, string>;
 export declare function getSlashCommandBody(id: SlashCommandId): string;
 //# sourceMappingURL=slash-command-templates.d.ts.map