<procedure name="feature-acceptance-test">
<execute_dor_checks_before_starting/>
<schedule_dod_checks_with_sub_agent_before_starting/>
<phase_1 name="博学之 — Study Broadly">
<step_1_1>
<name>Load Toolbox Config</name>
<action>
1. CHECK if x-ipe-docs/config/tools.json exists
2. IF exists: parse JSON, extract tools from stages.validation.acceptance_test
3. IF NOT exists: config_active = false (all tools enabled by default)
4. Build enabled_tools list — only tools with value `true` count as enabled
5. Classify enabled tools by capability:
- frontend_ui_tool: "chrome-devtools-mcp" (browser interaction for UI tests)
- frontend_ui_skill: "x-ipe-tool-ui-testing-via-chrome-mcp" (structured UI test execution via chrome MCP)
- code_test_tools: x-ipe-tool-implementation-* (for backend/unit/integration tests)
6. BLOCKING: For each enabled tool that has a corresponding skill at .github/skills/{tool-name}/SKILL.md, LOAD that skill now
7. Output enabled_tools list with capability classification
</action>
<constraints>
- BLOCKING: tools.json is the single source of truth; do NOT use disabled tools
</constraints>
<output>enabled_tools list with capability classification</output>
</step_1_1>
<step_1_2>
<name>Classify & Generate Acceptance Test Plan</name>
<action>
1. READ specification at specification_link (resolved in Input Initialization)
2. READ technical design at technical_design_link to determine Technical Scope
3. EXTRACT all acceptance criteria (AC-X) with testable conditions
4. CLASSIFY each AC by test_type:
- "frontend-ui": requires browser interaction (UI rendering, clicks, forms, visual)
- "backend-api": requires HTTP/API calls (endpoints, responses, status codes)
- "unit": requires code-level testing (functions, classes, logic)
- "integration": requires multi-component verification (data flow, service interaction)
- "structured-review": non-executable deliverables (skills/SKILL.md, prompt templates, reference docs, config files) — verified via checklist-based review
5. MATCH each test_type to the best enabled tool:
- frontend-ui → chrome-devtools-mcp (if enabled)
- backend-api → matched code_test_tool skill (python/typescript/etc.)
- unit → matched code_test_tool skill
- integration → matched code_test_tool skill or chrome-devtools-mcp
- structured-review → agent self-review (no external tool needed)
6. DETECT tech_stack from specification and implementation files
7. SEMANTIC MATCH tech_stack to enabled tool skills (same as code-implementation routing)
8. CHECK mockup_link (resolved in Input Initialization):
a. IF mockup_link != "N/A": note mockup available for Step 3.1 and Step 4.1
b. IF mockup_link == "N/A": proceed without mockup validation
9. CREATE acceptance-test-cases.md using templates/acceptance-test-cases.md
10. FOR EACH AC: create TC-XXX, map to AC, set priority (P0/P1/P2), set test_type, assign tool, write steps, define expected outcomes
11. PRIORITIZE: P0=Critical, P1=High, P2=Medium (edge cases)
12. GROUP and STORE test cases by test_type in acceptance-test-cases.md:
- Create a section per test_type: "## Frontend-UI Tests", "## Backend-API Tests", "## Unit Tests", "## Integration Tests", "## Structured-Review Tests"
- Each section lists only TCs of that type with their assigned tool
- This grouping enables batch execution per type in Phase 4
</action>
<constraints>
- MANDATORY: Each AC must have at least one test case regardless of type
- CRITICAL: Test cases must be independent and self-contained
- MANDATORY: Each TC must declare its test_type and assigned_tool
</constraints>
<output>acceptance-test-cases.md with typed test cases and tool assignments</output>
</step_1_2>
</phase_1>
<phase_2 name="审问之 — Inquire Thoroughly">
<step_2_1>
<name>Analyze Implementation</name>
<action>
FOR EACH test_type group (see references/detailed-procedures.md for per-type analysis patterns):
1. frontend-ui: Locate UI files, identify selectors (priority: data-testid > id > aria-label > class), update test steps
2. backend-api: Locate route files, document endpoint/method/schema, update test steps with API details
3. unit: Locate source modules, document function signatures/inputs/expected outputs
4. integration: Locate service interaction points, document setup/trigger/verification
</action>
<constraints>
- CRITICAL: For frontend-ui, use selector priority order from references/detailed-procedures.md
- BLOCKING: Never use auto-generated IDs or fragile class chains
</constraints>
<output>Test cases updated with implementation-specific details per type</output>
</step_2_1>
<step_2_2>
<name>Test Data Preparation</name>
<action>
1. ANALYZE each test case for data requirements (Input, Selection, Expected, Compare)
2. Collect test data per test case (see references/detailed-procedures.md)
3. UPDATE Test Data table in each test case section
Response source (based on interaction_mode):
IF process_preference.interaction_mode == "dao-represent-human-to-interact":
→ Use placeholder/generated test data (auto-populate)
ELSE (interact-with-human/dao-represent-human-to-interact-for-questions-in-skill):
→ Ask human for test data per test case
</action>
<output>Test Data tables populated in each test case</output>
</step_2_2>
</phase_2>
<phase_3 name="慎思之 — Think Carefully">
<step_3_1>
<name>Reflect and Refine Test Cases</name>
<action>
1. FOR EACH test case, validate: AC coverage, preconditions, actionable steps, measurable expected results, edge cases
2. FOR frontend-ui tests: validate selector existence, add wait conditions, handle dynamic content
3. FOR backend-api tests: validate endpoint existence, check error cases (4xx, 5xx), auth requirements
4. FOR unit tests: validate function signatures, check boundary conditions
5. REFLECT: false negative risks, missing steps, vague expectations, split candidates
6. IF mockup_link != "N/A" (frontend-ui only):
a. ADD UI/UX visual validation TCs (P1): layout, styling, interactive states
b. Reference mockup_link in each TC description
7. ROUTE TEST CODE GENERATION (if matched_tool_skill from Step 1.1):
a. CONVERT refined test cases to AAA scenarios (per test_type group)
b. INVOKE matched_tool_skill with operation: "implement", aaa_scenarios, feature_context
c. Tool skill generates test scaffolding using language-specific conventions
d. IF no matched tool skill → fall back to inline test generation
8. UPDATE acceptance-test-cases.md with refinements
</action>
<constraints>
- MANDATORY: Every test case must pass reflection checklist (see references/detailed-procedures.md)
- MANDATORY: File links in generated markdown MUST use project-root-relative paths so the UI can intercept them and open a preview modal. **Avoid** relative paths (`../`, `./`, `../../`) and absolute filesystem paths (`/Users/...`). **Correct:** `[spec](x-ipe-docs/requirements/EPIC-001/specification.md)`, `[skill](.github/skills/x-ipe-task-based-bug-fix/SKILL.md)`. **Wrong:** `[spec](../specification.md)`, `[spec](./specification.md)`.
</constraints>
<output>Refined test cases with implementation-specific test code</output>
</step_3_1>
</phase_3>
<phase_4 name="明辨之 — Discern Clearly">
<step_4_1>
<name>Execute Tests</name>
<action>
GROUP test cases by test_type and assigned_tool. FOR EACH group:
1. frontend-ui (x-ipe-tool-ui-testing-via-chrome-mcp):
- CHECK if "x-ipe-tool-ui-testing-via-chrome-mcp" is enabled in tools.json
- IF enabled AND chrome-devtools-mcp is available:
a. LOAD skill x-ipe-tool-ui-testing-via-chrome-mcp (if not already loaded in Step 1.1)
b. INVOKE the skill's execute_ui_tests operation with:
- test_cases: all frontend-ui TCs from the grouped test plan
- target_url: {from input}
- mockup_link: {from input, resolved in Input Initialization}
- screenshot_on_failure: true
- screenshot_dir: x-ipe-docs/requirements/{feature_id}/screenshots/
c. COLLECT per-TC results from the tool skill's operation_output
- ELIF chrome-devtools-mcp enabled but skill NOT enabled: fall back to direct MCP
- ELSE: SET group status="blocked"
2. backend-api (tool skill):
- Make API calls (curl, httpx, fetch, or test framework), verify response status/body/headers
3. unit (tool skill):
- Run unit tests via matched tool skill or test runner (pytest, vitest, etc.)
4. integration (tool skill or chrome-devtools-mcp):
- Initialize services, trigger flow, verify end-to-end state
5. structured-review (agent self-review — for skills, prompts, docs, configs):
FOR EACH TC: read deliverable file(s) → evaluate AC criterion against content →
check presence (keyword search, section/structural validation) → cross-reference with spec →
set pass/fail/partial with evidence (cited section/line). Build coverage map: every AC must have definitive result.
See references/detailed-procedures.md for command patterns per type.
6. CONTINUE with remaining tests even if some fail
</action>
<output>Test execution results per test case, grouped by type</output>
</step_4_1>
<step_4_2>
<name>Report Test Results</name>
<action>
1. UPDATE acceptance-test-cases.md: set status per test case, add execution notes, fill Execution Results
2. DOCUMENT failures with reason and recommended action
3. IF mockup_comparison returned by UI tool: add "Mockup Comparison Summary" with gaps and match_score
4. GROUP results by test_type in summary (frontend-ui / backend-api / unit / integration / structured-review: X passed / Y total)
5. CALCULATE metrics: total, passed, failed, blocked, pass_rate
6. RETURN task completion output with results
</action>
<success_criteria>
- All test cases have a status recorded
- Metrics calculated and documented
- acceptance-test-cases.md saved to feature folder
</success_criteria>
<output>Completed acceptance-test-cases.md with execution results</output>
</step_4_2>
</phase_4>
<phase_5 name="笃行之 — Practice Earnestly">
<step_5_1>
<name>Update Workflow Status</name>
<action>
1. IF execution_mode == "workflow-mode":
a. Run the workflow update script via bash (`python3 .github/skills/x-ipe-tool-x-ipe-app-interactor/scripts/workflow_update_action.py`) with:
- workflow_name: {from context}
- action: {workflow.action}
- status: "done"
- feature_id: {feature_id}
- deliverables: {"test-report": "{path to acceptance-test-cases.md}", "test-folder": "{path to test folder}"}
b. Log: "Workflow action status updated to done"
</action>
<output>workflow_action_updated</output>
</step_5_1>
</phase_5>
<phase_6 name="继续执行（Continue Execute）">
<step_6_1>
<name>Decide Next Action</name>
<action>
Collect the full context and task_completion_output from this skill execution.
IF process_preference.interaction_mode == "dao-represent-human-to-interact":
→ Invoke x-ipe-assistant-user-representative-Engineer with:
type: "routing"
completed_skill_output: {full task_completion_output YAML from this skill}
next_task_based_skill: "{from output}"
context: "Skill completed. Study the context and full output to decide best next action."
→ DAO studies the complete context and decides the best next action
ELSE (interact-with-human):
→ Present next task suggestion to human and wait for instruction
</action>
<constraints>
- BLOCKING (manual): Human MUST confirm or redirect before proceeding
- BLOCKING (auto): Proceed after DoD verification; auto-select next task via DAO
</constraints>
<output>Next action decided with execution context</output>
</step_6_1>
<step_6_2>
<name>Execute Next Action</name>
<action>
Based on the decision from Step 6.1:
1. Load the target task-based skill's SKILL.md
2. Generate an execution plan from the skill's Execution Flow table
3. Start execution from the skill's first phase/step
</action>
<constraints>
- MUST load the skill before executing — do not skip skill loading
- Execution follows the target skill's procedure, not this skill's
</constraints>
<output>Next task execution started</output>
</step_6_2>
</phase_6>
</procedure>
task_completion_output:
category: "{standalone | feature-stage}"
status: completed | blocked
next_task_based_skill:
- skill: "x-ipe-task-based-code-refactor"
condition: "Refactor code for quality improvements"
- skill: "x-ipe-task-based-feature-closing"
condition: "Close feature if no refactoring needed"
process_preference:
workflow:
name: "{from input}"
workflow_action: "{workflow.action}"
workflow_action_updated: true | false
task_output_links:
- "x-ipe-docs/requirements/FEATURE-XXX/acceptance-test-cases.md"
feature_id: "FEATURE-XXX"
feature_title: "{title}"
feature_version: "{version}"
feature_phase: "Acceptance Testing"
test_types_tested: ["frontend-ui", "backend-api", "unit", "integration", "structured-review"]
test_cases_created: "{count}"
tests_passed: "{count}"
tests_failed: "{count}"
tests_blocked: "{count}"
pass_rate: "{X}%"
results_by_type: { frontend_ui: {passed, failed, blocked}, backend_api: {...}, unit: {...}, integration: {...}, structured_review: {...} }
