speccrew 0.7.73 → 0.7.75

package/.speccrew/skills/speccrew-test-manager-orchestration/SKILL.md

@@ -1,106 +1,18 @@
 ---
 name: speccrew-test-manager-orchestration
-version: 1.0.0
 description: Test Manager 的编排调度技能，负责执行三阶段测试工作流：测试用例设计 → 测试代码生成 → 测试执行与报告。支持单平台直接调用和多平台 Worker 并行调度。
 tools: Read, Write, Glob, Grep, Bash, Agent
 ---
 
-> **⚠️ MANDATORY EXECUTION PROTOCOL — READ BEFORE EXECUTING ANY BLOCK**
->
-> **Step 1**: Load XML workflow specification: `speccrew-workspace/docs/rules/agentflow-spec.md` — this defines all block types and action-to-tool mappings
->
-> **Step 2**: Execute this SKILL.md's XML workflow **block by block in document order**. For EVERY block, you MUST follow this 3-step cycle:
->
-> ```
-> 🏷️ Block [ID] (action=[action]) — [desc]
-> 🔧 Tool: [which IDE tool to call]
-> ✅ Result: [output or status]
-> ```
->
-> Action-to-tool mapping:
-> - `action="run-skill"` → Invoke via **Skill tool** (pass the `<field name="skill">` value EXACTLY)
-> - `action="run-script"` → Execute via **Terminal tool** (pass the `<field name="command">` value EXACTLY)
-> - `action="dispatch-to-worker"` → Create **Task** via **Task tool** for `speccrew-task-worker`
-> - `action="read-file"` → Read via **Read tool**
-> - `action="log"` → Output message directly
-> - `action="confirm"` → Present to user and wait for response
->
-> **Step 3**: Execute ALL blocks sequentially without pausing (only stop at explicit `<event action="confirm">` blocks)
+# Trigger Scenarios
 
-# Test Manager Orchestration
-
-Test Manager 的核心编排技能，负责：
-
-1. **Stage Gate Verification** - 验证部署阶段已完成确认
-2. **IDE Directory Detection** - 检测 IDE 目录并验证测试技能存在
-3. **Preparation** - 识别迭代路径、定位输入文档、检查现有制品
-4. **Knowledge Loading** - 加载功能规格、API契约、系统设计
-5. **Test Case Design** - 测试用例设计（支持单平台/多平台模式）
-6. **Test Code Generation** - 测试代码生成（含代码审查）
-7. **Test Execution & Reporting** - 测试执行与缺陷报告
-8. **Delivery Summary** - 交付总结确认
-
-## Invocation Method
-
-**CRITICAL**: This skill is loaded directly by Test Manager Agent — do NOT invoke via Worker Agent.
-
-```xml
-<block type="task" action="run-skill" desc="Test Manager orchestration workflow">
-  <field name="skill">speccrew-test-manager-orchestration</field>
-</block>
-```
-
-## Input Parameters
-
-| Parameter | Type | Required | Description |
-|-----------|------|----------|-------------|
-| `workspace_path` | string | Yes | speccrew-workspace 根目录绝对路径 |
-| `iteration_dir` | string | Yes | 当前迭代目录路径 |
-| `update_progress_script` | string | Yes | update-progress.js 脚本路径 |
-
-## Output
-
-- `status` - Execution status (success / partial / failed)
-- `test_cases_designed` - Number of test cases designed
-- `test_code_generated` - Number of test code files generated
-- `tests_passed` - Number of tests passed
-- `tests_failed` - Number of tests failed
-- `bug_reports` - List of bug report paths
-- `output_files` - List of generated/modified files
-- `summary` - Execution summary
-- `next_steps` - Suggested next actions
-
----
+- Test Manager Agent starts the three-phase testing workflow after development confirmation
+- Development stage confirmed and test case design needs to begin
+- User requests test execution or test report generation
 
 ## AgentFlow Definition
 
 <!-- @agentflow: SKILL.xml -->
 
----
-
-## CONTINUOUS EXECUTION RULES
-
-This skill MUST execute tasks continuously without unnecessary interruptions.
-
-### FORBIDDEN Interruptions
-
-1. DO NOT ask user "Should I continue?" after completing a subtask
-2. DO NOT suggest "Let me split this into batches" or "Let's do this in parts"
-3. DO NOT pause to list what you plan to do next — just do it
-4. DO NOT ask for confirmation before generating output files
-5. DO NOT warn about "large number of files" — proceed with generation
-6. DO NOT offer "Should I proceed with the remaining items?"
-
-### When to Pause (ONLY these cases)
-
-1. CHECKPOINT gates defined in workflow (user confirmation required by design)
-2. Ambiguous requirements that genuinely need clarification
-3. Unrecoverable errors that prevent further progress
-4. Security-sensitive operations (e.g., deleting existing files)
-
-### Batch Execution Behavior
-
-- When multiple items need processing, process ALL of them sequentially without asking
-- Use DISPATCH-PROGRESS.json to track progress, enabling resumption if interrupted by context limits
-- If context window is approaching limit, save progress to checkpoint and inform user how to resume
-- NEVER voluntarily stop mid-batch to ask if user wants to continue
+> **REQUIRED**: Before executing this workflow, read the XML workflow specification: speccrew-workspace/docs/rules/agentflow-spec.md
+> Then read and execute the XML workflow in SKILL.xml block-by-block as the authoritative execution plan.

package/.speccrew/skills/speccrew-test-reporter/SKILL.md

@@ -10,109 +10,9 @@ tools: Read, Write, Glob, Grep
 - When user explicitly requests "generate test report", "create bug reports"
 - When test execution results need to be converted to human-readable reports
 
-# Role Positioning
-
-**Primary Role**: Test Report Generator
-
-**Responsibilities**:
-- Read structured test execution results from speccrew-test-runner
-- Generate comprehensive test reports with statistics and analysis
-- Generate individual bug reports for each failed test case
-- Perform detailed root cause analysis with impact assessment
-- Classify bug severity for prioritization
-- Output human-readable documents for stakeholders
-
-**Upstream Dependencies**: speccrew-test-runner
-**Downstream Consumers**: speccrew-test-manager, development teams, QA teams
-
 ## AgentFlow Definition
 
 <!-- @agentflow: SKILL.xml -->
 
-> **REQUIRED**: Before executing this workflow, read the XML workflow specification: `speccrew-workspace/docs/rules/agentflow-spec.md`
-
-## Output
-
-### Output Files
-
-| File | Path | Description |
-|------|------|-------------|
-| Test Report | `{output_dir}/reports/{feature}-test-report.md` | Comprehensive test execution report |
-| Bug Reports | `{output_dir}/bugs/{feature}-bug-{seq}.md` | Individual bug report per failure |
-
-### Output Structure
-
-```
-{output_dir}/
-├── reports/
-│   └── {feature}-test-report.md
-└── bugs/
-    ├── {feature}-bug-001.md
-    ├── {feature}-bug-002.md
-    └── ...
-```
-
-# Key Rules
-
-| Rule | Description |
-|------|-------------|
-| **Template-First Workflow** | Always copy template before filling sections |
-| **One Bug Per File** | Each bug gets its own report file for tracking |
-| **Severity Classification** | Always classify bug severity for prioritization |
-| **Actionable Reports** | Bug reports must include suggested fix direction |
-| **TC ID Traceability** | Every bug must be traced back to its TC ID |
-| **Root Cause Analysis** | Provide detailed analysis of failure causes |
-| **No Execution** | This skill does NOT execute tests, only generates reports |
-
-# Checklist
-
-- [ ] Execution results document loaded successfully
-- [ ] Test report generated with complete statistics
-- [ ] Results broken down by test dimension
-- [ ] Failed tests linked to corresponding bug reports
-- [ ] Each FAIL/ERROR has a corresponding bug report
-- [ ] Bug severity classified (Critical/High/Medium/Low)
-- [ ] Root cause analysis completed for each bug
-- [ ] All bug reports written to correct output path
-- [ ] Test report written to correct output path
-- [ ] Bug links updated in test report
-
----
-
-# Task Completion Report
-
-Upon completion (success or failure), output the following report format:
-
-## Success Report
-```
-## Task Completion Report
-- **Status**: SUCCESS
-- **Task ID**: <from dispatch context, e.g., "test-reporter-web-vue">
-- **Platform**: <platform_id, e.g., "web-vue">
-- **Phase**: test_reporting
-- **Output Files**:
-  - `{output_dir}/reports/{feature}-test-report.md`
-  - `{output_dir}/bugs/{feature}-bug-{seq}.md` (if any failures)
-- **Summary**: Generated test report with {total} tests, {failed} bugs reported
-```
-
-## Failure Report
-```
-## Task Completion Report
-- **Status**: FAILED
-- **Task ID**: <from dispatch context>
-- **Platform**: <platform_id>
-- **Phase**: test_reporting
-- **Output Files**: <list of partial outputs or "None">
-- **Summary**: Test report generation failed during {step}
-- **Error**: <detailed error description>
-- **Error Category**: INPUT_MISSING | TEMPLATE_ERROR | WRITE_ERROR | BLOCKED
-- **Partial Outputs**: <list of files that were generated before failure, or "None">
-- **Recovery Hint**: <suggestion for recovery>
-```
-
-**Error Category Definitions**:
-- `INPUT_MISSING`: Required execution results or test cases document not available
-- `TEMPLATE_ERROR`: Template file missing or malformed
-- `WRITE_ERROR`: File system error during report generation
-- `BLOCKED`: Blocked by missing upstream dependency
+> **REQUIRED**: Before executing this workflow, read the XML workflow specification: speccrew-workspace/docs/rules/agentflow-spec.md
+> Then read and execute the XML workflow in SKILL.xml block-by-block as the authoritative execution plan.

package/.speccrew/skills/speccrew-test-runner/SKILL.md

@@ -7,130 +7,12 @@ tools: Read, Write, Bash, Glob, Grep
 # Trigger Scenarios
 
 - When speccrew-test-manager dispatches test execution after test code is confirmed
-- When speccrew-test-reporter needs raw execution results to generate reports
 - When user explicitly requests "run tests", "execute tests", "run test suite"
-
-# Role Positioning
-
-**Primary Role**: Test Execution Engine
-
-**Responsibilities**:
-- Read and validate test code files
-- Perform environment pre-checks (runtime, dependencies, test framework)
-- Execute test commands for various platforms and frameworks
-- Parse test framework output into structured data
-- Detect deviations between expected and actual results
-- Output structured execution results for downstream consumers
-
-**Upstream Dependencies**: speccrew-test-manager, speccrew-test-code-generator
-**Downstream Consumers**: speccrew-test-reporter
+- When speccrew-test-reporter needs raw execution results to generate reports
 
 ## AgentFlow Definition
 
 <!-- @agentflow: SKILL.xml -->
 
-> **REQUIRED**: Before executing this workflow, read the XML workflow specification: `speccrew-workspace/docs/rules/agentflow-spec.md`
-
-## Output
-
-### Output Files
-
-| File | Path | Description |
-|------|------|-------------|
-| Execution Results | `{output_dir}/{feature}-test-execution-results.md` | Structured test execution data |
-
-### Output Format Contract
-
-The execution results document serves as the **input contract** for speccrew-test-reporter:
-
-```yaml
-execution_summary:
-  feature_name: string
-  platform_id: string
-  framework: string
-  execution_date: ISO8601
-  duration_ms: number
-  total_tests: number
-  passed: number
-  failed: number
-  errors: number
-  skipped: number
-  pass_rate: percentage
-
-test_results:
-  - tc_id: string
-    test_name: string
-    status: PASS|FAIL|ERROR|SKIP
-    duration_ms: number
-    error_message: string|null
-    stack_trace: string|null
-    expected_result: string
-    actual_result: string
-
-deviations:
-  - tc_id: string
-    type: FAIL|ERROR|SKIP|FLAKY
-    severity: Critical|High|Medium|Low
-    description: string
-
-environment:
-  os: string
-  runtime_version: string
-  framework_version: string
-  dependencies: list
-```
-
-# Key Rules
-
-| Rule | Description |
-|------|-------------|
-| **Environment First** | Always verify environment before running tests |
-| **Complete Output Capture** | Capture both stdout and stderr for diagnostics |
-| **TC ID Traceability** | Every test result must be traced back to its TC ID |
-| **No Report Generation** | This skill does NOT generate human-readable reports |
-| **Structured Output Only** | Output must be structured data for downstream consumption |
-| **Runner → Reporter Contract** | Output format must match speccrew-test-reporter input expectations |
-
-# Checklist
-
-- [ ] Environment pre-check passed before execution
-- [ ] All test files from code plan were executed
-- [ ] Test results are correctly parsed from framework output
-- [ ] Failed tests are correctly traced back to TC IDs
-- [ ] Deviation classification completed for all non-PASS results
-- [ ] Execution results written to correct output path
-- [ ] Output format follows contract for speccrew-test-reporter
-
----
-
-# Task Completion Report
-
-Upon completion (success or failure), output the following report format:
-
-## Success Report
-```
-## Task Completion Report
-- **Status**: SUCCESS
-- **Task ID**: <from dispatch context, e.g., "test-runner-web-vue">
-- **Platform**: <platform_id, e.g., "web-vue">
-- **Phase**: test_execution
-- **Output Files**:
-  - `{output_dir}/{feature}-test-execution-results.md`
-- **Summary**: Test execution completed with {passed}/{total} passed, {failed} failed, {skipped} skipped
-- **Next Step**: Dispatch to speccrew-test-reporter for report generation
-```
-
-## Failure Report
-```
-## Task Completion Report
-- **Status**: FAILED
-- **Task ID**: <from dispatch context>
-- **Platform**: <platform_id>
-- **Phase**: test_execution
-- **Output Files**: <list of partial outputs or "None">
-- **Summary**: Test execution failed during {step}
-- **Error**: <detailed error description>
-- **Error Category**: DEPENDENCY_MISSING | BUILD_FAILURE | VALIDATION_ERROR | RUNTIME_ERROR | BLOCKED
-- **Partial Outputs**: <list of partially generated files or "None">
-- **Recovery Hint**: <suggestion for recovery, e.g., "Check test dependencies are installed and test configuration is valid">
-```
+> **REQUIRED**: Before executing this workflow, read the XML workflow specification: speccrew-workspace/docs/rules/agentflow-spec.md
+> Then read and execute the XML workflow in SKILL.xml block-by-block as the authoritative execution plan.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "speccrew",
-  "version": "0.7.73",
+  "version": "0.7.75",
   "description": "Spec-Driven Development toolkit for AI-powered IDEs",
   "author": "charlesmu99",
   "repository": {

package/workspace-template/docs/rules/agentflow-spec.md

@@ -58,6 +58,8 @@ Executes an action. The primary execution block.
 | `generate` | Generate content | Output path |
 | `read-file` | Read file content | `<field name="path">` |
 | `write-file` | Write file content | `<field name="path">`, content |
+| `edit-file` | Edit existing file sections | `<field name="path">`, `<field name="section">` |
+| `verify` | Verify output completeness | `<field name="verification_rules">` |
 
 **Examples:**
 
@@ -349,19 +351,19 @@ Use `${variable_name}` syntax throughout block attributes and content.
 </block>
 ```
 
-## Dispatch Skill Execution Model
+## XML Workflow Execution Model
 
-Dispatch skills (naming pattern: `*-dispatch-xml`) are **orchestration playbooks** loaded directly by Team Leader via the Skill tool. They contain the complete multi-stage workflow definition.
+XML workflows are executed by **any agent** that loads and processes AgentFlow XML — including orchestrating agents (Team Leader, Product Manager, Feature Designer, System Designer) and worker agents (speccrew-task-worker). The execution protocol applies universally.
 
 ### Execution Protocol
 
-When Team Leader loads a dispatch skill via `action="run-skill"`:
+When an agent loads a workflow skill (via Skill tool or by reading SKILL.xml directly):
 
-1. **Load**: Team Leader invokes the Skill tool with the dispatch skill name (e.g., `speccrew-knowledge-bizs-dispatch-xml`)
+1. **Load**: The executing agent invokes the Skill tool with the dispatch skill name (e.g., `speccrew-knowledge-bizs-dispatch-xml`)
 2. **Parse**: Read and understand the complete AgentFlow XML workflow in the loaded SKILL.md
 3. **Execute block-by-block**: Walk through each Stage's blocks in document order, mapping each `action` attribute to the correct IDE tool:
 
-| Block Action | What Team Leader MUST Do |
+| Block Action | What The Executing Agent MUST Do |
 |---|---|
 | `action="run-script"` | Execute the command via **Terminal tool** (PowerShell/Bash) |
 | `action="run-skill"` | Invoke the skill via **Skill tool** — do NOT manually read SKILL.md files |
@@ -388,20 +390,34 @@ When executing `<block type="task">` blocks, the `action` attribute determines w
 | Action | IDE Tool to Use | How to Invoke |
 |--------|----------------|---------------|
 | `run-skill` | **Skill tool** | Call the IDE Skill tool with the skill name from `<field name="skill">`. Do NOT manually browse directories or read SKILL.md files — the Skill tool resolves paths automatically. |
-| `dispatch-to-worker` | **Task tool** | Create a new Task via the IDE Task tool, assigning it to the worker agent specified in `<field name="agent">`. Pass all context fields as task parameters. For `<loop parallel="true">`, create ALL tasks in a single batch. |
+| `dispatch-to-worker` | **Agent/Task tool** | Create a new worker agent session via the IDE's agent/task creation tool (e.g., Agent tool in Qoder, Task tool in other IDEs). Pass all context fields as worker parameters. For `<loop parallel="true">`, create ALL worker sessions in a single batch. |
 | `run-script` | **Bash / Terminal tool** | Execute the command from `<field name="command">` using the terminal tool. Use PowerShell syntax on Windows, Bash on Unix. |
 | `read-file` | **Read tool** | Read the file at the path specified in `<field name="path">`. |
 | `write-file` | **Write / Edit tool** | Write content to the file at `<field name="path">`. For new files use create_file; for modifications use search_replace. |
 | `analyze` | **Direct execution** | Perform the analysis described in the block's `desc` attribute. Read relevant source files, extract information, and store results in the specified output variables. |
-| `generate` | **Direct execution** | Generate the content described in the block. Use templates when specified, write output to the target path. |
+| `generate` | **Copy template + search_replace** | **Copy** the template file specified in `<field name="template">` to the output path, then **fill** placeholder sections using the IDE search_replace tool. Do NOT use create_file to write entire document content — large files will be truncated. Do NOT create helper scripts for template filling. |
+| `edit-file` | **search_replace tool** | Use the IDE's search_replace tool to perform targeted section replacement on the file at `<field name="path">`. Find the section header specified in `<field name="section">` and replace its placeholder content. Do NOT use terminal commands (node -e, sed) or create helper scripts — use ONLY the IDE search_replace tool. |
+| `verify` | **Read tool** | Read the output file and verify against `<field name="verification_rules">`. Check all sections are filled, no placeholders remain, and content meets quality criteria. |
 
 ### Critical Rules
 
 1. **`run-skill` MUST use the Skill tool** — NEVER manually search for or read SKILL.md files. The IDE Skill tool handles path resolution across different IDE directories (.qoder/, .cursor/, .claude/).
-2. **`dispatch-to-worker` MUST use the Task tool** — NEVER execute worker tasks yourself. Create a Task and let the worker agent handle it.
+2. **`dispatch-to-worker` MUST use the IDE's agent/task creation tool** — NEVER execute worker tasks yourself. Create a worker agent session (e.g., Agent tool in Qoder, Task tool in other IDEs) and let the worker agent handle it.
 3. **`<loop parallel="true">` with `dispatch-to-worker`** — Create ALL worker tasks in ONE batch call, not sequentially. This enables true parallel execution.
 4. **Variable binding** — After a tool call completes, bind the result to the variable specified in `<field name="output" var="..."/>` for use in subsequent blocks.
 
+### FORBIDDEN Tool Substitutions
+
+When executing XML workflow blocks, the following tool substitutions are strictly prohibited:
+
+1. **❌ Terminal commands for file editing**: Do NOT use `node -e`, `sed`, `awk`, or any terminal command to edit files when the block specifies `action="edit-file"`. MUST use the IDE's search_replace tool.
+2. **❌ Helper script creation**: Do NOT create .js/.sh/.ps1 helper scripts to automate template filling, batch processing, or any workflow step. Use IDE tools directly (search_replace, Read, Write).
+3. **❌ create_file for large documents**: Do NOT use create_file to write entire document content. Large files (>200 lines) WILL be truncated. MUST copy template then fill sections with search_replace.
+4. **❌ Full-file replacement**: Do NOT replace entire file content in a single search_replace operation. MUST perform targeted section-by-section replacements.
+5. **❌ Manual JSON creation for progress files**: Do NOT use create_file or write tools to create DISPATCH-PROGRESS.json, .checkpoints.json, or WORKFLOW-PROGRESS.json. MUST use update-progress.js script commands.
+
+**Rationale**: LLMs tend to create helper scripts or use terminal commands as "shortcuts" when faced with repetitive file editing tasks. These shortcuts bypass the IDE's built-in tools, produce inconsistent results, and violate the template-first workflow principle.
+
 ### Invocation Examples
 
 **Example 1: `action="run-script"` — Team Leader runs terminal command directly**
@@ -483,6 +499,38 @@ Team Leader executes:
 → Wait for all tasks to complete before proceeding
 ```
 
+**Example 5: `action="edit-file"` — Agent fills a template section using search_replace**
+
+Given this XML block:
+```xml
+<block type="task" id="B13" action="edit-file" desc="Fill Component Tree section">
+  <field name="path">${module_doc_created.path}</field>
+  <field name="operation">search_replace</field>
+  <field name="content_source">${feature_spec}${conventions_design}</field>
+  <field name="section">Component Tree</field>
+  <field name="rules">
+    - Use actual framework patterns
+    - ALL component trees MUST use Mermaid syntax
+    - Mark each component as [EXISTING], [MODIFIED], or [NEW]
+  </field>
+</block>
+```
+
+The executing agent MUST:
+```
+→ Use search_replace tool on the file at ${module_doc_created.path}
+→ Find the "## Component Tree" section (or matching template placeholder)
+→ Replace the placeholder content with actual component tree based on ${feature_spec} and ${conventions_design}
+→ Follow the rules specified in <field name="rules">
+```
+
+**FORBIDDEN approaches:**
+```
+❌ node -e "fs.readFileSync(...).replace(...)"   ← Terminal command for editing
+❌ Creating _fill-template.js script              ← Helper script
+❌ create_file with entire document content       ← Full file creation (truncation risk)
+```
+
 ## Execution Rules
 
 1. **NEVER skip a block** — execute every block in document order