@zeyue0329/xiaoma-cli 1.0.49 → 1.0.66

package/src/xmc/workflows/4-implementation/auto-story-pipeline/steps/step-01-init-and-validate.md

@@ -0,0 +1,173 @@
+---
+name: "step-01-init-and-validate"
+description: "Validate environment prerequisites, initialize state variables, and select pipeline mode (single/resume only)"
+nextStepFile: "./step-02-create-story.md"
+---
+
+# Step 1 of 9: Initialize and Validate Environment
+
+**Goal:** Verify all prerequisites are met, initialize pipeline state variables, and select the story to process (single or resume mode).
+
+**Role:** Pipeline Orchestrator
+
+---
+
+## EXECUTION SEQUENCE
+
+### 1. Validate Prerequisites
+
+Check that the following required artifacts exist:
+
+1. **Epics File** — `{planning_artifacts}/*epic*.md` must exist
+   - If missing: HALT — "No epics file found. Run the planning workflow first to create epics."
+
+2. **Sprint Status File** — `{sprint_status}` must exist
+   - If missing:
+     a. Output INFO — "sprint-status.yaml not found. Auto-generating via Sprint Planning..."
+     b. Verify epics file exists (checked in step 1 above) — if epics are present, proceed with auto-generation
+     c. Read and follow the sprint-planning workflow: `{project-root}/_xiaoma/xmc/workflows/4-implementation/xiaoma-sprint-planning/workflow.md`
+     d. Execute the sprint-planning workflow fully — it will parse epics, detect story statuses, and generate `{sprint_status}`
+     e. After sprint-planning completes, verify `{sprint_status}` now exists
+     f. If `{sprint_status}` still does not exist after auto-generation attempt: HALT — "Failed to auto-generate sprint-status.yaml. Check that epics are correctly formatted and try running Sprint Planning (SP) manually: /xiaoma-sprint-planning"
+     g. Output INFO — "sprint-status.yaml auto-generated successfully. Continuing pipeline..."
+
+3. **Planning Artifacts** — At least one of `{planning_artifacts}/*prd*.md` or `{planning_artifacts}/*architecture*.md` should exist
+   - If missing: Output warning but continue — "Planning documents not found. Story creation may have limited context."
+
+4. **Requirements Pipeline Status** *(Optional — recommended check)* — If `{planning_artifacts}/pipeline-status.json` exists, read it and verify the `status` field equals "complete"
+   - If file exists AND `status` != "complete": Output WARNING — "pipeline-status.json found but requirements pipeline did not complete successfully (status: {status}). Story pipeline may proceed, but planning artifacts may be incomplete. Consider rerunning AR (Auto Requirements) first."
+   - If file does not exist: Output INFO — "pipeline-status.json not found. Assuming planning was done outside auto-requirements-pipeline. Continuing."
+   - *(Note: This is a non-blocking check. The pipeline continues regardless — it is informational only, to prevent silently working from incomplete requirements.)*
+
+### 2. Analyze Sprint Status
+
+1. Load the FULL file: `{sprint_status}`
+2. Read ALL lines from beginning to end — do not skip any content
+3. Parse the `development_status` section completely
+4. Count stories by 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"
+
+5. If `{backlog_count}` == 0 AND `{ready_count}` == 0:
+   - HALT — "No backlog or ready-for-dev stories found. All stories are either in-progress, in review, or done."
+
+### 3. Initialize State Variables
+
+- Set `{fix_iteration}` = 0
+- Set `{stories_completed}` = 0
+- Set `{steps_completed}` = 0
+- Set `{pipeline_status}` = "initializing"
+
+### 4. Select Pipeline Mode
+
+**Check if the user provided a pipeline mode argument at invocation time** (e.g., "ASP single", "ASP resume <story-key>"):
+
+- If the user specified **single** or **S**: Set `{pipeline_mode}` = "single"
+- If the user specified **resume** or **R** with a story key: Set `{pipeline_mode}` = "resume", Set `{current_story_key}` from the provided key
+- If the user specified **batch** or **B**: Output INFO — "Batch mode has been moved to a dedicated skill. Please use **ASPB** (`/xiaoma-auto-story-pipeline-batch`) for batch processing of all stories." — HALT
+- **If no mode was provided by the user**: Default to `{pipeline_mode}` = "single" (process the next backlog story) — DO NOT pause to ask
+
+Output sprint status summary (do NOT wait for user input):
+
+**Output:**
+```
+Pipeline Environment Validated
+
+Sprint Status Summary:
+- Backlog: {backlog_count} stories
+- Ready for Dev: {ready_count} stories
+- In Progress: {in_progress_count} stories
+- Review: {review_count} stories
+- Done: {done_count} stories
+
+Pipeline Mode: {pipeline_mode} (single story)
+```
+
+Set `{steps_completed}` = 1
+Set `{pipeline_status}` = "initialized"
+
+Then resolve `{current_story_key}`:
+
+- IF `{pipeline_mode}` == "single" AND `{current_story_key}` not yet set:
+  - Find the FIRST story with status "backlog" (or "ready-for-dev" if no backlog)
+  - Set `{current_story_key}` from the found story
+- IF `{pipeline_mode}` == "resume" AND `{current_story_key}` was provided:
+  - Verify story exists in sprint-status.yaml — HALT if not found
+
+After resolving `{current_story_key}`, derive the story file path:
+- Set `{current_story_path}` = `{implementation_artifacts}/{current_story_key}.md`
+
+### 4.5. Resume State Validation
+
+If `{current_story_key}` was provided via resume (user specified a specific story key):
+
+1. Verify story exists in sprint-status.yaml — HALT if not found: "Story {current_story_key} not found in sprint-status.yaml."
+2. Read the story file at `{current_story_path}` (if it exists)
+3. Verify story status is one of: "backlog", "ready-for-dev", "in-progress", "review"
+4. If status is "done":
+   - HALT — "Cannot resume on story {current_story_key} with status 'done'. Done stories cannot be re-opened. Use 'ASP resume {other-story-key}' with a different story key, or run ASP without specifying a story to process the next pending story."
+5. If the story file exists, verify it contains at least basic required sections (Story, Status, Tasks)
+   - If sections are missing: Output WARNING — "Story file for {current_story_key} may be incomplete. Proceeding with caution."
+
+### 4.6. In-Progress Story Quality Check
+
+For stories with status == "in-progress", verify minimum work has begun:
+
+1. Read the story file at `{current_story_path}`
+2. Count completed tasks: look for `[x]`, `[X]`, or `[✓]` markers in Tasks/Subtasks section (case-insensitive match — any of these formats indicate a completed task)
+3. If completed_tasks == 0:
+   - Output WARNING: "Story {current_story_key} is marked in-progress but has no completed tasks. This may indicate an abandoned development session."
+   - Recommend: "Consider resetting to 'ready-for-dev' if development was not actually started."
+   - Continue anyway (do not HALT — non-blocking warning)
+4. If completed_tasks > 0:
+   - Output: "Story {current_story_key} is in-progress with {completed_tasks} tasks completed. Resuming development..."
+
+### 5. Determine Starting Step
+
+Based on the current status of `{current_story_key}`:
+
+- If status == "backlog": Start at step-02 (create story)
+- If status == "ready-for-dev": Start at step-03 (validate story) — story was created but must pass pipeline validation before development
+- If status == "in-progress": Skip to step-04 (develop story) — resume development
+- If status == "review": Skip to step-05 (code review) — resume review
+- If status == "done": HALT — "Story {current_story_key} is already done. No action needed. Use 'ASP resume {other-story-key}' with a different story key, or run ASP without specifying a story to process the next pending story."
+
+---
+
+## NEXT STEP
+
+Based on the starting step determined in section 5 above, proceed to the correct step — **do NOT default to step-02 if section 5 indicates a different starting point**:
+
+**IF starting at step-02 (story status == "backlog"):**
+**NEXT:** Read fully and follow: `{project-root}/_xiaoma/xmc/workflows/4-implementation/auto-story-pipeline/steps/step-02-create-story.md`
+
+**IF starting at step-03 (story status == "ready-for-dev"):**
+**NEXT:** Read fully and follow: `{project-root}/_xiaoma/xmc/workflows/4-implementation/auto-story-pipeline/steps/step-03-validate-story.md`
+
+**IF starting at step-04 (story status == "in-progress"):**
+**NEXT:** Read fully and follow: `{project-root}/_xiaoma/xmc/workflows/4-implementation/auto-story-pipeline/steps/step-04-develop-story.md`
+
+**IF starting at step-05 (story status == "review"):**
+**NEXT:** Read fully and follow: `{project-root}/_xiaoma/xmc/workflows/4-implementation/auto-story-pipeline/steps/step-05-code-review.md`
+
+---
+
+## SUCCESS METRICS
+
+- All prerequisites validated
+- Sprint status parsed and summarized
+- `{pipeline_mode}` set
+- `{current_story_key}` identified
+- `{current_story_path}` derived from `{current_story_key}`
+- State variables initialized
+- Correct starting step determined (backlog→step-02, ready-for-dev→step-03, in-progress→step-04, review→step-05)
+
+## FAILURE MODES
+
+- Proceeding without sprint-status.yaml AND without auto-generating it
+- Auto-generation of sprint-status.yaml fails silently without HALT
+- Not initializing state variables
+- No backlog or ready-for-dev stories found

package/src/xmc/workflows/4-implementation/auto-story-pipeline/steps/step-02-create-story.md

@@ -0,0 +1,102 @@
+---
+name: "step-02-create-story"
+description: "Create the user story using SM role, delegating to create-story workflow logic"
+nextStepFile: "./step-03-validate-story.md"
+input_variables:
+  - "epic_key"
+  - "story_template"
+output_variables:
+  - "created_story"
+  - "story_details"
+  - "story_metadata"
+---
+
+# Step 2 of 9: Create User Story
+
+**Goal:** Create a comprehensive user story file with full implementation context using the SM (Scrum Master) role.
+
+**Role:** SM (xiaomin) — Story Context Engine
+
+---
+
+## EXECUTION SEQUENCE
+
+### 1. Check if Story Already Exists
+
+1. Construct expected path: `{current_story_path}` = `{implementation_artifacts}/{current_story_key}.md`
+2. Verify path exists and is a readable file
+   - If path doesn't exist: Proceed to creation (section 2)
+   - If path exists but is not readable: HALT — "Story file exists but cannot be read: {current_story_path}. Check file permissions."
+3. If story file exists and is readable:
+   - Read the story file header including Status field
+   - If status is "ready-for-dev" or later: Skip creation
+   - Output: "Story {current_story_key} already exists with status '{status}'. Using existing story file."
+   - Set `{current_story_path}` = confirmed path
+   - Verify file contains required sections (Story, Status, Tasks) before proceeding
+   - If required sections missing: Output WARNING — "Story file exists but may be incomplete. Re-creating."  — Proceed to creation (section 2) instead of skipping
+   - **NEXT:** Read fully and follow: `{project-root}/_xiaoma/xmc/workflows/4-implementation/auto-story-pipeline/steps/step-03-validate-story.md`
+
+### 2. Switch to SM Role
+
+Adopt the SM (Scrum Master) persona:
+- You are xiaomin, the Technical Scrum Master + Story Preparation Specialist
+- Your purpose is to create a comprehensive story file that gives the dev agent everything needed for flawless implementation
+- Communication style: Crisp and checklist-driven
+
+### 3. Execute Story Creation
+
+Invoke the `xiaoma-create-story` skill to create the story.
+
+Key parameters to pass:
+- Story key: `{current_story_key}`
+- Auto-discovered from sprint-status (no user input needed for story selection)
+- Output file: `{implementation_artifacts}/{current_story_key}.md`
+
+**CRITICAL:** The create-story workflow will:
+1. Load and analyze all planning artifacts (epics, PRD, architecture, UX)
+2. Extract story requirements and context
+3. Analyze previous story intelligence
+4. Research latest technical specifics
+5. Create the comprehensive story file from template
+6. Set story status to "ready-for-dev"
+7. Update sprint-status.yaml
+
+### 4. Verify Creation Output
+
+After create-story workflow completes:
+1. Verify story file exists at expected path
+2. Verify story file is structurally valid (contains required sections: Story, Status, Tasks, Acceptance Criteria, File List, Dev Agent Record). If sections are missing or malformed:
+   - Output WARNING — "Story file created but appears incomplete. Missing sections: {section_list}. Re-running create-story workflow."
+   - Retry the workflow (max 2 attempts) or HALT if retries exhausted
+3. Verify story status is "ready-for-dev"
+4. Store `{current_story_path}` = path to the created story file
+
+If creation failed:
+- HALT — "Story creation failed for {current_story_key}. Check planning artifacts and retry."
+
+### 5. Pipeline Status Update
+
+- Set `{pipeline_status}` = "story-created"
+- Set `{steps_completed}` = `{steps_completed}` + 1
+- Output: "Story {current_story_key} created successfully. Proceeding to validation."
+
+---
+
+## NEXT STEP
+
+**NEXT:** Read fully and follow: `{project-root}/_xiaoma/xmc/workflows/4-implementation/auto-story-pipeline/steps/step-03-validate-story.md`
+
+---
+
+## SUCCESS METRICS
+
+- Story file created at `{implementation_artifacts}/{current_story_key}.md`
+- Story status set to "ready-for-dev"
+- Sprint-status.yaml updated
+- `{current_story_path}` variable set
+
+## FAILURE MODES
+
+- Missing planning artifacts preventing story creation
+- Story creation exceeding 3 retry attempts
+- Template not found at expected path

package/src/xmc/workflows/4-implementation/auto-story-pipeline/steps/step-03-validate-story.md

@@ -0,0 +1,107 @@
+---
+name: "step-03-validate-story"
+description: "Validate story quality using PM role with 10-step verification process"
+nextStepFile: "./step-04-develop-story.md"
+---
+
+# Step 3 of 9: Validate User Story
+
+**Goal:** Perform comprehensive quality validation of the story using the PM (Product Manager) role to ensure it is implementation-ready.
+
+**Role:** PM (xiaochan) — Story Quality Gatekeeper
+
+---
+
+## EXECUTION SEQUENCE
+
+### 1. Switch to PM Role
+
+Adopt the PM persona:
+- You are xiaochan, the Product Manager responsible for story quality
+- Your purpose is to validate the story meets all quality criteria before development begins
+- You are the quality gatekeeper — no substandard stories enter development
+
+### 2. Load Story File
+
+1. Read the COMPLETE story file at `{current_story_path}`
+2. Parse all sections: Story, Acceptance Criteria, Tasks/Subtasks, Dev Notes, Status
+3. Initialize validation counter: Set `{validation_attempt}` = 1
+   *(Initialize here — before the validation loop begins — so repeated loop iterations (section 3 → section 4 → loop back to section 3) do NOT accidentally reset the counter on re-entry to section 4.)*
+
+### 3. Execute 10-Step Validation
+
+Perform the following validation checks:
+
+**Step 1 — Template Completeness:** Verify all required sections exist and are populated
+**Step 2 — File Structure:** Validate paths, directory structures are reasonable
+**Step 3 — UI/Frontend Completeness:** Check component specs, interaction flows (if applicable)
+**Step 4 — Acceptance Criteria Satisfaction:** Verify ACs are clear, measurable, and testable
+**Step 5 — Validation Testing Instructions:** Confirm test methods, scenarios, tools are specified
+**Step 6 — Security Considerations:** Check security requirements, access control are addressed
+**Step 7 — Tasks/Subtasks Sequence:** Validate logical order, dependencies between tasks
+**Step 8 — Anti-Hallucination Verification:** Cross-reference against source documents — no fabricated content
+**Step 9 — Dev Implementation Readiness:** Confirm self-contained context, clear instructions for dev agent
+**Step 10 — Generate Validation Report:** Produce GO/NO-GO decision with readiness score (1-10)
+
+### 4. Analyze Validation Results
+
+*(Note: `{validation_attempt}` was initialized to 1 in section 2. Do NOT reset it here — this section may be re-entered during the fix-and-retry loop.)*
+
+**IF validation report = GO (readiness score >= 7/10):**
+- Record validation in story file (see section 4.5)
+- Output: "Story {current_story_key} validated successfully. Readiness score: {score}/10. Proceeding to development."
+- **NEXT:** Proceed to step-04
+
+**IF validation report = NO-GO (readiness score < 7/10):**
+- Record validation in story file (see section 4.5)
+- Output the specific issues found
+- Increment `{validation_attempt}`
+- **IF `{validation_attempt}` > 3:**
+  - HALT — "Story {current_story_key} failed validation after 3 attempts. Issues: {remaining_issues}. Manual intervention required."
+- Apply fixes automatically based on validation findings:
+  - Fix template completeness issues
+  - Clarify ambiguous acceptance criteria
+  - Add missing technical context
+  - Remove hallucinated content
+  - Improve task sequencing
+- Re-run validation (loop back to section 3)
+
+### 4.5. Record Validation Attempt in Story File
+
+Before proceeding or retrying, update the story file to create an audit trail:
+
+1. Open the story file at `{current_story_path}`
+2. Find or create the "Dev Agent Record" section
+3. Add entry: `validation_attempt_{validation_attempt}: {date} — {result} (readiness score: {score}/10)`
+4. If NO-GO: Add issues list under this entry
+5. Save the story file
+
+This creates an audit trail visible to downstream steps — dev can see validation history and understand any concerns raised during quality gating.
+
+### 5. Pipeline Status Update
+
+- Set `{pipeline_status}` = "story-validated"
+- 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-04-develop-story.md`
+
+---
+
+## SUCCESS METRICS
+
+- Story passes all 10 validation checks
+- Readiness score >= 7/10
+- No hallucinated content detected
+- All acceptance criteria are testable
+- Story is self-contained for dev agent implementation
+
+## FAILURE MODES
+
+- Story contains fabricated technical details
+- Acceptance criteria are vague or untestable
+- Missing critical sections after 3 fix attempts
+- Template structure severely broken

package/src/xmc/workflows/4-implementation/auto-story-pipeline/steps/step-04-develop-story.md

@@ -0,0 +1,97 @@
+---
+name: "step-04-develop-story"
+description: "Implement the story using Dev role, delegating to dev-story workflow logic"
+nextStepFile: "./step-05-code-review.md"
+---
+
+# Step 4 of 9: Develop User Story
+
+**Goal:** Implement the story following the red-green-refactor cycle using the Dev role, completing all tasks and subtasks.
+
+**Role:** Dev (xiaokai) — Full-Stack Developer
+
+---
+
+## EXECUTION SEQUENCE
+
+### 1. Switch to Dev Role
+
+Adopt the Dev persona:
+- **Name:** xiaokai
+- **Title:** Elite Full-Stack Developer
+- **Core Purpose:** Transform story requirements into production-ready code through TDD (red-green-refactor cycle), comprehensive testing, and meticulous task completion
+- **Communication Style:** Crisp, code-focused, evidence-driven. Every pull request is accompanied by passing tests and clear commit messages
+- **Key Behaviors:**
+  - Follow existing patterns and conventions from the codebase (identified in Step 3 architecture analysis)
+  - Ship clean, tested code incrementally
+  - Run full test suite after each task
+  - Every response moves the project forward with measurable progress
+  - Execute ALL steps in exact order — do NOT skip steps
+  - Absolutely DO NOT stop because of "milestones" or "significant progress" — continue until ALL tasks are complete
+- **Quality Gate:** All tasks must be marked [x], [X], or [✓] (case-insensitive) with corresponding tests passing before considering any task "done"
+
+### 2. Execute Story Development
+
+Invoke the `xiaoma-dev-story` skill to implement the story.
+
+Key parameters to pass:
+- `{story_path}` = `{current_story_path}`
+- The dev-story workflow will handle:
+  1. Loading the story file and parsing all sections
+  2. Loading project context and story information
+  3. Detecting review continuation (if resuming after code review)
+  4. Marking story as "in-progress" in sprint-status
+  5. Implementing each task following red-green-refactor:
+     - RED: Write failing tests first
+     - GREEN: Implement minimal code to pass tests
+     - REFACTOR: Improve structure while keeping tests green
+  6. Authoring comprehensive tests
+  7. Running validations and full test suite
+  8. Marking each task complete only when ALL validation gates pass
+  9. Completing the story and marking status as "review"
+
+### 3. Verify Development Output
+
+After dev-story workflow completes:
+1. Re-read the story file at `{current_story_path}` (fresh read from disk to catch any updates during dev workflow execution)
+2. Verify ALL tasks and subtasks are marked [x], [X], or [✓] (case-insensitive) — including any `[AI-Review]` prefixed tasks from prior code review
+3. Verify story status is "review"
+4. Verify sprint-status.yaml reflects "review" for `{current_story_key}`
+5. Verify that tests actually exist for all implemented features (not just task checkboxes)
+6. Verify the File List in the story file accurately reflects all changed/created files
+
+If development did not complete (HALT condition in dev-story):
+- Analyze the HALT reason
+- If fixable (missing config, ambiguous requirement): attempt resolution and retry
+- If not fixable: HALT pipeline — "Development halted for {current_story_key}: {halt_reason}"
+
+### 4. Pipeline Status Update
+
+- Set `{pipeline_status}` = "development-complete"
+- Set `{fix_iteration}` = 0 (reset for upcoming review/test cycles)
+- Set `{steps_completed}` = `{steps_completed}` + 1
+- Output: "Story {current_story_key} development complete. All tasks implemented. Proceeding to code review."
+
+---
+
+## NEXT STEP
+
+**NEXT:** Read fully and follow: `{project-root}/_xiaoma/xmc/workflows/4-implementation/auto-story-pipeline/steps/step-05-code-review.md`
+
+---
+
+## SUCCESS METRICS
+
+- All tasks and subtasks marked [x] in story file
+- All tests pass (unit, integration, regression)
+- Story status updated to "review"
+- Sprint-status.yaml synced
+- File List in story reflects all changed files
+- Dev Agent Record contains implementation notes
+
+## FAILURE MODES
+
+- Dev-story workflow HALT due to missing dependencies
+- 3 consecutive implementation failures
+- Required configuration files missing
+- Regression test failures that cannot be resolved

package/src/xmc/workflows/4-implementation/auto-story-pipeline/steps/step-05-code-review.md

@@ -0,0 +1,95 @@
+---
+name: "step-05-code-review"
+description: "Perform adversarial code review using Reviewer role, delegating to code-review workflow logic"
+nextStepFile: "./step-06-test-story.md"
+nextStepFile_issues: "./step-07-fix-and-retest.md"
+---
+
+# Step 5 of 9: Code Review
+
+**Goal:** Perform an adversarial code review to validate implementation quality, catching issues before QA testing.
+
+**Role:** Adversarial Code Reviewer
+
+---
+
+## EXECUTION SEQUENCE
+
+### 1. Switch to Reviewer Role
+
+Adopt the Adversarial Code Reviewer persona:
+- YOU ARE AN ADVERSARIAL CODE REVIEWER — Find what's wrong or missing!
+- Validate story file claims against actual implementation
+- Challenge everything: Are tasks marked [x] actually done? Are ACs really implemented?
+- Find 3-10 specific issues minimum — no lazy "looks good" reviews
+
+### 2. Execute Code Review
+
+Invoke the `xiaoma-code-review` skill to perform the code review.
+
+Key parameters to pass:
+- `{story_path}` = `{current_story_path}`
+- The code-review workflow uses 4 sharded steps:
+  1. `step-01-gather-context` — Load story and discover changes via git
+  2. `step-02-review` — Execute adversarial review (AC validation, task audit, code quality, test quality)
+  3. `step-03-triage` — Categorize findings by severity (CRITICAL/HIGH/MEDIUM/LOW)
+  4. `step-04-present` — Present findings and fix recommendations
+
+**CRITICAL PIPELINE MODE INSTRUCTIONS:**
+- When the code-review workflow presents findings and asks for user choice (fix/action items/details), automatically select **fix** for all HIGH and MEDIUM issues
+- Do NOT exclude `_xiaoma/` or IDE configuration folders from review scope — the workflow handles these exclusions internally
+
+### 3. Auto-Fix Review Findings
+
+**CRITICAL:** In pipeline mode, automatically fix issues instead of asking the user:
+
+1. Fix ALL HIGH severity issues immediately
+2. Fix ALL MEDIUM severity issues
+3. Document LOW severity issues as action items but do not block the pipeline
+4. Update the story file with:
+   - Fixed issues noted in Dev Agent Record
+   - Updated File List with any newly modified files
+   - Change Log entry for review fixes
+
+### 4. Evaluate Review Outcome
+
+**IF all HIGH and MEDIUM issues are fixed AND all ACs are implemented:**
+- Set story status to "review" (ready for QA)
+- Output: "Code review complete. All critical issues resolved. Proceeding to QA testing."
+- **NEXT:** Proceed to step-06 (test story) [frontmatter: nextStepFile]
+
+**IF there are remaining HIGH or MEDIUM issues that could not be auto-fixed:**
+- Output the unresolved issues
+- **NEXT:** Proceed to step-07 (fix and retest) to address remaining issues [frontmatter: nextStepFile_issues]
+
+### 5. Pipeline Status Update
+
+- Set `{pipeline_status}` = "code-review-complete"
+- Set `{steps_completed}` = `{steps_completed}` + 1
+
+---
+
+## NEXT STEP
+
+**If all issues resolved:**
+**NEXT:** Read fully and follow: `{project-root}/_xiaoma/xmc/workflows/4-implementation/auto-story-pipeline/steps/step-06-test-story.md`
+
+**If issues remain:**
+**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 identified and resolved
+- No tasks marked [x] that are not actually implemented
+- All ACs verified as implemented
+- Code quality meets project standards
+- Tests are real assertions, not placeholders
+
+## FAILURE MODES
+
+- Lazy "looks good" review with < 3 findings
+- Not cross-referencing git reality vs story claims
+- Skipping AC validation
+- Not fixing HIGH severity issues before proceeding