Compare commits

...

5 Commits

Author SHA1 Message Date
Murat Ozcan
81c2776f75 added examples per level 2025-09-29 13:52:41 -05:00
Murat Ozcan
b4508c6c73 format fix 2025-09-29 13:41:21 -05:00
Murat Ozcan
3883949b57 docs: update tea docs for review by Brian 2025-09-29 13:38:15 -05:00
Murat Ozcan
860341534c docs: update tea docs for review by Brian 2025-09-29 13:27:47 -05:00
Murat Ozcan
cf0a52189e docs: update tea docs for review by Brian 2025-09-29 12:31:08 -05:00
6 changed files with 186 additions and 68 deletions

View File

@@ -17,15 +17,14 @@
</critical-actions> </critical-actions>
<cmds> <cmds>
<c cmd="*help">Show numbered cmd list</c> <c cmd="*help">Show numbered cmd list</c>
<c cmd="*init-test-framework" exec="{project-root}/bmad/bmm/testarch/framework.md">Initialize production-ready test framework architecture</c> <c cmd="*framework" exec="{project-root}/bmad/bmm/testarch/framework.md">Initialize production-ready test framework architecture</c>
<c cmd="*atdd" exec="{project-root}/bmad/bmm/testarch/atdd.md">Generate E2E tests first, before starting implementation</c> <c cmd="*atdd" exec="{project-root}/bmad/bmm/testarch/atdd.md">Generate E2E tests first, before starting implementation</c>
<c cmd="*create-automated-tests" exec="{project-root}/bmad/bmm/testarch/automate.md">Generate comprehensive test automation</c> <c cmd="*automate" exec="{project-root}/bmad/bmm/testarch/automate.md">Generate comprehensive test automation</c>
<c cmd="*risk-profile" exec="{project-root}/bmad/bmm/testarch/risk-profile.md">Generate risk assessment matrix</c>
<c cmd="*test-design" exec="{project-root}/bmad/bmm/testarch/test-design.md">Create comprehensive test scenarios</c> <c cmd="*test-design" exec="{project-root}/bmad/bmm/testarch/test-design.md">Create comprehensive test scenarios</c>
<c cmd="*req-to-bdd" exec="{project-root}/bmad/bmm/testarch/trace-requirements.md">Map requirements to tests Given-When-Then BDD format</c> <c cmd="*trace" exec="{project-root}/bmad/bmm/testarch/trace-requirements.md">Map requirements to tests Given-When-Then BDD format</c>
<c cmd="*nfr-assess" exec="{project-root}/bmad/bmm/testarch/nfr-assess.md">Validate non-functional requirements</c> <c cmd="*nfr-assess" exec="{project-root}/bmad/bmm/testarch/nfr-assess.md">Validate non-functional requirements</c>
<c cmd="*gate" exec="{project-root}/bmad/bmm/testarch/tea-gate.md">Write/update quality gate decision assessment</c> <c cmd="*ci" exec="{project-root}/bmad/bmm/testarch/ci.md">Scaffold CI/CD quality pipeline</c>
<c cmd="*review-gate" exec="{project-root}/bmad/bmm/tasks/review-story.md">Generate a Risk Aware Results with gate file</c> <c cmd="*gate" exec="{project-root}/bmad/bmm/testarch/gate.md">Write/update quality gate decision assessment</c>
<c cmd="*exit">Goodbye+exit persona</c> <c cmd="*exit">Goodbye+exit persona</c>
</cmds> </cmds>
</agent> </agent>

View File

@@ -0,0 +1,155 @@
---
last-redoc-date: 2025-09-30
---
# Test Architect (TEA) Agent Guide
## Overview
- **Persona:** Murat, Master Test Architect & Quality Advisor focused on risk-based testing, fixture architecture, ATDD, and CI/CD governance.
- **Mission:** Deliver actionable quality strategies, automation coverage, and gate decisions that scale with project level and compliance demands.
- **Use When:** Project level ≥2, integration risk is non-trivial, brownfield regression risk exists, or compliance/NFR evidence is required.
## Prerequisites & Setup
1. Run the core planning workflows first:
- Analyst `*product-brief`
- Product Manager `*plan-project`
- Architect `*solution-architecture`
2. Confirm `bmad/bmm/config.yaml` defines `project_name`, `output_folder`, `dev_story_location`, and language settings.
3. Ensure a test harness exists; if not, schedule `*framework` before development.
4. Skim supporting references under `./testarch/`:
- `tea-knowledge.md`
- `test-levels-framework.md`
- `test-priorities-matrix.md`
## High-Level Cheat Sheets
### Greenfield Feature Launch (Level 2)
| Phase | Test Architect | Dev / Team | Outputs |
| ------------------ | ------------------------------------------------------------------------- | -------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- |
| Setup | - | Analyst `*product-brief`, PM `*plan-project`, Architect `*solution-architecture` | `{output_folder}/product-brief*.md`, `PRD.md`, `epics.md`, `solution-architecture.md` |
| Pre-Implementation | Run `*framework` (if harness missing), `*ci`, and `*test-design` | Review risk/design/CI guidance, align backlog | Test scaffold, CI pipeline, risk & coverage strategy |
| Story Prep | - | Scrum Master `*create-story`, `*story-context` | Story markdown + context XML |
| Implementation | (Optional) Trigger `*atdd` before dev to supply failing tests + checklist | Implement story guided by ATDD checklist | Failing acceptance tests + implementation checklist |
| Post-Dev | Execute `*automate`, re-run `*trace` | Address recommendations, update code/tests | Regression specs, refreshed coverage matrix |
| Release | Run `*gate` | Confirm Definition of Done, share release notes | Gate YAML + release summary (owners, waivers) |
<details>
<summary>Execution Notes</summary>
- Run `*framework` only once per repo or when modern harness support is missing.
- `*framework` followed by `*ci` establishes install + pipeline; `*test-design` then handles risk scoring, mitigations, and scenario planning in one pass.
- Use `*atdd` before coding when the team can adopt ATDD; share its checklist with the dev agent.
- Post-implementation, keep `*trace` current, expand coverage with `*automate`, and finish with `*gate`.
</details>
<details>
<summary>Worked Example “Nova CRM” Greenfield Feature</summary>
1. **Planning:** Analyst runs `*product-brief`; PM executes `*plan-project` to produce PRD and epics; Architect completes `*solution-architecture` for the new module.
2. **Setup:** TEA checks harness via `*framework`, configures `*ci`, and runs `*test-design` to capture risk/coverage plans.
3. **Story Prep:** Scrum Master generates the story via `*create-story`; PO validates using `*assess-project-ready`.
4. **Implementation:** TEA optionally runs `*atdd`; Dev implements with guidance from failing tests and the plan.
5. **Post-Dev & Release:** TEA runs `*automate`, re-runs `*trace`, and finishes with `*gate` to document the decision.
</details>
### Brownfield Feature Enhancement (Level 23)
| Phase | Test Architect | Dev / Team | Outputs |
| ----------------- | ------------------------------------------------------------------- | ---------------------------------------------------------- | ------------------------------------------------------- |
| Refresh Context | - | Analyst/PM/Architect rerun planning workflows | Updated planning artifacts in `{output_folder}` |
| Baseline Coverage | Run `*trace` to inventory existing tests | Review matrix, flag hotspots | Coverage matrix + initial gate snippet |
| Risk Targeting | Run `*test-design` | Align remediation/backlog priorities | Brownfield risk memo + scenario matrix |
| Story Prep | - | Scrum Master `*create-story` | Updated story markdown |
| Implementation | (Optional) Run `*atdd` before dev | Implement story, referencing checklist/tests | Failing acceptance tests + implementation checklist |
| Post-Dev | Apply `*automate`, re-run `*trace`, trigger `*nfr-assess` if needed | Resolve gaps, update docs/tests | Regression specs, refreshed coverage matrix, NFR report |
| Release | Run `*gate` | Product Owner `*assess-project-ready`, share release notes | Gate YAML + release summary |
<details>
<summary>Execution Notes</summary>
- Lead with `*trace` so remediation plans target true coverage gaps. Ensure `*framework` and `*ci` are in place early in the engagement; if the brownfield lacks them, run those setup steps immediately after refreshing context.
- `*test-design` should highlight regression hotspots, mitigations, and P0 scenarios.
- Use `*atdd` when stories benefit from ATDD; otherwise proceed to implementation and rely on post-dev automation.
- After development, expand coverage with `*automate`, re-run `*trace`, and close with `*gate`. Run `*nfr-assess` now if non-functional risks weren't addressed earlier.
- Product Owner `*assess-project-ready` confirms the team has artifacts before handoff or release.
</details>
<details>
<summary>Worked Example “Atlas Payments” Brownfield Story</summary>
1. **Context Refresh:** Analyst reruns `*product-brief`; PM executes `*plan-project` to update PRD, analysis, and `epics.md`; Architect triggers `*solution-architecture` capturing legacy payment flows.
2. **Baseline Coverage:** TEA executes `*trace` to record current coverage in `docs/qa/assessments/atlas-payment-trace.md`.
3. **Risk & Design:** `*test-design` flags settlement edge cases, plans mitigations, and allocates new API/E2E scenarios with P0 priorities.
4. **Story Prep:** Scrum Master generates `stories/story-1.1.md` via `*create-story`, automatically pulling updated context.
5. **ATDD First:** TEA runs `*atdd`, producing failing Playwright specs under `tests/e2e/payments/` plus an implementation checklist.
6. **Implementation:** Dev pairs with the checklist/tests to deliver the story.
7. **Post-Implementation:** TEA applies `*automate`, re-runs `*trace`, performs `*nfr-assess` to validate SLAs, and closes with `*gate` marking PASS with follow-ups.
</details>
### Enterprise / Compliance Program (Level 4)
| Phase | Test Architect | Dev / Team | Outputs |
| ------------------- | ------------------------------------------------ | ---------------------------------------------- | --------------------------------------------------------- |
| Strategic Planning | - | Analyst/PM/Architect standard workflows | Enterprise-grade PRD, epics, architecture |
| Quality Planning | Run `*framework`, `*test-design`, `*nfr-assess` | Review guidance, align compliance requirements | Harness scaffold, risk + coverage plan, NFR documentation |
| Pipeline Enablement | Configure `*ci` | Coordinate secrets, pipeline approvals | `.github/workflows/test.yml`, helper scripts |
| Execution | Enforce `*atdd`, `*automate`, `*trace` per story | Implement stories, resolve TEA findings | Tests, fixtures, coverage matrices |
| Release | Run `*gate` | Capture sign-offs, archive artifacts | Updated assessments, gate YAML, audit trail |
<details>
<summary>Execution Notes</summary>
- Use `*atdd` for every story when feasible so acceptance tests lead implementation in regulated environments.
- `*ci` scaffolds selective testing scripts, burn-in jobs, caching, and notifications for long-running suites.
- Prior to release, rerun coverage (`*trace`, `*automate`) and formalize the decision in `*gate`; store everything for audits. Call `*nfr-assess` here if compliance/performance requirements weren't captured during planning.
</details>
<details>
<summary>Worked Example “Helios Ledger” Enterprise Release</summary>
1. **Strategic Planning:** Analyst/PM/Architect complete PRD, epics, and architecture using the standard workflows.
2. **Quality Planning:** TEA runs `*framework`, `*test-design`, and `*nfr-assess` to establish mitigations, coverage, and NFR targets.
3. **Pipeline Setup:** TEA configures CI via `*ci` with selective execution scripts.
4. **Execution:** For each story, TEA enforces `*atdd`, `*automate`, and `*trace`; Dev teams iterate on the findings.
5. **Release:** TEA re-checks coverage and logs the final gate decision via `*gate`, archiving artifacts for compliance.
</details>
## Command Catalog
| Command | Task File | Primary Outputs | Notes |
| -------------- | -------------------------------- | -------------------------------------------------------------------- | ------------------------------------------------ |
| `*framework` | `testarch/framework.md` | Playwright/Cypress scaffold, `.env.example`, `.nvmrc`, sample specs | Use when no production-ready harness exists |
| `*atdd` | `testarch/atdd.md` | Failing Acceptance-Test Driven Development, implementation checklist | Requires approved story + harness |
| `*automate` | `testarch/automate.md` | Prioritized specs, fixtures, README/script updates, DoD summary | Avoid duplicate coverage (see priority matrix) |
| `*ci` | `testarch/ci.md` | CI workflow, selective test scripts, secrets checklist | Platform-aware (GitHub Actions default) |
| `*test-design` | `testarch/test-design.md` | Combined risk assessment, mitigation plan, and coverage strategy | Handles risk scoring and test design in one pass |
| `*trace` | `testarch/trace-requirements.md` | Coverage matrix, recommendations, gate snippet | Requires access to story/tests repositories |
| `*nfr-assess` | `testarch/nfr-assess.md` | NFR assessment report with actions | Focus on security/performance/reliability |
| `*gate` | `testarch/gate.md` | Gate YAML + summary (PASS/CONCERNS/FAIL/WAIVED) | Deterministic decision rules + rationale |
<details>
<summary>Command Guidance & Context Loading</summary>
- Each task reads one row from `tea-commands.csv` via `command_key`, expanding pipe-delimited (`|`) values into checklists.
- Keep CSV rows lightweight; place in-depth heuristics in `tea-knowledge.md` and reference via `knowledge_tags`.
- If the CSV grows substantially, consider splitting into scoped registries (e.g., planning vs execution) or upgrading to Markdown tables for humans.
- `tea-knowledge.md` encapsulates Murats philosophy—update both CSV and knowledge file together to avoid drift.
</details>
## Appendix
- **Supporting Knowledge:**
- `tea-knowledge.md` Murats testing philosophy, heuristics, and risk scales.
- `test-levels-framework.md` Decision matrix for unit/integration/E2E selection.
- `test-priorities-matrix.md` Priority (P0P3) criteria and target coverage percentages.
s

View File

@@ -1,38 +0,0 @@
<!-- Powered by BMAD-CORE™ -->
# Risk Profile v2.0 (Slim)
```xml
<task id="bmad/bmm/testarch/risk-profile" name="Risk Profile">
<llm critical="true">
<i>Set command_key="*risk-profile"</i>
<i>Load {project-root}/bmad/bmm/testarch/tea-commands.csv and parse the row where command equals command_key</i>
<i>Load {project-root}/bmad/bmm/testarch/tea-knowledge.md focusing on risk-model guidance</i>
<i>Use CSV columns preflight, flow_cues, deliverables, halt_rules, notes, knowledge_tags as the full instruction set</i>
<i>Split pipe-delimited values into actionable items</i>
<i>Keep assessment grounded in evidence from PRD/architecture/story files—do not restate requirements as risks</i>
</llm>
<flow>
<step n="1" title="Preflight">
<action>Verify prerequisites; stop if halt_rules trigger</action>
</step>
<step n="2" title="Execute Risk Analysis">
<action>Follow flow_cues to distinguish requirements from genuine risks and score probability × impact</action>
<action>Use knowledge heuristics to calibrate scoring (score 9 rare, ≥6 notable) and recommend mitigations</action>
</step>
<step n="3" title="Deliverables">
<action>Produce artifacts described in deliverables (assessment markdown, gate snippet, mitigation plan)</action>
<action>Summarize key findings with clear recommendations</action>
</step>
</flow>
<halt>
<i>Apply halt_rules from the CSV row without modification</i>
</halt>
<notes>
<i>Use notes column for calibration reminders</i>
</notes>
<output>
<i>Risk assessment report + gate summary</i>
</output>
</task>
```

View File

@@ -1,11 +1,9 @@
command,title,when_to_use,preflight,flow_cues,deliverables,halt_rules,notes,knowledge_tags command,title,when_to_use,preflight,flow_cues,deliverables,halt_rules,notes,knowledge_tags
*framework,Initialize test architecture,Run once per repo or when no production-ready harness exists,package.json present|no existing E2E framework detected|architectural context available,"Identify stack from package.json (React/Vue/Angular/Next.js); detect bundler (Vite/Webpack/Rollup/esbuild); match test language to source (JS/TS frontend -> JS/TS tests); choose Playwright for large or performance-critical repos, Cypress for small DX-first teams; create {framework}/tests/ and {framework}/support/fixtures/ and {framework}/support/helpers/; configure config files with timeouts (action 15s, navigation 30s, test 60s) and reporters (HTML + JUnit); create .env.example with TEST_ENV, BASE_URL, API_URL; implement pure function->fixture->mergeTests pattern and faker-based data factories; enable failure-only screenshots/videos and ensure .nvmrc recorded",playwright/ or cypress/ folder with config + support tree; .env.example; .nvmrc; example tests; README with setup instructions,"If package.json missing OR framework already configured, halt and instruct manual review","Playwright: worker parallelism, trace viewer, multi-language support; Cypress: avoid if many dependent API calls; Component testing: Vitest (large) or Cypress CT (small); Contract testing: Pact for microservices; always use data-cy/data-testid selectors",philosophy/core|patterns/fixtures|patterns/selectors
*tdd,Acceptance Test Driven Development,Before implementation when team commits to TDD,story approved with acceptance criteria|dev sandbox ready|framework scaffolding in place,Clarify acceptance criteria and affected systems; pick appropriate test level (E2E/API/Component); write failing acceptance tests using Given-When-Then with network interception first then navigation; create data factories and fixture stubs for required entities; outline mocks/fixtures infrastructure the dev team must supply; generate component tests for critical UI logic; compile implementation checklist mapping each test to source work; share failing tests with dev agent and maintain red -> green -> refactor loop,Failing acceptance test files; component test stubs; fixture/mocks skeleton; implementation checklist with test-to-code mapping; documented data-testid requirements,"If criteria ambiguous or framework missing, halt for clarification",Start red; one assertion per test; use beforeEach for visible setup (no shared state); remind devs to run tests before writing production code; update checklist as each test goes green,philosophy/core|patterns/test-structure
*automate,Automation expansion,After implementation or when reforging coverage,all acceptance criteria satisfied|code builds locally|framework configured,"Review story source/diff to confirm automation target; ensure fixture architecture exists (mergeTests for Playwright, commands for Cypress) and implement apiRequest/network/auth/log fixtures if missing; map acceptance criteria with test-levels-framework.md guidance and avoid duplicate coverage; assign priorities using test-priorities-matrix.md; generate unit/integration/E2E specs with naming convention feature-name.spec.ts, covering happy, negative, and edge paths; enforce deterministic waits, self-cleaning factories, and <=1.5 minute execution per test; run suite and capture Definition of Done results; update package.json scripts and README instructions",New or enhanced spec files grouped by level; fixture modules under support/; data factory utilities; updated package.json scripts and README notes; DoD summary with remaining gaps; gate-ready coverage summary,"If automation target unclear or framework missing, halt and request clarification",Never create page objects; keep tests <300 lines and stateless; forbid hard waits and conditional flow in tests; co-locate tests near source; flag flaky patterns immediately,philosophy/core|patterns/helpers|patterns/waits|patterns/dod *automate,Automation expansion,After implementation or when reforging coverage,all acceptance criteria satisfied|code builds locally|framework configured,"Review story source/diff to confirm automation target; ensure fixture architecture exists (mergeTests for Playwright, commands for Cypress) and implement apiRequest/network/auth/log fixtures if missing; map acceptance criteria with test-levels-framework.md guidance and avoid duplicate coverage; assign priorities using test-priorities-matrix.md; generate unit/integration/E2E specs with naming convention feature-name.spec.ts, covering happy, negative, and edge paths; enforce deterministic waits, self-cleaning factories, and <=1.5 minute execution per test; run suite and capture Definition of Done results; update package.json scripts and README instructions",New or enhanced spec files grouped by level; fixture modules under support/; data factory utilities; updated package.json scripts and README notes; DoD summary with remaining gaps; gate-ready coverage summary,"If automation target unclear or framework missing, halt and request clarification",Never create page objects; keep tests <300 lines and stateless; forbid hard waits and conditional flow in tests; co-locate tests near source; flag flaky patterns immediately,philosophy/core|patterns/helpers|patterns/waits|patterns/dod
*ci,CI/CD quality pipeline,Once automation suite exists or needs optimization,git repository initialized|tests pass locally|team agrees on target environments|access to CI platform settings,"Detect CI platform (default GitHub Actions, ask if GitLab/CircleCI/etc); scaffold workflow (.github/workflows/test.yml or platform equivalent) with triggers; set Node.js version from .nvmrc and cache node_modules + browsers; stage jobs: lint -> unit -> component -> e2e with matrix parallelization (shard by file not test); add selective execution script for affected tests; create burn-in job that reruns changed specs 3x to catch flakiness; attach artifacts on failure (traces/videos/HAR); configure retries/backoff and concurrency controls; document required secrets and environment variables; add Slack/email notifications and local script mirroring CI",.github/workflows/test.yml (or platform equivalent); scripts/test-changed.sh; scripts/burn-in-changed.sh; updated README/ci.md instructions; secrets checklist; dashboard or badge configuration,"If git repo absent, test framework missing, or CI platform unspecified, halt and request setup",Target 20x speedups via parallel shards + caching; shard by file; keep jobs under 10 minutes; wait-on-timeout 120s for app startup; ensure npm test locally matches CI run; mention alternative platform paths when not on GitHub,philosophy/core|ci-strategy *ci,CI/CD quality pipeline,Once automation suite exists or needs optimization,git repository initialized|tests pass locally|team agrees on target environments|access to CI platform settings,"Detect CI platform (default GitHub Actions, ask if GitLab/CircleCI/etc); scaffold workflow (.github/workflows/test.yml or platform equivalent) with triggers; set Node.js version from .nvmrc and cache node_modules + browsers; stage jobs: lint -> unit -> component -> e2e with matrix parallelization (shard by file not test); add selective execution script for affected tests; create burn-in job that reruns changed specs 3x to catch flakiness; attach artifacts on failure (traces/videos/HAR); configure retries/backoff and concurrency controls; document required secrets and environment variables; add Slack/email notifications and local script mirroring CI",.github/workflows/test.yml (or platform equivalent); scripts/test-changed.sh; scripts/burn-in-changed.sh; updated README/ci.md instructions; secrets checklist; dashboard or badge configuration,"If git repo absent, test framework missing, or CI platform unspecified, halt and request setup",Target 20x speedups via parallel shards + caching; shard by file; keep jobs under 10 minutes; wait-on-timeout 120s for app startup; ensure npm test locally matches CI run; mention alternative platform paths when not on GitHub,philosophy/core|ci-strategy
*risk-profile,Risk profile analysis,"After story approval, before development",story markdown present|acceptance criteria clear|architecture/PRD accessible,"Filter requirements so only genuine risks remain; review PRD/architecture/story for unresolved gaps; classify risks across TECH, SEC, PERF, DATA, BUS, OPS with category definitions; request clarification when evidence missing; score probability (1 unlikely, 2 possible, 3 likely) and impact (1 minor, 2 degraded, 3 critical) then compute totals; highlight risks >=6 and plan mitigations with owners and timelines; prepare gate summary with residual risk",Risk assessment markdown in docs/qa/assessments; table of category/probability/impact/score; gate YAML snippet summarizing totals; mitigation matrix with owners and due dates,"If story missing or criteria unclear, halt for clarification","Category definitions: TECH=unmitigated architecture flaws, SEC=missing controls/vulnerabilities, PERF=SLA-breaking performance, DATA=loss/corruption scenarios, BUS=user/business harm, OPS=deployment/run failures; rely on evidence, not speculation; score 9 -> FAIL, 6-8 -> CONCERNS; most stories should have 0-1 high risks",philosophy/core|risk-model *framework,Initialize test architecture,Run once per repo or when no production-ready harness exists,package.json present|no existing E2E framework detected|architectural context available,"Identify stack from package.json (React/Vue/Angular/Next.js); detect bundler (Vite/Webpack/Rollup/esbuild); match test language to source (JS/TS frontend -> JS/TS tests); choose Playwright for large or performance-critical repos, Cypress for small DX-first teams; create {framework}/tests/ and {framework}/support/fixtures/ and {framework}/support/helpers/; configure config files with timeouts (action 15s, navigation 30s, test 60s) and reporters (HTML + JUnit); create .env.example with TEST_ENV, BASE_URL, API_URL; implement pure function->fixture->mergeTests pattern and faker-based data factories; enable failure-only screenshots/videos and ensure .nvmrc recorded",playwright/ or cypress/ folder with config + support tree; .env.example; .nvmrc; example tests; README with setup instructions,"If package.json missing OR framework already configured, halt and instruct manual review","Playwright: worker parallelism, trace viewer, multi-language support; Cypress: avoid if many dependent API calls; Component testing: Vitest (large) or Cypress CT (small); Contract testing: Pact for microservices; always use data-cy/data-testid selectors",philosophy/core|patterns/fixtures|patterns/selectors
*test-design,Test design playbook,"After risk profile, before coding",risk assessment completed|story acceptance criteria available,"Break acceptance criteria into atomic scenarios; reference test-levels-framework.md to pick unit/integration/E2E/component levels; avoid duplicate coverage and prefer lower levels when possible; assign priorities using test-priorities-matrix.md (P0 revenue/security, P1 core journeys, P2 secondary, P3 nice-to-have); map scenarios to risk mitigations and required data/tooling; follow naming {epic}.{story}-LEVEL-SEQ and plan execution order",Test-design markdown saved to docs/qa/assessments; scenario table with requirement/level/priority/mitigation; gate YAML block summarizing scenario counts and coverage; recommended execution order,"If risk profile missing or acceptance criteria unclear, request it and halt","Shift left: unit first, escalate only when needed; tie scenarios back to risk mitigations; keep scenarios independent and maintainable",philosophy/core|patterns/test-structure
*trace,Requirements traceability,Mid-development checkpoint or before review,tests exist for story|access to source + specs,"Gather acceptance criteria and implemented tests; map each criterion to concrete tests (file + describe/it) using Given-When-Then narrative; classify coverage status as FULL, PARTIAL, NONE, UNIT-ONLY, INTEGRATION-ONLY; flag severity based on priority (P0 gaps critical); recommend additional tests or refactors; generate gate YAML coverage summary",Traceability report saved under docs/qa/assessments; coverage matrix with status per criterion; gate YAML snippet for coverage totals and gaps,"If story lacks implemented tests, pause and advise running *tdd or writing tests","Definitions: FULL=all scenarios validated, PARTIAL=some coverage exists, NONE=no validation, UNIT-ONLY=missing higher level, INTEGRATION-ONLY=lacks lower confidence; ensure assertions explicit and avoid duplicate coverage",philosophy/core|patterns/assertions
*nfr-assess,NFR validation,Late development or pre-review for critical stories,implementation deployed locally|non-functional goals defined or discoverable,"Ask which NFRs to assess; default to core four (security, performance, reliability, maintainability); gather thresholds from story/architecture/technical-preferences and mark unknown targets; inspect evidence (tests, telemetry, logs) for each NFR; classify status using deterministic pass/concerns/fail rules and list quick wins; produce gate block and assessment doc with recommended actions",NFR assessment markdown with findings; gate YAML block capturing statuses and notes; checklist of evidence gaps and follow-up owners,"If NFR targets undefined and no guidance available, request definition and halt","Unknown thresholds -> CONCERNS, never guess; ensure each NFR has evidence or call it out; suggest monitoring hooks and fail-fast mechanisms when gaps exist",philosophy/core|nfr
*review,Comprehensive TEA review,Story marked ready; tests passing locally,traceability complete|risk + design docs available|tests executed locally,"Determine review depth (deep if security/auth touched, no new tests, diff >500, prior gate FAIL/CONCERNS, >5 acceptance criteria); follow flow cues to inspect code quality, selectors, waits, and architecture alignment; map requirements to tests and ensure coverage matches trace report; perform safe refactors when low risk and record others as recommendations; prepare TEA Results summary and gate recommendation",Updated story markdown with TEA Results and recommendations; gate recommendation summary; list of refactors performed and outstanding issues,"If prerequisites missing (tests failing, docs absent), halt with checklist","Evidence-focused: reference concrete files/lines; escalate security/performance issues immediately; distinguish must-fix vs optional improvements; reuse Murat patterns for helpers, waits, selectors",philosophy/core|patterns/review
*gate,Quality gate decision,After review or mitigation updates,latest assessments gathered|team consensus on fixes,"Assemble story metadata (id, title); choose gate status using deterministic rules (PASS all critical issues resolved, CONCERNS minor residual risk, FAIL critical blockers, WAIVED approved by business); update YAML schema with sections: metadata, waiver status, top_issues, risk_summary totals, recommendations (must_fix, monitor), nfr_validation statuses, history; capture rationale, owners, due dates, and summary comment back to story","docs/qa/gates/{story}.yml updated with schema fields (schema, story, story_title, gate, status_reason, reviewer, updated, waiver, top_issues, risk_summary, recommendations, nfr_validation, history); summary message for team","If review incomplete or risk data outdated, halt and request rerun","FAIL whenever unresolved P0 risks/tests or security holes remain; CONCERNS when mitigations planned but residual risk exists; WAIVED requires reason, approver, and expiry; maintain audit trail in history",philosophy/core|risk-model *gate,Quality gate decision,After review or mitigation updates,latest assessments gathered|team consensus on fixes,"Assemble story metadata (id, title); choose gate status using deterministic rules (PASS all critical issues resolved, CONCERNS minor residual risk, FAIL critical blockers, WAIVED approved by business); update YAML schema with sections: metadata, waiver status, top_issues, risk_summary totals, recommendations (must_fix, monitor), nfr_validation statuses, history; capture rationale, owners, due dates, and summary comment back to story","docs/qa/gates/{story}.yml updated with schema fields (schema, story, story_title, gate, status_reason, reviewer, updated, waiver, top_issues, risk_summary, recommendations, nfr_validation, history); summary message for team","If review incomplete or risk data outdated, halt and request rerun","FAIL whenever unresolved P0 risks/tests or security holes remain; CONCERNS when mitigations planned but residual risk exists; WAIVED requires reason, approver, and expiry; maintain audit trail in history",philosophy/core|risk-model
*nfr-assess,NFR validation,Late development or pre-review for critical stories,implementation deployed locally|non-functional goals defined or discoverable,"Ask which NFRs to assess; default to core four (security, performance, reliability, maintainability); gather thresholds from story/architecture/technical-preferences and mark unknown targets; inspect evidence (tests, telemetry, logs) for each NFR; classify status using deterministic pass/concerns/fail rules and list quick wins; produce gate block and assessment doc with recommended actions",NFR assessment markdown with findings; gate YAML block capturing statuses and notes; checklist of evidence gaps and follow-up owners,"If NFR targets undefined and no guidance available, request definition and halt","Unknown thresholds -> CONCERNS, never guess; ensure each NFR has evidence or call it out; suggest monitoring hooks and fail-fast mechanisms when gaps exist",philosophy/core|nfr
*tdd,Acceptance Test Driven Development,Before implementation when team commits to TDD,story approved with acceptance criteria|dev sandbox ready|framework scaffolding in place,Clarify acceptance criteria and affected systems; pick appropriate test level (E2E/API/Component); write failing acceptance tests using Given-When-Then with network interception first then navigation; create data factories and fixture stubs for required entities; outline mocks/fixtures infrastructure the dev team must supply; generate component tests for critical UI logic; compile implementation checklist mapping each test to source work; share failing tests with dev agent and maintain red -> green -> refactor loop,Failing acceptance test files; component test stubs; fixture/mocks skeleton; implementation checklist with test-to-code mapping; documented data-testid requirements,"If criteria ambiguous or framework missing, halt for clarification",Start red; one assertion per test; use beforeEach for visible setup (no shared state); remind devs to run tests before writing production code; update checklist as each test goes green,philosophy/core|patterns/test-structure
*test-design,Risk and test design planning,"After story approval, before development",story markdown present|acceptance criteria clear|architecture/PRD accessible,"Filter requirements so only genuine risks remain; review PRD/architecture/story for unresolved gaps; classify risks across TECH, SEC, PERF, DATA, BUS, OPS using category definitions; request clarification when evidence missing; score probability (1 unlikely, 2 possible, 3 likely) and impact (1 minor, 2 degraded, 3 critical) then compute totals; highlight risks >=6 and plan mitigations with owners and timelines; break acceptance criteria into atomic scenarios mapped to mitigations; reference test-levels-framework.md to pick unit/integration/E2E/component levels; avoid duplicate coverage, prefer lower levels when possible; assign priorities using test-priorities-matrix.md; outline data/tooling prerequisites and execution order",Risk assessment markdown in docs/qa/assessments; table of category/probability/impact/score; mitigation matrix with owners and due dates; coverage matrix with requirement/level/priority/mitigation; gate YAML snippet summarizing risk totals and scenario counts; recommended execution order,"If story missing or criteria unclear, halt for clarification","Category definitions: TECH=architecture flaws; SEC=missing controls/vulnerabilities; PERF=SLA risk; DATA=loss/corruption; BUS=user/business harm; OPS=deployment/run failures; rely on evidence, not speculation; tie scenarios back to risk mitigations; keep scenarios independent and maintainable",philosophy/core|risk-model|patterns/test-structure
*trace,Requirements traceability,Mid-development checkpoint or before review,tests exist for story|access to source + specs,"Gather acceptance criteria and implemented tests; map each criterion to concrete tests (file + describe/it) using Given-When-Then narrative; classify coverage status as FULL, PARTIAL, NONE, UNIT-ONLY, INTEGRATION-ONLY; flag severity based on priority (P0 gaps critical); recommend additional tests or refactors; generate gate YAML coverage summary",Traceability report saved under docs/qa/assessments; coverage matrix with status per criterion; gate YAML snippet for coverage totals and gaps,"If story lacks implemented tests, pause and advise running *tdd or writing tests","Definitions: FULL=all scenarios validated, PARTIAL=some coverage exists, NONE=no validation, UNIT-ONLY=missing higher level, INTEGRATION-ONLY=lacks lower confidence; ensure assertions explicit and avoid duplicate coverage",philosophy/core|patterns/assertions
1 command title when_to_use preflight flow_cues deliverables halt_rules notes knowledge_tags
*framework Initialize test architecture Run once per repo or when no production-ready harness exists package.json present|no existing E2E framework detected|architectural context available Identify stack from package.json (React/Vue/Angular/Next.js); detect bundler (Vite/Webpack/Rollup/esbuild); match test language to source (JS/TS frontend -> JS/TS tests); choose Playwright for large or performance-critical repos, Cypress for small DX-first teams; create {framework}/tests/ and {framework}/support/fixtures/ and {framework}/support/helpers/; configure config files with timeouts (action 15s, navigation 30s, test 60s) and reporters (HTML + JUnit); create .env.example with TEST_ENV, BASE_URL, API_URL; implement pure function->fixture->mergeTests pattern and faker-based data factories; enable failure-only screenshots/videos and ensure .nvmrc recorded playwright/ or cypress/ folder with config + support tree; .env.example; .nvmrc; example tests; README with setup instructions If package.json missing OR framework already configured, halt and instruct manual review Playwright: worker parallelism, trace viewer, multi-language support; Cypress: avoid if many dependent API calls; Component testing: Vitest (large) or Cypress CT (small); Contract testing: Pact for microservices; always use data-cy/data-testid selectors philosophy/core|patterns/fixtures|patterns/selectors
*tdd Acceptance Test Driven Development Before implementation when team commits to TDD story approved with acceptance criteria|dev sandbox ready|framework scaffolding in place Clarify acceptance criteria and affected systems; pick appropriate test level (E2E/API/Component); write failing acceptance tests using Given-When-Then with network interception first then navigation; create data factories and fixture stubs for required entities; outline mocks/fixtures infrastructure the dev team must supply; generate component tests for critical UI logic; compile implementation checklist mapping each test to source work; share failing tests with dev agent and maintain red -> green -> refactor loop Failing acceptance test files; component test stubs; fixture/mocks skeleton; implementation checklist with test-to-code mapping; documented data-testid requirements If criteria ambiguous or framework missing, halt for clarification Start red; one assertion per test; use beforeEach for visible setup (no shared state); remind devs to run tests before writing production code; update checklist as each test goes green philosophy/core|patterns/test-structure
2 *automate Automation expansion After implementation or when reforging coverage all acceptance criteria satisfied|code builds locally|framework configured Review story source/diff to confirm automation target; ensure fixture architecture exists (mergeTests for Playwright, commands for Cypress) and implement apiRequest/network/auth/log fixtures if missing; map acceptance criteria with test-levels-framework.md guidance and avoid duplicate coverage; assign priorities using test-priorities-matrix.md; generate unit/integration/E2E specs with naming convention feature-name.spec.ts, covering happy, negative, and edge paths; enforce deterministic waits, self-cleaning factories, and <=1.5 minute execution per test; run suite and capture Definition of Done results; update package.json scripts and README instructions New or enhanced spec files grouped by level; fixture modules under support/; data factory utilities; updated package.json scripts and README notes; DoD summary with remaining gaps; gate-ready coverage summary If automation target unclear or framework missing, halt and request clarification Never create page objects; keep tests <300 lines and stateless; forbid hard waits and conditional flow in tests; co-locate tests near source; flag flaky patterns immediately philosophy/core|patterns/helpers|patterns/waits|patterns/dod
3 *ci CI/CD quality pipeline Once automation suite exists or needs optimization git repository initialized|tests pass locally|team agrees on target environments|access to CI platform settings Detect CI platform (default GitHub Actions, ask if GitLab/CircleCI/etc); scaffold workflow (.github/workflows/test.yml or platform equivalent) with triggers; set Node.js version from .nvmrc and cache node_modules + browsers; stage jobs: lint -> unit -> component -> e2e with matrix parallelization (shard by file not test); add selective execution script for affected tests; create burn-in job that reruns changed specs 3x to catch flakiness; attach artifacts on failure (traces/videos/HAR); configure retries/backoff and concurrency controls; document required secrets and environment variables; add Slack/email notifications and local script mirroring CI .github/workflows/test.yml (or platform equivalent); scripts/test-changed.sh; scripts/burn-in-changed.sh; updated README/ci.md instructions; secrets checklist; dashboard or badge configuration If git repo absent, test framework missing, or CI platform unspecified, halt and request setup Target 20x speedups via parallel shards + caching; shard by file; keep jobs under 10 minutes; wait-on-timeout 120s for app startup; ensure npm test locally matches CI run; mention alternative platform paths when not on GitHub philosophy/core|ci-strategy
4 *risk-profile *framework Risk profile analysis Initialize test architecture After story approval, before development Run once per repo or when no production-ready harness exists story markdown present|acceptance criteria clear|architecture/PRD accessible package.json present|no existing E2E framework detected|architectural context available Filter requirements so only genuine risks remain; review PRD/architecture/story for unresolved gaps; classify risks across TECH, SEC, PERF, DATA, BUS, OPS with category definitions; request clarification when evidence missing; score probability (1 unlikely, 2 possible, 3 likely) and impact (1 minor, 2 degraded, 3 critical) then compute totals; highlight risks >=6 and plan mitigations with owners and timelines; prepare gate summary with residual risk Identify stack from package.json (React/Vue/Angular/Next.js); detect bundler (Vite/Webpack/Rollup/esbuild); match test language to source (JS/TS frontend -> JS/TS tests); choose Playwright for large or performance-critical repos, Cypress for small DX-first teams; create {framework}/tests/ and {framework}/support/fixtures/ and {framework}/support/helpers/; configure config files with timeouts (action 15s, navigation 30s, test 60s) and reporters (HTML + JUnit); create .env.example with TEST_ENV, BASE_URL, API_URL; implement pure function->fixture->mergeTests pattern and faker-based data factories; enable failure-only screenshots/videos and ensure .nvmrc recorded Risk assessment markdown in docs/qa/assessments; table of category/probability/impact/score; gate YAML snippet summarizing totals; mitigation matrix with owners and due dates playwright/ or cypress/ folder with config + support tree; .env.example; .nvmrc; example tests; README with setup instructions If story missing or criteria unclear, halt for clarification If package.json missing OR framework already configured, halt and instruct manual review Category definitions: TECH=unmitigated architecture flaws, SEC=missing controls/vulnerabilities, PERF=SLA-breaking performance, DATA=loss/corruption scenarios, BUS=user/business harm, OPS=deployment/run failures; rely on evidence, not speculation; score 9 -> FAIL, 6-8 -> CONCERNS; most stories should have 0-1 high risks Playwright: worker parallelism, trace viewer, multi-language support; Cypress: avoid if many dependent API calls; Component testing: Vitest (large) or Cypress CT (small); Contract testing: Pact for microservices; always use data-cy/data-testid selectors philosophy/core|risk-model philosophy/core|patterns/fixtures|patterns/selectors
*test-design Test design playbook After risk profile, before coding risk assessment completed|story acceptance criteria available Break acceptance criteria into atomic scenarios; reference test-levels-framework.md to pick unit/integration/E2E/component levels; avoid duplicate coverage and prefer lower levels when possible; assign priorities using test-priorities-matrix.md (P0 revenue/security, P1 core journeys, P2 secondary, P3 nice-to-have); map scenarios to risk mitigations and required data/tooling; follow naming {epic}.{story}-LEVEL-SEQ and plan execution order Test-design markdown saved to docs/qa/assessments; scenario table with requirement/level/priority/mitigation; gate YAML block summarizing scenario counts and coverage; recommended execution order If risk profile missing or acceptance criteria unclear, request it and halt Shift left: unit first, escalate only when needed; tie scenarios back to risk mitigations; keep scenarios independent and maintainable philosophy/core|patterns/test-structure
*trace Requirements traceability Mid-development checkpoint or before review tests exist for story|access to source + specs Gather acceptance criteria and implemented tests; map each criterion to concrete tests (file + describe/it) using Given-When-Then narrative; classify coverage status as FULL, PARTIAL, NONE, UNIT-ONLY, INTEGRATION-ONLY; flag severity based on priority (P0 gaps critical); recommend additional tests or refactors; generate gate YAML coverage summary Traceability report saved under docs/qa/assessments; coverage matrix with status per criterion; gate YAML snippet for coverage totals and gaps If story lacks implemented tests, pause and advise running *tdd or writing tests Definitions: FULL=all scenarios validated, PARTIAL=some coverage exists, NONE=no validation, UNIT-ONLY=missing higher level, INTEGRATION-ONLY=lacks lower confidence; ensure assertions explicit and avoid duplicate coverage philosophy/core|patterns/assertions
*nfr-assess NFR validation Late development or pre-review for critical stories implementation deployed locally|non-functional goals defined or discoverable Ask which NFRs to assess; default to core four (security, performance, reliability, maintainability); gather thresholds from story/architecture/technical-preferences and mark unknown targets; inspect evidence (tests, telemetry, logs) for each NFR; classify status using deterministic pass/concerns/fail rules and list quick wins; produce gate block and assessment doc with recommended actions NFR assessment markdown with findings; gate YAML block capturing statuses and notes; checklist of evidence gaps and follow-up owners If NFR targets undefined and no guidance available, request definition and halt Unknown thresholds -> CONCERNS, never guess; ensure each NFR has evidence or call it out; suggest monitoring hooks and fail-fast mechanisms when gaps exist philosophy/core|nfr
*review Comprehensive TEA review Story marked ready; tests passing locally traceability complete|risk + design docs available|tests executed locally Determine review depth (deep if security/auth touched, no new tests, diff >500, prior gate FAIL/CONCERNS, >5 acceptance criteria); follow flow cues to inspect code quality, selectors, waits, and architecture alignment; map requirements to tests and ensure coverage matches trace report; perform safe refactors when low risk and record others as recommendations; prepare TEA Results summary and gate recommendation Updated story markdown with TEA Results and recommendations; gate recommendation summary; list of refactors performed and outstanding issues If prerequisites missing (tests failing, docs absent), halt with checklist Evidence-focused: reference concrete files/lines; escalate security/performance issues immediately; distinguish must-fix vs optional improvements; reuse Murat patterns for helpers, waits, selectors philosophy/core|patterns/review
5 *gate Quality gate decision After review or mitigation updates latest assessments gathered|team consensus on fixes Assemble story metadata (id, title); choose gate status using deterministic rules (PASS all critical issues resolved, CONCERNS minor residual risk, FAIL critical blockers, WAIVED approved by business); update YAML schema with sections: metadata, waiver status, top_issues, risk_summary totals, recommendations (must_fix, monitor), nfr_validation statuses, history; capture rationale, owners, due dates, and summary comment back to story docs/qa/gates/{story}.yml updated with schema fields (schema, story, story_title, gate, status_reason, reviewer, updated, waiver, top_issues, risk_summary, recommendations, nfr_validation, history); summary message for team If review incomplete or risk data outdated, halt and request rerun FAIL whenever unresolved P0 risks/tests or security holes remain; CONCERNS when mitigations planned but residual risk exists; WAIVED requires reason, approver, and expiry; maintain audit trail in history philosophy/core|risk-model
6 *nfr-assess NFR validation Late development or pre-review for critical stories implementation deployed locally|non-functional goals defined or discoverable Ask which NFRs to assess; default to core four (security, performance, reliability, maintainability); gather thresholds from story/architecture/technical-preferences and mark unknown targets; inspect evidence (tests, telemetry, logs) for each NFR; classify status using deterministic pass/concerns/fail rules and list quick wins; produce gate block and assessment doc with recommended actions NFR assessment markdown with findings; gate YAML block capturing statuses and notes; checklist of evidence gaps and follow-up owners If NFR targets undefined and no guidance available, request definition and halt Unknown thresholds -> CONCERNS, never guess; ensure each NFR has evidence or call it out; suggest monitoring hooks and fail-fast mechanisms when gaps exist philosophy/core|nfr
7 *tdd Acceptance Test Driven Development Before implementation when team commits to TDD story approved with acceptance criteria|dev sandbox ready|framework scaffolding in place Clarify acceptance criteria and affected systems; pick appropriate test level (E2E/API/Component); write failing acceptance tests using Given-When-Then with network interception first then navigation; create data factories and fixture stubs for required entities; outline mocks/fixtures infrastructure the dev team must supply; generate component tests for critical UI logic; compile implementation checklist mapping each test to source work; share failing tests with dev agent and maintain red -> green -> refactor loop Failing acceptance test files; component test stubs; fixture/mocks skeleton; implementation checklist with test-to-code mapping; documented data-testid requirements If criteria ambiguous or framework missing, halt for clarification Start red; one assertion per test; use beforeEach for visible setup (no shared state); remind devs to run tests before writing production code; update checklist as each test goes green philosophy/core|patterns/test-structure
8 *test-design Risk and test design planning After story approval, before development story markdown present|acceptance criteria clear|architecture/PRD accessible Filter requirements so only genuine risks remain; review PRD/architecture/story for unresolved gaps; classify risks across TECH, SEC, PERF, DATA, BUS, OPS using category definitions; request clarification when evidence missing; score probability (1 unlikely, 2 possible, 3 likely) and impact (1 minor, 2 degraded, 3 critical) then compute totals; highlight risks >=6 and plan mitigations with owners and timelines; break acceptance criteria into atomic scenarios mapped to mitigations; reference test-levels-framework.md to pick unit/integration/E2E/component levels; avoid duplicate coverage, prefer lower levels when possible; assign priorities using test-priorities-matrix.md; outline data/tooling prerequisites and execution order Risk assessment markdown in docs/qa/assessments; table of category/probability/impact/score; mitigation matrix with owners and due dates; coverage matrix with requirement/level/priority/mitigation; gate YAML snippet summarizing risk totals and scenario counts; recommended execution order If story missing or criteria unclear, halt for clarification Category definitions: TECH=architecture flaws; SEC=missing controls/vulnerabilities; PERF=SLA risk; DATA=loss/corruption; BUS=user/business harm; OPS=deployment/run failures; rely on evidence, not speculation; tie scenarios back to risk mitigations; keep scenarios independent and maintainable philosophy/core|risk-model|patterns/test-structure
9 *trace Requirements traceability Mid-development checkpoint or before review tests exist for story|access to source + specs Gather acceptance criteria and implemented tests; map each criterion to concrete tests (file + describe/it) using Given-When-Then narrative; classify coverage status as FULL, PARTIAL, NONE, UNIT-ONLY, INTEGRATION-ONLY; flag severity based on priority (P0 gaps critical); recommend additional tests or refactors; generate gate YAML coverage summary Traceability report saved under docs/qa/assessments; coverage matrix with status per criterion; gate YAML snippet for coverage totals and gaps If story lacks implemented tests, pause and advise running *tdd or writing tests Definitions: FULL=all scenarios validated, PARTIAL=some coverage exists, NONE=no validation, UNIT-ONLY=missing higher level, INTEGRATION-ONLY=lacks lower confidence; ensure assertions explicit and avoid duplicate coverage philosophy/core|patterns/assertions

View File

@@ -1,39 +1,43 @@
<!-- Powered by BMAD-CORE™ --> <!-- Powered by BMAD-CORE™ -->
# Test Design v2.0 (Slim) # Risk & Test Design v3.0 (Slim)
```xml ```xml
<task id="bmad/bmm/testarch/test-design" name="Test Design"> <task id="bmad/bmm/testarch/test-design" name="Risk & Test Design">
<llm critical="true"> <llm critical="true">
<i>Set command_key="*test-design"</i> <i>Set command_key="*test-design"</i>
<i>Load {project-root}/bmad/bmm/testarch/tea-commands.csv and parse the matching row</i> <i>Load {project-root}/bmad/bmm/testarch/tea-commands.csv and parse the matching row</i>
<i>Load {project-root}/bmad/bmm/testarch/tea-knowledge.md to reinforce Murat's coverage heuristics</i> <i>Load {project-root}/bmad/bmm/testarch/tea-knowledge.md for risk-model and coverage heuristics</i>
<i>Use CSV columns preflight, flow_cues, deliverables, halt_rules, notes, knowledge_tags as guidance</i> <i>Use CSV columns preflight, flow_cues, deliverables, halt_rules, notes, knowledge_tags as the execution blueprint</i>
<i>Split pipe-delimited values into actionable lists</i> <i>Split pipe-delimited values into actionable checklists</i>
<i>Keep documents actionable—no verbose restatement of requirements</i> <i>Stay evidence-based—link risks and scenarios directly to PRD/architecture/story artifacts</i>
</llm> </llm>
<flow> <flow>
<step n="1" title="Preflight"> <step n="1" title="Preflight">
<action>Confirm required inputs (risk profile, acceptance criteria)</action> <action>Confirm story markdown, acceptance criteria, and architecture/PRD access.</action>
<action>Abort using halt_rules if prerequisites missing</action> <action>Stop immediately if halt_rules trigger (missing inputs or unclear requirements).</action>
</step> </step>
<step n="2" title="Design Strategy"> <step n="2" title="Assess Risks">
<action>Follow flow_cues to map criteria to scenarios, assign test levels, set priorities</action> <action>Follow flow_cues to filter genuine risks, classify them (TECH/SEC/PERF/DATA/BUS/OPS), and score probability × impact.</action>
<action>Use knowledge heuristics for ratios, data factories, and cost vs confidence trade-offs</action> <action>Document mitigations with owners, timelines, and residual risk expectations.</action>
</step> </step>
<step n="3" title="Deliverables"> <step n="3" title="Design Coverage">
<action>Create artifacts defined in deliverables (strategy markdown, tables)</action> <action>Break acceptance criteria into atomic scenarios mapped to mitigations.</action>
<action>Summarize guidance for developers/testers</action> <action>Choose test levels using test-levels-framework.md, assign priorities via test-priorities-matrix.md, and note tooling/data prerequisites.</action>
</step>
<step n="4" title="Deliverables">
<action>Generate the combined risk report and test design artifacts described in deliverables.</action>
<action>Summarize key risks, mitigations, coverage plan, and recommended execution order.</action>
</step> </step>
</flow> </flow>
<halt> <halt>
<i>Follow halt_rules from the CSV row</i> <i>Apply halt_rules from the CSV row verbatim.</i>
</halt> </halt>
<notes> <notes>
<i>Apply notes column for extra context</i> <i>Use notes column for calibration reminders and coverage heuristics.</i>
</notes> </notes>
<output> <output>
<i>Lean test design document aligned with risk profile</i> <i>Unified risk assessment plus coverage strategy ready for implementation.</i>
</output> </output>
</task> </task>
``` ```