bmad-method-test-architecture-enterprise 1.27.2-next.2 → 1.27.2-next.3

package/.claude-plugin/marketplace.json

@@ -31,7 +31,7 @@
       "name": "bmad-method-test-architecture-enterprise",
       "source": "./",
       "description": "Master Test Architect module for quality strategy, test automation, CI/CD quality gates, and structured testing education. Part of the BMad Method ecosystem.",
-      "version": "1.27.2-next.2",
+      "version": "1.27.2-next.3",
       "author": {
         "name": "Murat K Ozcan (TEA Creator) & Brian (BMad) Madison"
       },

package/package.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://json.schemastore.org/package.json",
   "name": "bmad-method-test-architecture-enterprise",
-  "version": "1.27.2-next.2",
+  "version": "1.27.2-next.3",
   "description": "Master Test Architect for quality strategy, test automation, and release gates",
   "keywords": [
     "bmad",

package/src/workflows/testarch/bmad-testarch-atdd/steps-c/step-01-preflight-and-context.md

@@ -109,49 +109,11 @@ From `{config_source}`:
 
 ---
 
-### Tiered Knowledge Loading
+### Deterministic Knowledge Selection
 
-Load fragments based on their `tier` classification in `tea-index.csv`:
+The fragment list for this step is a closed set. Start empty, evaluate the complete conditions under **Load Knowledge Base Fragments**, and add every fragment from each matching list. A config flag opens a branch only when every stack, runner, package, and relevance condition on that branch also matches. Do not add fragments from tier labels, index descriptions, nearby mentions, general usefulness, or possible future need. Deduplicate while preserving the order below. Identical facts and config must produce an identical list.
 
-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**, load `playwright-utils-mandate.md` FIRST, before any profile below. It is the binding rule for this run: playwright-utils is the default implementation for every capability it covers, and a vanilla Playwright equivalent is a deviation that must be justified in the output. Red-phase scaffolds are still real test code, so the mandate applies to them exactly as it applies to green tests.
-
-Then select the appropriate loading profile:
-
-- **API-only profile** (when `{detected_stack}` is `backend` or no `page.goto`/`page.locator` found in test files):
-  Load: `playwright-utils-mandate`, `overview`, `api-request`, `auth-session`, `recurse` (~2,100 lines)
-
-- **Full UI+API profile** (when `{detected_stack}` is `frontend`/`fullstack` or browser tests detected):
-  Load: `playwright-utils-mandate` plus all Playwright Utils core fragments (~4,800 lines)
-
-**Detection**: Scan `{test_dir}` for files containing `page.goto` or `page.locator`. If none found, use API-only profile.
-
-### Pact.js Utils Loading
-
-**If `tea_use_pactjs_utils` is enabled** (and `{detected_stack}` is `backend` or `fullstack`, or a microservices layout is detected, `pactjs-utils-mandate.md`'s own definition: two or more independently deployable services in this repo that call each other):
-
-Load `pactjs-utils-mandate.md` FIRST. It is the binding rule for any Pact artifact this run produces, and it carries the relevance gate: the flag defaults to `true` and means "use these utilities when contract tests are written", never "add contract tests to this project".
-
-Then load: `pactjs-utils-overview.md`, `pactjs-utils-consumer-helpers.md`, `pactjs-utils-provider-verifier.md`, `pactjs-utils-request-filter.md`, `pactjs-utils-zod-to-pact.md`, `pact-consumer-di.md`, `pact-consumer-framework-setup.md`, `pact-broker-webhooks.md`
-
-**If `tea_use_pactjs_utils` is disabled** but contract testing is relevant:
-
-Load: `contract-testing.md`
-
-### Pact MCP Loading
-
-**If `tea_pact_mcp` is `"mcp"`:**
-
-Load: `pact-mcp.md`
-
-**`tea_pact_mcp` defaults to `"mcp"`, and Pact artifacts are gated on relevance, not on this flag.** Follow `pact-mcp.md` § _When the Tools Are Not Reachable_: the probe is a tool-list check and never a broker call, its result is recorded once per run as `pact_mcp_reachable`, and the fallback order is provider source, then an OpenAPI spec, then `confidence-gate.md`. Report the outcome once and continue; never block, never retry, never present inferred provider states as broker data.
+Contract testing is relevant only when repository facts show existing Pact artifacts, dependencies, configuration, or broker variables, or when the task explicitly requests contract testing. A service count or target-state architecture alone does not open a contract branch.
 
 ## 5. Load Knowledge Base Fragments
 
@@ -169,7 +131,7 @@ Use `{knowledgeIndex}` to load:
 - `selector-resilience.md`
 - `timing-debugging.md`
 
-**Playwright Utils (if enabled and {detected_stack} is `frontend` or `fullstack`):**
+**Playwright Utils (if enabled, `@seontechnologies/playwright-utils` is in `package.json`, the test files run on the Playwright runner, and {detected_stack} is `frontend` or `fullstack`):**
 
 - `playwright-utils-mandate.md` (load first — it governs how the fragments below are applied)
 - `overview.md`, `api-request.md`, `network-recorder.md`, `auth-session.md`, `intercept-network-call.md`, `recurse.md`, `log.md`, `file-utils.md`, `network-error-monitor.md`, `fixtures-composition.md`
@@ -183,7 +145,7 @@ Use `{knowledgeIndex}` to load:
 
 - (existing MCP-related fragments, if any are added in future)
 
-**Traditional Patterns (if utils disabled and {detected_stack} is `frontend` or `fullstack`):**
+**Traditional Patterns (if the Playwright Utils applicability gate above did not open and {detected_stack} is `frontend` or `fullstack`):**
 
 - `fixture-architecture.md`
 - `network-first.md`
@@ -194,16 +156,16 @@ Use `{knowledgeIndex}` to load:
 - `test-priorities-matrix.md`
 - `ci-burn-in.md`
 
-**Pact.js Utils (if enabled and contract testing is relevant):**
+**Pact.js Utils (if enabled, `@seontechnologies/pactjs-utils` is in `package.json`, and contract testing is relevant):**
 
 - `pactjs-utils-mandate.md` (load first — it governs how the fragments below are applied)
 - `pactjs-utils-overview.md`, `pactjs-utils-consumer-helpers.md`, `pactjs-utils-provider-verifier.md`, `pactjs-utils-request-filter.md`, `pactjs-utils-zod-to-pact.md`, `pact-consumer-di.md`, `pact-consumer-framework-setup.md`, `pact-broker-webhooks.md`
 
-**Contract Testing (if pactjs-utils disabled but relevant):**
+**Contract Testing (if Pact.js Utils is disabled or not installed, and contract testing is relevant):**
 
 - `contract-testing.md`
 
-**Pact MCP (if tea_pact_mcp is "mcp"):**
+**Pact MCP (if tea_pact_mcp is "mcp" and contract testing is relevant):**
 
 - `pact-mcp.md`
 

package/src/workflows/testarch/bmad-testarch-automate/steps-c/step-01-preflight-and-context.md

@@ -113,56 +113,11 @@ If required framework configuration is missing: **HALT** with message "Run `fram
 
 ---
 
-### Tiered Knowledge Loading
+### Deterministic Knowledge Selection
 
-Load fragments based on their `tier` classification in `tea-index.csv`:
+The fragment list for this step is a closed set. Start empty, evaluate the complete conditions under **Load Knowledge Base Fragments**, and add every fragment from each matching list. A config flag opens a branch only when every stack, runner, package, and relevance condition on that branch also matches. Do not add fragments from tier labels, index descriptions, nearby mentions, general usefulness, or possible future need. Deduplicate while preserving the order below. Identical facts and config must produce an identical list.
 
-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**, load `playwright-utils-mandate.md` FIRST, before any profile below. It is the binding rule for this run: playwright-utils is the default implementation for every capability it covers, and a vanilla Playwright equivalent is a deviation that must be justified in the output. Every worker step dispatched from this workflow inherits that rule.
-
-Then select the appropriate loading profile:
-
-- **API-only profile** (when `{detected_stack}` is `backend` or no `page.goto`/`page.locator` found in test files):
-  Load: `playwright-utils-mandate`, `overview`, `api-request`, `auth-session`, `recurse` (~2,100 lines)
-
-- **Full UI+API profile** (when `{detected_stack}` is `frontend`/`fullstack` or browser tests detected):
-  Load: `playwright-utils-mandate` plus all Playwright Utils core fragments (~4,800 lines)
-
-- **Mobile profile** (when `{detected_stack}` is `mobile`):
-  Load: `mobile-test-strategy`, `maestro-flows`, `mobile-ci-device-lab`, `test-levels-framework`, `test-priorities-matrix`, `test-quality`, plus `playwright-utils-mandate`, `overview`, `api-request`, `auth-session`, `recurse` for the app's HTTP boundary.
-  Do NOT load the browser fragments (`network-first`, `playwright-config`, `intercept-network-call`, `selector-resilience`): a device flow has no DOM and no request interceptor, and loading them invites browser patterns into a Maestro flow.
-  The mandate is loaded here for the HTTP-boundary tests only. It has no bearing on a Maestro flow, and its own scope section says so.
-
-**Detection**: Scan `{test_dir}` for files containing `page.goto` or `page.locator`. If none found, use API-only profile. A `maestro/` or `.maestro/` directory selects the mobile profile regardless of what `{test_dir}` holds.
-
-### Pact.js Utils Loading
-
-**If `tea_use_pactjs_utils` is enabled** (and `{detected_stack}` is `backend` or `fullstack`, or a microservices layout is detected, `pactjs-utils-mandate.md`'s own definition: two or more independently deployable services in this repo that call each other):
-
-Load `pactjs-utils-mandate.md` FIRST. It is the binding rule for any Pact artifact this run produces, and it carries the relevance gate: the flag defaults to `true` and means "use these utilities when contract tests are written", never "add contract tests to this project".
-
-Then load: `pactjs-utils-overview.md`, `pactjs-utils-consumer-helpers.md`, `pactjs-utils-provider-verifier.md`, `pactjs-utils-request-filter.md`, `pactjs-utils-zod-to-pact.md` (~1,100 lines)
-
-**If `tea_use_pactjs_utils` is disabled** but contract testing is relevant (a microservices layout detected per the definition above, or existing Pact config found):
-
-Load: `contract-testing.md` (~960 lines)
-
-**Detection**: Scan `{project-root}` for Pact indicators: `pact/` directory, `@pact-foundation/pact` in `package.json`, `pactUrls` in test files, `PACT_BROKER` in env files.
-
-### Pact MCP Loading
-
-**If `tea_pact_mcp` is `"mcp"`:**
-
-Load: `pact-mcp.md` (~150 lines) — enables agent to use SmartBear MCP tools for fetching provider states and generating pact tests during automation.
-
-**`tea_pact_mcp` defaults to `"mcp"`, and Pact artifacts are gated on relevance, not on this flag.** Follow `pact-mcp.md` § _When the Tools Are Not Reachable_: the probe is a tool-list check and never a broker call, its result is recorded once per run as `pact_mcp_reachable`, and the fallback order is provider source, then an OpenAPI spec, then `confidence-gate.md`. Report the outcome once and continue; never block, never retry, never present inferred provider states as broker data.
+Contract testing is relevant only when repository facts show existing Pact artifacts, dependencies, configuration, or broker variables, or when the task explicitly requests contract testing. A service count or target-state architecture alone does not open a contract branch.
 
 ## 4. Load Knowledge Base Fragments
 
@@ -177,27 +132,33 @@ Use `{knowledgeIndex}` and load only what is required.
 - `ci-burn-in.md`
 - `test-quality.md`
 
-**Playwright Utils (if enabled):**
+**Mobile (if `{detected_stack}` is `mobile`):**
+
+- `mobile-test-strategy.md`
+- `maestro-flows.md`
+- `mobile-ci-device-lab.md`
+
+**Playwright Utils (if enabled, `@seontechnologies/playwright-utils` is in `package.json`, and the test files run on the Playwright runner):**
 
 - `playwright-utils-mandate.md` (load first — it governs how the fragments below are applied)
 - `overview.md`, `api-request.md`, `network-recorder.md`, `auth-session.md`, `intercept-network-call.md`, `recurse.md`, `log.md`, `file-utils.md`, `burn-in.md`, `network-error-monitor.md`, `fixtures-composition.md`
 - `fixture-architecture.md` and `network-first.md` for their principles only. Under the mandate the mechanism comes from the playwright-utils fragments: interception is `interceptNetworkCall` declared before `page.goto`, and composition is `mergeTests`.
 
-**Traditional Patterns (if Playwright Utils disabled):**
+**Traditional Patterns (if the Playwright Utils applicability gate above did not open and the test files run on the Playwright runner):**
 
 - `fixture-architecture.md`
 - `network-first.md`
 
-**Pact.js Utils (if enabled and contract testing is relevant):**
+**Pact.js Utils (if enabled, `@seontechnologies/pactjs-utils` is in `package.json`, and contract testing is relevant):**
 
 - `pactjs-utils-mandate.md` (load first — it governs how the fragments below are applied)
 - `pactjs-utils-overview.md`, `pactjs-utils-consumer-helpers.md`, `pactjs-utils-provider-verifier.md`, `pactjs-utils-request-filter.md`, `pactjs-utils-zod-to-pact.md`
 
-**Contract Testing (if pactjs-utils disabled but relevant):**
+**Contract Testing (if Pact.js Utils is disabled or not installed, and contract testing is relevant):**
 
 - `contract-testing.md`
 
-**Pact MCP (if tea_pact_mcp is "mcp"):**
+**Pact MCP (if tea_pact_mcp is "mcp" and contract testing is relevant):**
 
 - `pact-mcp.md`
 
@@ -207,7 +168,7 @@ Use `{knowledgeIndex}` and load only what is required.
 - `selector-resilience.md`
 - `timing-debugging.md`
 
-**Playwright CLI (if tea_browser_automation is "cli" or "auto"):**
+**Playwright CLI (if tea_browser_automation is "cli" or "auto" and the test files run on the Playwright runner):**
 
 - `playwright-cli.md`
 

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

@@ -164,7 +164,7 @@ Include stages:
 
 - lint
 - test (parallel shards)
-- contract-test (if `tea_use_pactjs_utils` enabled)
+- contract-test (if `tea_use_pactjs_utils` is enabled and Step 1 found contract testing relevant)
 - burn-in (flaky detection)
 - report (aggregate + publish)
 
@@ -197,9 +197,9 @@ Write the selected pipeline configuration to the resolved output path from step
   - **Artifacts**: upload the per-step statuses, hierarchy dumps, screenshots, video, AND device logs on failure, resolving the newest run directory rather than globbing a flat filename that recent versions no longer write. The hierarchy dump captured at failure is what identifies a selector break; the failure screenshot is taken after teardown and frequently shows the launcher, so do not lead with it.
   - **Cache**: Gradle or CocoaPods plus the JS toolchain for React Native and Expo.
 
-### Contract Testing Pipeline (if `tea_use_pactjs_utils` enabled)
+### Contract Testing Pipeline (if `tea_use_pactjs_utils` is enabled and Step 1 found contract testing relevant)
 
-**If `tea_use_pactjs_utils` is enabled**, use `{knowledgeIndex}` to load:
+**If `tea_use_pactjs_utils` is enabled and Step 1 found contract testing relevant**, use `{knowledgeIndex}` to load:
 
 - `pact-consumer-framework-setup.md` — determinism gate, `jq -S` publish normalization, PR-only provider branch detection, additive branch-aware `can-i-deploy`, 1:1 local/CI parity
 - `pactjs-utils-consumer-helpers.md` — one-interaction-per-`it()` determinism rule
@@ -207,7 +207,7 @@ Write the selected pipeline configuration to the resolved output path from step
 - `pactjs-utils-request-filter.md` — `createRequestFilter` auth injection patterns for CI pipeline auth setup
 - `pact-broker-webhooks.md` — PactFlow → GitHub webhook auth, exact registered provider target checkout, rotation runbook, and staleness monitoring
 
-When `tea_use_pactjs_utils` is enabled, add a `contract-test` stage after `test`:
+When `tea_use_pactjs_utils` is enabled and Step 1 found contract testing relevant, add a `contract-test` stage after `test`:
 
 **Required env block** (add to the generated pipeline):
 
@@ -256,7 +256,7 @@ env:
 
 Required CI secrets: `PACT_BROKER_BASE_URL`, `PACT_BROKER_TOKEN`
 
-**If `tea_pact_mcp` is `"mcp"`:** Reference the SmartBear MCP `Can I Deploy` and `Matrix` tools for pipeline guidance in `pact-mcp.md`.
+**If `tea_pact_mcp` is `"mcp"` and contract testing is relevant:** Reference the SmartBear MCP `Can I Deploy` and `Matrix` tools for pipeline guidance in `pact-mcp.md`.
 
 **`tea_pact_mcp` defaults to `"mcp"`, and Pact artifacts are gated on relevance, not on this flag.** Follow `pact-mcp.md` § _When the Tools Are Not Reachable_: the probe is a tool-list check and never a broker call, its result is recorded once per run as `pact_mcp_reachable`, and the fallback order is provider source, then an OpenAPI spec, then `confidence-gate.md`. Report the outcome once and continue; never block, never retry, never present inferred provider states as broker data.
 
@@ -290,7 +290,7 @@ For this step, treat these work units as parallelizable when `resolvedMode` is `
 
 - Worker A: resolve platform path/template and produce base pipeline skeleton (section 1)
 - Worker B: construct stage definitions and test execution blocks (sections 2-3)
-- Worker C: contract-testing block (only when `tea_use_pactjs_utils` is true)
+- Worker C: contract-testing block (only when `tea_use_pactjs_utils` is true and Step 1 found contract testing relevant)
 
 If `resolvedMode` is `sequential`, execute sections 1→4 in order.
 

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

@@ -36,6 +36,12 @@ Configure burn-in loops, quality thresholds, and notification hooks.
 
 **CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise.
 
+### Deterministic Knowledge Selection
+
+The fragment list for this step is a closed set. Start empty, evaluate the complete conditions in the numbered sections below, and add every fragment from each matching list. A config flag opens a branch only when every stack, runner, package, and relevance condition on that branch also matches. Do not add fragments from tier labels, index descriptions, nearby mentions, general usefulness, or possible future need. Deduplicate while preserving the order below. Identical facts and config must produce an identical list.
+
+Contract testing is relevant only when repository facts show existing Pact artifacts, dependencies, configuration, or broker variables, or when the task explicitly requests contract testing. A service count or target-state architecture alone does not open a contract branch.
+
 ## 1. Burn-In Configuration
 
 Use `{knowledgeIndex}` to load `ci-burn-in.md` guidance:
@@ -65,7 +71,7 @@ Skip this for Cypress, Maestro, and non-Playwright backend suites; those keep th
 - **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.
 - **Mobile** (`test_stack_type` is `mobile`): Enable burn-in by default, and scope it to new and changed Maestro flows only. Device flows are the most flake-prone level in any suite (emulator boot, app install, animation timing, real network), so a new flow that has not survived repeated runs is not evidence. Never burn in the whole flow suite on a PR: run the changed flows N times on the primary target, and leave the full matrix to the nightly job.
 
-**The gate must be able to fail.** Per `evidence-integrity.md`, `continue-on-error` belongs on artifact collection and never on a step that runs tests, and a runner manifest that names a subset of the discovered test files is a silent coverage hole rather than a configuration choice. Reconcile the executed count against the discovered count in the job, so a suite that quietly stopped running most of itself fails instead of passing faster.
+**The gate must be able to fail.** `continue-on-error` belongs on artifact collection and never on a step that runs tests, and a runner manifest that names a subset of the discovered test files is a silent coverage hole rather than a configuration choice. Reconcile the executed count against the discovered count in the job, so a suite that quietly stopped running most of itself fails instead of passing faster.
 
 **Security: Script injection prevention for reusable burn-in workflows:**
 
@@ -100,7 +106,7 @@ Define:
 - Fail CI on critical test failures
 - Optional: require traceability or nfr-assess output before release
 
-**Contract testing gate** (if `tea_use_pactjs_utils` is enabled):
+**Contract testing gate** (if `tea_use_pactjs_utils` is enabled and contract testing is relevant):
 
 Use `{knowledgeIndex}` to load:
 

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

@@ -236,6 +236,12 @@ Create the idiomatic version file for the detected language:
 
 Read `{config_source}` and use `{knowledgeIndex}` to load fragments based on `{detected_stack}`:
 
+### Deterministic Knowledge Selection
+
+The fragment list for this step is a closed set. Start empty, evaluate the complete conditions in this section, and add every fragment from each matching list. A config flag opens a branch only when every stack, runner, package, and relevance condition on that branch also matches. Do not add fragments from tier labels, index descriptions, nearby mentions elsewhere in this step, general usefulness, or possible future need. Deduplicate while preserving the order below. Identical facts and config must produce an identical list.
+
+Contract testing is relevant only when repository facts show existing Pact artifacts, dependencies, configuration, or broker variables, or when the task explicitly requests contract testing. A service count or target-state architecture alone does not open a contract branch.
+
 **If `{detected_stack}` is `mobile`:**
 
 - `mobile-test-strategy.md` (CRITICAL: load this first — it decides which behaviors become device flows at all, and most should not)
@@ -289,7 +295,7 @@ Read `{config_source}` and use `{knowledgeIndex}` to load fragments based on `{d
 
 - `contract-testing.md`
 
-**If Pact MCP enabled** (`config.tea_pact_mcp` is `"mcp"`):
+**If Pact MCP is enabled and the relevance gate in section 1 opened** (`config.tea_pact_mcp` is `"mcp"`):
 
 - `pact-mcp.md`
 

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

@@ -54,15 +54,9 @@ From `{config_source}`:
 
 ---
 
-### Tiered Knowledge Loading
+### Deterministic Knowledge Selection
 
-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.
+The fragment list for this step is a closed set. Start empty, evaluate the complete conditions under **Load Knowledge Base Fragments**, and add every fragment from each matching list. A config flag opens a branch only when every stack, runner, package, and relevance condition on that branch also matches. Do not add fragments from tier labels, index descriptions, nearby mentions, general usefulness, or possible future need. Deduplicate while preserving the order below. Identical facts and config must produce an identical list.
 
 ## 3. Load Knowledge Base Fragments
 

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

@@ -125,49 +125,11 @@ Store artifacts under `{test_artifacts}/exploration/`
 
 ---
 
-### Tiered Knowledge Loading
+### Deterministic Knowledge Selection
 
-Load fragments based on their `tier` classification in `tea-index.csv`:
+The fragment list for this step is a closed set. Start empty, evaluate the complete conditions under **Load Knowledge Base Fragments**, and add every fragment from each matching list. A config flag opens a branch only when every stack, runner, package, and relevance condition on that branch also matches. Do not add fragments from tier labels, index descriptions, nearby mentions, general usefulness, or possible future need. Deduplicate while preserving the order below. Identical facts and config must produce an identical list.
 
-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**, load `playwright-utils-mandate.md` FIRST, before any profile below. Every code example this workflow puts into a design document is a pattern a developer will copy, so the examples follow the mandate: `apiRequest` rather than the raw `request` fixture, `interceptNetworkCall` rather than `page.route`, `test` imported from the project's merged fixtures with `expect` still from `@playwright/test`.
-
-Then select the appropriate loading profile:
-
-- **API-only profile** (when `{detected_stack}` is `backend` or no `page.goto`/`page.locator` found in test files):
-  Load: `playwright-utils-mandate`, `overview`, `api-request`, `auth-session`, `recurse` (~2,100 lines)
-
-- **Full UI+API profile** (when `{detected_stack}` is `frontend`/`fullstack` or browser tests detected):
-  Load: `playwright-utils-mandate` plus all Playwright Utils core fragments (~4,800 lines)
-
-**Detection**: Scan `{test_dir}` for files containing `page.goto` or `page.locator`. If none found, use API-only profile.
-
-### Pact.js Utils Loading
-
-**If `tea_use_pactjs_utils` is enabled** and contract testing is relevant. Relevance is not a stack question: the consumer side of a contract is most often a `frontend`, and gating on `backend`/`fullstack` alone skips exactly the case Pact exists for. Load when `{detected_stack}` is `backend` or `fullstack`, **or** when Pact artifacts are present on any stack (a `pact/` or `tests/contract/` directory, `.pacttest.ts` files, `@pact-foundation/pact` in `package.json`, `PACT_BROKER_*` in the environment), **or** when a microservices layout is detected, `pactjs-utils-mandate.md`'s own definition: two or more independently deployable services in this repo that call each other. A target-state architecture description naming a service count, with no repo to inspect yet, does not satisfy this on its own:
-
-Load `pactjs-utils-mandate.md` FIRST. Every Pact code example this workflow puts into a design document is a pattern a developer will copy, so the examples follow the mandate: `createProviderState` rather than a hand-cast `.given()`, `buildVerifierOptions` rather than a literal options object. The mandate also carries the relevance gate: the flag defaults to `true` and never means "add contract tests to this project".
-
-Then load: `pactjs-utils-overview.md`, `pactjs-utils-consumer-helpers.md`, `pactjs-utils-provider-verifier.md`, `pactjs-utils-request-filter.md`, `pactjs-utils-zod-to-pact.md`
-
-**If `tea_use_pactjs_utils` is disabled** but contract testing is relevant:
-
-Load: `contract-testing.md`
-
-### Pact MCP Loading
-
-**If `tea_pact_mcp` is `"mcp"`:**
-
-Load: `pact-mcp.md` — enables agent to use SmartBear MCP "Fetch Provider States" and "Matrix" tools to understand existing contract landscape during test design.
-
-**`tea_pact_mcp` defaults to `"mcp"`, and Pact artifacts are gated on relevance, not on this flag.** Follow `pact-mcp.md` § _When the Tools Are Not Reachable_: the probe is a tool-list check and never a broker call, its result is recorded once per run as `pact_mcp_reachable`, and the fallback order is provider source, then an OpenAPI spec, then `confidence-gate.md`. Report the outcome once and continue; never block, never retry, never present inferred provider states as broker data.
+Contract testing is relevant only when repository facts show existing Pact artifacts, dependencies, configuration, or broker variables, or when the task explicitly requests contract testing. A service count or target-state architecture alone does not open a contract branch.
 
 ## 4. Load Knowledge Base Fragments
 
@@ -201,15 +163,15 @@ Use `{knowledgeIndex}` to select and load only relevant fragments.
 
 - (existing MCP-related fragments, if any are added in future)
 
-**Pact.js Utils (if enabled — both System-Level and Epic-Level):**
+**Pact.js Utils (if enabled, `@seontechnologies/pactjs-utils` is in `package.json`, and contract testing is relevant, in either mode):**
 
-- `pactjs-utils-overview.md`, `pactjs-utils-consumer-helpers.md`, `pactjs-utils-provider-verifier.md`, `pactjs-utils-request-filter.md`
+- `pactjs-utils-mandate.md`, `pactjs-utils-overview.md`, `pactjs-utils-consumer-helpers.md`, `pactjs-utils-provider-verifier.md`, `pactjs-utils-request-filter.md`
 
-**Contract Testing (if pactjs-utils disabled but relevant):**
+**Contract Testing (if Pact.js Utils is disabled or not installed, and contract testing is relevant):**
 
 - `contract-testing.md`
 
-**Pact MCP (if tea_pact_mcp is "mcp"):**
+**Pact MCP (if tea_pact_mcp is "mcp" and contract testing is relevant):**
 
 - `pact-mcp.md`
 

package/src/workflows/testarch/bmad-testarch-test-review/steps-c/step-01-load-context.md

@@ -61,55 +61,9 @@ Read `test_stack_type` from `{config_source}`. If `"auto"` or not configured, in
 
 ---
 
-### Tiered Knowledge Loading
+### Deterministic Knowledge Selection
 
-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**, load `playwright-utils-mandate.md` FIRST, before any profile below. It supplies the firing predicate for registry rows M9 and L9: which vanilla calls have a required substitution, which are legitimate exceptions, and which utilities are recommended rather than required and therefore never deduct.
-
-Then select the appropriate loading profile:
-
-- **API-only profile** (when `{detected_stack}` is `backend` or no `page.goto`/`page.locator` found in test files):
-  Load: `playwright-utils-mandate`, `overview`, `api-request`, `auth-session`, `recurse` (~2,100 lines)
-
-- **Full UI+API profile** (when `{detected_stack}` is `frontend`/`fullstack` or browser tests detected):
-  Load: `playwright-utils-mandate` plus all Playwright Utils core fragments (~4,800 lines)
-
-**Detection**: Scan `{test_dir}` for files containing `page.goto` or `page.locator`. If none found, use API-only profile.
-
-The profiles above assume a JavaScript/TypeScript suite on the Playwright runner. For a Cypress project, a Maestro flow set, or a backend suite in pytest, JUnit, Go test, xUnit, or RSpec, skip them entirely whatever the flag says: the mandate does not bind those runners, so loading its fragments only spends context and invites rows that cannot fire. Decide by the runner the reviewed files execute under, not by the language of the code they test.
-
-**Also record whether `@seontechnologies/playwright-utils` is in the project's `package.json`.** Carry it into `subagentContext` as `playwright_utils_installed`. The M9 gate needs both the flag and the package: the flag alone is an intention, and deducting against an uninstalled library produces findings nobody can act on file by file. When the flag is true and the package is missing, say so once in the report and recommend the `framework` workflow.
-
-### Pact.js Utils Loading
-
-**If `tea_use_pactjs_utils` is enabled** (and contract tests detected in review scope):
-
-Load `pactjs-utils-mandate.md` FIRST. It supplies the firing predicate for registry row M10: which raw-Pact constructs have a required substitution, which are legitimate exceptions, and which utilities are recommended rather than required and therefore never deduct.
-
-**Also record whether `@seontechnologies/pactjs-utils` is in the project's `package.json`.** Carry it into `subagentContext` as `pactjs_utils_installed`. The M10 gate needs both the flag and the package, for the same reason M9 does.
-
-Then load: `pactjs-utils-overview.md`, `pactjs-utils-consumer-helpers.md` (one-interaction-per-`it()` determinism rule), `pactjs-utils-provider-verifier.md` (vitest `pool: 'forks'` + `singleFork` — applies to BOTH consumer and provider), `pactjs-utils-request-filter.md`, `pactjs-utils-zod-to-pact.md`, `pact-consumer-framework-setup.md` (consumer Vitest `fileParallelism: false` + `pool: 'forks'` + `singleFork: true`, determinism gate, `jq` publish normalization), `pact-broker-webhooks.md` (webhook auth, PAT rotation, staleness monitoring — relevant if CI failure patterns include `can-i-deploy` timeouts with no verification).
-
-**If `tea_use_pactjs_utils` is disabled** but contract tests are in review scope:
-
-Load: `contract-testing.md`
-
-### Pact MCP Loading
-
-**If `tea_pact_mcp` is `"mcp"`:**
-
-Load: `pact-mcp.md` — enables agent to use SmartBear MCP "Review Pact Tests" tool for automated best-practice feedback during test review.
-
-**`tea_pact_mcp` defaults to `"mcp"`, and Pact artifacts are gated on relevance, not on this flag.** Follow `pact-mcp.md` § _When the Tools Are Not Reachable_: the probe is a tool-list check and never a broker call, its result is recorded once per run as `pact_mcp_reachable`, and the fallback order is provider source, then an OpenAPI spec, then `confidence-gate.md`. Report the outcome once and continue; never block, never retry, never present inferred provider states as broker data.
+The fragment list for this step is a closed set. Start empty, evaluate the complete conditions under **Load Knowledge Base**, and add every fragment from each matching list. A config flag opens a branch only when every stack, runner, package, and relevance condition on that branch also matches. Do not add fragments from tier labels, index descriptions, nearby mentions, general usefulness, or possible future need. Deduplicate while preserving the order below. Identical facts and config must produce an identical list.
 
 ## 2. Load Knowledge Base
 
@@ -134,12 +88,12 @@ Read `{config_source}` and check `tea_use_playwright_utils`, `tea_use_pactjs_uti
 
 Without these, a flow is reviewed against browser predicates that cannot match it, which is how a flow used to score 100 by matching nothing.
 
-**If Playwright Utils enabled:**
+**If Playwright Utils is enabled, installed, and the reviewed files run on the Playwright runner:**
 
 - `playwright-utils-mandate.md`: required to score rows M9 and L9
 - `overview.md`, `api-request.md`, `network-recorder.md`, `auth-session.md`, `intercept-network-call.md`, `recurse.md`, `log.md`, `file-utils.md`, `burn-in.md`, `network-error-monitor.md`, `fixtures-composition.md`
 
-**If disabled:**
+**If Playwright Utils is disabled and the reviewed files run on the Playwright runner:**
 
 - `fixture-architecture.md`
 - `network-first.md`
@@ -147,7 +101,7 @@ Without these, a flow is reviewed against browser predicates that cannot match i
 - `component-tdd.md`
 - `ci-burn-in.md`
 
-**Playwright CLI (if `tea_browser_automation` is "cli" or "auto"):**
+**Playwright CLI (if `tea_browser_automation` is "cli" or "auto" and the reviewed files run on the Playwright runner):**
 
 - `playwright-cli.md`
 
@@ -155,15 +109,15 @@ Without these, a flow is reviewed against browser predicates that cannot match i
 
 - (existing MCP-related fragments, if any are added in future)
 
-**Pact.js Utils (if enabled and contract tests in review scope):**
+**Pact.js Utils (if enabled, `@seontechnologies/pactjs-utils` is in `package.json`, and contract tests are in review scope):**
 
 - `pactjs-utils-overview.md`, `pactjs-utils-consumer-helpers.md`, `pactjs-utils-provider-verifier.md`, `pactjs-utils-request-filter.md`, `pact-consumer-di.md`, `pact-consumer-framework-setup.md`, `pact-broker-webhooks.md`
 
-**Contract Testing (if pactjs-utils disabled but contract tests in review scope):**
+**Contract Testing (if Pact.js Utils is disabled or not installed, and contract tests are in review scope):**
 
 - `contract-testing.md`
 
-**Pact MCP (if tea_pact_mcp is "mcp"):**
+**Pact MCP (if tea_pact_mcp is "mcp" and contract tests are in review scope):**
 
 - `pact-mcp.md`
 

package/src/workflows/testarch/bmad-testarch-trace/steps-c/step-01-load-context.md

@@ -97,6 +97,10 @@ If none of the four oracle types can be resolved, **HALT** and request the small
 
 From `{knowledgeIndex}` load:
 
+### Deterministic Knowledge Selection
+
+The fragment list for this step is a closed set. Start empty and add every fragment in the list below. Do not add fragments from tier labels, index descriptions, nearby mentions elsewhere in this step, general usefulness, or possible future need. Deduplicate while preserving the order below. Identical facts and config must produce an identical list.
+
 - `test-priorities-matrix.md`
 - `risk-governance.md`
 - `probability-impact.md`