bmad-method-test-architecture-enterprise 1.22.3-next.0 → 1.22.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.22.3-next.0",
+      "version": "1.22.3",
       "author": {
         "name": "Murat K Ozcan (TEA Creator) & Brian (BMad) Madison"
       },

package/CHANGELOG.md

@@ -7,8 +7,58 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [1.22.3] - 2026-08-14
+
+### Added
+
+- `playwright-utils-mandate.md` knowledge fragment (core tier). Makes `tea_use_playwright_utils: true` binding rather than advisory: when the flag is on, `@seontechnologies/playwright-utils` is the default implementation for every capability it covers. Carries the substitution table (`page.route`/`page.waitForResponse` to `interceptNetworkCall`, raw `request.<method>` to `apiRequest`, `page.waitForTimeout` and hand-written polls to `recurse`, `console.log` to `log`, per-spec `base.extend` to `mergeTests`), a REQUIRED versus RECOMMENDED split so utilities needing project wiring are proposed rather than silently skipped, the legitimate exceptions (`page.route` on analytics, fonts, and third-party scripts), a pre-emit self-check, and a deviation protocol that puts a stated reason on any surviving vanilla call. Scoped to JS/TS suites on the Playwright runner; Cypress, Maestro, Pact/Vitest, and non-Playwright backend suites are explicitly out of scope.
+- Criteria registry rows `M9` (MEDIUM) and `L9` (LOW). `M9` fires when a file hand-rolls a capability the installed playwright-utils already provides with no stated deviation; its gate needs both `tea_use_playwright_utils: true` and the package present in `package.json`, so a flag with no install never produces per-file deductions. `L9` fires when a spec imports `test` from `@playwright/test` against a merged-fixtures convention. Both surface in the report as a new `Playwright Utils Adoption` criterion.
+- `playwrightUtils` convention key in the `test-review` baseline, mechanically detected in `cli/lib/convention-baseline.js`. Partial migration now reads as an adoption ratio instead of collapsing to a single pass or fail.
+- `library-integration-mandate.md` knowledge fragment (core tier). The general contract every per-library mandate instantiates, so the pattern generalizes past the two libraries that exist today: the two gates (the flag is `true` AND the package is installed), the REQUIRED versus RECOMMENDED levels, the deviation protocol, scope decided by the runner a file executes under rather than the language of the code under test, the flag-to-mandate registry, and a ten-point checklist for wiring a new library through config, CLI defaults, fragments, loading, generation, aggregation, review, docs, and changelog. A library wired into fewer than all ten produces the decorative-flag failure the mandates exist to prevent.
+- `pactjs-utils-mandate.md` knowledge fragment (core tier). Makes `tea_use_pactjs_utils: true` binding the same way the Playwright mandate does: `createProviderState` instead of a hand-cast `.given('name', obj as JsonMap)`, `buildVerifierOptions` and `buildMessageVerifierOptions` instead of literal `VerifierOptions` objects, `createRequestFilter` / `noOpRequestFilter` instead of bespoke auth middleware, `setJsonContent` / `setJsonBody` instead of repeated PactV4 builder lambdas, `handlePactBrokerUrlAndSelectors` and `getProviderVersionTags` instead of hand-written env and CI branching. `zodToPactMatchers` and the `pact-consumer-di` injection sit at RECOMMENDED because one needs a Zod schema and the other a two-line production change. Carries a relevance gate so a default-on flag never turns into unwanted scaffolding, and restates the determinism rules the mandate does not relax (one `addInteraction()` per `it()`, the Vitest pool settings, provider scrutiny before matchers).
+- Criteria registry row `M10` (MEDIUM): a file hand-rolls a capability the installed `@seontechnologies/pactjs-utils` already provides, with no stated deviation. Gated on the flag plus the package being a project dependency, so a flag with no install never produces per-file deductions. `MatchersV3` used directly does not fire it. Surfaces as a new `Pact.js Utils Adoption` criterion, bringing the registry to 35 rows.
+- `docs/how-to/customization/integrate-pactjs-utils.md`, covering what the flag changes, the substitution table, the relevance gate, the determinism rules that never relax, and how to turn it off.
+
+### Changed
+
+- **`tea_use_pactjs_utils` now defaults to `true`** (was `false`). It decides _how_ Pact suites are written, not _whether_ a project gets one: the mandate's relevance gate still requires a real consumer-provider boundary: an outbound call to a service the repo does not deploy with, an existing `pact/` directory or `@pact-foundation/pact` dependency, `PACT_BROKER_*` in the environment, a microservices layout, or the user asking. `framework` now checks that gate before creating any Pact directory, script, or CI workflow, and states in the summary when it skipped.
+- **`tea_pact_mcp` now defaults to `"mcp"`** (was `"none"`). Unlike the two library flags this one gates a runtime capability rather than a dependency, so its second gate is whether the SmartBear MCP tools are reachable in the session. All six broker-dependent steps now carry an explicit degradation path: probe once, fall back to provider source or an OpenAPI spec, report that the broker was unreachable, and continue. No workflow blocks on it, nothing retries in a loop, and inferred provider states are never presented as broker data.
+- `framework` installs `@seontechnologies/pactjs-utils` and `@pact-foundation/pact` and scaffolds samples in the mandated style, where it previously only recommended the packages. Declining the install falls the whole contract scaffold through to the raw-Pact branch rather than leaving imports against a package the project lacks.
+- `automate` and `atdd` API workers generate contract artifacts under the mandate and report `pactjs_utils_deviations`; `test-design` loads it so Pact examples in design documents match what `automate` generates.
+- The `bmad-tea` agent's critical action and persona principle are now library-agnostic: they read the integration flags, load `library-integration-mandate.md` plus whichever per-library mandate applies, and carry the same rule into ordinary conversation. Asking Murat for a Pact test no longer requires naming `createProviderState` to get it.
+- `playwright-utils-mandate.md` now states the package-installed gate explicitly and defers the shared contract to `library-integration-mandate.md`.
+- `pact-mcp.md` gains a `When the Tools Are Not Reachable` section, which the six broker-dependent steps now point at instead of each restating it. The probe is defined as 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`.
+- `cli/lib/resolve-tea-config.js` resolves `playwright_utils_installed` and `pactjs_utils_installed` from the project manifest and states them in the headless prompt. Both halves of each mandate gate are now resolved in code; the agent is no longer asked to read `package.json` to decide half of it.
+- Registry rows `M9` and `L9` report an unspread convention rather than staying silent. When the flag is on and the package is installed but the sampled corpus shows `absent` or `unknown` adoption, the score is unchanged and one run-level line says so. That is the freshly scaffolded case: `framework` writes a few sample specs, `automate` writes twenty, and a review of the twenty measures a corpus too small to score while being entirely clean.
+- The `playwrightUtils` convention definition in `step-02-discover-tests.md` now matches the detector regex it is paired with. The table cell still described the two-alternative form after the regex dropped the `merged-fixtures` alternative, so a headless run and an interactive run would have counted different corpora. `L9`'s criterion text moved from "a merged-fixtures convention" to "playwright-utils adoption" for the same reason.
+- Registry rows `M9` and `L9` are Convention rows scored against the `playwrightUtils` baseline rather than Applicability rows, so a brownfield repo mid-migration steps down to LOW and a repo at zero adoption deducts nothing. The flag-plus-install half moved out of the Gate column into a new `RUN-LEVEL PRECONDITIONS` section: when a precondition is false those rows do not exist for the run, reported once instead of as a per-file `PASS (n/a)`.
+- The `playwrightUtils` convention detector no longer matches a bare `merged-fixtures` import. That is the `fixtures` key's signal, and matching it let a repo with no playwright-utils anywhere register adoption.
+- `framework` asks before writing `@seontechnologies/*` packages into `package.json`, naming the packages and their peers. It is the only step that writes outside the test directory.
+- The pactjs relevance gate lives in one place. `framework` defers to `pactjs-utils-mandate.md` rather than carrying a looser copy, and the gate now separates signals that settle the question alone from weak ones (an outbound HTTP call, a generated client, a service URL) that need the called service to have no source in this repo plus a second signal.
+- The Pact canonical shape in `pactjs-utils-mandate.md` is PactV4 `addInteraction()` with `setJsonContent` and `setJsonBody`, demonstrating four REQUIRED substitutions rather than one. A worker copies the canonical shape, so a PactV3 example that skipped its own rules taught the wrong pattern.
+- The Pact.js Utils mandate no longer bans importing `@pact-foundation/pact`. The banned-pattern line read "importing from a package name other than `@seontechnologies/pactjs-utils`", which forbade `PactV3`, `MatchersV3`, and `Verifier` — the Pact API every example in the same fragment imports. Only the helper layer is mandated; the two packages are used side by side.
+- `pactjs-utils-zod-to-pact.md` and `confidence-gate.md` ship to every workflow. Five step files loaded the first and nine loaded the second while neither existed outside the agent directory, so each load silently found nothing. `confidence-gate.md` is the terminal branch of the Pact MCP fallback chain and the stop-and-ask rule six fragments cite, so a workflow that could not open it had no floor under either. The parity test's agent-only allowlist is gone rather than emptied: it was the one line asserting intent instead of measuring, and both of its entries were wrong.
+- `pact-consumer-di.md` cited `api-testing-foundations.md`, a fragment that has never existed. The reference is `api-testing-patterns.md`.
+- The auth fixture scaffold implements the real `AuthProvider` contract. It showed an invented `getToken({ identifier })` method; the interface is `getEnvironment`, `getUserIdentifier`, `extractToken`, `extractCookies`, `isTokenExpired`, and `manageAuthToken`, and a fixture built on the invented shape returns no token.
+- Contract scaffolding is gated on relevance, on the package being installed, and on artifacts existing, not on the flag alone. `atdd` requires all three before generating Pact tests, and `ci` skips contract jobs when the repo has no contract tests to run rather than wiring a job that fails every build on a missing script.
+- Workers receive `pact_mcp_reachable` and the selected fallback source, so a subagent can tell a reachable broker session from an unavailable one. They previously saw only the mode, which says what the user allows rather than what answered.
+- Pact deviations reach the final summary. Only the Playwright roll-up was carried into Step 6, so a stated raw-Pact deviation was recorded by a worker and then dropped.
+- The `playwrightUtils` detector matches import syntax rather than the bare package literal, so a prose mention in a comment no longer registers as adoption.
+- Browser fixtures are merged conditionally, and the ATDD error-path scaffold carries `skipNetworkMonitoring`. A scaffold that stubs a 409 on purpose would otherwise fail on the backend error it was asserting.
+- `merged-fixtures.ts` resolves under `{test_dir}` in every workflow. Three different hardcoded paths across the aggregates, checklists, and fragments could have produced a second entry point in a project whose tests do not live in `tests/`.
+- `tea_use_playwright_utils: true` now changes what gets generated, not only which knowledge fragments load. Previously the flag selected a fragment profile while the code templates the generation workers copied from stayed vanilla, so the agent produced `page.route` and raw `request.post` unless the user asked for a utility by name. The API and E2E workers in `*automate` and `*atdd` now carry the playwright-utils template as the primary shape with the vanilla template kept for the flag-off branch, and both list the mandate's substitutions in their success and failure metrics.
+- `*automate` aggregation generates `tests/support/merged-fixtures.ts` and an `auth-session`-based auth fixture instead of a form-driven login fixture and a `page.route` mock module. Network stubs move into the tests that need them as `interceptNetworkCall({ url, fulfillResponse })`, so the stub and the assertion stay together.
+- `*atdd` aggregation creates the merged-fixtures file the red-phase scaffolds import. A scaffold is the file the developer un-skips and keeps, so it is generated in the mandated style rather than as vanilla code to be rewritten later.
+- `*framework` installs `@seontechnologies/playwright-utils` and scaffolds `merged-fixtures.ts`, the auth fixture, and `global-setup.ts` wiring, where it previously only recommended the package. Sample tests are generated in the mandated style, since every later workflow reads them as the reference.
+- `*ci` reads `tea_use_playwright_utils` and drives burn-in selection through `runBurnIn` instead of `--only-changed` on Playwright stacks. The workflow previously had no playwright-utils reference at all, despite `module.yaml` listing it as a consumer.
+- The `bmad-tea` agent applies the mandate in ordinary conversation, not only inside workflows, via a critical action and a persona principle. Asking Murat to write a Playwright test no longer requires naming `interceptNetworkCall` or `apiRequest` to get them.
+- Corrected the package path in the `*automate` and `*atdd` API worker templates: they showed `@playwright-utils/api`, which is not the published package. It is `@seontechnologies/playwright-utils/api-request`.
+- The `*atdd` E2E scaffold template used CSS attribute and `:has-text()` selectors while the same file's requirements and failure metrics called those brittle. Template and rules now agree on `getByLabel` and `getByRole`.
+- `docs/reference/configuration.md` states what `tea_use_playwright_utils: true` actually means, and corrects the claim that `ci` does not read the key.
+
 ### Fixed
 
+- **All eight workflows had been loading stale knowledge.** Six fragments were out of date in every workflow's `resources/knowledge/` directory, having missed agent-level edits that landed after the original copy-in: `contract-testing.md`, `pact-consumer-framework-setup.md` (174 lines of difference), `pactjs-utils-consumer-helpers.md`, `pactjs-utils-overview.md`, `pactjs-utils-provider-verifier.md`, and `test-quality.md`. Workflows read their own copy, never the agent's, so contract-testing and test-quality guidance differed between what the agent recommended and what a workflow generated or reviewed against. Every copy is re-synced from the agent version, which changes the guidance loaded by `framework`, `atdd`, `automate`, `test-design`, `test-review`, `ci`, `nfr`, and `trace`. Expect contract-testing output in particular to change. `test/test-knowledge-base.js` now asserts, per workflow, that the fragment set matches the agent's, that every shared file is byte-identical, and that the workflow's own `tea-index.csv` lists exactly the fragments on disk. That last check had been running against a single workflow before returning early, leaving seven indexes unvalidated: a fragment present on disk but absent from the index is never selected, which looks identical to a fragment that shipped.
 - `test-design` progress checkpoints now carry run identity, so a run for one epic no longer clobbers an interrupted run for another ([#128](https://github.com/bmad-code-org/bmad-method-test-architecture-enterprise/issues/128)). Every create-mode step wrote to a single fixed `{test_artifacts}/test-design-progress.md`, and each step's save appended to whatever was already there, so a second epic's run merged its content and its `stepsCompleted` into the first epic's checkpoint; resuming the first epic afterwards read the second epic's state. `step-01-detect-mode.md` now resolves `run_scope` and `run_key` (`system`, or `epic-{epic_num}`) before the first save, checkpoints are written to `{test_artifacts}/test-design-progress-{run_key}.md`, and the frontmatter carries `runScope` and `runKey`. Resolving `epic_num` in step 1 also removes the late "if `epic_num` is unclear, ask the user" prompt in `step-05-generate-output.md`, so a plan and its checkpoint always name the same run.
 - `test-design` create mode no longer merges two runs into one checkpoint. When a checkpoint already exists for the same scope, step 1 reports its `lastStep` and `lastSaved` and asks whether to resume or start over, and starting over replaces the file instead of appending to it.
 - `test-design` resume mode selects the checkpoint belonging to the run being resumed, asks which run to continue when several checkpoints exist and no scope was named, and refuses a checkpoint whose `runKey` does not match. Checkpoints written under the old fixed name are detected, confirmed with the user, and migrated.

package/README.md

@@ -129,9 +129,9 @@ npx bmad-method install
 TEA variables are defined in `src/module.yaml` and prompted during install:
 
 - `test_artifacts` — base output folder for test artifacts
-- `tea_use_playwright_utils` — enable Playwright Utils integration (boolean)
-- `tea_use_pactjs_utils` — enable Pact.js Utils integration for contract testing when your project explicitly uses Pact (boolean)
-- `tea_pact_mcp` — SmartBear MCP for PactFlow/Broker interaction when broker integration is needed: mcp, none (string)
+- `tea_use_playwright_utils` — enable Playwright Utils integration (boolean, default true). When true **and the package is installed**, `@seontechnologies/playwright-utils` becomes the default implementation for everything it covers: generated Playwright tests use `interceptNetworkCall`, `apiRequest`, `recurse`, and `log` without being asked, and `test-review` flags a vanilla equivalent that carries no stated reason. See [Integrate Playwright Utils](https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/how-to/customization/integrate-playwright-utils/)
+- `tea_use_pactjs_utils` — enable Pact.js Utils integration for contract testing (boolean, default true). It decides how Pact suites are written, not whether a project gets one: TEA still requires a real consumer-provider boundary before scaffolding a contract test. When on **and the package is installed**, generated Pact code uses `createProviderState`, `buildVerifierOptions`, and `createRequestFilter` rather than raw Pact boilerplate. A flag with no install generates the raw path and reports one recommendation rather than flagging every file
+- `tea_pact_mcp` — SmartBear MCP for PactFlow/Broker interaction: mcp, none (string, default mcp). Safe without a broker: every broker-dependent step degrades to provider source or an OpenAPI spec and reports that the broker was unreachable
 - `tea_browser_automation` — browser automation mode: auto, cli, mcp, none (string)
 - `test_framework` — detected or configured test framework (Playwright, Cypress, Jest, Vitest, pytest, JUnit, Go test, dotnet test, RSpec, Maestro)
 - `test_stack_type` — detected or configured stack type (frontend, backend, fullstack, mobile)

package/cli/lib/build-prompt.js

@@ -103,6 +103,10 @@ function conventionBaselinePromptLines(conventionBaseline) {
  * @param {string} [options.scope] - review_scope override (single|directory|suite).
  *   Default derives from the review set: single for one file, directory otherwise.
  * @param {string} [options.testDir] - test_dir hint for the workflow.
+ * @param {object} [options.installedPackages] - Resolved library-install booleans
+ *   from resolve-tea-config (`playwright_utils_installed`, `pactjs_utils_installed`).
+ *   The second half of each mandate gate, read from the project manifest so a
+ *   headless run never leaves it to the agent.
  * @param {object} [options.teaConfig] - Resolved TEA config keys from
  *   resolve-tea-config. Defaults to the module defaults so the prompt always
  *   states them and the agent never has to infer them.
@@ -138,6 +142,7 @@ function buildPrompt({
   scope,
   testDir = 'tests',
   teaConfig = MODULE_DEFAULTS,
+  installedPackages = { playwright_utils_installed: false, pactjs_utils_installed: false },
   contextFiles = [],
   contextBasis = 'none',
   focus = '',
@@ -185,9 +190,19 @@ function buildPrompt({
     `tea_use_playwright_utils=${teaConfig.tea_use_playwright_utils}`,
     `tea_use_pactjs_utils=${teaConfig.tea_use_pactjs_utils}`,
     `tea_pact_mcp=${teaConfig.tea_pact_mcp}`,
+    `playwright_utils_installed=${installedPackages.playwright_utils_installed}`,
+    `pactjs_utils_installed=${installedPackages.pactjs_utils_installed}`,
     'The values above are the resolved configuration for this run and take precedence over anything read from',
     'config.yaml. Use them for the step-01 fragment selection (Playwright Utils loading profile, pactjs-utils',
     'fragment set, Pact MCP) instead of inferring the flags.',
+    'The two *_installed values above were read from the project manifest by the CLI. Do not re-derive them, and do',
+    'not open package.json: they are the second half of each mandate gate, stated here for the same reason the flags are.',
+    'playwrightUtilsActive = tea_use_playwright_utils AND playwright_utils_installed; when true, load',
+    'playwright-utils-mandate.md and score registry rows M9 and L9. pactjsUtilsActive = tea_use_pactjs_utils AND',
+    'pactjs_utils_installed; when true, load pactjs-utils-mandate.md and score registry row M10.',
+    'A false precondition means those rows DO NOT EXIST for this run (criteria-registry.md § RUN-LEVEL PRECONDITIONS):',
+    'emit no violations and no per-file PASS (n/a) for them, and state the reason once, naming which half was missing.',
+    'library-integration-mandate.md carries the general contract behind both rows.',
     '',
     'The file list below IS the complete and authoritative review set: skip the discovery glob in',
     "step-02-discover-tests regardless of review_scope. This overrides step-02's glob for this run only.",

package/cli/lib/convention-baseline.js

@@ -23,8 +23,8 @@
  *   sampling rules, just executed by code instead of described in prose. A report
  *   that cites a different sampled count, or a different corpus, is provably wrong
  *   and rejected outright.
- * - adopted counts for the five keys with a concrete, literal recognized form
- *   (priorityMarkers, testIds, networkFirst, dataFactories, fixtures): a generous,
+ * - adopted counts for the six keys with a concrete, literal recognized form
+ *   (priorityMarkers, testIds, networkFirst, dataFactories, fixtures, playwrightUtils): a generous,
  *   high-recall regex scan over the real sampled files' real content. This is not
  *   claimed to be a precise semantic judgment — a regex cannot know intent — but it
  *   gives a safe one-directional floor: when the scan finds ZERO occurrences of any
@@ -47,8 +47,17 @@ const { isTestFile } = require('./changed-tests');
 
 // Same order as step-02-discover-tests.md §2b's "Conventions to measure" table and
 // criteria-registry.md's mapping table. Every consumer of this list (build-prompt,
-// parse-report, the tests) shares this one array so the seven keys cannot drift.
-const CONVENTION_KEYS = ['priorityMarkers', 'testIds', 'bddNaming', 'networkFirst', 'dataFactories', 'fixtures', 'assertionStyle'];
+// parse-report, the tests) shares this one array so the eight keys cannot drift.
+const CONVENTION_KEYS = [
+  'priorityMarkers',
+  'testIds',
+  'bddNaming',
+  'networkFirst',
+  'dataFactories',
+  'fixtures',
+  'assertionStyle',
+  'playwrightUtils',
+];
 
 const MAX_SAMPLED_FILES = 40;
 const MIN_CORPUS_TO_ATTEMPT = 1; // 0 eligible files outside the review set: nothing to sample at all.
@@ -57,8 +66,9 @@ const MIN_CORPUS_TO_ATTEMPT = 1; // 0 eligible files outside the review set: not
 // content (case-insensitive, no /g flag so repeated .test() calls carry no state).
 // Deliberately high-recall: a false positive here only ever makes the zero-signal
 // floor check more permissive (it stops treating a convention as unattested), never
-// less — see the module doc comment. The literal forms mirror the "Record as `form`"
-// examples in step-02-discover-tests.md's table.
+// less — see the module doc comment. Each detector must match what the "Adopted when
+// a sampled file..." column in step-02-discover-tests.md's table says, so a headless
+// run and an interactive run count the same corpus. Changing one means changing both.
 const MECHANICAL_DETECTORS = {
   priorityMarkers: /(\[P[0-3]\]|@P[0-3]\b|['"`]@?P[0-3]['"`]|\bpriority\s*:\s*['"`]?P[0-3]\b)/i,
   testIds: /(data-testid|data-test-id|getByTestId|test-id\s*=|testid\s*=)/i,
@@ -66,6 +76,13 @@ const MECHANICAL_DETECTORS = {
     /(interceptNetworkCall\s*\(|page\.route\s*\(|cy\.intercept\s*\(|waitForResponse\s*\(|waitForRequest\s*\(|route\.fulfill\s*\()/i,
   dataFactories: /(\bbuild[A-Z]\w*\s*\(|\bFactory\s*\(|from\s+['"][^'"]*factories|\bfactories\/)/i,
   fixtures: /(mergeTests\s*\(|test\.extend\s*\(|from\s+['"][^'"]*fixtures|merged-fixtures)/i,
+  // Only the package literal. `merged-fixtures` is already the `fixtures` key's
+  // signal, and a hand-rolled merged-fixtures.ts with no playwright-utils anywhere
+  // would otherwise register adoption for a package the repo never installed.
+  // Import-shaped only. The bare package literal also matches a prose mention in a
+  // comment ("// TODO: migrate to @seontechnologies/playwright-utils"), which would
+  // register adoption for a file that uses none of it.
+  playwrightUtils: /(?:from|require\s*\(|import\s*\()\s*['"`]@seontechnologies\/playwright-utils/i,
 };
 
 const MECHANICAL_CONVENTION_KEYS = Object.keys(MECHANICAL_DETECTORS);

package/cli/lib/resolve-tea-config.js

@@ -24,8 +24,8 @@ const CONFIG_RELATIVE_PATH = path.join('_bmad', 'tea', 'config.yaml');
 
 const MODULE_DEFAULTS = {
   tea_use_playwright_utils: true,
-  tea_use_pactjs_utils: false,
-  tea_pact_mcp: 'none',
+  tea_use_pactjs_utils: true,
+  tea_pact_mcp: 'mcp',
 };
 
 const PACT_MCP_VALUES = ['mcp', 'none'];
@@ -126,6 +126,54 @@ function readTeaConfigFile(projectRoot) {
   return { present: true, path: configPath, values };
 }
 
+/**
+ * Whether a package appears in the consuming project's dependency manifest.
+ *
+ * Half of a library mandate's gate is the flag, resolved above. The other half is
+ * whether the package is actually installed, and leaving that to the agent means a
+ * headless run decides it by reading package.json — an unlisted extra read the
+ * prompt otherwise discourages, and a judgment call where a lookup will do. Both
+ * halves resolve here so the gate closes the same way on every run.
+ *
+ * Absent, unreadable, or unparseable manifest reads as "not installed": the
+ * conservative answer, since the consequence is that a mandate row does not fire.
+ *
+ * @param {string} projectRoot
+ * @param {string} packageName
+ * @returns {boolean}
+ */
+function isPackageInstalled(projectRoot, packageName) {
+  const manifestPath = path.join(projectRoot, 'package.json');
+  if (!fs.existsSync(manifestPath)) {
+    return false;
+  }
+  let manifest;
+  try {
+    manifest = JSON.parse(fs.readFileSync(manifestPath, 'utf8'));
+  } catch {
+    return false;
+  }
+  if (manifest === null || typeof manifest !== 'object' || Array.isArray(manifest)) {
+    return false;
+  }
+  return ['dependencies', 'devDependencies', 'peerDependencies', 'optionalDependencies'].some((section) => {
+    const deps = manifest[section];
+    return Boolean(deps) && typeof deps === 'object' && !Array.isArray(deps) && packageName in deps;
+  });
+}
+
+/** Config key to the npm package whose presence completes its gate. */
+const KEY_TO_PACKAGE = {
+  tea_use_playwright_utils: '@seontechnologies/playwright-utils',
+  tea_use_pactjs_utils: '@seontechnologies/pactjs-utils',
+};
+
+/** The `installed` field each gate reports under. */
+const KEY_TO_INSTALLED_FIELD = {
+  tea_use_playwright_utils: 'playwright_utils_installed',
+  tea_use_pactjs_utils: 'pactjs_utils_installed',
+};
+
 /**
  * Resolve every key through the precedence chain.
  *
@@ -133,7 +181,9 @@ function readTeaConfigFile(projectRoot) {
  * @param {string} options.projectRoot - Consuming project root.
  * @param {object} [options.flags] - Parsed CLI options; only the keys in
  *   FLAG_TO_KEY are read, and only when not undefined.
- * @returns {{values: object, sources: object, configPath: string, configPresent: boolean}}
+ * @returns {{values: object, sources: object, installed: object, configPath: string, configPresent: boolean}}
+ *   `installed` carries one boolean per library gate, read from the project
+ *   manifest rather than left to the agent.
  * @throws {Error} With code TEA_CONFIG_INVALID on unusable config content.
  */
 function resolveTeaConfig({ projectRoot, flags = {} }) {
@@ -158,12 +208,20 @@ function resolveTeaConfig({ projectRoot, flags = {} }) {
     sources[key] = 'default';
   }
 
-  return { values, sources, configPath: file.path, configPresent: file.present };
+  const installed = {};
+  for (const [key, packageName] of Object.entries(KEY_TO_PACKAGE)) {
+    installed[KEY_TO_INSTALLED_FIELD[key]] = isPackageInstalled(projectRoot, packageName);
+  }
+
+  return { values, sources, installed, configPath: file.path, configPresent: file.present };
 }
 
 module.exports = {
   resolveTeaConfig,
   readTeaConfigFile,
+  isPackageInstalled,
+  KEY_TO_PACKAGE,
+  KEY_TO_INSTALLED_FIELD,
   MODULE_DEFAULTS,
   PACT_MCP_VALUES,
   CONFIG_RELATIVE_PATH,

package/cli/test-review.js

@@ -412,8 +412,11 @@ function main() {
   // project's config.yaml, then the module default) and stated in the prompt.
   // An unstated key is one the agent decides per run.
   let teaConfig;
+  let installedPackages;
   try {
-    teaConfig = resolveTeaConfig({ projectRoot, flags: options }).values;
+    const resolvedTeaConfig = resolveTeaConfig({ projectRoot, flags: options });
+    teaConfig = resolvedTeaConfig.values;
+    installedPackages = resolvedTeaConfig.installed;
   } catch (error) {
     if (error.code === 'TEA_CONFIG_INVALID') {
       fail(EXIT.ENV_ERROR, error.message);
@@ -576,6 +579,7 @@ function main() {
       scope: options.scope,
       testDir: options.testDir,
       teaConfig,
+      installedPackages,
       contextFiles,
       contextBasis,
       focus: options.focus,
@@ -684,6 +688,7 @@ function main() {
     scope: options.scope,
     testDir: options.testDir,
     teaConfig,
+    installedPackages,
     contextFiles,
     contextBasis,
     focus: options.focus,

package/docs/explanation/knowledge-base-system.md

@@ -20,7 +20,7 @@ network-first,Network-First Safeguards,"Intercept-before-navigate workflow, HAR
 test-quality,Test Quality Definition of Done,"Execution limits, isolation rules, green criteria","quality,definition-of-done,tests",core,knowledge/test-quality.md
 ```
 
-`tier` is one of `core`, `extended`, or `specialized`. The 56 fragments split 21 / 19 / 16 across those tiers.
+`tier` is one of `core`, `extended`, or `specialized`. The 59 fragments split 24 / 19 / 16 across those tiers.
 
 The agent-level `resources/` directory is the reference catalog. Workflow skills also carry their own `resources/tea-index.csv` and `resources/knowledge/` directories. That duplication is intentional: workflow step frontmatter resolves `knowledgeIndex: './resources/tea-index.csv'` from `{skill-root}`, which keeps each workflow skill modular and self-contained.
 
@@ -150,7 +150,7 @@ test('job completion', async ({ apiRequest, recurse }) => {
 
 ## Related
 
-- [Knowledge Base Index](/docs/reference/knowledge-base.md) - all 56 fragments, categorized
+- [Knowledge Base Index](/docs/reference/knowledge-base.md) - all 59 fragments, categorized
 - [Testing as Engineering](/docs/explanation/testing-as-engineering.md) - the context engineering argument
 - [Test Quality Standards](/docs/explanation/test-quality-standards.md) - what `test-quality.md` encodes
 - [Network-First Patterns](/docs/explanation/network-first-patterns.md) - what `network-first.md` encodes

package/docs/explanation/network-first-patterns.md

@@ -135,7 +135,9 @@ Both forms wait exactly as long as needed, whether that is 100 ms or 5 seconds,
 
 ## What Playwright Utils Adds
 
-`@seontechnologies/playwright-utils` is optional. When `tea_use_playwright_utils` is enabled, TEA generates the second form above instead of the first. Seven things it changes:
+`@seontechnologies/playwright-utils` is optional as a choice, and binding once chosen. `tea_use_playwright_utils` defaults to `true`, and while it is `true` **and the package is installed** the second form above is what TEA generates and what `test-review` expects. Both halves are required: a flag with no install generates the vanilla form and produces one setup recommendation rather than findings. `page.route` on an application endpoint becomes a finding unless the code says why. It stays correct for what it is genuinely for: blocking analytics, fonts, and third-party scripts, and that needs no justification. Where the utility genuinely does not cover a case, the vanilla call ships with a `// playwright-utils deviation: <reason>` comment on the line and an entry in the workflow's summary, which is what separates a decision from an oversight. The full rule is the `playwright-utils-mandate` knowledge fragment.
+
+Seven things the utility changes:
 
 1. **Automatic JSON parsing.** No `await response.json()` anywhere.
 2. **Different result shapes for different utilities**, and the distinction matters. `interceptNetworkCall` resolves to `{ status, responseJson, requestJson }` because it observes a browser round trip and can see both directions. `apiRequest` resolves to `{ status, body }` because it issues the request itself.

package/docs/explanation/tea-overview.md

@@ -159,7 +159,11 @@ Codex users run `$bmad-testarch-test-design` with the same scope-setting prompt.
 
 TEA spans Phase 3, Phase 4, and the release gate, where most BMM agents operate in a single phase. That multi-phase role is paired with a dedicated testing knowledge base so standards stay consistent across projects: extensive domain knowledge (test patterns, CI/CD, fixtures, quality practices), cross-cutting standards that apply to every BMad project rather than to one document type, and optional integrations for Playwright Utils, the Playwright CLI, and MCP servers. See [Knowledge Base System](/docs/explanation/knowledge-base-system.md).
 
-## Optional Integrations
+## Library Integrations
+
+"Optional" describes the choice, not the effect. Each library has a config flag, and while a flag is `true` and its package is installed, that library is the implementation TEA reaches for on everything it covers — you never name a utility in a prompt to get it. The contract behind that is the `library-integration-mandate` knowledge fragment, and each library has its own mandate carrying the substitutions. Turning a flag off is what makes TEA hand-roll the equivalent instead.
+
+The same fragment holds the checklist for adding the next library, so a new integration lands in generation, aggregation, review, and docs rather than only in a fragment nobody applies.
 
 ### Playwright Utils (`@seontechnologies/playwright-utils`)
 
@@ -175,7 +179,7 @@ Production-ready fixtures and utilities that enhance TEA workflows.
 Contract testing utilities that reduce raw Pact.js boilerplate and standardize provider verification.
 
 - Install: `npm install -D @seontechnologies/pactjs-utils @pact-foundation/pact`
-- Config: `tea_use_pactjs_utils: true` (default `false`; opt in only when you want Pact-aware workflows)
+- Config: `tea_use_pactjs_utils: true` (the default). It decides _how_ Pact suites are written, never _whether_ a project gets one: TEA still requires a real consumer-provider boundary before scaffolding any contract test. Set `false` to have TEA write raw `@pact-foundation/pact`.
 - Impacts: `framework`, `atdd`, `automate`, `test-design`, `test-review`, `ci`
 - Utilities: createProviderState, toJsonMap, setJsonBody, setJsonContent, buildVerifierOptions, buildMessageVerifierOptions, createRequestFilter, noOpRequestFilter, handlePactBrokerUrlAndSelectors, getProviderVersionTags
 - Supports the local monorepo flow (`pactUrls`) and the remote broker flow (`PACT_BROKER_BASE_URL`, `PACT_BROKER_TOKEN`)
@@ -213,12 +217,12 @@ Optional design-time broker interaction for contract testing workflows.
 
 **Configuration** (`_bmad/tea/config.yaml`):
 
-    tea_pact_mcp: "none"  # none | mcp
+    tea_pact_mcp: "mcp"  # none | mcp (default "mcp")
 
-| Mode   | What happens                                                                                                        |
-| ------ | ------------------------------------------------------------------------------------------------------------------- |
-| `mcp`  | TEA can use SmartBear MCP tools for provider-state discovery, test review support, can-i-deploy, and matrix checks. |
-| `none` | Default. TEA skips broker/MCP integration entirely unless you explicitly enable it.                                 |
+| Mode   | What happens                                                                                                                                                                                                            |
+| ------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `mcp`  | Default. TEA uses SmartBear MCP tools for provider-state discovery, test review support, can-i-deploy, and matrix checks when they are reachable, and degrades to provider source or an OpenAPI spec when they are not. |
+| `none` | TEA never attempts a broker call, and skips the reachability probe entirely.                                                                                                                                            |
 
 **Setup:**
 

package/docs/explanation/verification-architecture.md

@@ -87,7 +87,7 @@ TEA's execution coverage is uneven, and the uneven part is deliberate to state r
 
 ### The self-audit
 
-Of TEA's 56 knowledge fragments, 38 name Playwright or Cypress. Three cover mobile. None covers a backend test framework, and the knowledge index has no row tagged for pytest, JUnit, Go test, xUnit, or RSpec.
+Of TEA's 59 knowledge fragments, 40 name Playwright or Cypress. Three cover mobile. None covers a backend test framework, and the knowledge index has no row tagged for pytest, JUnit, Go test, xUnit, or RSpec.
 
 That is the real shape of the gap, and it is uneven in a specific way. Web and mobile are knowledge-backed: TEA carries curated patterns for both, so what it generates follows a pattern library rather than the model's improvisation. Backend languages are not. TEA can decide to scaffold pytest, and does, but it works from the conventions named inline in the workflow step and from the project it can see. The reasoning that selects pytest is as rigorous for a Python service as for a React Native app. The execution guidance behind it is not yet equivalent.
 

package/docs/glossary/index.md

@@ -135,7 +135,7 @@ Terminology reference for Test Architect (TEA).
 | **Epic-Level Test Design**   | Test planning per epic (Phase 4) focusing on risk assessment, priorities, and coverage strategy for that specific epic.                                                                                                                                            |
 | **Fixture Architecture**     | Pattern of building pure functions first, then wrapping in framework-specific fixtures for testability, reusability, and composition.                                                                                                                              |
 | **Gate Decision**            | Go/no-go decision for release with four outcomes: PASS ✅ (ready), CONCERNS ⚠️ (proceed with mitigation), FAIL ❌ (blocked), WAIVED ⏭️ (approved despite issues).                                                                                                  |
-| **Knowledge Fragment**       | Individual markdown file in TEA's knowledge base covering a specific testing pattern or practice (56 fragments total).                                                                                                                                             |
+| **Knowledge Fragment**       | Individual markdown file in TEA's knowledge base covering a specific testing pattern or practice (59 fragments total).                                                                                                                                             |
 | **Network-First Pattern**    | Testing pattern that waits for actual network responses instead of fixed timeouts to avoid race conditions and flakiness.                                                                                                                                          |
 | **NFR Evidence Audit**       | Validation of non-functional requirement evidence (security, performance, reliability, maintainability) against defined thresholds.                                                                                                                                |
 | **No TEA**                   | Engagement model 1. Skip all TEA workflows and keep the team's existing testing approach. A valid choice when that approach already works.                                                                                                                         |

package/docs/how-to/customization/integrate-pactjs-utils.md

@@ -0,0 +1,184 @@
+---
+title: 'Integrate Pact.js Utils with TEA'
+description: What TEA generates for consumer-driven contract testing when tea_use_pactjs_utils is on, and how to turn it off
+---
+
+# Integrate Pact.js Utils with TEA
+
+`@seontechnologies/pactjs-utils` wraps `@pact-foundation/pact` with type-safe helpers for provider states, PactV4 builders, verifier configuration, and request filters. TEA integrates with it through the `tea_use_pactjs_utils` config flag, which is **on by default**.
+
+## What the Flag Actually Does
+
+`tea_use_pactjs_utils: true` does not mean "the library is available if you ask for it", and it does not mean "add contract tests to this project". It means: **whenever TEA writes a Pact artifact, it writes it with these utilities.**
+
+The rule lives in the `pactjs-utils-mandate` knowledge fragment, which every generating and reviewing workflow loads first. It instantiates the same general contract as the Playwright Utils mandate, documented in `library-integration-mandate`.
+
+### Two gates
+
+The mandate binds only when both hold:
+
+1. `tea_use_pactjs_utils` is `true`.
+2. `@seontechnologies/pactjs-utils` is a dependency in your `package.json`.
+
+A flag with no install is an intention, not a capability. TEA will not scaffold imports against a package you do not have, and `test-review` will not deduct for not using one.
+
+### The relevance gate
+
+Separately from the two gates above, TEA decides whether a Pact suite belongs in your project at all. It scaffolds one only with evidence of a real consumer-provider boundary:
+
+**Any one of these settles it:**
+
+- An existing `pact/` or `tests/contract/` directory
+- `@pact-foundation/pact` already in `package.json`
+- `PACT_BROKER_*` in the environment or `.env.example`
+- A microservices layout: two or more independently deployable services in the repo that call each other
+- You asked for contract testing
+
+**These are weak on their own** and need corroboration: an outbound HTTP call, a generated API client, a service URL in `.env.example`. Most frontends have all three and call a backend that ships in the same deploy. They count only when the called service has no source in this repo and is not started by this repo's compose file, dev script, or CI — **and** a second signal is present.
+
+With none of that, TEA creates no Pact artifacts and says why in the summary. A dead contract suite that fails CI for a boundary the project does not have is worse than no suite, so the default-on flag never turns into unwanted scaffolding.
+
+## Substitutions
+
+**REQUIRED** — drop-in. Generating the raw-Pact equivalent instead is a defect:
+
+| You need                                    | TEA emits                                                    | Not                                                      |
+| ------------------------------------------- | ------------------------------------------------------------ | -------------------------------------------------------- |
+| A provider state on an interaction          | `.given(...createProviderState({ name, params }))`           | `.given('name', obj as JsonMap)`                         |
+| Params coerced to Pact's `JsonMap`          | `toJsonMap(value)`                                           | Manual casts, per-call-site `null` and `Date` handling   |
+| PactV4 request/response builder callbacks   | `setJsonContent({ query?, headers?, body? })`, `setJsonBody` | Repeated inline `(b) => { b.query(...); ... }` lambdas   |
+| HTTP provider verification options          | `buildVerifierOptions({ provider, port, ... })`              | A hand-assembled 30-line `VerifierOptions` object        |
+| Message/Kafka provider verification         | `buildMessageVerifierOptions({ ... })`                       | A second hand-assembled options object                   |
+| Broker URL and consumer version selectors   | `handlePactBrokerUrlAndSelectors(...)`                       | Hand-written env-var branching per flow                  |
+| Provider version tags in CI                 | `getProviderVersionTags()`                                   | Hand-written branch/tag extraction per CI platform       |
+| Auth injection during provider verification | `createRequestFilter({ tokenGenerator })`                    | Bespoke Express middleware, with its `Bearer Bearer` bug |
+| A provider that needs no auth               | `noOpRequestFilter`                                          | An empty inline function                                 |
+
+**RECOMMENDED** — needs something the project may not have, so TEA proposes it and names what is missing rather than silently hand-rolling the alternative:
+
+- `zodToPactMatchers(schema)` where a Zod schema already exists, instead of a parallel hand-written matcher tree
+- The `pact-consumer-di` injection, so `executeTest` calls your real client with `mockServer.url` instead of raw `fetch`. It needs an optional `baseUrl` on your API context type: two lines of production code
+
+**Real exceptions still ship.** `MatchersV3` used directly for something `zodToPactMatchers` cannot express is correct and is not a deviation. Where a genuine gap exists, generated code carries `// pactjs-utils deviation: <reason>` and the workflow summary lists it.
+
+## What Never Relaxes
+
+The mandate does not soften the correctness rules from the per-utility fragments. They apply with or without the utilities:
+
+- **One `pact.addInteraction()` per `it()` block.** PactV4's Rust FFI drops interactions non-deterministically otherwise. Use `it.each` for parameterized cases.
+- **Consumer Vitest config** carries `fileParallelism: false` AND `pool: 'forks'` AND `poolOptions.forks.singleFork: true`.
+- **Provider Vitest config** carries the `pool: 'forks'` + `singleFork` pair.
+- **Provider scrutiny before matchers.** Response matchers come from provider source, an OpenAPI spec, or broker data, never from consumer-side types alone.
+- **Postel's Law.** Matchers in `willRespondWith` only; request bodies in `withRequest` use exact values.
+- **A `// Provider endpoint:` comment** on every interaction.
+
+## Canonical Shapes
+
+### Consumer test
+
+```typescript
+import { PactV4, MatchersV3 } from '@pact-foundation/pact';
+import { createProviderState, setJsonBody, setJsonContent } from '@seontechnologies/pactjs-utils';
+import { getMovieById } from '../../src/api/movies-client';
+
+const { integer, string } = MatchersV3;
+
+const pact = new PactV4({ consumer: 'movie-web', provider: 'SampleMoviesAPI', dir: './pacts' });
+
+describe('Movie API Contract', () => {
+  it('returns a movie by id', async () => {
+    // Provider endpoint: server/src/routes/movies.ts -> GET /movies/:id
+    await pact
+      .addInteraction()
+      .given(...createProviderState({ name: 'movie with id 1 exists', params: { id: 1 } }))
+      .uponReceiving('a request for movie 1')
+      .withRequest('GET', '/movies/1', setJsonContent({ headers: { Accept: 'application/json' } }))
+      .willRespondWith(200, setJsonBody({ id: integer(1), name: string('Inception') }))
+      .executeTest(async (mockServer) => {
+        // The real client, pointed at the mock server
+        const movie = await getMovieById(1, { baseUrl: mockServer.url });
+        expect(movie.name).toBe('Inception');
+      });
+  });
+});
+```
+
+One `addInteraction()` per `it()`. A second scenario is a second `it()`, or `it.each` — never a second chain in the same block.
+
+Where a Zod schema for the response already exists, `zodToPactMatchers(MovieSchema)` replaces the inline `MatchersV3` tree so the schema stays the single source of the shape.
+
+### Provider verification
+
+```typescript
+import { Verifier } from '@pact-foundation/pact';
+import { buildVerifierOptions, createRequestFilter } from '@seontechnologies/pactjs-utils';
+import type { StateHandlers } from '@seontechnologies/pactjs-utils';
+
+const stateHandlers: StateHandlers = {
+  'movie with id 1 exists': {
+    setup: async (params) => db.seed({ movies: [{ id: params?.id ?? 1 }] }),
+    teardown: async () => db.clean('movies'),
+  },
+};
+
+await new Verifier(
+  buildVerifierOptions({
+    provider: 'SampleMoviesAPI',
+    port: '3001',
+    includeMainAndDeployed: process.env.PACT_BREAKING_CHANGE !== 'true',
+    stateHandlers,
+    requestFilter: createRequestFilter({ tokenGenerator: () => process.env.TEST_AUTH_TOKEN ?? 'test-token' }),
+  }),
+).verifyProvider();
+```
+
+State handler names and their `params` must match the consumer's `createProviderState` exactly. That pairing is the contract's own contract.
+
+## Which Workflows Change
+
+| Workflow      | What the flag changes                                                                                                                                                                              |
+| ------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `framework`   | Installs `@seontechnologies/pactjs-utils` and `@pact-foundation/pact`, then scaffolds directories, Vitest configs, scripts, CI workflow, and mandated samples — only when the relevance gate opens |
+| `atdd`        | Red-phase contract scaffolds generated in the mandated style. A scaffold is the file the developer un-skips and keeps                                                                              |
+| `automate`    | The API worker emits contract artifacts in the mandated style and reports deviations                                                                                                               |
+| `test-design` | Pact code examples in design documents match what `automate` will generate                                                                                                                         |
+| `test-review` | Scores registry row `M10` (a configured contract utility bypassed with no stated deviation, MEDIUM), gated on flag plus install                                                                    |
+| `ci`          | Adds the contract-test stage and quality gates                                                                                                                                                     |
+
+## Pact MCP (`tea_pact_mcp`)
+
+Also on by default, and safe without a broker. It gates a runtime capability rather than a dependency, so its second gate is "are the SmartBear MCP tools reachable in this session".
+
+When they are, TEA prefers real broker data for provider states, the verification matrix, and `can-i-deploy`. When they are not, it degrades: falls back to provider source or an OpenAPI spec, states in the output that the broker was unreachable, and continues. No workflow blocks on it, nothing retries in a loop, and inferred provider states are never presented as broker data.
+
+Set `tea_pact_mcp: 'none'` to stop TEA attempting a broker call at all.
+
+## Turning It Off
+
+```yaml
+# _bmad/tea/config.yaml
+tea_use_pactjs_utils: false # TEA writes raw @pact-foundation/pact instead
+tea_pact_mcp: 'none' # TEA never attempts a broker call
+```
+
+Turning `tea_use_pactjs_utils` off does not disable contract testing. It changes which API the generated tests are written against; the determinism rules and provider scrutiny still apply.
+
+## Installation
+
+```bash
+npm install -D @seontechnologies/pactjs-utils @pact-foundation/pact
+# peer dependency: @pact-foundation/pact >= 16.2.0, Node.js >= 18
+```
+
+For the remote broker flow, set `PACT_BROKER_BASE_URL` and `PACT_BROKER_TOKEN`, plus `GITHUB_SHA` (GitHub Actions sets this) and `GITHUB_BRANCH` (set it explicitly: `${{ github.head_ref || github.ref_name }}`). The local monorepo flow needs no broker.
+
+## Related Guides
+
+- [Integrate Playwright Utils](/docs/how-to/customization/integrate-playwright-utils.md) — the same mandate shape for browser and API suites
+- [TEA Configuration Reference](/docs/reference/configuration.md) — every key and its default
+- [Knowledge Base Index](/docs/reference/knowledge-base.md) — the contract-testing fragments
+
+## Reference
+
+- [Pact.js Utils docs](https://seontechnologies.github.io/pactjs-utils/)
+- [Pact.js Utils on npm](https://www.npmjs.com/package/@seontechnologies/pactjs-utils)