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

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.4",
       "author": {
         "name": "Murat K Ozcan (TEA Creator) & Brian (BMad) Madison"
       },

package/README.md

@@ -392,7 +392,7 @@ A passing fragment-selection eval means the workflow loaded the right knowledge.
 
 ### Deterministic Checks
 
-`npm test` chains seventy-four checks. That count covers the whole chain: every entry in it is deterministic and credential-free, so the chain and its credential-free subset are the same list. `npm run test:ci-coverage` derives the count from `package.json` and prints it. Ten of the seventy-four keep the rules, guidance, hook, eval data, eval contracts, diagnostics, and documentation aligned:
+`npm test` chains seventy-five checks. That count covers the whole chain: every entry in it is deterministic and credential-free, so the chain and its credential-free subset are the same list. `npm run test:ci-coverage` derives the count from `package.json` and prints it. Eleven of the seventy-five keep the rules, guidance, hook, eval data, eval contracts, diagnostics, and documentation aligned:
 
 - `test:criteria-fragments` fails when a registry row is neither mapped to a knowledge fragment nor declared a known gap. A rule the reviewer scores but no fragment teaches is a rule TEA punishes without ever having explained it. All 36 rows are currently mapped across 50 anchors. Because the declared-gap list is empty, the validator feeds itself a synthetic unmapped row on every run to prove that path still works.
 - `test:doc-counts` runs `eval-quality-gates doc-counts`, which holds a hand-written count on a published page against the source that computes it: the roadmap's per-suite `eval:all` call counts, the knowledge-fragment tier breakdown, this section's own npm-test-chain length, and the fragment-selection case count. A pattern matching no sentence, or more than one, fails the same way a wrong number does, so the entry cannot go stale by drifting out from under its own pattern either.
@@ -403,6 +403,7 @@ A passing fragment-selection eval means the workflow loaded the right knowledge.
 - `test:eval-routing-boundaries` mutates the facts, candidate codes, and missing deciding information in each source-bound routing ambiguity rule. It also rejects duplicate and orphan boundaries, plus any boundary that would turn a clear intent into a clarification.
 - `test:eval-schemas` checks this repository's own eval suite manifest against its schema, confirms that every threshold it declares is the threshold the harness actually applies, that the runner capabilities it declares are the ones the harness grants its runner, and that the preflight argv it declares fails on a missing runner and passes on a present one, and fails when a TEA skill has neither a behavioral suite nor a deferred declaration. A suite list that omits a skill reads as coverage, so the omission has to be an error rather than a silence.
 - `test:eval-diagnostics` checks that current result writers emit bounded case and repetition diagnostics, that quality and environment outcomes stay separate, that unstable signatures remain visible, and that the protected 1.3.0 baseline remains readable and byte-for-byte unchanged.
+- `test:nfr-evidence-guidance` holds every NFR worker and the publication audit to the supplied-evidence ledger, exercises supported, missing, and mismatched evidence, rejects contaminating examples, and binds the protected baseline and focused remediation records by digest.
 - `test:contract-oracles` evaluates every oracle in every eval contract with `eval-quality`'s own evaluator, over the stored replay outputs and over constructed selections for all 24 fragment-selection cases, and fails when an oracle faults or disagrees with the harness scorer on the same evidence. The first run found that every regex oracle in the `test-review` contract was refused by the evaluator before it matched anything.
 
 These checks produce the same answer from the same repository state. They need no agent credential, network call, or model budget. `test:eval-data` runs through `npm test`, the local pre-commit hook, pull-request quality checks, and the publish workflow.

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.4",
   "description": "Master Test Architect for quality strategy, test automation, and release gates",
   "keywords": [
     "bmad",
@@ -83,7 +83,7 @@
     "release:minor": "gh workflow run publish.yaml -f channel=latest -f bump=minor",
     "release:next": "gh workflow run publish.yaml -f channel=next",
     "release:patch": "gh workflow run publish.yaml -f channel=latest -f bump=patch",
-    "test": "npm run test:conflict-markers && npm run test:schemas && npm run test:install && npm run test:knowledge && npm run test:criteria-fragments && npm run test:doc-count-sources && npm run test:doc-counts && npm run test:doc-claim-sources && npm run test:doc-claims && npm run test:doc-invocation-entry && npm run test:doc-invocations && npm run test:enforce-hook && npm run test:framework-scaffold && npm run test:atdd-isolation && npm run test:atdd-net-guard && npm run test:atdd-scoring && npm run test:atdd-workflow-guidance && npm run test:framework-scaffold-install-isolation && npm run test:transcript-harness && npm run test:suite-manifest && npm run test:teach-me-testing-scoring && npm run test:eval-data && npm run test:eval-atdd-data && npm run test:eval-ci-data && npm run test:eval-framework-scaffold-data && npm run test:eval-nfr-data && npm run test:nfr-validate-corpus && npm run test:eval-test-design-data && npm run test:eval-trace-data && npm run test:eval-routing-data && npm run test:eval-routing-boundaries && npm run test:eval-routing-evidence && npm run test:eval-transcript-data && npm run test:eval-teach-me-testing-data && npm run test:eval-schemas && npm run test:eval-diagnostics && npm run test:eval-replay && npm run test:eval-quality-corpus && npm run test:schema-versions && npm run test:contract-sources && npm run test:contracts && npm run test:contract-oracles && npm run test:probe-sources && npm run test:probe-corpus && npm run test:compare-dominance && npm run test:compare-eval-runs && npm run test:automate-eval-fixture && npm run test:eval-automate-data && npm run test:clock-port && npm run test:probe-conformance && npm run test:corpus-conformance && npm run test:file-system-conformance && npm run test:file-system-port && npm run test:probe-targets && npm run test:port-totality && npm run test:ci-coverage && npm run test:ci-coverage-filters && npm run test:bmad-output-gated && npm run test:release-metadata && npm run test:lockfile-age && npm run test:lockfile-age-cache && npm run test:licences && npm run test:supply-chain && npm run test:boundary && npm run test:direction && npm run test:lineage && npm run test:guard-publish && npm run test:layering-boundary-lineage && npm run test:changelog && npm run test:tea-workflow-descriptions && npm run validate:schemas && npm run lint && npm run lint:md && npm run format:check",
+    "test": "npm run test:conflict-markers && npm run test:schemas && npm run test:install && npm run test:knowledge && npm run test:criteria-fragments && npm run test:doc-count-sources && npm run test:doc-counts && npm run test:doc-claim-sources && npm run test:doc-claims && npm run test:doc-invocation-entry && npm run test:doc-invocations && npm run test:enforce-hook && npm run test:framework-scaffold && npm run test:atdd-isolation && npm run test:atdd-net-guard && npm run test:atdd-scoring && npm run test:atdd-workflow-guidance && npm run test:framework-scaffold-install-isolation && npm run test:transcript-harness && npm run test:suite-manifest && npm run test:teach-me-testing-scoring && npm run test:eval-data && npm run test:eval-atdd-data && npm run test:eval-ci-data && npm run test:eval-framework-scaffold-data && npm run test:eval-nfr-data && npm run test:nfr-validate-corpus && npm run test:nfr-evidence-guidance && npm run test:eval-test-design-data && npm run test:eval-trace-data && npm run test:eval-routing-data && npm run test:eval-routing-boundaries && npm run test:eval-routing-evidence && npm run test:eval-transcript-data && npm run test:eval-teach-me-testing-data && npm run test:eval-schemas && npm run test:eval-diagnostics && npm run test:eval-replay && npm run test:eval-quality-corpus && npm run test:schema-versions && npm run test:contract-sources && npm run test:contracts && npm run test:contract-oracles && npm run test:probe-sources && npm run test:probe-corpus && npm run test:compare-dominance && npm run test:compare-eval-runs && npm run test:automate-eval-fixture && npm run test:eval-automate-data && npm run test:clock-port && npm run test:probe-conformance && npm run test:corpus-conformance && npm run test:file-system-conformance && npm run test:file-system-port && npm run test:probe-targets && npm run test:port-totality && npm run test:ci-coverage && npm run test:ci-coverage-filters && npm run test:bmad-output-gated && npm run test:release-metadata && npm run test:lockfile-age && npm run test:lockfile-age-cache && npm run test:licences && npm run test:supply-chain && npm run test:boundary && npm run test:direction && npm run test:lineage && npm run test:guard-publish && npm run test:layering-boundary-lineage && npm run test:changelog && npm run test:tea-workflow-descriptions && npm run validate:schemas && npm run lint && npm run lint:md && npm run format:check",
     "test:atdd-isolation": "node test/test-atdd-isolation.js",
     "test:atdd-net-guard": "node test/test-atdd-net-guard.js",
     "test:atdd-scoring": "node test/test-atdd-scoring.js",
@@ -142,6 +142,7 @@
     "test:lineage": "eval-quality-gates field-ownership",
     "test:lockfile-age": "eval-quality-gates lockfile-age",
     "test:lockfile-age-cache": "node test/test-generate-lockfile-age-cache.js",
+    "test:nfr-evidence-guidance": "node test/test-nfr-evidence-guidance.js",
     "test:nfr-validate-corpus": "node test/test-nfr-validate-corpus.js",
     "test:port-totality": "node test/test-port-totality.js",
     "test:probe-conformance": "node test/test-probe-conformance.js",

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/nfr-report-template.md

@@ -35,7 +35,8 @@ Note: This audit summarizes existing implementation evidence; it does not run te
 - **Status:** {STATUS} {STATUS_ICON}
 - **Threshold:** {THRESHOLD_VALUE}
 - **Actual:** {ACTUAL_VALUE}
-- **Evidence:** {EVIDENCE_SOURCE}
+- **Evidence:** {PROJECT_RELATIVE_PATH}
+- **Supports:** {SUPPORTED_OBSERVATION}
 - **Findings:** {FINDINGS_DESCRIPTION}
 
 ### Throughput
@@ -43,7 +44,8 @@ Note: This audit summarizes existing implementation evidence; it does not run te
 - **Status:** {STATUS} {STATUS_ICON}
 - **Threshold:** {THRESHOLD_VALUE}
 - **Actual:** {ACTUAL_VALUE}
-- **Evidence:** {EVIDENCE_SOURCE}
+- **Evidence:** {PROJECT_RELATIVE_PATH}
+- **Supports:** {SUPPORTED_OBSERVATION}
 - **Findings:** {FINDINGS_DESCRIPTION}
 
 ### Resource Usage
@@ -52,13 +54,15 @@ Note: This audit summarizes existing implementation evidence; it does not run te
   - **Status:** {STATUS} {STATUS_ICON}
   - **Threshold:** {THRESHOLD_VALUE}
   - **Actual:** {ACTUAL_VALUE}
-  - **Evidence:** {EVIDENCE_SOURCE}
+  - **Evidence:** {PROJECT_RELATIVE_PATH}
+  - **Supports:** {SUPPORTED_OBSERVATION}
 
 - **Memory Usage**
   - **Status:** {STATUS} {STATUS_ICON}
   - **Threshold:** {THRESHOLD_VALUE}
   - **Actual:** {ACTUAL_VALUE}
-  - **Evidence:** {EVIDENCE_SOURCE}
+  - **Evidence:** {PROJECT_RELATIVE_PATH}
+  - **Supports:** {SUPPORTED_OBSERVATION}
 
 ---
 
@@ -69,7 +73,8 @@ Note: This audit summarizes existing implementation evidence; it does not run te
 - **Status:** {STATUS} {STATUS_ICON}
 - **Threshold:** {THRESHOLD_DESCRIPTION}
 - **Actual:** {ACTUAL_DESCRIPTION}
-- **Evidence:** {EVIDENCE_SOURCE}
+- **Evidence:** {PROJECT_RELATIVE_PATH}
+- **Supports:** {SUPPORTED_OBSERVATION}
 - **Findings:** {FINDINGS_DESCRIPTION}
 - **Recommendation:** {RECOMMENDATION} (if CONCERNS or FAIL)
 
@@ -78,7 +83,8 @@ Note: This audit summarizes existing implementation evidence; it does not run te
 - **Status:** {STATUS} {STATUS_ICON}
 - **Threshold:** {THRESHOLD_DESCRIPTION}
 - **Actual:** {ACTUAL_DESCRIPTION}
-- **Evidence:** {EVIDENCE_SOURCE}
+- **Evidence:** {PROJECT_RELATIVE_PATH}
+- **Supports:** {SUPPORTED_OBSERVATION}
 - **Findings:** {FINDINGS_DESCRIPTION}
 
 ### Data Protection
@@ -86,23 +92,26 @@ Note: This audit summarizes existing implementation evidence; it does not run te
 - **Status:** {STATUS} {STATUS_ICON}
 - **Threshold:** {THRESHOLD_DESCRIPTION}
 - **Actual:** {ACTUAL_DESCRIPTION}
-- **Evidence:** {EVIDENCE_SOURCE}
+- **Evidence:** {PROJECT_RELATIVE_PATH}
+- **Supports:** {SUPPORTED_OBSERVATION}
 - **Findings:** {FINDINGS_DESCRIPTION}
 
 ### Vulnerability Management
 
 - **Status:** {STATUS} {STATUS_ICON}
-- **Threshold:** {THRESHOLD_DESCRIPTION} (e.g., "0 critical, <3 high vulnerabilities")
-- **Actual:** {ACTUAL_DESCRIPTION} (e.g., "0 critical, 1 high, 5 medium vulnerabilities")
-- **Evidence:** {EVIDENCE_SOURCE} (e.g., "Snyk scan results - scan-2025-10-14.json")
+- **Threshold:** {THRESHOLD_DESCRIPTION}
+- **Actual:** {ACTUAL_DESCRIPTION}
+- **Evidence:** {PROJECT_RELATIVE_PATH}
+- **Supports:** {SUPPORTED_OBSERVATION}
 - **Findings:** {FINDINGS_DESCRIPTION}
 
 ### Compliance (if applicable)
 
 - **Status:** {STATUS} {STATUS_ICON}
-- **Standards:** {COMPLIANCE_STANDARDS} (e.g., "GDPR, HIPAA, PCI-DSS")
+- **Standards:** {COMPLIANCE_STANDARDS}
 - **Actual:** {ACTUAL_COMPLIANCE_STATUS}
-- **Evidence:** {EVIDENCE_SOURCE}
+- **Evidence:** {PROJECT_RELATIVE_PATH}
+- **Supports:** {SUPPORTED_OBSERVATION}
 - **Findings:** {FINDINGS_DESCRIPTION}
 
 ---
@@ -112,25 +121,28 @@ Note: This audit summarizes existing implementation evidence; it does not run te
 ### Availability (Uptime)
 
 - **Status:** {STATUS} {STATUS_ICON}
-- **Threshold:** {THRESHOLD_VALUE} (e.g., "99.9%")
-- **Actual:** {ACTUAL_VALUE} (e.g., "99.95%")
-- **Evidence:** {EVIDENCE_SOURCE} (e.g., "Uptime monitoring - uptime-report-2025-10-14.csv")
+- **Threshold:** {THRESHOLD_VALUE}
+- **Actual:** {ACTUAL_VALUE}
+- **Evidence:** {PROJECT_RELATIVE_PATH}
+- **Supports:** {SUPPORTED_OBSERVATION}
 - **Findings:** {FINDINGS_DESCRIPTION}
 
 ### Error Rate
 
 - **Status:** {STATUS} {STATUS_ICON}
-- **Threshold:** {THRESHOLD_VALUE} (e.g., "<0.1%")
-- **Actual:** {ACTUAL_VALUE} (e.g., "0.05%")
-- **Evidence:** {EVIDENCE_SOURCE} (e.g., "Error logs - logs/errors-2025-10.log")
+- **Threshold:** {THRESHOLD_VALUE}
+- **Actual:** {ACTUAL_VALUE}
+- **Evidence:** {PROJECT_RELATIVE_PATH}
+- **Supports:** {SUPPORTED_OBSERVATION}
 - **Findings:** {FINDINGS_DESCRIPTION}
 
 ### MTTR (Mean Time To Recovery)
 
 - **Status:** {STATUS} {STATUS_ICON}
-- **Threshold:** {THRESHOLD_VALUE} (e.g., "<15 minutes")
-- **Actual:** {ACTUAL_VALUE} (e.g., "12 minutes")
-- **Evidence:** {EVIDENCE_SOURCE} (e.g., "Incident reports - incidents/")
+- **Threshold:** {THRESHOLD_VALUE}
+- **Actual:** {ACTUAL_VALUE}
+- **Evidence:** {PROJECT_RELATIVE_PATH}
+- **Supports:** {SUPPORTED_OBSERVATION}
 - **Findings:** {FINDINGS_DESCRIPTION}
 
 ### Fault Tolerance
@@ -138,15 +150,17 @@ Note: This audit summarizes existing implementation evidence; it does not run te
 - **Status:** {STATUS} {STATUS_ICON}
 - **Threshold:** {THRESHOLD_DESCRIPTION}
 - **Actual:** {ACTUAL_DESCRIPTION}
-- **Evidence:** {EVIDENCE_SOURCE}
+- **Evidence:** {PROJECT_RELATIVE_PATH}
+- **Supports:** {SUPPORTED_OBSERVATION}
 - **Findings:** {FINDINGS_DESCRIPTION}
 
 ### CI Burn-In (Stability)
 
 - **Status:** {STATUS} {STATUS_ICON}
-- **Threshold:** {THRESHOLD_VALUE} (e.g., "100 consecutive successful runs")
-- **Actual:** {ACTUAL_VALUE} (e.g., "150 consecutive successful runs")
-- **Evidence:** {EVIDENCE_SOURCE} (e.g., "CI burn-in results - ci-burn-in-2025-10-14.log")
+- **Threshold:** {THRESHOLD_VALUE}
+- **Actual:** {ACTUAL_VALUE}
+- **Evidence:** {PROJECT_RELATIVE_PATH}
+- **Supports:** {SUPPORTED_OBSERVATION}
 - **Findings:** {FINDINGS_DESCRIPTION}
 
 ### Disaster Recovery (if applicable)
@@ -155,13 +169,15 @@ Note: This audit summarizes existing implementation evidence; it does not run te
   - **Status:** {STATUS} {STATUS_ICON}
   - **Threshold:** {THRESHOLD_VALUE}
   - **Actual:** {ACTUAL_VALUE}
-  - **Evidence:** {EVIDENCE_SOURCE}
+  - **Evidence:** {PROJECT_RELATIVE_PATH}
+  - **Supports:** {SUPPORTED_OBSERVATION}
 
 - **RPO (Recovery Point Objective)**
   - **Status:** {STATUS} {STATUS_ICON}
   - **Threshold:** {THRESHOLD_VALUE}
   - **Actual:** {ACTUAL_VALUE}
-  - **Evidence:** {EVIDENCE_SOURCE}
+  - **Evidence:** {PROJECT_RELATIVE_PATH}
+  - **Supports:** {SUPPORTED_OBSERVATION}
 
 ---
 
@@ -170,33 +186,37 @@ Note: This audit summarizes existing implementation evidence; it does not run te
 ### Test Coverage
 
 - **Status:** {STATUS} {STATUS_ICON}
-- **Threshold:** {THRESHOLD_DESCRIPTION} (e.g., "≥80% coverage")
+- **Threshold:** {THRESHOLD_DESCRIPTION}
 - **Actual:** {ACTUAL_DESCRIPTION}
-- **Evidence:** {EVIDENCE_SOURCE} (e.g., "CI coverage report - coverage/lcov-report/index.html")
+- **Evidence:** {PROJECT_RELATIVE_PATH}
+- **Supports:** {SUPPORTED_OBSERVATION}
 - **Findings:** {FINDINGS_DESCRIPTION}
 
 ### Code Duplication
 
 - **Status:** {STATUS} {STATUS_ICON}
-- **Threshold:** {THRESHOLD_DESCRIPTION} (e.g., "<5% duplication")
+- **Threshold:** {THRESHOLD_DESCRIPTION}
 - **Actual:** {ACTUAL_DESCRIPTION}
-- **Evidence:** {EVIDENCE_SOURCE} (e.g., "jscpd report - reports/jscpd/jscpd-report.json")
+- **Evidence:** {PROJECT_RELATIVE_PATH}
+- **Supports:** {SUPPORTED_OBSERVATION}
 - **Findings:** {FINDINGS_DESCRIPTION}
 
 ### Vulnerability Scan
 
 - **Status:** {STATUS} {STATUS_ICON}
-- **Threshold:** {THRESHOLD_DESCRIPTION} (e.g., "0 critical, 0 high vulnerabilities")
+- **Threshold:** {THRESHOLD_DESCRIPTION}
 - **Actual:** {ACTUAL_DESCRIPTION}
-- **Evidence:** {EVIDENCE_SOURCE} (e.g., "npm audit CI job output")
+- **Evidence:** {PROJECT_RELATIVE_PATH}
+- **Supports:** {SUPPORTED_OBSERVATION}
 - **Findings:** {FINDINGS_DESCRIPTION}
 
 ### Observability
 
 - **Status:** {STATUS} {STATUS_ICON}
-- **Threshold:** {THRESHOLD_DESCRIPTION} (e.g., "structured logging + error tracking configured")
+- **Threshold:** {THRESHOLD_DESCRIPTION}
 - **Actual:** {ACTUAL_DESCRIPTION}
-- **Evidence:** {EVIDENCE_SOURCE}
+- **Evidence:** {PROJECT_RELATIVE_PATH}
+- **Supports:** {SUPPORTED_OBSERVATION}
 - **Findings:** {FINDINGS_DESCRIPTION}
 
 ---
@@ -208,7 +228,8 @@ Note: This audit summarizes existing implementation evidence; it does not run te
 - **Status:** {STATUS} {STATUS_ICON}
 - **Threshold:** {THRESHOLD_DESCRIPTION}
 - **Actual:** {ACTUAL_DESCRIPTION}
-- **Evidence:** {EVIDENCE_SOURCE}
+- **Evidence:** {PROJECT_RELATIVE_PATH}
+- **Supports:** {SUPPORTED_OBSERVATION}
 - **Findings:** {FINDINGS_DESCRIPTION}
 
 ### {CUSTOM_NFR_NAME_2}
@@ -216,7 +237,8 @@ Note: This audit summarizes existing implementation evidence; it does not run te
 - **Status:** {STATUS} {STATUS_ICON}
 - **Threshold:** {THRESHOLD_DESCRIPTION}
 - **Actual:** {ACTUAL_DESCRIPTION}
-- **Evidence:** {EVIDENCE_SOURCE}
+- **Evidence:** {PROJECT_RELATIVE_PATH}
+- **Supports:** {SUPPORTED_OBSERVATION}
 - **Findings:** {FINDINGS_DESCRIPTION}
 
 ---

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