@zeyue0329/xiaoma-cli 1.0.49 → 1.0.66

package/src/xmc/workflows/4-implementation/auto-story-pipeline/steps/step-06-test-story.md

@@ -0,0 +1,253 @@
+---
+name: "step-06-test-story"
+description: "Perform functional testing with real data using QA role"
+nextStepFile: "./step-08-complete-story.md"
+nextStepFile_fail: "./step-07-fix-and-retest.md"
+---
+
+# Step 6 of 9: QA Functional Testing
+
+**Goal:** Perform comprehensive functional testing using real data to verify all acceptance criteria are met.
+
+**Role:** QA (xiaoce) — Quality Assurance Engineer
+
+---
+
+## CORE TESTING PRINCIPLE
+
+**ALL tests MUST use real data. Mock data is strictly forbidden.**
+
+- Query APIs MUST return data from the actual database
+- Create operations MUST insert real records and verify in database
+- Update operations MUST modify real records and verify changes
+- Delete operations MUST remove/soft-delete real records and verify
+- End-to-end flows MUST validate the complete data pipeline
+
+---
+
+## EXECUTION SEQUENCE
+
+### 1. Switch to QA Role
+
+Adopt the QA persona:
+- You are xiaoce, the QA Engineer focused on functional correctness
+- Your mission: verify every acceptance criterion with real data
+- Zero tolerance for mock data or fake test passes
+- Test from the user's perspective — does it actually work?
+
+### 2. Load Story and Implementation Context
+
+1. Read the COMPLETE story file at `{current_story_path}`
+2. Extract all Acceptance Criteria
+3. Load the File List to identify all implementation files
+4. Load project context for testing standards
+
+### 3. Generate Automated Tests (Delegate)
+
+Invoke the `xiaoma-qa-generate-e2e-tests` skill to generate automated test files:
+
+**CRITICAL PIPELINE MODE INSTRUCTIONS:**
+- This is running in **automated pipeline mode** — do NOT pause for user input
+- Auto-detect the project's test framework (playwright, jest, vitest, cypress, etc.)
+- Auto-discover features from the story's implementation files
+- Generate API tests for any new/modified endpoints
+- Generate E2E tests for any new/modified UI features
+- Run the generated tests to verify they pass; fix any failures immediately
+
+If the project has no test framework or tests are not applicable for this story type, skip this step and proceed directly to functional verification.
+
+### 4. Execute Functional Test Sequence
+
+Perform tests in priority order:
+
+**4.1 Acceptance Criteria Verification**
+- For EACH acceptance criterion:
+  1. Design a test scenario that exercises the AC
+  2. Execute the test using real application flow
+  3. Verify expected outcomes against actual results
+  4. Record: PASS / FAIL with evidence
+
+**4.2 Database Operation Testing (Real Data)**
+- Query tests: Call API → verify response matches actual database state
+- Create tests: Call API → query database to verify record insertion
+- Update tests: Call API → query database to verify record modification
+- Delete tests: Call API → query database to verify record removal/soft-delete
+
+**4.3 API Contract Testing**
+- Verify request/response formats match specifications
+- Test error responses for invalid inputs
+- Validate authentication/authorization requirements
+- Check pagination, filtering, sorting if applicable
+
+**4.4 Business Logic End-to-End Testing**
+- Execute complete business workflows
+- Verify data flows correctly through all layers
+- Test boundary conditions and edge cases
+- Validate error handling and user-facing messages
+
+**4.5 Data Integrity Verification**
+- Verify referential integrity after operations
+- Check data consistency across related entities
+- Validate business rule enforcement at data level
+
+### 5. Compile Test Results
+
+Create a test results summary:
+- Total ACs tested: {ac_count}
+- ACs passed: {ac_pass_count}
+- ACs failed: {ac_fail_count}
+- Issues found: List with severity (HIGH/MEDIUM/LOW)
+- Overall gate decision: PASS / FAIL
+
+### 6. Evaluate Test Outcome
+
+**IF all ACs pass AND no HIGH severity issues:**
+- Output: "QA testing PASSED. All {ac_count} acceptance criteria verified with real data. Proceeding to completion."
+- **NEXT:** Proceed to step-08 (complete story) [frontmatter: nextStepFile]
+
+**IF any AC fails OR HIGH severity issues found:**
+- Output: "QA testing FAILED. {ac_fail_count} acceptance criteria not met. Issues: {issue_list}"
+- Record test failures in story file under QA Results section
+- Set `{fix_source}` = "qa-testing" (this variable will be used in step-07 to route fixes directly to step-08 after correction, since QA issues often don't require code review re-entry)
+- **NEXT:** Proceed to step-07 (fix and retest) [frontmatter: nextStepFile_fail]
+
+### 7. Pipeline Status Update
+
+- Set `{pipeline_status}` = "qa-testing-complete" (if passed) or "qa-testing-failed" (if failed)
+- Set `{steps_completed}` = `{steps_completed}` + 1
+
+---
+
+## NEXT STEP
+
+**If tests pass:**
+**NEXT:** Read fully and follow: `{project-root}/_xiaoma/xmc/workflows/4-implementation/auto-story-pipeline/steps/step-08-complete-story.md`
+
+**If tests fail:**
+**NEXT:** Read fully and follow: `{project-root}/_xiaoma/xmc/workflows/4-implementation/auto-story-pipeline/steps/step-07-fix-and-retest.md`
+
+---
+
+## SUCCESS METRICS
+
+- All acceptance criteria tested with real data
+- All database operations verified against actual database state
+- API contracts validated with real requests/responses
+- End-to-end business flows tested
+- No mock data used in any test
+- PASS gate decision achieved
+
+## FAILURE MODES
+
+- Using mock data instead of real database queries
+- Skipping acceptance criteria during testing
+- Not verifying database state after write operations
+- Marking tests as PASS without evidence
+
+---
+
+## 测试失败处理流程 (Test Failure Handling)
+
+**当任何acceptance criteria失败时:**
+
+### 1. 失败分类 (Categorize Failures)
+
+对每个失败进行分类:
+
+- **Type A - AC Failure (接受标准失败)**: 核心功能没有达到预期
+  - 示例: 应该返回值X，实际返回值Y
+  - 路由: → step-07 (fix-and-retest)
+  
+- **Type B - Data Integrity Issue (数据完整性问题)**: 数据库状态不正确
+  - 示例: 记录未保存或数据损坏
+  - 路由: → step-07 (fix-and-retest) 并标记为HIGH优先级
+  
+- **Type C - Performance Issue (性能问题)**: 功能正常但超过性能阈值
+  - 示例: API响应时间 > 2秒
+  - 路由: → step-07 (fix-and-retest) 但标记为MEDIUM优先级
+  
+- **Type D - Environment/Test Setup Issue (环境问题)**: 测试环境配置问题
+  - 示例: 数据库连接失败、假数据缺失
+  - 路由: → 修复测试环境，然后重新运行tests
+
+### 2. 重试策略 (Retry Strategy)
+
+**对于Type A和B失败:**
+- 在step-07中作为HIGH优先级修复
+- 每个Type A/B失败最多重试1次在step-06（re-run tests）
+  
+**对于Type C失败（仅性能）:**
+- 如果只有Type C失败，可以有条件地PASS
+- 但必须在story文件中记录性能问题
+- 标记为"KNOWN_PERFORMANCE_ISSUE"
+- 移至backlog作为future optimization
+- 仅在Type A/B都PASS时允许带Type C继续
+
+**对于Type D失败:**
+- 不计入fix iteration（fix-and-retest）
+- 修复测试环境
+- 立即重新运行测试
+
+### 3. 测试覆盖率阈值 (Coverage Thresholds)
+
+**强制要求:**
+- 单元测试覆盖率: >= 75%
+- 集成测试覆盖率: >= 60%
+- 接受标准覆盖率: 100% (所有AC必须有至少1个测试)
+
+**如果未达到:**
+- 不允许进入step-07
+- 回到开发阶段添加缺失的tests
+- Type: AC-Incomplete failure → 标记story为"NEEDS_MORE_TESTS"
+
+### 4. 记录失败详情 (Document Failures)
+
+在Story文件的"QA Results"部分记录:
+
+```markdown
+## QA Results
+
+**Overall Status:** FAILED - 2/5 ACs passed
+
+### Failed Tests
+- **AC#2 (Type A):** [Description] 
+  - Expected: [X]
+  - Actual: [Y]
+  - Root Cause: [Analysis]
+  - Fix Priority: HIGH
+  
+- **AC#4 (Type C):** [Performance]
+  - Threshold: 1s
+  - Actual: 2.3s
+  - Fix Priority: MEDIUM (Known issue, defer if needed)
+
+### Coverage Summary
+- Unit: 72% (Below 75% threshold)
+- Integration: 65%
+- AC Coverage: 100%
+
+### Recommended Next Step
+- Re-run step-07 to fix AC#2 (HIGH)
+- Consider Type C as known limitation unless time allows
+```
+
+### 5. 条件通过规则 (Conditional Pass)
+
+故事可以在以下条件下**有条件通过**到step-07:
+
+✅ **全部Type A/B失败已解决**
+✅ **至少80%的接受标准通过** 
+✅ **无Critical数据完整性问题**
+❌ **Type C (性能)失败不阻止进度** (但需要记录)
+❌ **测试覆盖率 < 60% 则必须返回修复**
+
+### 6. 向step-07传递信息 (Hand-off to step-07)
+
+设置以下变量供step-07使用:
+
+```
+{fix_source} = "qa-testing"
+{failure_categories} = [Type A count, Type B count, Type C count]
+{high_priority_issues} = [list]
+{performance_known_issues} = [list]  // For conditional pass scenarios
+```

package/src/xmc/workflows/4-implementation/auto-story-pipeline/steps/step-07-fix-and-retest.md

@@ -0,0 +1,237 @@
+---
+name: "step-07-fix-and-retest"
+description: "Fix bugs found in review/testing, then re-run tests. Self-referencing loop with max 5 iterations."
+nextStepFile: "./step-08-complete-story.md"
+nextStepFile_loop: "./step-07-fix-and-retest.md"
+---
+
+# Step 7 of 9: Fix and Retest
+
+**Goal:** Analyze failures from code review or QA testing, apply targeted fixes, and re-run tests. This step loops until all issues are resolved or the iteration limit is reached.
+
+**Role:** Dev (xiaokai) — Bug Fixer
+
+---
+
+## CONFIGURATION
+
+Load from `{project-root}/_xiaoma/xmc/config.yaml`:
+- `max_fix_iterations` (default: 5) — Maximum number of fix-and-retest cycles allowed per story
+- If not specified in config, use default value of 5
+
+Set `{max_fix_iterations}` from config (or default 5).
+
+## LOOP CONTROL
+
+1. Increment `{fix_iteration}` by 1
+2. **IF `{fix_iteration}` > `{max_fix_iterations}`:**
+   - HALT — "Fix iteration limit reached ({max_fix_iterations} attempts) for story {current_story_key}. Remaining issues: {unresolved_issues}. Manual intervention required."
+   - Output a summary of all fix attempts and remaining issues
+   - **DO NOT CONTINUE** — This is a hard stop
+
+3. Set `{steps_completed}` = `{steps_completed}` + 1
+4. Output: "Fix Iteration {fix_iteration}/{max_fix_iterations} for story {current_story_key}"
+
+---
+
+## EXECUTION SEQUENCE
+
+### 1. Switch to Dev Role
+
+Adopt the Dev persona:
+- You are xiaokai, focused on precise bug fixing
+- Analyze root causes, not just symptoms
+- Fix issues without introducing regressions
+
+### 2. Analyze Failure Context
+
+1. Read the COMPLETE story file at `{current_story_path}`
+2. Identify the source of failures and set `{fix_source}`:
+   - Code review findings (from step-05): Check Dev Agent Record for review issues → `{fix_source}` = "code-review"
+   - QA test failures (from step-06): Check QA Results section for test failures → `{fix_source}` = "qa-testing"
+   - Mixed (both code review and QA issues): → `{fix_source}` = "mixed"
+3. Record `{fix_source}` — this determines post-fix routing (see section 6)
+4. Compile a prioritized fix list:
+   - **Priority 1:** HIGH severity issues / failed acceptance criteria
+   - **Priority 2:** MEDIUM severity issues / partial AC failures
+   - **Priority 3:** LOW severity issues (fix if time permits)
+
+### 3. Build Fix Plan
+
+For each issue in priority order:
+1. Identify the root cause (not just the symptom)
+2. Determine the minimal fix that resolves the issue
+3. Identify which tests need to be added/updated
+4. Check for potential ripple effects on other components
+
+### 4. Apply Fixes
+
+For each fix in the plan:
+1. Implement the code fix
+2. Add or update tests to cover the fixed behavior
+3. Run the specific test to verify the fix works
+4. Run the full test suite to verify no regressions
+5. Update the story file:
+   - Add fix details to Dev Agent Record → Debug Log
+   - Update File List with modified files
+   - Add Change Log entry: "Fix iteration {fix_iteration}: {fix_summary}"
+
+### 5. Re-Run Full Validation
+
+After all fixes are applied:
+
+1. Run all unit tests
+2. Run all integration tests
+3. Run full regression suite
+4. Re-verify each previously failed acceptance criterion
+
+### 6. Evaluate Fix Results
+
+**IF all tests pass AND all previously failed ACs now pass:**
+- Output: "All issues resolved in fix iteration {fix_iteration}. Tests passing."
+- Determine routing based on `{fix_source}`:
+  - **IF `{fix_source}` == "code-review" or "mixed":** Run a targeted code re-check: re-verify that the specific code-review HIGH/MEDIUM issues are genuinely resolved (no full re-delegation required — do a focused inline verification of the fixed areas). If verified clean: **NEXT:** Proceed to step-08 (complete story). If new issues surface: Loop back to step-07.
+  - **IF `{fix_source}` == "qa-testing":** **NEXT:** Proceed to step-08 (complete story) directly — no additional code review needed.
+
+**IF some issues remain:**
+- Output: "Fix iteration {fix_iteration} resolved {fixed_count} issues. {remaining_count} issues remain: {remaining_list}"
+- **NEXT:** Loop back to this step (step-07) for another iteration
+
+---
+
+## NEXT STEP
+
+**If all issues resolved AND (`{fix_source}` == "qa-testing" OR post-fix code re-check passed):**
+**NEXT:** Read fully and follow: `{project-root}/_xiaoma/xmc/workflows/4-implementation/auto-story-pipeline/steps/step-08-complete-story.md`
+
+**If all issues resolved but post-fix code re-check surfaced new issues (`{fix_source}` was "code-review" or "mixed"):**
+**NEXT:** Read fully and follow: `{project-root}/_xiaoma/xmc/workflows/4-implementation/auto-story-pipeline/steps/step-07-fix-and-retest.md`
+
+**If issues remain and `{fix_iteration}` <= `{max_fix_iterations}`:**
+**NEXT:** Read fully and follow: `{project-root}/_xiaoma/xmc/workflows/4-implementation/auto-story-pipeline/steps/step-07-fix-and-retest.md`
+
+---
+
+## SUCCESS METRICS
+
+- All HIGH and MEDIUM issues resolved
+- All previously failed acceptance criteria now pass
+- Full test suite passes with no regressions
+- Fix details documented in story file
+- Resolution achieved within `{max_fix_iterations}` iterations
+
+## FAILURE MODES
+
+- Fixing symptoms instead of root causes (leads to recurring failures)
+- Introducing new regressions while fixing existing issues
+- Exceeding `{max_fix_iterations}` fix iterations without resolution
+- Not running regression tests after each fix
+
+---
+
+## 当超过最大修复迭代次数 (Escalation Path: Beyond Max Fix Iterations)
+
+**触发条件:** `{fix_iteration}` > `{max_fix_iterations}` (默认 > 5)
+
+**Escalation Protocol:**
+
+### 1. 生成Escalation Report
+
+文档所有修复尝试和失败原因:
+
+```
+ESCALATION REPORT: Story {current_story_key}
+==========================================
+Status: FIX LIMIT EXCEEDED
+Fix Iterations Attempted: {max_fix_iterations}
+Unresolved Issues:
+  - [Issue 1]: [Root Cause Analysis]
+  - [Issue 2]: [Root Cause Analysis]
+  
+Pattern Analysis:
+  - Recurring issue? [Yes/No] — [Description]
+  - Root cause identified? [Yes/No]
+  - Architectural blocker? [Yes/No]
+  
+Timeline Impact: [number] days
+Recommended Action: [A/B/C below]
+```
+
+### 2. 通知团队 (Owner Notification)
+
+发送通知至:
+- **Primary:** Story Owner / Scrum Master (xiaofen)
+- **Secondary:** Tech Lead / Architect (xiaojia)
+
+**Notification Template:**
+
+```
+URGENT: Story {current_story_key} - Fix Limit Reached
+
+Summary: After {max_fix_iterations} fix iterations, the following issues remain unresolved:
+- [Issue list]
+
+Root Cause Analysis:
+- [Analysis summary]
+
+Recommended Actions:
+A) Mark as "Blocked" - Investigate architectural changes needed
+B) Reduce scope - Defer failing AC to next iteration  
+C) Re-assign to Tech Lead for deep investigation
+D) Revert changes and restart implementation from scratch
+
+Timeline: Requires decision within [4 hours / 1 day]
+Severity: BLOCKING SPRINT PROGRESS
+```
+
+### 3. 处理选项 (Handling Options)
+
+**选项 A - 标记为Blocked:**
+- 更新story状态为 `BLOCKED_INVESTIGATION`
+- 记录blocking factors
+- Escalate to Architect (xiaojia) for architectural review
+- 移出当前sprint backlog
+
+**选项 B - 缩小范围 (Reduce Scope):**
+- 识别哪些acceptance criteria无法在{max_fix_iterations}内完成
+- 将这些AC移至"acceptance-criteria-deferred"部分
+- 标记为"READY_FOR_TESTING"（简化的AC集合）
+- 继续进入step-08
+
+**选项 C - 重新分配 (Tech Lead Deep Dive):**
+- 暂停当前story处理
+- 分配给Tech Lead (xiaojia) 进行深度root cause分析
+- 预计时间: 2-4小时的深度分析
+- 结果: 要么找到fix，要么confirm需要选项A或B
+
+**选项 D - 重新开始 (Fresh Start):**
+- 回退所有代码更改到step-04开始前的状态
+- 重新执行step-04到step-07
+- 仅在其他选项都不可行时使用
+- 添加至"lessons learned"文档
+
+### 4. Story状态管理
+
+**设置Story Meta字段:**
+```
+escalation_status: ESCALATED
+escalation_date: {current_timestamp}
+escalation_owner: {person_assigned}
+recommended_action: [A/B/C/D]
+estimated_resolution_time: [hours]
+```
+
+### 5. 防止进度堵塞 (Prevent Sprint Blocking)
+
+- 不允许story卡在此步骤超过{max_fix_iterations} + 4小时
+- 自动移至Scrum Master队列以处理escalation
+- 在sprint status中标记为"NEEDS_DECISION"
+- 不将此issue计入sprint velocity（因为未完成）
+
+### 6. 恢复进度 (Recovery Process)
+
+一旦Escalation决策完成:
+- 如果选择 A: Story移至 `BLOCKED` 状态，等待Architect反馈
+- 如果选择 B: 回到step-08 (complete story)，使用简化的AC集合
+- 如果选择 C: Architect执行分析，结果完成后回到step-07
+- 如果选择 D: Story重置到step-04，重新开始整个cycle

package/src/xmc/workflows/4-implementation/auto-story-pipeline/steps/step-08-complete-story.md

@@ -0,0 +1,114 @@
+---
+name: "step-08-complete-story"
+description: "Mark story as done, update sprint-status, and generate completion summary"
+nextStepFile: "./step-09-finalize.md"
+---
+
+# Step 8 of 9: Complete Story
+
+**Goal:** Mark the story as done, sync all tracking artifacts, and generate a completion summary.
+
+**Role:** Pipeline Orchestrator
+
+---
+
+## EXECUTION SEQUENCE
+
+### 1. Final Validation
+
+Before marking complete, verify all gates:
+1. **Fresh Read:** Read the COMPLETE story file at `{current_story_path}` directly from disk (not from cache or prior state). This is critical because step-07 may have modified the file (e.g., updated task checkboxes, changed story status), and you MUST verify the current on-disk state, not a stale in-memory version.
+2. Verify ALL tasks and subtasks are marked [x], [X], or [✓] (case-insensitive, all formats accepted)
+3. Verify ALL acceptance criteria have been tested and passed
+4. Verify no unresolved HIGH or MEDIUM issues remain
+5. Verify the full test suite passes
+
+If any gate fails: **DO NOT mark as done** — return to the appropriate step:
+- Incomplete tasks → step-04 (develop)
+- Failed tests → step-07 (fix and retest)
+- Unresolved review issues → step-07 (fix and retest)
+
+### 2. Update Story Status
+
+1. Update the story Status field to "done"
+2. Add completion timestamp to Dev Agent Record
+3. Add final Change Log entry: "Story completed via auto-pipeline on {date}"
+4. Save the story file
+
+### 3. Update Sprint Status
+
+1. Load the FULL file: `{sprint_status}`
+2. Find `development_status` key matching `{current_story_key}`
+3. Update `development_status[{current_story_key}]` = "done"
+4. Update `last_updated` field to current date
+5. Save file, preserving ALL comments and structure
+
+### 4. Check Epic Completion
+
+1. Extract `{epic_num}` from `{current_story_key}` using pattern matching:
+   - Pattern: story key must match `{epic_num}-{story_num}-{name}` where epic_num and story_num are positive integers
+   - Extract: Read first numeric component before first dash
+   - Example: "1-2-user-auth" → epic_num = "1"
+   - Example: "12-3-payment-flow" → epic_num = "12"
+   - Skip keys that don't match pattern (e.g., "epic-1-retrospective" is an epic marker, not a story)
+   - If key doesn't match expected pattern: Output WARNING — "Could not extract epic number from {current_story_key}. Skipping epic completion check." and skip to section 5
+   - If extraction fails for any reason: Continue without epic update (non-blocking)
+2. In sprint-status.yaml, find all stories for epic `{epic_num}` (pattern: `{epic_num}-*`, excluding epic markers like `epic-{epic_num}` and retrospectives like `epic-{epic_num}-retrospective`)
+3. Check if ALL stories in this epic have status "done"
+4. If all stories are done:
+   - Update `development_status[epic-{epic_num}]` = "done"
+   - Output: "Epic {epic_num} fully completed! All stories are done."
+5. If some stories remain:
+   - Output: "Epic {epic_num}: {done_in_epic}/{total_in_epic} stories completed."
+
+### 5. Generate Completion Summary
+
+Increment `{stories_completed}` by 1
+
+Output:
+```
+Story {current_story_key} — COMPLETED
+
+Summary:
+- Story: {story_title}
+- File: {current_story_path}
+- Status: done
+- Fix Iterations Used: {fix_iteration}
+- Stories Completed This Pipeline Run: {stories_completed}
+
+Pipeline Phases Completed:
+  [x] Story Creation (SM)
+  [x] Story Validation (PM)
+  [x] Development (Dev)
+  [x] Code Review (Reviewer)
+  [x] QA Testing (QA)
+  [x] Status Updated (done)
+```
+
+### 6. Pipeline Status Update
+
+- Set `{pipeline_status}` = "story-completed"
+- Set `{steps_completed}` = `{steps_completed}` + 1
+
+---
+
+## NEXT STEP
+
+**NEXT:** Read fully and follow: `{project-root}/_xiaoma/xmc/workflows/4-implementation/auto-story-pipeline/steps/step-09-finalize.md`
+
+---
+
+## SUCCESS METRICS
+
+- Story status set to "done" in story file
+- Sprint-status.yaml updated with "done" for story key
+- Epic completion checked and updated if applicable
+- Completion summary generated
+- `{stories_completed}` counter incremented
+
+## FAILURE MODES
+
+- Marking story done without verifying all gates
+- Not updating sprint-status.yaml
+- Not checking epic-level completion
+- Not generating completion summary

package/src/xmc/workflows/4-implementation/auto-story-pipeline/steps/step-09-finalize.md

@@ -0,0 +1,69 @@
+---
+name: "step-09-finalize"
+description: "Finalize the single-story pipeline run and output completion report."
+nextStepFile: null
+---
+
+# Step 9 of 9: Pipeline Finalization
+
+**Goal:** Generate the final completion report for this single-story pipeline run.
+
+**Role:** Pipeline Orchestrator
+
+---
+
+## EXECUTION SEQUENCE
+
+### 1. Refresh Sprint Status
+
+1. Load the FULL file: `{sprint_status}`
+2. Read ALL lines from beginning to end — do not skip any content
+3. Recount all stories by current status:
+   - `{backlog_count}` — Stories with status "backlog"
+   - `{ready_count}` — Stories with status "ready-for-dev"
+   - `{in_progress_count}` — Stories with status "in-progress"
+   - `{review_count}` — Stories with status "review"
+   - `{done_count}` — Stories with status "done"
+
+### 2. Generate Final Report
+
+Output:
+```
+Auto Story Pipeline — COMPLETE
+
+Pipeline Summary:
+- Mode: single
+- Story Processed: {current_story_key}
+- Steps Executed: {steps_completed}
+- Pipeline Status: finalized
+
+Sprint Status (current):
+- Backlog: {backlog_count} remaining
+- Ready for Dev: {ready_count}
+- In Progress: {in_progress_count}
+- In Review: {review_count}
+- Done: {done_count}
+
+The automated story development pipeline has finished.
+```
+
+**IF `{backlog_count}` == 0 AND `{ready_count}` == 0 AND `{in_progress_count}` == 0 AND `{review_count}` == 0:**
+- Output: "All stories in the sprint are complete! Consider running epic-retrospective (ER) to review the work."
+
+**IF `{backlog_count}` > 0 OR `{ready_count}` > 0:**
+- Output: "There are still {backlog_count + ready_count} pending stories. Run ASPB (`/xiaoma-auto-story-pipeline-batch`) to process all remaining stories in batch mode, or run ASP again to process the next story."
+
+**HALT** — Pipeline complete.
+
+---
+
+## SUCCESS METRICS
+
+- Final sprint status refreshed from disk
+- Comprehensive completion report generated
+- User informed of remaining stories and next steps
+
+## FAILURE MODES
+
+- Not refreshing sprint status before generating report
+- Skipping final report generation