bmad-method-test-architecture-enterprise 1.5.3 → 1.7.0

package/README.md

@@ -173,15 +173,15 @@ src/
 │   └── tea.agent.yaml
 ├── workflows/
 │   └── testarch/
-│       ├── atdd/
-│       ├── automate/
-│       ├── ci/
-│       ├── framework/
-│       ├── nfr-assess/
-│       ├── teach-me-testing/
-│       ├── test-design/
-│       ├── test-review/
-│       └── trace/
+│       ├── bmad-teach-me-testing/
+│       ├── bmad-testarch-atdd/
+│       ├── bmad-testarch-automate/
+│       ├── bmad-testarch-ci/
+│       ├── bmad-testarch-framework/
+│       ├── bmad-testarch-nfr/
+│       ├── bmad-testarch-test-design/
+│       ├── bmad-testarch-test-review/
+│       └── bmad-testarch-trace/
 └── testarch/
     ├── tea-index.csv
     └── knowledge/

package/docs/reference/troubleshooting.md

@@ -191,7 +191,7 @@ If the BMAD installer can run but cannot fetch the Test Architect module from Gi
 
    ```bash
    # Check each workflow
-   cat _bmad/tea/workflows/testarch/test-design/workflow.yaml
+   cat _bmad/tea/workflows/testarch/bmad-testarch-test-design/workflow.yaml
    ```
 
 3. Test workflow trigger directly:
@@ -262,7 +262,7 @@ If the BMAD installer can run but cannot fetch the Test Architect module from Gi
 
    ```bash
    # For automate workflow
-   ls -la _bmad/tea/workflows/testarch/automate/steps-c/step-03*.md
+   ls -la _bmad/tea/workflows/testarch/bmad-testarch-automate/steps-c/step-03*.md
    # Should show: step-03a-*.md, step-03b-*.md, step-03c-aggregate.md
    ```
 
@@ -328,7 +328,7 @@ If the BMAD installer can run but cannot fetch the Test Architect module from Gi
 4. Check workflow manifest:
    ```bash
    # Each workflow.yaml should specify knowledge_fragments
-   grep -A 5 "knowledge_fragments" _bmad/tea/workflows/testarch/test-design/workflow.yaml
+   grep -A 5 "knowledge_fragments" _bmad/tea/workflows/testarch/bmad-testarch-test-design/workflow.yaml
    ```
 
 ---
@@ -715,7 +715,7 @@ Check these first:
 
 ### "Workflow 'test-design' failed at step 3"
 
-**Fix**: Check step file exists: `_bmad/tea/workflows/testarch/test-design/steps-c/step-03-*`
+**Fix**: Check step file exists: `_bmad/tea/workflows/testarch/bmad-testarch-test-design/steps-c/step-03-*`
 
 ### "Agent YAML validation failed"
 

package/package.json

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

package/release_notes.md

@@ -1,10 +1,11 @@
-## 🚀 What's New in v1.5.3
+## 🚀 What's New in v1.7.0
 
-### 🐛 Bug Fixes
-- fix: tweak pactjs instructions
+### ✨ New Features
+- feat: skills migration part1
 
 ### 📦 Other Changes
-- Merge pull request #52 from bmad-code-org/fix/tweak-pactjs-instructions
+- addressed review comments
+- Merge pull request #54 from bmad-code-org/feat/skill-migration-part1
 
 
 ## 📦 Installation
@@ -14,4 +15,4 @@ npx bmad-method install
 # Select "Test Architect" from module menu
 ```
 
-**Full Changelog**: https://github.com/bmad-code-org/bmad-method-test-architecture-enterprise/compare/v1.5.2...v1.5.3
+**Full Changelog**: https://github.com/bmad-code-org/bmad-method-test-architecture-enterprise/compare/v1.6.0...v1.7.0

package/src/module-help.csv

@@ -1,10 +1,10 @@
 module,phase,name,code,sequence,workflow-file,command,required,agent,options,description,output-location,outputs,
-tea,0-learning,Teach Me Testing,TMT,10,_bmad/tea/workflows/testarch/teach-me-testing/workflow.md,bmad-tea-teach-me-testing,false,tea,Create Mode,"Teach testing fundamentals through 7 sessions (TEA Academy)",test_artifacts,"progress file|session notes|certificate",
-tea,3-solutioning,Test Design,TD,10,_bmad/tea/workflows/testarch/test-design/workflow.yaml,bmad-tea-testarch-test-design,false,tea,Create Mode,"Risk-based test planning",test_artifacts,"test design document",
-tea,3-solutioning,Test Framework,TF,20,_bmad/tea/workflows/testarch/framework/workflow.yaml,bmad-tea-testarch-framework,false,tea,Create Mode,"Initialize production-ready test framework",test_artifacts,"framework scaffold",
-tea,3-solutioning,CI Setup,CI,30,_bmad/tea/workflows/testarch/ci/workflow.yaml,bmad-tea-testarch-ci,false,tea,Create Mode,"Configure CI/CD quality pipeline",test_artifacts,"ci config",
-tea,4-implementation,ATDD,AT,10,_bmad/tea/workflows/testarch/atdd/workflow.yaml,bmad-tea-testarch-atdd,false,tea,Create Mode,"Generate failing tests (TDD red phase)",test_artifacts,"atdd tests",
-tea,4-implementation,Test Automation,TA,20,_bmad/tea/workflows/testarch/automate/workflow.yaml,bmad-tea-testarch-automate,false,tea,Create Mode,"Expand test coverage",test_artifacts,"test suite",
-tea,4-implementation,Test Review,RV,30,_bmad/tea/workflows/testarch/test-review/workflow.yaml,bmad-tea-testarch-test-review,false,tea,Validate Mode,"Quality audit (0-100 scoring)",test_artifacts,"review report",
-tea,4-implementation,NFR Assessment,NR,40,_bmad/tea/workflows/testarch/nfr-assess/workflow.yaml,bmad-tea-testarch-nfr,false,tea,Create Mode,"Non-functional requirements",test_artifacts,"nfr report",
-tea,4-implementation,Traceability,TR,50,_bmad/tea/workflows/testarch/trace/workflow.yaml,bmad-tea-testarch-trace,false,tea,Create Mode,"Coverage traceability and gate",test_artifacts,"traceability matrix|gate decision",
+tea,0-learning,Teach Me Testing,TMT,10,skill:bmad-teach-me-testing,bmad-tea-teach-me-testing,false,tea,Create Mode,"Teach testing fundamentals through 7 sessions (TEA Academy)",test_artifacts,"progress file|session notes|certificate",
+tea,3-solutioning,Test Design,TD,10,skill:bmad-testarch-test-design,bmad-tea-testarch-test-design,false,tea,Create Mode,"Risk-based test planning",test_artifacts,"test design document",
+tea,3-solutioning,Test Framework,TF,20,skill:bmad-testarch-framework,bmad-tea-testarch-framework,false,tea,Create Mode,"Initialize production-ready test framework",test_artifacts,"framework scaffold",
+tea,3-solutioning,CI Setup,CI,30,skill:bmad-testarch-ci,bmad-tea-testarch-ci,false,tea,Create Mode,"Configure CI/CD quality pipeline",test_artifacts,"ci config",
+tea,4-implementation,ATDD,AT,10,skill:bmad-testarch-atdd,bmad-tea-testarch-atdd,false,tea,Create Mode,"Generate failing tests (TDD red phase)",test_artifacts,"atdd tests",
+tea,4-implementation,Test Automation,TA,20,skill:bmad-testarch-automate,bmad-tea-testarch-automate,false,tea,Create Mode,"Expand test coverage",test_artifacts,"test suite",
+tea,4-implementation,Test Review,RV,30,skill:bmad-testarch-test-review,bmad-tea-testarch-test-review,false,tea,Validate Mode,"Quality audit (0-100 scoring)",test_artifacts,"review report",
+tea,4-implementation,NFR Assessment,NR,40,skill:bmad-testarch-nfr,bmad-tea-testarch-nfr,false,tea,Create Mode,"Non-functional requirements",test_artifacts,"nfr report",
+tea,4-implementation,Traceability,TR,50,skill:bmad-testarch-trace,bmad-tea-testarch-trace,false,tea,Create Mode,"Coverage traceability and gate",test_artifacts,"traceability matrix|gate decision",

package/src/testarch/knowledge/ci-burn-in.md

@@ -714,4 +714,4 @@ Before deploying your CI pipeline, verify:
 - Related fragments: `selective-testing.md`, `playwright-config.md`, `test-quality.md`
 - CI tools: GitHub Actions, GitLab CI, CircleCI, Jenkins
 
-_Source: Murat CI/CD strategy blog, Playwright/Cypress workflow examples, SEON production pipelines_
+_Source: Murat CI/CD strategy blog, Playwright/Cypress workflow examples, enterprise production pipelines_

package/src/testarch/knowledge/contract-testing.md

@@ -944,6 +944,67 @@ jobs:
 
 ---
 
+## Provider Scrutiny Protocol
+
+When generating consumer contract tests, the agent **MUST** analyze provider source code — or the provider's OpenAPI/Swagger spec — before writing any Pact interaction. Generating contracts from consumer-side assumptions alone leads to mismatches that only surface during provider verification — wrong response shapes, wrong status codes, wrong field names, wrong types, missing required fields, and wrong enum values.
+
+**Source priority**: Provider source code is the most authoritative reference. When an OpenAPI/Swagger spec exists (`openapi.yaml`, `openapi.json`, `swagger.json`), use it as a complementary or alternative source — it documents the provider's contract explicitly and can be faster to parse than tracing through handler code. When both exist, cross-reference them; if they disagree, the source code wins.
+
+### Provider Endpoint Comment
+
+Every Pact interaction MUST include a provider endpoint comment immediately above the `.given()` call:
+
+```typescript
+// Provider endpoint: server/src/routes/userRouteHandlers.ts -> GET /api/v2/users/:userId
+await provider.given('user with id 1 exists').uponReceiving('a request for user 1');
+```
+
+**Format**: `// Provider endpoint: <relative-path-to-handler> -> <METHOD> <route-pattern>`
+
+If the provider source is not accessible, use: `// Provider endpoint: TODO — provider source not accessible, verify manually`
+
+### Seven-Point Scrutiny Checklist
+
+Before generating each Pact interaction, read the provider route handler and/or OpenAPI spec and verify:
+
+| #   | Check                 | What to Read (source code / OpenAPI spec)                         | Common Mismatch                                               |
+| --- | --------------------- | ----------------------------------------------------------------- | ------------------------------------------------------------- |
+| 1   | **Response shape**    | Handler's `res.json()` calls / OpenAPI `responses.content.schema` | Nested object vs flat; array wrapper vs direct                |
+| 2   | **Status codes**      | Handler's `res.status()` calls / OpenAPI `responses` keys         | 200 vs 201 for creation; 204 vs 200 for delete                |
+| 3   | **Field names**       | Response type/DTO definitions / OpenAPI `schema.properties`       | `transaction_id` vs `transactionId`; `fraud_score` vs `score` |
+| 4   | **Enum values**       | Validation schemas, constants / OpenAPI `schema.enum`             | `"active"` vs `"ACTIVE"`; `"pending"` vs `"in_progress"`      |
+| 5   | **Required fields**   | Request validation (Joi, Zod) / OpenAPI `schema.required`         | Missing required header; optional field assumed required      |
+| 6   | **Data types**        | TypeScript types, DB models / OpenAPI `schema.type` + `format`    | `string` ID vs `number` ID; ISO date vs Unix timestamp        |
+| 7   | **Nested structures** | Response builder, serializer / OpenAPI `$ref` + `allOf`/`oneOf`   | `{ data: { items: [] } }` vs `{ items: [] }`                  |
+
+### Scrutiny Evidence Block
+
+Document what was found from provider source and/or OpenAPI spec as a block comment in the test file:
+
+```typescript
+/*
+ * Provider Scrutiny Evidence:
+ * - Handler: server/src/routes/userRouteHandlers.ts:45
+ * - OpenAPI: server/openapi.yaml paths./api/v2/users/{userId}.get (if available)
+ * - Response type: UserResponseDto (server/src/types/user.ts:12)
+ * - Status: 200 (line 52), 404 (line 48)
+ * - Fields: { id: number, name: string, email: string, role: "user" | "admin", createdAt: string }
+ * - Required request headers: Authorization (Bearer token)
+ * - Validation: Zod schema at server/src/validation/user.ts:8
+ */
+```
+
+### Graceful Degradation
+
+When provider source code is not accessible (different repo, no access, closed source):
+
+1. **OpenAPI/Swagger spec available**: Use the spec as the source of truth for response shapes, status codes, and field names
+2. **Pact Broker has existing contracts**: Use `pact_mcp` tools to fetch existing provider states and verified interactions as reference
+3. **Neither available**: Generate contracts from consumer-side types but use the TODO form of the mandatory comment: `// Provider endpoint: TODO — provider source not accessible, verify manually` and add a `provider_scrutiny: "pending"` field to the output JSON
+4. **Never silently guess**: If you cannot verify, document what you assumed and why
+
+---
+
 ## Contract Testing Checklist
 
 Before implementing contract testing, verify:
@@ -956,6 +1017,9 @@ Before implementing contract testing, verify:
 - [ ] **Webhooks configured**: Consumer changes trigger provider verification
 - [ ] **Retention policy**: Old pacts archived (keep 30 days, all production tags)
 - [ ] **Resilience tested**: Timeouts, retries, error codes in contracts
+- [ ] **Provider endpoint comments**: Every Pact interaction has `// Provider endpoint:` comment
+- [ ] **Provider scrutiny completed**: Seven-point checklist verified for each interaction
+- [ ] **Scrutiny evidence documented**: Block comment with handler, types, status codes, and fields
 
 ## Integration Points
 

package/src/testarch/knowledge/error-handling.md

@@ -722,4 +722,4 @@ Before shipping error handling code, verify:
 - Related fragments: `network-first.md`, `test-quality.md`, `contract-testing.md`
 - Monitoring tools: Sentry, Datadog, LogRocket
 
-_Source: Murat error-handling patterns, Pact resilience guidance, SEON production error handling_
+_Source: Murat error-handling patterns, Pact resilience guidance, enterprise production error handling_

package/src/testarch/knowledge/feature-flags.md

@@ -747,4 +747,4 @@ Before merging flag-related code, verify:
 - Related fragments: `test-quality.md`, `selective-testing.md`
 - Flag services: LaunchDarkly, Split.io, Unleash, custom implementations
 
-_Source: LaunchDarkly strategy blog, Murat test architecture notes, SEON feature flag governance_
+_Source: LaunchDarkly strategy blog, Murat test architecture notes, enterprise feature flag governance_

package/src/testarch/knowledge/fixture-architecture.md

@@ -398,4 +398,4 @@ When deciding whether to create a fixture, follow these rules:
 - **1 use** → Keep inline (avoid premature abstraction)
 - **Complex logic** → Factory function pattern (dynamic data generation)
 
-_Source: Murat Testing Philosophy (lines 74-122), SEON production patterns, Playwright fixture docs._
+_Source: Murat Testing Philosophy (lines 74-122), enterprise production patterns, Playwright fixture docs._

package/src/testarch/knowledge/network-recorder.md

@@ -304,13 +304,13 @@ await networkRecorder.setup(context, {
   playback: {
     urlMapping: {
       hostMapping: {
-        'localhost:3000': 'admin.seondev.space',
-        'admin-staging.seon.io': 'admin.seondev.space',
-        'admin.seon.io': 'admin.seondev.space',
+        'localhost:3000': 'admin.example.com',
+        'admin-staging.example.com': 'admin.example.com',
+        'admin.example.com': 'admin.example.com',
       },
       patterns: [
-        { match: /admin-\d+\.seondev\.space/, replace: 'admin.seondev.space' },
-        { match: /admin-staging-pr-\w+-\d\.seon\.io/, replace: 'admin.seondev.space' },
+        { match: /admin-\d+\.example\.com/, replace: 'admin.example.com' },
+        { match: /admin-staging-pr-\w+-\d\.example\.com/, replace: 'admin.example.com' },
       ],
     },
   },

package/src/testarch/knowledge/overview.md

@@ -15,7 +15,7 @@ Writing Playwright utilities from scratch for every project leads to:
 
 `@seontechnologies/playwright-utils` provides:
 
-- **Production-tested utilities**: Used at SEON Technologies in production
+- **Production-tested**: Used in enterprise production environments
 - **Functional-first design**: Core logic as pure functions, fixtures for convenience
 - **Composable fixtures**: Use `mergeTests` to combine utilities
 - **TypeScript support**: Full type safety with generic types

package/src/testarch/knowledge/pact-consumer-di.md

@@ -4,7 +4,7 @@
 
 Inject the Pact mock server URL into consumer code via an optional `baseUrl` field on the API context type instead of using raw `fetch()` inside `executeTest()`. This ensures contract tests exercise the real consumer HTTP client — including retry logic, header assembly, timeout configuration, error handling, and metrics — rather than testing Pact itself.
 
-The base URL is typically a module-level constant evaluated at import time (`export const API_BASE_URL = env.SEON_API_URL`), but `mockServer.url` is only available at runtime inside `executeTest()`. Dependency injection solves this timing mismatch cleanly: add one optional field to the context type, use nullish coalescing in the HTTP client factory, and inject the mock server URL in tests.
+The base URL is typically a module-level constant evaluated at import time (`export const API_BASE_URL = env.API_BASE_URL`), but `mockServer.url` is only available at runtime inside `executeTest()`. Dependency injection solves this timing mismatch cleanly: add one optional field to the context type, use nullish coalescing in the HTTP client factory, and inject the mock server URL in tests.
 
 ## Rationale
 
@@ -124,7 +124,7 @@ export function createTestContext(mockServerUrl: string): ApiContext {
 
 ```typescript
 .executeTest(async (mockServer: V3MockServer) => {
-  const api = createSeonApi(createTestContext(mockServer.url));
+  const api = createApiClient(createTestContext(mockServer.url));
   const result = await api.getFilterFields();
   expect(result).toEqual(
     expect.arrayContaining([
@@ -277,7 +277,7 @@ expect(response.status).toBe(200);
 
 ```typescript
 // GOOD: Exercises real client, validates parsed return value
-const api = createSeonApi(createTestContext(mockServer.url));
+const api = createApiClient(createTestContext(mockServer.url));
 const result = await api.searchTransactions(request);
 expect(result.transactions).toBeDefined();
 ```
@@ -307,4 +307,4 @@ Used in workflows:
 
 ## Source
 
-Pattern derived from seon-mcp-server Pact consumer test refactor (March 2026). Implements dependency injection for testability as described in Pact.js best practices.
+Pattern derived from my-consumer-app Pact consumer test refactor (March 2026). Implements dependency injection for testability as described in Pact.js best practices.

package/src/testarch/knowledge/pact-consumer-framework-setup.md

@@ -463,6 +463,7 @@ describe('Movies API Consumer Contract', () => {
 - Consumer code MUST expose a URL injection mechanism: `setApiUrl()`, env var override, or constructor parameter
 - If the consumer code doesn't support URL injection, add it — this is a design prerequisite for CDC testing
 - Use PactV4 `addInteraction()` builder (not PactV3 fluent API with `withRequest({...})` object)
+- **Interaction naming convention**: Use the pattern `"a request to <action> <resource> [<condition>]"` for `uponReceiving()`. Examples: `"a request to get a movie by ID"`, `"a request to delete a non-existing movie"`, `"a request to create a movie that already exists"`. These names appear in Pact Broker UI and verification logs — keep them descriptive and unique within the consumer-provider pair.
 - Use `setJsonContent` for request/response builder callbacks with query/header/body concerns; use `setJsonBody` for body-only response callbacks
 - Provider state factory functions (`movieExists`) return `ProviderStateInput` objects
 - `createProviderState` converts to `[stateName, stateParams]` tuple for `.given()`
@@ -616,9 +617,10 @@ Before presenting the consumer CDC framework to the user, verify:
 - [ ] `.github/actions/detect-breaking-change/action.yml` exists
 - [ ] Consumer tests use `.pacttest.ts` extension
 - [ ] Consumer tests use PactV4 `addInteraction()` builder
+- [ ] `uponReceiving()` names follow `"a request to <action> <resource> [<condition>]"` pattern and are unique within the consumer-provider pair
 - [ ] Interaction callbacks use `setJsonContent` for query/header/body and `setJsonBody` for body-only responses
 - [ ] Request bodies use exact values (no `like()` wrapper) — Postel's Law: be strict in what you send
-- [ ] `like()`, `eachLike()`, `string()`, `integer()` matchers are only used in `willRespondWith` (responses), not in `withRequest` (requests)
+- [ ] `like()`, `eachLike()`, `string()`, `integer()` matchers are only used in `willRespondWith` (responses), not in `withRequest` (requests) — matchers check type/shape, not exact values
 - [ ] Consumer tests call REAL consumer code (actual API client functions), NOT raw `fetch()`
 - [ ] Consumer code exposes URL injection mechanism (`setApiUrl()`, env var, or constructor param)
 - [ ] Local consumer-helpers shim present if pactjs-utils not installed

package/src/testarch/knowledge/pactjs-utils-consumer-helpers.md

@@ -196,6 +196,8 @@ await pact
 - **Message pacts**: Works identically with `MessageConsumerPact` — same `.given()` API
 - **Builder reuse**: `setJsonContent` works for both `.withRequest(...)` and `.willRespondWith(...)` callbacks (query is ignored on response builders)
 - **Body shorthand**: `setJsonBody` keeps body-only responses concise and readable
+- **Matchers check type, not value**: `string('My movie')` means "any string", `integer(1)` means "any integer". The example values are arbitrary — the provider can return different values and verification still passes as long as the type matches. Use matchers only in `.willRespondWith()` (responses), never in `.withRequest()` (requests) — Postel's Law applies.
+- **Reuse test values across files**: Interactions are uniquely identified by `uponReceiving` + `.given()`, not by placeholder values. Two test files can both use `testId: 100` without conflicting. On the provider side, shared values simplify state handlers — idempotent handlers (check if exists, create if not) only need to ensure one record exists. Use different values only when testing different states of the same entity type (e.g., `movieExists(100)` for happy paths vs. `movieNotFound(999)` for error paths).
 
 ## Related Fragments
 

package/src/testarch/knowledge/playwright-config.md

@@ -727,4 +727,4 @@ jobs:
 - [ ] Projects defined for cross-browser/device testing (if needed)
 - [ ] CI uploads artifacts on failure with 30-day retention
 
-_Source: Playwright book repo, SEON configuration example, Murat testing philosophy (lines 216-271)._
+_Source: Playwright book repo, enterprise configuration example, Murat testing philosophy (lines 216-271)._

package/src/testarch/knowledge/risk-governance.md

@@ -612,4 +612,4 @@ Before deploying to production, ensure:
 - **Related fragments**: `probability-impact.md` (scoring definitions), `test-priorities-matrix.md` (P0-P3 classification), `nfr-criteria.md` (non-functional risks)
 - **Tools**: Risk tracking dashboards (Jira, Linear), gate automation (CI/CD), traceability reports (Markdown, Confluence)
 
-_Source: Murat risk governance notes, gate schema guidance, SEON production gate workflows, ISO 31000 risk management standards_
+_Source: Murat risk governance notes, gate schema guidance, enterprise production gate workflows, ISO 31000 risk management standards_

package/src/testarch/knowledge/selective-testing.md

@@ -728,5 +728,5 @@ Before implementing selective testing, verify:
 - Related fragments: `ci-burn-in.md`, `test-priorities-matrix.md`, `test-quality.md`
 - Selection tools: Playwright --grep, Cypress @cypress/grep, git diff
 
-_Source: 32+ selective testing strategies blog, Murat testing philosophy, SEON CI optimization_
+_Source: 32+ selective testing strategies blog, Murat testing philosophy, enterprise CI optimization_
 ```

package/src/testarch/knowledge/visual-debugging.md

@@ -521,4 +521,4 @@ Before deploying tests to CI, ensure:
 - **Related fragments**: `playwright-config.md` (artifact configuration), `ci-burn-in.md` (CI artifact upload), `test-quality.md` (debugging best practices)
 - **Tools**: Playwright Trace Viewer, Cypress Debug UI, axe-core, HAR files
 
-_Source: Playwright official docs, Murat testing philosophy (visual debugging manifesto), SEON production debugging patterns_
+_Source: Playwright official docs, Murat testing philosophy (visual debugging manifesto), enterprise production debugging patterns_

package/src/workflows/testarch/bmad-teach-me-testing/SKILL.md

@@ -0,0 +1,6 @@
+---
+name: bmad-teach-me-testing
+description: 'Teach testing progressively through structured sessions. Use when user says "lets learn testing" or "I want to study test practices"'
+---
+
+Follow the instructions in [workflow.md](workflow.md).

package/src/workflows/testarch/bmad-teach-me-testing/bmad-skill-manifest.yaml

@@ -0,0 +1 @@
+type: skill

package/src/workflows/testarch/{teach-me-testing → bmad-teach-me-testing}/workflow-plan-teach-me-testing.md

@@ -60,7 +60,7 @@ Create an ongoing learning companion that teaches testing progressively through
 ## Classification Decisions
 
 **Workflow Name:** teach-me-testing
-**Target Path:** {project-root}/src/workflows/testarch/teach-me-testing/
+**Target Path:** {project-root}/src/workflows/testarch/bmad-teach-me-testing/
 
 **4 Key Decisions:**
 
@@ -927,7 +927,7 @@ teach-me-testing/
 `{external-project-root}/_bmad-output/bmb-creations/workflows/teach-me-testing/`
 
 **Target (Production):**
-`{project-root}/src/workflows/testarch/teach-me-testing/`
+`{project-root}/src/workflows/testarch/bmad-teach-me-testing/`
 
 **Command:**
 

package/src/workflows/testarch/{teach-me-testing → bmad-teach-me-testing}/workflow.md

@@ -1,5 +1,5 @@
 ---
-name: teach-me-testing
+name: bmad-teach-me-testing
 description: 'Teach testing progressively through structured sessions. Use when user says "lets learn testing" or "I want to study test practices"'
 web_bundle: true
 ---

package/src/workflows/testarch/bmad-testarch-atdd/SKILL.md

@@ -0,0 +1,6 @@
+---
+name: bmad-testarch-atdd
+description: 'Generate failing acceptance tests using TDD cycle. Use when the user says "lets write acceptance tests" or "I want to do ATDD"'
+---
+
+Follow the instructions in [workflow.md](workflow.md).

package/src/workflows/testarch/bmad-testarch-atdd/bmad-skill-manifest.yaml

@@ -0,0 +1 @@
+type: skill

package/src/workflows/testarch/{atdd → bmad-testarch-atdd}/instructions.md

@@ -2,7 +2,7 @@
 
 # Acceptance Test-Driven Development (ATDD)
 
-**Workflow ID**: `_bmad/tea/testarch/atdd`
+**Workflow ID**: `_bmad/tea/testarch/bmad-testarch-atdd`
 **Version**: 5.0 (Step-File Architecture)
 
 ---
@@ -35,11 +35,11 @@ From `workflow.yaml`, resolve:
 ### 2. First Step
 
 Load, read completely, and execute:
-`{project-root}/_bmad/tea/workflows/testarch/atdd/steps-c/step-01-preflight-and-context.md`
+`./steps-c/step-01-preflight-and-context.md`
 
 ### 3. Resume Support
 
 If the user selects **Resume** mode, load, read completely, and execute:
-`{project-root}/_bmad/tea/workflows/testarch/atdd/steps-c/step-01b-resume.md`
+`./steps-c/step-01b-resume.md`
 
 This checks the output document for progress tracking frontmatter and routes to the next incomplete step.

package/src/workflows/testarch/{atdd → bmad-testarch-atdd}/steps-c/step-04-generate-tests.md

@@ -71,9 +71,12 @@ const subagentContext = {
   config: {
     test_framework: config.test_framework,
     use_playwright_utils: config.tea_use_playwright_utils,
+    use_pactjs_utils: config.tea_use_pactjs_utils,
+    pact_mcp: config.tea_pact_mcp,  // "mcp" | "none"
     browser_automation: config.tea_browser_automation,
     execution_mode: config.tea_execution_mode || 'auto',  // "auto" | "subagent" | "agent-team" | "sequential"
     capability_probe: parseBooleanFlag(config.tea_capability_probe, true),  // supports booleans and "false"/"true" strings
+    provider_endpoint_map: /* from Step 1/3 context, if use_pactjs_utils enabled */,
   },
   timestamp: timestamp
 };

package/src/workflows/testarch/{atdd → bmad-testarch-atdd}/steps-c/step-04a-subagent-api-failing.md

@@ -16,7 +16,8 @@ This is an **isolated subagent** running in parallel with E2E failing test gener
 - Story acceptance criteria from Step 1
 - Test strategy and scenarios from Step 3
 - Knowledge fragments loaded: api-request, data-factories, api-testing-patterns
-- Config: test framework, Playwright Utils enabled/disabled
+- Config: test framework, Playwright Utils enabled/disabled, Pact.js Utils enabled/disabled (`use_pactjs_utils`), Pact MCP mode (`pact_mcp`)
+- Provider Endpoint Map (if `use_pactjs_utils` enabled and provider source accessible)
 
 **Your task:** Generate API tests that will FAIL because the feature is not implemented yet (TDD RED PHASE).
 
@@ -113,6 +114,72 @@ test.describe('[Story Name] API Tests (ATDD)', () => {
 - ✅ Use data factories for test data (from data-factories fragment)
 - ✅ Include priority tags [P0], [P1], [P2], [P3]
 
+### 1.5 Provider Source Scrutiny for CDC in TDD Red Phase (If `use_pactjs_utils` Enabled)
+
+When generating Pact consumer contract tests in the ATDD red phase, provider scrutiny applies with TDD-specific rules. Apply the **Seven-Point Scrutiny Checklist** from `contract-testing.md` (Response shape, Status codes, Field names, Enum values, Required fields, Data types, Nested structures) for both existing and new endpoints.
+
+**If provider endpoint already exists** (extending an existing API):
+
+- READ the provider route handler, types, and validation schemas
+- Verify all seven scrutiny points against the provider source: Response shape, Status codes, Field names, Enum values, Required fields, Data types, Nested structures
+- Add `// Provider endpoint:` comment and scrutiny evidence block documenting findings for each point
+- Wrap the entire test function in `test.skip()` (so the whole test including `executeTest` is skipped), not just the callback
+
+**If provider endpoint is new** (TDD — endpoint not implemented yet):
+
+- Use acceptance criteria as the source of truth for expected behavior
+- Acceptance criteria should specify all seven scrutiny points where possible (status codes, field names, types, etc.) — note any gaps as assumptions in the evidence block
+- Add `// Provider endpoint: TODO — new endpoint, not yet implemented`
+- Document expected behavior from acceptance criteria in scrutiny evidence block
+- Wrap the entire test function in `test.skip()` and use realistic expectations from the story
+
+**Graceful degradation when provider source is inaccessible:**
+
+1. **OpenAPI/Swagger spec available**: Use the spec as the source of truth for response shapes, status codes, and field names
+2. **Pact Broker available** (when `pact_mcp` is `"mcp"`): Use SmartBear MCP tools to fetch existing provider states and verified interactions as reference
+3. **Neither available**: For new endpoints, use acceptance criteria; for existing endpoints, use consumer-side types. Mark with `// Provider endpoint: TODO — provider source not accessible, verify manually` and set `provider_scrutiny: "pending"` in output JSON
+4. **Never silently guess**: Document all assumptions in the scrutiny evidence block
+
+**Provider endpoint comments are MANDATORY** even in red-phase tests — they document the intent.
+
+**Example: Red-phase Pact test with provider scrutiny:**
+
+```typescript
+// Provider endpoint: TODO — new endpoint, not yet implemented
+/*
+ * Provider Scrutiny Evidence:
+ * - Handler: NEW — not yet implemented (TDD red phase)
+ * - Expected from acceptance criteria:
+ *   - Endpoint: POST /api/v2/users/register
+ *   - Status: 201 for success, 400 for duplicate email, 422 for validation error
+ *   - Response: { id: number, email: string, createdAt: string }
+ */
+test.skip('[P0] should generate consumer contract for user registration', async () => {
+  await provider
+    .given('no users exist')
+    .uponReceiving('a request to register a new user')
+    .withRequest({
+      method: 'POST',
+      path: '/api/v2/users/register',
+      headers: { 'Content-Type': 'application/json' },
+      body: { email: 'newuser@example.com', password: 'SecurePass123!' },
+    })
+    .willRespondWith({
+      status: 201,
+      headers: { 'Content-Type': 'application/json' },
+      body: like({
+        id: integer(1),
+        email: string('newuser@example.com'),
+        createdAt: string('2025-01-15T10:00:00Z'),
+      }),
+    })
+    .executeTest(async (mockServer) => {
+      const result = await registerUser({ email: 'newuser@example.com', password: 'SecurePass123!' }, { baseUrl: mockServer.url });
+      expect(result.id).toEqual(expect.any(Number));
+    });
+});
+```
+
 **Why test.skip():**
 
 - Tests are written correctly for EXPECTED behavior
@@ -163,6 +230,7 @@ Write JSON to temp file: `/tmp/tea-atdd-api-tests-{{timestamp}}.json`
   "knowledge_fragments_used": ["api-request", "data-factories", "api-testing-patterns"],
   "test_count": 3,
   "tdd_phase": "RED",
+  "provider_scrutiny": "completed",
   "summary": "Generated 3 FAILING API tests for user registration story"
 }
 ```
@@ -205,6 +273,8 @@ Subagent completes when:
 - JSON output valid and complete
 - No E2E/component/unit tests included (out of scope)
 - Tests follow knowledge fragment patterns
+- Every Pact interaction has `// Provider endpoint:` comment (if CDC enabled)
+- Provider scrutiny completed or TODO markers added for new endpoints (if CDC enabled)
 
 ### ❌ FAILURE:
 
@@ -213,3 +283,4 @@ Subagent completes when:
 - Placeholder assertions (expect(true).toBe(true))
 - Did not follow knowledge fragment patterns
 - Invalid or missing JSON output
+- Pact interactions missing provider endpoint comments (if CDC enabled)

package/src/workflows/testarch/{atdd → bmad-testarch-atdd}/validation-report-20260127-095021.md

@@ -1,7 +1,7 @@
 ---
 validationDate: 2026-01-27
 workflowName: testarch-atdd
-workflowPath: {project-root}/src/workflows/testarch/atdd
+workflowPath: {project-root}/src/workflows/testarch/bmad-testarch-atdd
 validationStatus: COMPLETE
 completionDate: 2026-01-27 10:03:10
 ---

package/src/workflows/testarch/{atdd → bmad-testarch-atdd}/validation-report-20260127-102401.md

@@ -1,7 +1,7 @@
 ---
 validationDate: 2026-01-27
 workflowName: testarch-atdd
-workflowPath: {project-root}/src/workflows/testarch/atdd
+workflowPath: {project-root}/src/workflows/testarch/bmad-testarch-atdd
 validationStatus: COMPLETE
 completionDate: 2026-01-27 10:24:01
 ---

package/src/workflows/testarch/{atdd → bmad-testarch-atdd}/workflow.md

@@ -1,5 +1,5 @@
 ---
-name: testarch-atdd
+name: bmad-testarch-atdd
 description: Generate failing acceptance tests using TDD cycle. Use when user says 'lets write acceptance tests' or 'I want to do ATDD'
 web_bundle: true
 ---

package/src/workflows/testarch/{atdd → bmad-testarch-atdd}/workflow.yaml

@@ -1,5 +1,5 @@
-# Test Architect workflow: atdd
-name: testarch-atdd
+# Test Architect workflow: bmad-testarch-atdd
+name: bmad-testarch-atdd
 # prettier-ignore
 description: 'Generate failing acceptance tests using TDD cycle. Use when the user says "lets write acceptance tests" or "I want to do ATDD"'
 
@@ -13,10 +13,10 @@ document_output_language: "{config_source}:document_output_language"
 date: system-generated
 
 # Workflow components
-installed_path: "{project-root}/_bmad/tea/workflows/testarch/atdd"
-instructions: "{installed_path}/instructions.md"
-validation: "{installed_path}/checklist.md"
-template: "{installed_path}/atdd-checklist-template.md"
+installed_path: "."
+instructions: "./instructions.md"
+validation: "./checklist.md"
+template: "./atdd-checklist-template.md"
 
 # Variables and inputs
 variables:

package/src/workflows/testarch/bmad-testarch-automate/SKILL.md

@@ -0,0 +1,6 @@
+---
+name: bmad-testarch-automate
+description: 'Expand test automation coverage for codebase. Use when user says "lets expand test coverage" or "I want to automate tests"'
+---
+
+Follow the instructions in [workflow.md](workflow.md).

package/src/workflows/testarch/bmad-testarch-automate/bmad-skill-manifest.yaml

@@ -0,0 +1 @@
+type: skill