UI Test Plan
Purpose
Turn source material into an execution-ready ui-test-packet for UI exploration and verification.
Operating Rules
- Do not assume PRD, design, Figma, HTML prototype, code, or live UI is current. Record source version and confidence.
- Use source-grounded reasoning. If knowledge is missing or low confidence, mark it for confirmation instead of inventing facts.
- Separate business test design from UI execution details.
- Do not pass a flow to exploration until risk, scope, expected result, forbidden actions, and evidence requirements are explicit.
- Create or update the governed Source Case as the only case truth. Do not author separate Human/Midscene/Playwright case bodies.
- Declare P0/P1/P2, five-field scope, branch, test-point responsibility, applicable component variant, and separate setup/feature/assertion sections.
- Resolve output locations only through the
ui-test project config and Path Planner. A missing v2 config blocks new formal assets.
Workflow
- Build a source inventory with version, timestamp, owner if known, and confidence.
- Identify business objects, module boundaries, roles, states, permissions, upstream/downstream dependencies, and hidden conditions.
- Produce test points covering normal flow, abnormal flow, boundary, permission, state transition, data dependency, and upstream/downstream consistency.
- Mark ambiguity as P0/P1/P2 questions and route unresolved P0 issues to human confirmation.
- Screen automation candidates and define evidence expectations.
- Output or update
ui-test-packet with next_action: explore when ready.
Validation
- Every test point traces to at least one source reference or explicit assumption.
- P0 ambiguity is closed or blocks execution.
- Forbidden actions are listed before exploration.
- Expected results are specific enough to verify.
Read the planning checklist before marking a packet execution-ready.
Safety
Planning grants no execution permission. Block plans with unresolved P0 ambiguity, unknown environment, missing forbidden actions, embedded credentials, or unreviewed write scope.
1---2name: ui-test-plan3description: Create and review UI-test planning packets from PRD, design, Figma, HTML prototype, live URL, code evidence, and knowledge base sources. Use for test-point decomposition, coverage matrix design, ambiguity discovery, automation candidate screening, and execution readiness before Midscene exploration.4---56# UI Test Plan78## Purpose910Turn source material into an execution-ready `ui-test-packet` for UI exploration and verification.1112## Operating Rules1314- Do not assume PRD, design, Figma, HTML prototype, code, or live UI is current. Record source version and confidence.15- Use source-grounded reasoning. If knowledge is missing or low confidence, mark it for confirmation instead of inventing facts.16- Separate business test design from UI execution details.17- Do not pass a flow to exploration until risk, scope, expected result, forbidden actions, and evidence requirements are explicit.18- Create or update the governed Source Case as the only case truth. Do not author separate Human/Midscene/Playwright case bodies.19- Declare P0/P1/P2, five-field scope, branch, test-point responsibility, applicable component variant, and separate setup/feature/assertion sections.20- Resolve output locations only through the `ui-test` project config and Path Planner. A missing v2 config blocks new formal assets.2122## Workflow23241. Build a source inventory with version, timestamp, owner if known, and confidence.252. Identify business objects, module boundaries, roles, states, permissions, upstream/downstream dependencies, and hidden conditions.263. Produce test points covering normal flow, abnormal flow, boundary, permission, state transition, data dependency, and upstream/downstream consistency.274. Mark ambiguity as P0/P1/P2 questions and route unresolved P0 issues to human confirmation.285. Screen automation candidates and define evidence expectations.296. Output or update `ui-test-packet` with `next_action: explore` when ready.3031## Validation3233- Every test point traces to at least one source reference or explicit assumption.34- P0 ambiguity is closed or blocks execution.35- Forbidden actions are listed before exploration.36- Expected results are specific enough to verify.3738Read [the planning checklist](references/planning-checklist.md) before marking a packet execution-ready.3940## Safety4142Planning grants no execution permission. Block plans with unresolved P0 ambiguity, unknown environment, missing forbidden actions, embedded credentials, or unreviewed write scope.
Zengxiansheng007