bmad-method-test-architecture-enterprise 1.2.2 → 1.2.3

package/src/workflows/testarch/ci/steps-c/step-02-generate-pipeline.md

@@ -2,7 +2,6 @@
 name: 'step-02-generate-pipeline'
 description: 'Generate CI pipeline configuration'
 nextStepFile: './step-03-configure-quality-gates.md'
-pipelineOutputFile: '{project-root}/.github/workflows/test.yml'
 outputFile: '{test_artifacts}/ci-pipeline-progress.md'
 ---
 
@@ -36,16 +35,20 @@ Create platform-specific CI configuration with test execution, sharding, burn-in
 
 **CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise.
 
-## 1. Select Template
+## 1. Resolve Output Path and Select Template
 
-Choose template based on platform:
+Determine the pipeline output file path based on the detected `ci_platform`:
 
-- GitHub Actions → `.github/workflows/test.yml`
-- GitLab CI → `.gitlab-ci.yml`
-- Circle CI → `.circleci/config.yml`
-- Jenkins → `Jenkinsfile`
+| CI Platform      | Output Path                                 | Template File                                       |
+| ---------------- | ------------------------------------------- | --------------------------------------------------- |
+| `github-actions` | `{project-root}/.github/workflows/test.yml` | `{installed_path}/github-actions-template.yaml`     |
+| `gitlab-ci`      | `{project-root}/.gitlab-ci.yml`             | `{installed_path}/gitlab-ci-template.yaml`          |
+| `jenkins`        | `{project-root}/Jenkinsfile`                | `{installed_path}/jenkins-pipeline-template.groovy` |
+| `azure-devops`   | `{project-root}/azure-pipelines.yml`        | `{installed_path}/azure-pipelines-template.yaml`    |
+| `harness`        | `{project-root}/.harness/pipeline.yaml`     | `{installed_path}/harness-pipeline-template.yaml`   |
+| `circle-ci`      | `{project-root}/.circleci/config.yml`       | _(no template; generate from first principles)_     |
 
-Use templates from `{installed_path}` when available (e.g., `github-actions-template.yaml`, `gitlab-ci-template.yaml`).
+Use templates from `{installed_path}` when available. Adapt the template to the project's `test_stack_type` and `test_framework`.
 
 ---
 
@@ -65,9 +68,17 @@ Include stages:
 - Parallel sharding enabled
 - CI retries configured
 - Capture artifacts (HTML report, JUnit XML, traces/videos on failure)
-- Cache dependencies (node_modules / pnpm / npm cache)
+- Cache dependencies (language-appropriate: node_modules, .venv, .m2, go module cache, NuGet, bundler)
 
-Write the selected pipeline configuration to `{pipelineOutputFile}` (or adjust the path if a non-GitHub platform was chosen).
+Write the selected pipeline configuration to the resolved output path from step 1. Adjust test commands based on `test_stack_type` and `test_framework`:
+
+- **Frontend/Fullstack**: Include browser install, E2E/component test commands, Playwright/Cypress artifacts
+- **Backend (Node.js)**: Use `npm test` or framework-specific commands (`vitest`, `jest`), skip browser install
+- **Backend (Python)**: Use `pytest` with coverage (`pytest --cov`), install via `pip install -r requirements.txt` or `poetry install`
+- **Backend (Java/Kotlin)**: Use `mvn test` or `gradle test`, cache `.m2/repository` or `.gradle/caches`
+- **Backend (Go)**: Use `go test ./...` with coverage (`-coverprofile`), cache Go modules
+- **Backend (C#/.NET)**: Use `dotnet test` with coverage, restore NuGet packages
+- **Backend (Ruby)**: Use `bundle exec rspec` with coverage, cache `vendor/bundle`
 
 ---
 

package/src/workflows/testarch/ci/steps-c/step-03-configure-quality-gates.md

@@ -43,6 +43,11 @@ Use `{knowledgeIndex}` to load `ci-burn-in.md` guidance:
 - Run N-iteration burn-in for flaky detection
 - Gate promotion based on burn-in stability
 
+**Stack-conditional burn-in:**
+
+- **Frontend or Fullstack** (`test_stack_type` is `frontend` or `fullstack`): Enable burn-in by default. Burn-in targets UI flakiness (race conditions, selector instability, timing issues).
+- **Backend only** (`test_stack_type` is `backend`): Skip burn-in by default. Backend tests (unit, integration, API) are deterministic and rarely exhibit UI-related flakiness. If the user explicitly requests burn-in for backend, honor that override.
+
 ---
 
 ## 2. Quality Gates

package/src/workflows/testarch/ci/workflow.yaml

@@ -19,11 +19,13 @@ validation: "{installed_path}/checklist.md"
 
 # Variables and inputs
 variables:
-  ci_platform: "auto" # auto, github-actions, gitlab-ci, circle-ci, jenkins - user can override
+  ci_platform: "auto" # auto, github-actions, gitlab-ci, circle-ci, jenkins, azure-devops, harness - user can override
   test_dir: "{project-root}/tests" # Root test directory
+  test_stack_type: "auto" # auto, frontend, backend, fullstack - detected or user override
+  test_framework: "auto" # auto, playwright, cypress, jest, vitest - detected or user override
 
-# Output configuration
-default_output_file: "{project-root}/.github/workflows/test.yml" # GitHub Actions default
+# Output configuration (resolved dynamically based on ci_platform detection)
+default_output_file: "{project-root}/.github/workflows/test.yml" # GitHub Actions default; overridden per platform
 
 # Required tools
 required_tools:

package/src/workflows/testarch/framework/checklist.md

@@ -8,10 +8,10 @@ This checklist ensures the framework workflow completes successfully and all del
 
 Before starting the workflow:
 
-- [ ] Project root contains valid `package.json`
-- [ ] No existing modern E2E framework detected (`playwright.config.*`, `cypress.config.*`)
-- [ ] Project type identifiable (React, Vue, Angular, Next.js, Node, etc.)
-- [ ] Bundler identifiable (Vite, Webpack, Rollup, esbuild) or not applicable
+- [ ] Project root contains a valid project manifest (`package.json`, `pyproject.toml`, `pom.xml`, `build.gradle`, `go.mod`, `*.csproj`, `Gemfile`, or `Cargo.toml`)
+- [ ] No existing test framework detected that conflicts with the target setup
+- [ ] Project type identifiable (React, Vue, Angular, Next.js, Node, Python, Java, Go, .NET, Ruby, Rust, etc.)
+- [ ] Bundler identifiable (Vite, Webpack, Rollup, esbuild) or not applicable (backend projects)
 - [ ] User has write permissions to create directories and files
 
 ---
@@ -20,7 +20,8 @@ Before starting the workflow:
 
 ### Step 1: Preflight Checks
 
-- [ ] package.json successfully read and parsed
+- [ ] Stack type detected (`frontend`, `backend`, or `fullstack`)
+- [ ] Project manifest successfully read and parsed (`package.json`, `pyproject.toml`, `pom.xml`, `go.mod`, etc.)
 - [ ] Project type extracted correctly
 - [ ] Bundler identified (or marked as N/A for backend projects)
 - [ ] No framework conflicts detected
@@ -29,8 +30,8 @@ Before starting the workflow:
 ### Step 2: Framework Selection
 
 - [ ] Framework auto-detection logic executed
-- [ ] Framework choice justified (Playwright vs Cypress)
-- [ ] Framework preference respected (if explicitly set)
+- [ ] Framework choice justified (Playwright vs Cypress for frontend; pytest/JUnit/Go test/xUnit/RSpec for backend)
+- [ ] Framework preference respected (if explicitly set via `config.test_framework`)
 - [ ] User notified of framework selection and rationale
 
 ### Step 3: Directory Structure
@@ -115,9 +116,9 @@ Before starting the workflow:
 - [ ] Knowledge base references included
 - [ ] Troubleshooting section included
 
-### Step 11: Package.json Updates
+### Step 11: Build & Test Script Updates
 
-- [ ] Minimal test script added to package.json: `test:e2e`
+- [ ] Minimal test script added to appropriate config (`package.json` for frontend, `Makefile`/`pyproject.toml`/`build.gradle` for backend)
 - [ ] Test framework dependency added (if not already present)
 - [ ] Type definitions added (if TypeScript)
 - [ ] Users can extend with additional scripts as needed
@@ -231,7 +232,7 @@ Before starting the workflow:
 - [ ] All quality checks passed
 - [ ] All integration points verified
 - [ ] Sample test executes successfully
-- [ ] User can run `npm run test:e2e` without errors
+- [ ] User can run the appropriate test command without errors (`npm run test:e2e`, `pytest`, `go test ./...`, etc.)
 - [ ] Documentation is complete and accurate
 - [ ] No critical issues or blockers identified
 

package/src/workflows/testarch/framework/steps-c/step-01-preflight.md

@@ -36,19 +36,51 @@ Verify the project is ready for framework scaffolding and gather key context.
 
 **CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise.
 
-## 1. Validate Prerequisites
+## 1. Stack Detection
+
+**Read `config.test_stack_type`** from `{config_source}`.
+
+**Auto-Detection Algorithm** (when `test_stack_type` is `"auto"` or not configured):
+
+- Scan `{project-root}` for project manifests:
+  - **Frontend indicators**: `package.json` with react/vue/angular/next dependencies, `playwright.config.*`, `vite.config.*`, `webpack.config.*`
+  - **Backend indicators**: `pyproject.toml`, `pom.xml`/`build.gradle`, `go.mod`, `*.csproj`/`*.sln`, `Gemfile`, `Cargo.toml`
+  - **Both present** = `fullstack`; only frontend = `frontend`; only backend = `backend`
+- Explicit `test_stack_type` config value overrides auto-detection
+- **Backward compatibility**: if `test_stack_type` is not in config, treat as `"auto"` (preserves current frontend behavior for existing installs)
+
+Store result as `{detected_stack}` = `frontend` | `backend` | `fullstack`
+
+---
+
+## 2. Validate Prerequisites
+
+**If {detected_stack} is `frontend` or `fullstack`:**
 
 - `package.json` exists in project root
 - No existing E2E framework (`playwright.config.*`, `cypress.config.*`, `cypress.json`)
+
+**If {detected_stack} is `backend` or `fullstack`:**
+
+- At least one backend project manifest exists (`pyproject.toml`, `pom.xml`, `build.gradle`, `go.mod`, `*.csproj`, `Gemfile`, `Cargo.toml`)
+- No existing test framework config that conflicts (e.g., `conftest.py` with full pytest suite, `src/test/` with JUnit suite)
+
 - Architecture/stack context available (project type, bundler, dependencies)
 
 If any fail, **HALT** and report the missing requirement.
 
 ---
 
-## 2. Gather Project Context
+## 3. Gather Project Context
+
+**If {detected_stack} is `frontend` or `fullstack`:**
 
 - Read `package.json` to identify framework, bundler, dependencies
+
+**If {detected_stack} is `backend` or `fullstack`:**
+
+- Read the relevant project manifest (`pyproject.toml`, `pom.xml`, `go.mod`, `*.csproj`, `Gemfile`, `Cargo.toml`) to identify language, framework, and dependencies
+
 - Check for architecture docs (`architecture.md`, `tech-spec*.md`) if available
 - Note auth requirements and APIs (if documented)
 

package/src/workflows/testarch/framework/steps-c/step-02-select-framework.md

@@ -37,6 +37,10 @@ Choose the most appropriate framework and document the rationale.
 
 ## 1. Selection Logic
 
+Use `{detected_stack}` from Step 1 to guide framework selection.
+
+**If {detected_stack} is `frontend` or `fullstack` (browser-based testing):**
+
 Default to **Playwright** unless strong reasons suggest Cypress.
 
 **Playwright recommended when:**
@@ -52,7 +56,22 @@ Default to **Playwright** unless strong reasons suggest Cypress.
 - Component testing focus
 - Simpler setup needed
 
-Respect `framework_preference` if explicitly set.
+**If {detected_stack} is `backend` (no browser-based testing):**
+
+Select the framework matching the project language:
+
+- **Python**: pytest (default), unittest
+- **Java/Kotlin**: JUnit 5 (default), TestNG
+- **Go**: Go test (built-in)
+- **C#/.NET**: xUnit (default), NUnit, MSTest
+- **Ruby**: RSpec (default), Minitest
+- **Rust**: cargo test (built-in)
+
+**If {detected_stack} is `fullstack`:**
+
+Select both a browser-based framework (Playwright/Cypress) AND the appropriate backend framework for the detected language.
+
+Respect `config.test_framework` if explicitly set (not `"auto"`).
 
 ---
 

package/src/workflows/testarch/framework/steps-c/step-03-scaffold-framework.md

@@ -39,17 +39,32 @@ Generate the test directory structure, configuration files, fixtures, factories,
 
 ## 1. Create Directory Structure
 
-Create:
+Use `{detected_stack}` from Step 1 to determine directory layout.
+
+**If {detected_stack} is `frontend` or `fullstack`:**
 
 - `{test_dir}/e2e/`
 - `{test_dir}/support/fixtures/`
 - `{test_dir}/support/helpers/`
 - `{test_dir}/support/page-objects/` (optional)
 
+**If {detected_stack} is `backend` or `fullstack`:**
+
+Create the idiomatic test directory for the detected language:
+
+- **Python (pytest)**: `tests/` with `conftest.py`, `tests/unit/`, `tests/integration/`, `tests/api/`
+- **Java/Kotlin (JUnit)**: `src/test/java/` mirroring `src/main/java/` package structure, with `unit/`, `integration/`, `api/` sub-packages
+- **Go**: `*_test.go` files alongside source files (Go convention), plus `testdata/` for fixtures
+- **C#/.NET (xUnit)**: `tests/` project with `Unit/`, `Integration/`, `Api/` directories
+- **Ruby (RSpec)**: `spec/` with `spec/unit/`, `spec/integration/`, `spec/api/`, `spec/support/`
+- **Rust**: `tests/` for integration tests, inline `#[cfg(test)]` modules for unit tests
+
 ---
 
 ## 2. Generate Framework Config
 
+**If {detected_stack} is `frontend` or `fullstack`:**
+
 Create `playwright.config.ts` or `cypress.config.ts` with:
 
 - **Timeouts**: action 15s, navigation 30s, test 60s
@@ -60,15 +75,38 @@ Create `playwright.config.ts` or `cypress.config.ts` with:
 
 Use TypeScript if `use_typescript: true`.
 
+**If {detected_stack} is `backend` or `fullstack`:**
+
+Create the idiomatic test config for the detected framework:
+
+- **pytest**: `pyproject.toml` `[tool.pytest.ini_options]` or `pytest.ini` with markers, test paths, coverage settings
+- **JUnit**: `build.gradle`/`pom.xml` test configuration with JUnit 5 dependencies, Surefire/Failsafe plugins
+- **Go test**: no config file needed (Go convention); optionally create `Makefile` test targets
+- **xUnit**: `.csproj` test project with xUnit and coverlet dependencies
+- **RSpec**: `.rspec` config file with `spec_helper.rb` and `rails_helper.rb` (if Rails)
+
 ---
 
-## 3. Environment & Node
+## 3. Environment Setup
+
+Create `.env.example` with `TEST_ENV`, `BASE_URL`, `API_URL`.
 
-Create:
+**Stack-conditional environment files:**
+
+**If {detected_stack} is `frontend` or `fullstack` (Node.js):**
 
-- `.env.example` with `TEST_ENV`, `BASE_URL`, `API_URL`
 - `.nvmrc` using current LTS Node (prefer Node 24+)
 
+**If {detected_stack} is `backend`:**
+
+Create the idiomatic version file for the detected language:
+
+- **Python**: `.python-version` with current stable Python (prefer 3.12+)
+- **Java**: `.java-version` or `JAVA_HOME` documentation in `.env.example`
+- **Go**: Go version is already in `go.mod` (no additional file needed)
+- **C#/.NET**: `global.json` with SDK version if not already present
+- **Ruby**: `.ruby-version` with current stable Ruby
+
 ---
 
 ## 4. Fixtures & Factories
@@ -94,6 +132,8 @@ Implement:
 
 ## 5. Sample Tests & Helpers
 
+**If {detected_stack} is `frontend` or `fullstack`:**
+
 Create example tests in `{test_dir}/e2e/` demonstrating:
 
 - Given/When/Then format
@@ -101,11 +141,22 @@ Create example tests in `{test_dir}/e2e/` demonstrating:
 - Factory usage
 - Network interception pattern (if applicable)
 
+**If {detected_stack} is `backend` or `fullstack`:**
+
+Create example tests in the idiomatic location for the detected language:
+
+- **Python**: `tests/test_example.py` with pytest fixtures, parametrize, and factory usage
+- **Java**: `src/test/java/.../ExampleTest.java` with JUnit 5 annotations, `@BeforeEach` setup
+- **Go**: `example_test.go` alongside source with table-driven tests and `testify` assertions
+- **C#/.NET**: `tests/ExampleTests.cs` with xUnit `[Fact]`/`[Theory]` and fixture injection
+- **Ruby**: `spec/example_spec.rb` with RSpec `describe`/`context`/`it` and factory_bot
+
 Create helpers for:
 
 - API clients (if needed)
-- Network utilities
+- Network utilities (frontend/fullstack only)
 - Auth helpers
+- Test data factories (language-idiomatic patterns)
 
 ---
 

package/src/workflows/testarch/framework/steps-c/step-04-docs-and-scripts.md

@@ -10,7 +10,7 @@ progressFile: '{test_artifacts}/framework-setup-progress.md'
 
 ## STEP GOAL
 
-Create `tests/README.md` and update `package.json` scripts.
+Create test documentation and add build/test scripts appropriate for `{detected_stack}`.
 
 ## MANDATORY EXECUTION RULES
 
@@ -49,11 +49,23 @@ Create `{outputFile}` and include:
 
 ---
 
-## 2. package.json Scripts
+## 2. Build & Test Scripts
 
-Add at minimum:
+**If {detected_stack} is `frontend` or `fullstack`:**
 
-- `test:e2e`: framework execution command
+Add to `package.json` at minimum:
+
+- `test:e2e`: framework execution command (e.g., `npx playwright test`)
+
+**If {detected_stack} is `backend` or `fullstack`:**
+
+Add the idiomatic test commands for the detected framework:
+
+- **Python (pytest)**: Add to `pyproject.toml` scripts or `Makefile`: `pytest`, `pytest --cov`, `pytest -m integration`
+- **Java (JUnit)**: Add to `build.gradle`/`pom.xml`: `./gradlew test`, `mvn test`, `mvn verify` (integration)
+- **Go**: Add to `Makefile`: `go test ./...`, `go test -race ./...`, `go test -cover ./...`
+- **C#/.NET**: Add to CI scripts or `Makefile`: `dotnet test`, `dotnet test --collect:"XPlat Code Coverage"`
+- **Ruby (RSpec)**: Add to `Gemfile` binstubs or `Makefile`: `bundle exec rspec`, `bundle exec rspec spec/integration`
 
 ---
 

package/src/workflows/testarch/nfr-assess/nfr-report-template.md

@@ -2,6 +2,8 @@
 stepsCompleted: []
 lastStep: ''
 lastSaved: ''
+workflowType: 'testarch-nfr-assess'
+inputDocuments: []
 ---
 
 # NFR Assessment - {FEATURE_NAME}
@@ -262,7 +264,7 @@ Note: This assessment summarizes existing evidence; it does not run tests or CI
    - {SPECIFIC_STEPS}
    - {VALIDATION_CRITERIA}
 
-### Short-term (Next Sprint) - MEDIUM Priority
+### Short-term (Next Milestone) - MEDIUM Priority
 
 1. **{ACTION_TITLE_3}** - {PRIORITY} - {ESTIMATED_EFFORT} - {OWNER}
    - {ACTION_DESCRIPTION}

package/src/workflows/testarch/nfr-assess/steps-c/step-01-load-context.md

@@ -54,6 +54,16 @@ From `{config_source}`:
 
 ---
 
+### Tiered Knowledge Loading
+
+Load fragments based on their `tier` classification in `tea-index.csv`:
+
+1. **Core tier** (always load): Foundational fragments required for this workflow
+2. **Extended tier** (load on-demand): Load when deeper analysis is needed or when the user's context requires it
+3. **Specialized tier** (load only when relevant): Load only when the specific use case matches (e.g., contract-testing only for microservices, email-auth only for email flows)
+
+> **Context Efficiency**: Loading only core fragments reduces context usage by 40-50% compared to loading all fragments.
+
 ## 3. Load Knowledge Base Fragments
 
 From `{knowledgeIndex}` load:
@@ -112,6 +122,8 @@ Summarize loaded NFR sources and evidence availability.
   - Set `lastSaved: '{date}'`
   - Append this step's output to the appropriate section of the document.
 
+**Update `inputDocuments`**: Set `inputDocuments` in the output template frontmatter to the list of artifact paths loaded in this step (e.g., knowledge fragments, test design documents, configuration files).
+
 Load next step: `{nextStepFile}`
 
 ## 🚨 SYSTEM SUCCESS/FAILURE METRICS:

package/src/workflows/testarch/nfr-assess/steps-c/step-05-generate-report.md

@@ -45,7 +45,18 @@ Use `nfr-report-template.md` to produce `{outputFile}` containing:
 
 ---
 
-## 2. Validation
+## 2. Polish Output
+
+Before finalizing, review the complete output document for quality:
+
+1. **Remove duplication**: Progressive-append workflow may have created repeated sections — consolidate
+2. **Verify consistency**: Ensure terminology, risk scores, and references are consistent throughout
+3. **Check completeness**: All template sections should be populated or explicitly marked N/A
+4. **Format cleanup**: Ensure markdown formatting is clean (tables aligned, headers consistent, no orphaned references)
+
+---
+
+## 3. Validation
 
 Validate against `checklist.md` and fix gaps.
 
@@ -53,7 +64,7 @@ Validate against `checklist.md` and fix gaps.
 
 ---
 
-## 3. Save Progress
+## 4. Save Progress
 
 **Save this step's accumulated work to `{outputFile}`.**
 
@@ -77,7 +88,7 @@ Validate against `checklist.md` and fix gaps.
 
 ---
 
-## 4. Completion Summary
+## 5. Completion Summary
 
 Report:
 

package/src/workflows/testarch/test-design/checklist.md

@@ -190,7 +190,7 @@
 - [ ] Prerequisites for testing start are clearly defined
 - [ ] Environment readiness included
 - [ ] Test data readiness included
-- [ ] Sprint 0 blocker resolution referenced
+- [ ] Pre-implementation blocker resolution referenced
 
 ### Exit Criteria
 
@@ -225,7 +225,7 @@
 - [ ] **Purpose statement** at top (serves as contract with Architecture team)
 - [ ] **Executive Summary** with scope, business context, architecture decisions, risk summary
 - [ ] **Quick Guide** section with three tiers:
-  - [ ] 🚨 BLOCKERS - Team Must Decide (Sprint 0 critical path items)
+  - [ ] 🚨 BLOCKERS - Team Must Decide (pre-implementation critical path items)
   - [ ] ⚠️ HIGH PRIORITY - Team Should Validate (recommendations for approval)
   - [ ] 📋 INFO ONLY - Solutions Provided (no decisions needed)
 - [ ] **Risk Assessment** section - **ACTIONABLE**
@@ -262,7 +262,7 @@
   - [ ] NO "Test Levels Strategy" section (unit/integration/E2E split belongs in QA doc only)
   - [ ] NO "NFR Testing Approach" section with detailed test procedures (belongs in QA doc only)
   - [ ] NO "Test Environment Requirements" section (belongs in QA doc only)
-  - [ ] NO "Recommendations for Sprint 0" section with test framework setup (belongs in QA doc only)
+  - [ ] NO "Recommendations for pre-implementation" section with test framework setup (belongs in QA doc only)
   - [ ] NO "Quality Gate Criteria" section (pass rates, coverage targets belong in QA doc only)
   - [ ] NO "Tool Selection" section (Playwright, k6, etc. belongs in QA doc only)
 
@@ -295,11 +295,11 @@
 - [ ] **QA Effort Estimate** section (QA effort ONLY)
   - [ ] Interval-based estimates (e.g., "~1-2 weeks" NOT "36 hours")
   - [ ] NO DevOps, Backend, Data Eng, Finance effort
-  - [ ] No per-sprint effort breakdowns in this section
-- [ ] **Sprint Planning Handoff** section (optional)
+  - [ ] No per-milestone effort breakdowns in this section
+- [ ] **Implementation Planning Handoff** section (optional)
   - [ ] Only include if implementation tasks must be scheduled
   - [ ] Owners assigned (QA/Dev/Platform/etc)
-  - [ ] Target sprint may be noted, but avoid detailed per-sprint breakdowns
+  - [ ] Target milestone may be noted, but avoid detailed per-milestone breakdowns
 - [ ] **Appendix A: Code Examples & Tagging**
 - [ ] **Appendix B: Knowledge Base References**
 
@@ -315,14 +315,14 @@
 - [ ] ❌ NO Follow-on Workflows section (BMAD commands self-explanatory)
 - [ ] ❌ NO Approval section
 - [ ] ❌ NO Infrastructure/DevOps/Finance effort tables (out of scope)
-- [ ] ❌ NO detailed sprint-by-sprint breakdown tables (use Sprint Planning Handoff if needed)
-- [ ] ❌ NO generic Next Steps section (use Sprint Planning Handoff if needed)
+- [ ] ❌ NO detailed milestone-by-milestone breakdown tables (use Implementation Planning Handoff if needed)
+- [ ] ❌ NO generic Next Steps section (use Implementation Planning Handoff if needed)
 
 ### Cross-Document Consistency
 
 - [ ] Both documents reference same risks by ID (R-001, R-002, etc.)
 - [ ] Both documents use consistent priority levels (P0, P1, P2, P3)
-- [ ] Both documents reference same Sprint 0 blockers
+- [ ] Both documents reference same pre-implementation blockers
 - [ ] No duplicate content (cross-reference instead)
 - [ ] Dates and authors match across documents
 - [ ] ADR and PRD references consistent
@@ -361,6 +361,16 @@
   - [ ] Actionable ASRs included in 🚨 or ⚠️ sections
   - [ ] FYI ASRs included in 📋 section or omitted if obvious
 
+## BMAD Handoff Validation (System-Level Mode Only)
+
+- [ ] Handoff document generated at `{test_artifacts}/test-design/{project_name}-handoff.md`
+- [ ] TEA Artifacts Inventory table populated with actual paths
+- [ ] Epic-Level Integration Guidance populated with P0/P1 risks
+- [ ] Story-Level Integration Guidance populated with critical test scenarios
+- [ ] Risk-to-Story Mapping table populated from risk register
+- [ ] Recommended workflow sequence is accurate
+- [ ] Phase transition quality gates are defined
+
 ## Completion Criteria
 
 **All must be true:**
@@ -372,6 +382,7 @@
 - [ ] All integration points verified
 - [ ] Output file(s) complete and well-formatted
 - [ ] **System-level mode:** Both documents validated (if applicable)
+- [ ] **System-level mode:** Handoff document validated (if applicable)
 - [ ] **Epic-level mode:** Single document validated (if applicable)
 - [ ] Team review scheduled (if required)
 

package/src/workflows/testarch/test-design/instructions.md

@@ -74,7 +74,7 @@ When populating templates in step 5, apply the following guidance for these sect
 
 - **Entry criteria**: Derive from Dependencies and Test Blockers -- what must be resolved before QA can start testing
 - **Exit criteria**: Derive from Quality Gate Criteria -- what constitutes "done" for the testing phase
-- Include project-specific criteria based on context (e.g., "feature flag enabled in staging", "seed data loaded", "Sprint 0 blockers resolved")
+- Include project-specific criteria based on context (e.g., "feature flag enabled in staging", "seed data loaded", "pre-implementation blockers resolved")
 
 ### Project Team (Optional)
 
@@ -91,12 +91,12 @@ When populating templates in step 5, apply the following guidance for these sect
 - Mark each item's status as Ready or Pending based on available information
 - This section applies only to `test-design-qa-template.md` output
 
-### Sprint Planning Handoff (Optional)
+### Implementation Planning Handoff (Optional)
 
 - Include only if test design produces implementation tasks that must be scheduled
 - Derive items from Dependencies & Test Blockers, tooling/access needs, and QA infra setup
 - If no dedicated QA, assign ownership to Dev/Platform as appropriate
-- Keep the list short; avoid per-sprint breakdown tables
+- Keep the list short; avoid per-milestone breakdown tables
 
 ### Interworking & Regression
 

package/src/workflows/testarch/test-design/steps-c/step-02-load-context.md

@@ -43,8 +43,18 @@ From `{config_source}`:
 
 - Read `tea_use_playwright_utils`
 - Read `tea_browser_automation`
+- Read `test_stack_type` (if not set, default to `"auto"`)
 - Note `test_artifacts`
 
+**Stack Detection** (for context-aware loading):
+
+If `test_stack_type` is `"auto"` or not configured, infer `{detected_stack}` by scanning `{project-root}`:
+
+- **Frontend indicators**: `playwright.config.*`, `cypress.config.*`, `package.json` with react/vue/angular
+- **Backend indicators**: `pyproject.toml`, `pom.xml`/`build.gradle`, `go.mod`, `*.csproj`, `Gemfile`, `Cargo.toml`
+- **Both present** → `fullstack`; only frontend → `frontend`; only backend → `backend`
+- Explicit `test_stack_type` overrides auto-detection
+
 ---
 
 ## 2. Load Project Artifacts (Mode-Specific)
@@ -108,6 +118,28 @@ Store artifacts under `{test_artifacts}/exploration/`
 
 ---
 
+### Tiered Knowledge Loading
+
+Load fragments based on their `tier` classification in `tea-index.csv`:
+
+1. **Core tier** (always load): Foundational fragments required for this workflow
+2. **Extended tier** (load on-demand): Load when deeper analysis is needed or when the user's context requires it
+3. **Specialized tier** (load only when relevant): Load only when the specific use case matches (e.g., contract-testing only for microservices, email-auth only for email flows)
+
+> **Context Efficiency**: Loading only core fragments reduces context usage by 40-50% compared to loading all fragments.
+
+### Playwright Utils Loading Profiles
+
+**If `tea_use_playwright_utils` is enabled**, select the appropriate loading profile:
+
+- **API-only profile** (when `{detected_stack}` is `backend` or no `page.goto`/`page.locator` found in test files):
+  Load: `overview`, `api-request`, `auth-session`, `recurse` (~1,800 lines)
+
+- **Full UI+API profile** (when `{detected_stack}` is `frontend`/`fullstack` or browser tests detected):
+  Load: all Playwright Utils core fragments (~4,500 lines)
+
+**Detection**: Scan `{test_dir}` for files containing `page.goto` or `page.locator`. If none found, use API-only profile.
+
 ## 4. Load Knowledge Base Fragments
 
 Use `{knowledgeIndex}` to select and load only relevant fragments.
@@ -164,6 +196,8 @@ Summarize what was loaded and confirm with the user if anything is missing.
   - Set `lastSaved: '{date}'`
   - Append this step's output to the appropriate section of the document.
 
+**Update `inputDocuments`**: Set `inputDocuments` in the output template frontmatter to the list of artifact paths loaded in this step (e.g., knowledge fragments, test design documents, configuration files).
+
 Load next step: `{nextStepFile}`
 
 ## 🚨 SYSTEM SUCCESS/FAILURE METRICS: