bmad-method-test-architecture-enterprise 1.21.6 → 1.21.7

package/.claude-plugin/marketplace.json

@@ -6,13 +6,32 @@
   "license": "MIT",
   "homepage": "https://github.com/bmad-code-org/bmad-method-test-architecture-enterprise",
   "repository": "https://github.com/bmad-code-org/bmad-method-test-architecture-enterprise",
-  "keywords": ["bmad", "test-architect", "testing", "quality", "automation", "playwright", "test-engineering"],
+  "keywords": [
+    "bmad",
+    "test-architect",
+    "test-engineering",
+    "testing",
+    "quality",
+    "quality-gates",
+    "risk-based-testing",
+    "verification-and-validation",
+    "traceability",
+    "nfr",
+    "test-automation",
+    "automation",
+    "contract-testing",
+    "pact",
+    "playwright",
+    "cypress",
+    "mobile",
+    "maestro"
+  ],
   "plugins": [
     {
       "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.21.6",
+      "version": "1.21.7",
       "author": {
         "name": "Murat K Ozcan (TEA Creator) & Brian (BMad) Madison"
       },

package/CHANGELOG.md

@@ -7,7 +7,23 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
-### Added
+### Fixed
+
+- Aligned forced-unscorable candidate handling in `cli/lib/build-prompt.js` and `cli/lib/parse-report.js`: candidates without matching criteria rows are removed from `## Reviewed Files` when excluded in `## Excluded From Review Set`. Added end-to-end stub-agent coverage in `test/test-test-review-cli.js`.
+- Corrected shared-account guidance in `mobile-test-strategy.md` to recommend per-run accounts/data or explicit backend reset when server state changes.
+- Added `clearKeychain` between `clearState` and `launchApp` in `maestro-flows.md` login setup across all workflow copies.
+- Fixed mobile preflight HALT condition in `bmad-testarch-automate` so missing `maestro` on PATH records run as non-executable without halting.
+- Aligned mobile worker success contract across automation subagent, generation, and aggregate steps by adding required `success` boolean to mobile schema and validating it before aggregation.
+- Updated generated mobile flow guidance to require `clearState` only for device-flow entries, keeping subflows from resetting or relaunching mid-journey.
+- Resolved Maestro root directory (`maestro/` or `.maestro/`) and propagated it across generation, scaffolding, and CI pipeline steps.
+- Added Mobile framework verification branch to CI preflight step.
+- Replaced unpinned Maestro curl installer in CI pipeline generation with release-pinned or checksum-verified immutable artifact.
+- Added Mobile prerequisite and context loading branches to framework preflight step, and updated mobile+backend surface handling across framework and test-design workflows.
+- Reordered framework scaffold knowledge loading so mobile projects skip Playwright browser fragments, and aligned Maestro config and flow paths.
+- Updated Flutter detection in `pubspec.yaml` to require Flutter SDK dependency or platform project directory before classifying as mobile, recognized `*.flow.yml` in Maestro review triggers, and skipped DOM `selector-resilience` for mobile reviews.
+- Added `mobile` and `maestro` keywords to `package.json` and `.claude-plugin/marketplace.json`.
+- Updated `src/module.yaml`, `docs/explanation/tea-overview.md`, `docs/index.md`, `docs/reference/execution-targets.md`, and `docs/reference/knowledge-base.md` to align mobile native (Maestro) execution targets, tier dimensions, and knowledge fragment loading contracts.
+- Normalized the `test-review` checklist's Recommendation vocabulary to the canonical four-value enum (`checklist.md`).
 
 - New `tea-test-review` CLI (`bin` entry) — headless runner for the `bmad-testarch-test-review` skill: changed-test scoping from the PR diff (`--base`, or an explicit `--files` list), prompt-only mode (`--agent none`), JSON verdict (`--json`), and CI exit codes (`--fail-on request-changes|block`). Hardened for required-gate use: stdin-delivered prompt, filesystem isolation (`--isolate`, on by default in CI, `--no-isolate` to opt out), extra test-file matchers (`--test-glob`), a quality-score floor (`--min-score`), non-pass on skips (`--fail-on-skip`) and deletions-only diffs, and strict report validation (dual-section Recommendation, bounded score, violations line, frontmatter, and a `## Reviewed Files` manifest). Ships with `cli/examples/pr-test-review.yml`, a two-job (review + comment) starting template for a required test-review gate, plus `cli/examples/README.md` covering two real adaptations: a central reusable-workflows repo, and a repo already running a third-party review bot.
 - `tea-test-review` is no longer Claude-only: `--agent` resolves against a per-vendor adapter table (`cli/lib/agent-adapters.js`) instead of hardcoding `claude -p`'s argv at every call site `--agent-cmd` could override. `--agent codex` spawns `codex exec --sandbox workspace-write`, live-verified with a real review against a real Playwright spec (`codex-cli` 0.146.0) whose report `parseReport()` accepted; that run wrote Key Strengths/Weaknesses as plain bullets instead of the `✅`/`❌`-prefixed form claude reliably produces, which the existing best-effort extraction already tolerates by design (`plain-bullets-key-strengths.md` fixture). A drafted `--agent gemini` adapter was not shipped: this account's `gemini` CLI OAuth login is on a deprecated Code Assist tier with no fallback API key configured, so it was never verified end-to-end.
@@ -42,8 +58,6 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 - Publish releases now use `[Unreleased]` changelog notes before falling back to generated GitHub release notes when an exact version section is missing.
 - Documented workflow-local knowledge resources as intentional self-contained skill packaging and added validation for workflow-local knowledge indexes.
 
-### Fixed
-
 - Normalized the `test-review` checklist's Recommendation vocabulary to the canonical four-value enum (`checklist.md`).
 - `test-review` score aggregation now emits a CRITICAL severity tier (`step-03f`), mapped to the report's `Critical Issues (Must Fix)` section, matching the template's four-tier violations line; `generate_inline_comments` is now a defined workflow input (default `false`) instead of an unresolved reference in the checklist.
 - `test-review` reports now carry a machine-readable `## Reviewed Files` manifest section in `test-review-template.md`, and every step's first-save frontmatter snippet declares `workflowType: 'testarch-test-review'`. A report produced from the template alone now satisfies the headless verdict schema, so a clean review can no longer be reported as a parse failure when the agent follows the template rather than prompt prose.

package/README.md

@@ -1,18 +1,21 @@
 # Test Architect (TEA)
 
-[![Python Version](https://img.shields.io/badge/python-%3E%3D3.10-blue?logo=python&logoColor=white)](https://www.python.org)
-[![uv](https://img.shields.io/badge/uv-package%20manager-blueviolet?logo=uv)](https://docs.astral.sh/uv/)
+[![Node Version](https://img.shields.io/badge/node-%3E%3D20-brightgreen?logo=node.js&logoColor=white)](https://nodejs.org)
+[![License: MIT](https://img.shields.io/badge/license-MIT-blue)](./LICENSE)
 
 TEA (Test Engineering Architect) is a standalone BMAD module that delivers risk-based test strategy, test automation guidance, and release gate decisions. It provides a single expert agent (Murat, Master Test Architect and Quality Advisor) and nine workflows spanning Teach Me Testing (TEA Academy), test design, framework setup, CI guidance, ATDD, automation, test review, NFR Evidence Audit, and traceability.
 
+TEA is two layers. **TEA Core** decides what must be verified, at what depth, with what evidence, and whether that evidence is sufficient to release; it assumes nothing about your language, framework, or platform. **Execution targets** turn those decisions into runnable tests on a specific stack, and that layer is swappable. See [Verification Architecture](./docs/explanation/verification-architecture.md) for the split, and [Execution Targets](./docs/reference/execution-targets.md) for exactly which stacks are covered at which depth.
+
 Docs: <https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/>
 
 ## Why TEA
 
-- Risk-based testing with measurable quality gates
-- Consistent, knowledge-base driven outputs
-- Clear prioritization (P0-P3) and traceability
-- Optional Playwright Utils, CLI, and MCP browser automation
+- Risk-based prioritization (P0-P3) from probability × impact, with measurable quality gates
+- Requirements traced to evidence, and PASS / CONCERNS / FAIL / WAIVED release decisions that survive an audit
+- NFR thresholds set at design time and audited against real evidence, defaulting to CONCERNS when evidence is missing
+- Consistent, knowledge-base driven outputs instead of whatever the model felt like producing
+- Stack-aware execution: Playwright and Cypress for browsers, Maestro for mobile native, Pact for contracts, pytest / JUnit / Go test / xUnit / RSpec for backend services, k6 and scanners as NFR evidence
 
 ## How BMad Works
 
@@ -80,7 +83,7 @@ BMad workflows and Claude Code Skills solve different problems at different scal
 | ----------------- | --------------------------- | ---------------------------------------------------------------------------- |
 | **Execution**     | Single prompt, one shot     | 5-9 sequential steps with explicit handoffs                                  |
 | **State**         | Stateless                   | YAML frontmatter tracking (`stepsCompleted`, `lastStep`) with resume         |
-| **Knowledge**     | Whatever fits in one prompt | Tiered index (40 fragments), conditional loading by config + stack detection |
+| **Knowledge**     | Whatever fits in one prompt | Tiered index (54 fragments), conditional loading by config + stack detection |
 | **Context mgmt**  | Everything in one shot      | Just-in-time step loading, subagent isolation (separate contexts)            |
 | **Output**        | Freeform                    | Templates with `{PLACEHOLDER}` vars filled by specific steps                 |
 | **Validation**    | None                        | Dedicated mode (`steps-v/`) evaluating against checklists                    |
@@ -137,17 +140,17 @@ npx bmad-method install
 
 ## Workflows
 
-| Trigger | Slash Command                | Codex Skill                      | Purpose                                                   |
-| ------- | ---------------------------- | -------------------------------- | --------------------------------------------------------- |
-| TMT     | `/bmad:tea:teach-me-testing` | `$bmad-tea-teach-me-testing`     | Teach Me Testing (TEA Academy)                            |
-| TD      | `/bmad:tea:test-design`      | `$bmad-tea-testarch-test-design` | System-level or epic-level test design and NFR planning   |
-| TF      | `/bmad:tea:framework`        | `$bmad-tea-testarch-framework`   | Scaffold test framework (frontend, backend, or fullstack) |
-| CI      | `/bmad:tea:ci`               | `$bmad-tea-testarch-ci`          | Set up CI/CD quality pipeline (multi-platform)            |
-| AT      | `/bmad:tea:atdd`             | `$bmad-tea-testarch-atdd`        | Generate failing acceptance tests + checklist             |
-| TA      | `/bmad:tea:automate`         | `$bmad-tea-testarch-automate`    | Expand test automation coverage                           |
-| RV      | `/bmad:tea:test-review`      | `$bmad-tea-testarch-test-review` | Review test quality and score                             |
-| NR      | `/bmad:tea:nfr-assess`       | `$bmad-tea-testarch-nfr`         | Audit implemented NFR evidence                            |
-| TR      | `/bmad:tea:trace`            | `$bmad-tea-testarch-trace`       | Trace requirements to tests + gate decision               |
+| Trigger | Slash Command                | Codex Skill                      | Purpose                                                           |
+| ------- | ---------------------------- | -------------------------------- | ----------------------------------------------------------------- |
+| TMT     | `/bmad:tea:teach-me-testing` | `$bmad-tea-teach-me-testing`     | Teach Me Testing (TEA Academy)                                    |
+| TD      | `/bmad:tea:test-design`      | `$bmad-tea-testarch-test-design` | System-level or epic-level test design and NFR planning           |
+| TF      | `/bmad:tea:framework`        | `$bmad-tea-testarch-framework`   | Scaffold test framework (frontend, backend, fullstack, or mobile) |
+| CI      | `/bmad:tea:ci`               | `$bmad-tea-testarch-ci`          | Set up CI/CD quality pipeline (multi-platform)                    |
+| AT      | `/bmad:tea:atdd`             | `$bmad-tea-testarch-atdd`        | Generate failing acceptance tests + checklist                     |
+| TA      | `/bmad:tea:automate`         | `$bmad-tea-testarch-automate`    | Expand test automation coverage                                   |
+| RV      | `/bmad:tea:test-review`      | `$bmad-tea-testarch-test-review` | Review test quality and score                                     |
+| NR      | `/bmad:tea:nfr-assess`       | `$bmad-tea-testarch-nfr`         | Audit implemented NFR evidence                                    |
+| TR      | `/bmad:tea:trace`            | `$bmad-tea-testarch-trace`       | Trace requirements to tests + gate decision                       |
 
 ## Configuration
 
@@ -158,8 +161,8 @@ TEA variables are defined in `src/module.yaml` and prompted during install:
 - `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_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)
-- `test_stack_type` — detected or configured stack type (frontend, backend, fullstack)
+- `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)
 - `ci_platform` — CI platform (auto, github-actions, gitlab-ci, jenkins, azure-devops, harness, circle-ci)
 - `risk_threshold` — risk cutoff for mandatory testing (future)
 - `test_design_output`, `test_review_output`, `trace_output` — subfolders under `test_artifacts`

package/cli/lib/build-prompt.js

@@ -51,9 +51,13 @@ const { MODULE_DEFAULTS } = require('./resolve-tea-config');
  *   waive. When supplied, the report must quote it so a reader knows what
  *   steered the review.
  * @param {string[]} [options.unscorableTestArtifacts] - Changed test artifacts in
- *   a format the ledger has no criteria for (Maestro flows, Gherkin features,
+ *   a format the ledger has no criteria for (Gherkin features, Robot suites,
  *   .http collections). The CLI computes these; the report discloses them so a
  *   manifest that omits them never reads as "the diff held nothing else".
+ * @param {string[]} [options.forcedUnscorableCandidates] - Review-set files that
+ *   only --test-glob put there and that no built-in rule recognizes. The CLI
+ *   cannot know whether a registry row attached, so it names them and the agent
+ *   applies criteria-registry rule 4 rather than publishing 100 - 0 = 100.
  * @returns {string}
  */
 function buildPrompt({
@@ -67,6 +71,7 @@ function buildPrompt({
   contextBasis = 'none',
   focus = '',
   unscorableTestArtifacts = [],
+  forcedUnscorableCandidates = [],
 }) {
   const absoluteSkillRoot = path.resolve(skillRoot);
   const absoluteOutputPath = path.resolve(outputPath);
@@ -152,6 +157,24 @@ function buildPrompt({
           '',
         ]
       : []),
+    ...(forcedUnscorableCandidates.length > 0
+      ? [
+          'The paths listed below are in the review set only because --test-glob put them there, and no built-in rule',
+          'recognizes their format. Apply criteria-registry rule 4 to each one: read it, and determine whether any',
+          'registry row can attach to its syntax at all.',
+          '- If rows attach, review and score it normally. Nothing further is required.',
+          '- If NO row can attach, the file is unscorable. Do not score it, do not let it contribute to the total,',
+          '  remove it from "## Reviewed Files", and name it in "## Excluded From Review Set" with the reason',
+          '  "format not scorable by the ledger". Say plainly in the Executive Summary that --test-glob forced it in',
+          '  and the ledger has no criteria for its format.',
+          'A gate closed because the registry lacks a rule is not the same as a gate that opened and found nothing.',
+          'Publishing 100/Approve over a file no criterion could read is a defect in the review, not a clean result.',
+          '---BEGIN FORCED-UNSCORABLE-CANDIDATES---',
+          JSON.stringify(forcedUnscorableCandidates, null, 2),
+          '---END FORCED-UNSCORABLE-CANDIDATES---',
+          '',
+        ]
+      : []),
     ...(focus
       ? [
           'The requester left a focus note for this run, inside the delimiters below. It is their stated priority for',

package/cli/lib/changed-tests.js

@@ -27,6 +27,14 @@ const TEST_DIR_SEGMENTS = new Set(['test', 'tests', '__tests__', 'e2e', 'spec',
 // so fixtures like tests/data.json or e2e/docker-compose.yaml stay out.
 const CODE_EXTENSION_PATTERN = /\.(ts|tsx|js|jsx|mjs|cjs|py|go|rb|php|cs|java|kt|swift|rs|dart|exs|ex|vue|svelte)$/;
 
+// Maestro flows are declarative YAML, not code, but the criteria registry carries
+// mobile rows for them, so they are a scorable format and belong in the review set.
+const MAESTRO_DIR_SEGMENTS = new Set(['maestro', '.maestro']);
+const YAML_EXTENSION_PATTERN = /\.ya?ml$/i;
+const MAESTRO_FLOW_FILENAME_PATTERN = /\.flow\.ya?ml$/i;
+// .maestro/config.yaml is the workspace config, not a flow.
+const MAESTRO_NON_FLOW_FILENAMES = new Set(['config.yaml', 'config.yml']);
+
 const TEST_FILENAME_PATTERNS = [
   /^test_.*\.py$/, // pytest: test_checkout.py
   /_test\.py$/, // pytest: checkout_test.py
@@ -83,23 +91,32 @@ function resetExtraTestPatterns() {
 }
 
 /**
- * Match a repo-relative path that looks like a test/spec file. Directory
- * segments match case-insensitively but only on exact segment equality (so
- * src/latest/run.ts and src/test-utils/helpers.ts stay out). Every built-in
- * rule requires a code extension, so docs/example.spec.md is documentation,
- * not a test. Registered --test-glob matchers bypass the extension gate by
- * explicit user intent.
+ * Match a repo-relative path that looks like a test/spec file using the built-in
+ * rules only, ignoring the --test-glob registry. Directory segments match
+ * case-insensitively but only on exact segment equality (so src/latest/run.ts and
+ * src/test-utils/helpers.ts stay out).
+ *
+ * Code extensions are the general gate, so docs/example.spec.md is documentation,
+ * not a test. Maestro is the one deliberate exception: the criteria registry
+ * carries mobile rows (C4, H1, H3, H4, H9, M8, L8), so a declarative YAML flow is
+ * a format the ledger CAN score and it is recognized natively rather than needing
+ * --test-glob. The exception is scoped to YAML under a Maestro directory (or a
+ * *.flow.yaml anywhere) and excludes Maestro's own workspace config, which is
+ * configuration rather than a flow.
  *
  * @param {string} filePath - Repo-relative file path.
  * @returns {boolean}
  */
-function isTestFile(filePath) {
+function isNativeTestFile(filePath) {
   const segments = filePath.replaceAll('\\', '/').split('/');
   const filename = segments.at(-1);
   const directories = segments.slice(0, -1);
 
-  for (const matches of extraTestPatterns) {
-    if (matches(filePath)) {
+  if (YAML_EXTENSION_PATTERN.test(filename) && !MAESTRO_NON_FLOW_FILENAMES.has(filename.toLowerCase())) {
+    if (directories.some((segment) => MAESTRO_DIR_SEGMENTS.has(segment.toLowerCase()))) {
+      return true;
+    }
+    if (MAESTRO_FLOW_FILENAME_PATTERN.test(filename)) {
       return true;
     }
   }
@@ -115,6 +132,47 @@ function isTestFile(filePath) {
   return TEST_FILENAME_PATTERNS.some((pattern) => pattern.test(filename));
 }
 
+/**
+ * Match a repo-relative path that belongs in the review set. Registered
+ * --test-glob matchers bypass every gate by explicit user intent; everything
+ * else goes through the built-in rules.
+ *
+ * @param {string} filePath - Repo-relative file path.
+ * @returns {boolean}
+ */
+function isTestFile(filePath) {
+  for (const matches of extraTestPatterns) {
+    if (matches(filePath)) {
+      return true;
+    }
+  }
+
+  return isNativeTestFile(filePath);
+}
+
+/**
+ * Review-set files that are present ONLY because --test-glob forced them in and
+ * that no built-in rule recognizes as a scorable format.
+ *
+ * This is the gap that used to produce a silent perfect score. A --test-glob
+ * match short-circuits isTestFile, which removes the file from the unscorable
+ * manifest, and if the registry then has no row that can attach to its syntax the
+ * arithmetic runs 100 - 0 and publishes 100/Approve with no findings and no
+ * disclosure. The CLI cannot know which criteria attached, so it does not guess:
+ * it names these files to the agent, which applies criteria-registry rule 4 and
+ * declines to score a file no row could match.
+ *
+ * @param {string[]} reviewFiles - The computed review set.
+ * @returns {string[]}
+ */
+function getForcedUnscorableCandidates(reviewFiles) {
+  return (Array.isArray(reviewFiles) ? reviewFiles : []).filter((file) => {
+    if (typeof file !== 'string' || file.length === 0) return false;
+    if (isNativeTestFile(file)) return false;
+    return extraTestPatterns.some((matches) => matches(file));
+  });
+}
+
 /**
  * Split NUL-delimited `git diff -z` stdout into paths. Git paths are passed
  * through untouched (no trimming): leading/trailing whitespace can be part of
@@ -185,15 +243,18 @@ function isContextNoise(filePath) {
   return segments.slice(0, -1).some((segment) => CONTEXT_NOISE_DIR_SEGMENTS.has(segment.toLowerCase()));
 }
 
-// Test artifacts written in a format isTestFile deliberately will not match,
-// because every built-in rule requires a code extension. A Maestro flow, a
-// Gherkin feature, a Robot suite or an .http collection is a test the reviewer
-// cannot score, and staying silent about it reads as "there was nothing else to
-// review". These only ever produce a disclosure line and a --test-glob hint;
-// they never enter the review set on their own, since scoring a format the
+// Test artifacts written in a format the built-in rules deliberately will not
+// match. A Gherkin feature, a Robot suite or an .http collection is a test the
+// reviewer cannot score, and staying silent about it reads as "there was nothing
+// else to review". These only ever produce a disclosure line and a --test-glob
+// hint; they never enter the review set on their own, since scoring a format the
 // ledger has no criteria for would be worse than declining it.
+//
+// Maestro is deliberately absent from this set: the criteria registry now carries
+// mobile rows, so a Maestro flow is scorable and isNativeTestFile claims it before
+// it can reach here. Only Maestro's workspace config stays out, and it is
+// configuration rather than a test artifact, so it should not be disclosed either.
 const NON_CODE_TEST_DIR_SEGMENTS = new Set([
-  'maestro',
   'cypress',
   'playwright',
   'features',
@@ -401,10 +462,12 @@ module.exports = {
   getChangedTestFiles,
   getContextFiles,
   getUnscorableTestArtifacts,
+  getForcedUnscorableCandidates,
   getDeletedFiles,
   getDeletedTestFiles,
   contextBasisFor,
   isTestFile,
+  isNativeTestFile,
   isContextNoise,
   splitGitPathList,
   assertSafePaths,

package/cli/lib/parse-report.js

@@ -456,7 +456,7 @@ function verifyRunContract({ reviewedFiles, contextBasis, contextFiles, excluded
 
   if (has('reviewedFiles')) {
     const suppliedReviewed = canonicalizeManifest(runContract.reviewedFiles, 'supplied reviewed files');
-    const missing = manifestDifference(suppliedReviewed, reviewedFiles);
+    const missing = manifestDifference(suppliedReviewed, reviewedFiles).filter((file) => !excludedFiles.includes(file));
     const foreign = manifestDifference(reviewedFiles, suppliedReviewed);
     if (missing.length > 0 || foreign.length > 0) {
       unparseable(

package/cli/test-review.js

@@ -37,6 +37,7 @@ const {
   getChangedTestFiles,
   getContextFiles,
   getUnscorableTestArtifacts,
+  getForcedUnscorableCandidates,
   getDeletedTestFiles,
   contextBasisFor,
   isTestFile,
@@ -462,8 +463,8 @@ function main() {
   let changedTestFiles;
   let contextFiles = [];
   let contextTruncated = false;
-  // Changed test artifacts the ledger has no criteria for (Maestro flows,
-  // Gherkin features, .http collections). They stay out of the review set, but
+  // Changed test artifacts the ledger has no criteria for (Gherkin features,
+  // Robot suites, .http collections). They stay out of the review set, but
   // a reviewed-files manifest that simply omits them reads as though the diff
   // held nothing else, so they are disclosed and carry the --test-glob remedy.
   let unscorableTestArtifacts = [];
@@ -484,6 +485,11 @@ function main() {
   }
   const contextBasis = contextBasisFor({ files: contextFiles, truncated: contextTruncated });
 
+  // Files --test-glob forced in that no built-in rule recognizes. The CLI cannot
+  // tell whether a registry row attached, so it names them to the agent rather
+  // than letting a zero-violation run publish 100/Approve over an unread format.
+  const forcedUnscorableCandidates = getForcedUnscorableCandidates(changedTestFiles);
+
   // Fail closed on hostile paths before they reach the prompt (or anywhere
   // else). Context paths travel in their own delimited block and get the same
   // treatment as the review set.
@@ -559,6 +565,7 @@ function main() {
       contextBasis,
       focus: options.focus,
       unscorableTestArtifacts,
+      forcedUnscorableCandidates,
     });
     console.log(prompt);
     if (jsonPath) {
@@ -665,6 +672,7 @@ function main() {
     contextBasis,
     focus: options.focus,
     unscorableTestArtifacts,
+    forcedUnscorableCandidates,
   });
 
   const executeAgent = ({ agentCwd, spawnPrefix }) => {

package/docs/explanation/tea-overview.md

@@ -9,6 +9,10 @@ The Test Architect (TEA) is a specialized agent focused on quality strategy, tes
 TEA was built to solve AI-generated tests that rot in review. For the problem statement and design principles, see [Testing as Engineering](/docs/explanation/testing-as-engineering.md). For setup, see [Setup Test Framework](/docs/how-to/workflows/setup-test-framework.md).
 :::
 
+:::note[Scope]
+TEA's risk, design, NFR, traceability, and gate workflows are stack-neutral and apply to any system under test. Its execution depth is not uniform: browsers, HTTP services, contracts, and mobile native (Maestro) are covered end to end, while other stacks are covered at shallower tiers. [Verification Architecture](/docs/explanation/verification-architecture.md) explains the split; [Execution Targets](/docs/reference/execution-targets.md) publishes the per-target matrix and the known gaps.
+:::
+
 ## Overview
 
 - **Persona:** Murat, Master Test Architect and Quality Advisor focused on risk-based testing, fixture architecture, ATDD, and CI/CD governance.

package/docs/explanation/testing-as-engineering.md

@@ -1,6 +1,6 @@
 ---
 title: 'AI-Generated Testing: Why Most Approaches Fail'
-description: How Playwright-Utils, pactjs-utils, TEA workflows, Playwright CLI, and MCPs solve AI test quality problems
+description: Why prompt-driven test generation produces unreliable suites, and how standardized utilities, structured workflows, and deterministic interfaces fix it (worked through a JavaScript stack)
 ---
 
 AI-generated tests frequently fail in production because they lack systematic quality standards. This document explains the problem and presents a solution combining utility standards, TEA workflows, and automation interfaces across both UI, API and contract testing.

package/docs/explanation/verification-architecture.md

@@ -0,0 +1,129 @@
+---
+title: 'Verification Architecture'
+description: How TEA separates stack-neutral verification reasoning from stack-specific execution, which execution targets are covered today, and how to extend it
+---
+
+# Verification Architecture
+
+TEA is two layers, and they have different lifespans.
+
+**TEA Core** decides what must be verified, at what depth, with what evidence, and whether that evidence is sufficient to release. It holds no assumption about language, framework, or platform.
+
+**Execution targets** turn those decisions into runnable tests on one specific stack. This layer is technology-specific by design and is meant to be swapped as your stack changes.
+
+Read the second layer on its own and TEA looks like a browser-testing tool, because that is where its deepest coverage happens to sit today. The verification reasoning is the durable part. This page states what is in each layer, publishes TEA's actual coverage including the gaps, and describes how to extend it.
+
+```mermaid
+flowchart TB
+  subgraph CORE["TEA Core: stack-neutral"]
+    R[Risk model<br/>probability x impact, P0-P3]
+    L[Test level selection<br/>+ duplicate coverage guard]
+    N[NFR criteria<br/>+ gate decision matrix]
+    T[Requirements to evidence<br/>traceability]
+    G[Gate decision<br/>PASS / CONCERNS / FAIL / WAIVED]
+  end
+  CORE --> X{Execution target}
+  X --> W[Web browser<br/>Playwright, Cypress]
+  X --> A[HTTP service and contract<br/>Pact, API suites]
+  X --> M[Mobile native<br/>Maestro]
+  X --> B[Backend unit and integration<br/>pytest, JUnit, Go test, xUnit, RSpec]
+  X --> O[Your target<br/>desktop, embedded, data]
+  W --> E[Evidence]
+  A --> E
+  M --> E
+  B --> E
+  O --> E
+  E --> G
+```
+
+## The two layers
+
+|                     | TEA Core                                                                         | Execution target                                                             |
+| ------------------- | -------------------------------------------------------------------------------- | ---------------------------------------------------------------------------- |
+| Question it answers | What must be verified, and is the evidence sufficient to ship?                   | How is it verified on this stack?                                            |
+| Changes when        | Risk appetite, compliance regime, or release policy changes                      | Language, framework, or platform changes                                     |
+| Stability           | Durable across a rewrite                                                         | Replaced by a rewrite                                                        |
+| Owned by            | TEA                                                                              | TEA for supported targets; you for the rest                                  |
+| Examples            | Risk scoring, P0-P3, level selection, NFR criteria, traceability, gate decisions | Playwright, Cypress, Maestro, pytest, JUnit, Go test, xUnit, RSpec, Pact, k6 |
+
+## What TEA Core contains
+
+Core is the part an enterprise is actually buying, and it is stack-neutral in construction rather than by assertion:
+
+- **Risk model.** Probability × impact on a 1-9 scale, with scores ≥6 requiring documented mitigation and 9 mandating gate failure. See [Risk-Based Testing](/docs/explanation/risk-based-testing.md).
+- **Priority assignment.** P0-P3 with coverage targets and execution ordering per band.
+- **Test level selection.** Unit, integration, and end-to-end chosen by what the risk actually demands, with a duplicate-coverage guard that pushes verification to the cheapest level that can carry it.
+- **NFR criteria and gate matrix.** Security, performance, reliability, and maintainability scored PASS / CONCERNS / FAIL, defaulting to CONCERNS when targets or evidence are undefined.
+- **Requirements-to-evidence traceability.** Every acceptance criterion maps to evidence; gaps require an explicit waiver with an owner and an expiry date.
+- **Release gate decision.** PASS / CONCERNS / FAIL / WAIVED, derived from the traceability matrix rather than from a person's confidence.
+- **Architecture testability review.** An 8-category, 29-criteria audit applied at design time, before any test exists.
+- **Confidence gate.** A stop rule for the agent itself: below a confidence threshold it declines to generate rather than inventing plausible output.
+
+Two of TEA's nine workflows, `nfr-assess` and `trace`, contain no stack-conditional logic at any step. They run identically whether the system under test is a React app, a Go service, or a payment terminal. The risk and priority knowledge fragments reference no test framework at all.
+
+## What an execution target supplies
+
+An execution target is the set of technology-specific answers TEA needs before it can produce runnable tests. Six things:
+
+1. **Detection.** The manifest or file signature that identifies the stack.
+2. **Project layout.** Where tests live, and the idiomatic directory structure.
+3. **Runner configuration.** The config file, its timeouts, reporters, and artifact paths.
+4. **Commands.** Install, test, coverage, and the shard or filter syntax CI needs.
+5. **CI wiring.** Runtime setup, caching, and whether burn-in applies.
+6. **Review criteria.** Rows the test-review ledger can attach to that format.
+
+Item six is the one that decides whether a target is genuinely supported. `test-review` scores against a criteria registry, and a format with no matching rows is one TEA cannot honestly score. When TEA encounters a test artifact it has no criteria for, the correct behavior is to name it as unscorable rather than to return a passing grade over a file it could not read.
+
+## Coverage today
+
+TEA's execution coverage is uneven, and the uneven part is deliberate to state rather than to imply. Full detail is in [Execution Targets](/docs/reference/execution-targets.md). The summary:
+
+| Tier           | What it means                                                                                         | Targets                                                                                                                      |
+| -------------- | ----------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- |
+| **Full**       | Workflow branching, scaffolding, knowledge fragments, and review criteria                             | Web browser (Playwright, Cypress), mobile native (Maestro), HTTP and service tests, contract testing (Pact), component tests |
+| **Generation** | Detection, scaffolding, and test generation, with no dedicated knowledge fragments or review criteria | pytest, JUnit 5 / TestNG, Go test, xUnit / NUnit / MSTest, RSpec / Minitest                                                  |
+| **Evidence**   | TEA plans, requires, and audits the evidence; execution is your tooling                               | Performance (k6, JMeter, Gatling), security scanning (ZAP, Burp, Snyk), message contracts                                    |
+| **Core only**  | Risk, design, NFR, and traceability apply; execution is unassisted                                    | Desktop, embedded, data pipelines, mainframe                                                                                 |
+
+### The self-audit
+
+Of TEA's 54 knowledge fragments, 38 name Playwright or Cypress. Two 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.
+
+## What this means for your project
+
+**JavaScript or TypeScript web and API.** Every layer applies. This is the deepest path and the one the tutorials use.
+
+**Backend services in Python, Java, Go, .NET, or Ruby.** Planning, risk, design, NFR, traceability, and gating apply in full. Framework scaffolding and test generation work and are stack-aware. Review scoring is partial, because most registry criteria are written against JavaScript and browser constructs. Expect strong plans and generated tests that follow your project's conventions rather than a curated TEA pattern library.
+
+**Mobile native (iOS, Android, React Native, Expo, Flutter).** Every layer applies. `mobile` is a first-class stack type: TEA detects it, scaffolds a Maestro suite alongside the app's own unit and component framework, generates flows through a dedicated worker, produces a two-tier device pipeline, and scores flows against mobile criteria rows in the review ledger.
+
+**Desktop, embedded, data pipelines, and anything else.** Core applies without modification, and this is not a technicality: risk scoring, level selection, NFR thresholds, traceability, and the gate decision are the majority of what a test architect does, and none of it depends on the runner. Execution is unassisted. TEA will not scaffold the framework, and `test-review` will decline to score test formats it has no criteria for rather than passing them.
+
+The honest boundary is this: TEA's reasoning transfers to any stack today. TEA's execution depth does not, and the tiers above say exactly where it stops.
+
+## Extending TEA to a new execution target
+
+There is no plugin API for execution targets today. Extension happens through the surfaces TEA already exposes:
+
+- **Configuration.** Set `test_framework` and `test_stack_type` explicitly rather than letting detection run. See [Configuration](/docs/reference/configuration.md).
+- **Knowledge fragments.** Add fragments for your stack and register them in the knowledge index so workflows load them by tier and tag. See [Knowledge Base System](/docs/explanation/knowledge-base-system.md).
+- **Custom workflows.** Add stack-specific steps alongside the shipped ones. See [Extend TEA with Custom Workflows](/docs/how-to/customization/extend-tea-with-custom-workflows.md).
+
+Core requires no extension. Risk scoring, NFR criteria, traceability, and gate decisions apply to a new target on day one, which is why a stack TEA has never seen still produces a usable test plan.
+
+## Why the split matters under audit
+
+Regulated verification and validation asks a narrow question: was the evidence sufficient, and can you show the reasoning that decided it was. The answer has to survive a framework migration, because the systems being audited outlive their test tooling.
+
+Separating the layers makes that answerable. The risk score, the priority, the required evidence, the traceability matrix, and the gate decision are all recorded independently of the tool that produced the evidence. Replacing Cypress with Playwright, or Playwright with a device farm, changes which artifacts satisfy a requirement. It does not change the requirement, its risk score, or the standard the gate holds it to.
+
+An organization adopting TEA is standardizing the first layer. The second layer stays whatever each team already runs.
+
+## Related
+
+- [Execution Targets](/docs/reference/execution-targets.md) - per-target support detail
+- [TEA Overview](/docs/explanation/tea-overview.md) - the full workflow map
+- [Risk-Based Testing](/docs/explanation/risk-based-testing.md) - the scoring model in Core
+- [Use TEA for Enterprise](/docs/how-to/brownfield/use-tea-for-enterprise.md) - compliance evidence and audit trails

package/docs/index.md

@@ -9,10 +9,15 @@ description: Test Architect (TEA) - Risk-based testing workflows, automation gui
 
 TEA (Test Engineering Architect) is a BMAD module for testing strategy and automation. It provides nine workflows covering learning, setup, design, automation, review, and release gates.
 
-- **Workflow‑Driven**: Multiple workflows covering covering day to day activities of a test architect.
+- **Workflow‑Driven**: Multiple workflows covering day-to-day activities of a test architect.
 - **Consistent Outputs**: Knowledge-base guidance keeps standards consistent, no matter the agent being used.
 - **Risk‑Based**: P0–P3 prioritization from probability × impact.
 - **Release Gates**: Evidence‑backed go/no‑go decisions with traceability.
+- **Two Layers**: Stack-neutral verification reasoning, plus swappable execution targets. See [Verification Architecture](/explanation/verification-architecture).
+
+## What TEA Works On
+
+Risk assessment, test design, NFR planning, traceability, and release gates apply to any stack. Execution depth varies: browsers, HTTP services, and contracts are covered end to end; Python, Java, Go, .NET, and Ruby backends get detection, scaffolding, and generation; performance and security are planned and audited rather than executed. [Execution Targets](/reference/execution-targets) publishes the full matrix, including the gaps.
 
 ## Quick Install
 

package/docs/reference/configuration.md

@@ -469,21 +469,25 @@ Detected or configured project stack type. Controls CI pipeline generation and f
 
 **Default:** `"auto"`
 
-**Options:** `"auto"` | `"frontend"` | `"backend"` | `"fullstack"`
+**Options:** `"auto"` | `"frontend"` | `"backend"` | `"fullstack"` | `"mobile"`
 
 **Purpose:** Determines stack-specific behavior:
 
-| Stack Type  | Behavior                                                                                                   |
-| ----------- | ---------------------------------------------------------------------------------------------------------- |
-| `auto`      | Auto-detect from project manifests (playwright.config, jest.config, etc.)                                  |
-| `frontend`  | Browser-based tests (Playwright/Cypress), browser install in CI, burn-in enabled                           |
-| `backend`   | API/unit tests (pytest, JUnit, Go test, Jest/Vitest, etc.), no browser install, burn-in skipped by default |
-| `fullstack` | Both frontend and backend tests, full CI pipeline                                                          |
+| Stack Type  | Behavior                                                                                                                              |
+| ----------- | ------------------------------------------------------------------------------------------------------------------------------------- |
+| `auto`      | Auto-detect from project manifests (playwright.config, jest.config, etc.)                                                             |
+| `frontend`  | Browser-based tests (Playwright/Cypress), browser install in CI, burn-in enabled                                                      |
+| `backend`   | API/unit tests (pytest, JUnit, Go test, Jest/Vitest, etc.), no browser install, burn-in skipped by default                            |
+| `fullstack` | Both frontend and backend tests, full CI pipeline                                                                                     |
+| `mobile`    | Native app: Maestro device flows plus the app's unit/component suite, no browser install, burn-in enabled and scoped to changed flows |
 
 **Affects Workflows:**
 
-- `ci` - Stack-conditional pipeline stages (browser install, burn-in)
+- `ci` - Stack-conditional pipeline stages (browser install, burn-in, device/emulator legs)
 - `framework` - Framework scaffold adapts to stack type
+- `automate` - Selects which generation workers launch (`mobile` runs the API worker plus the mobile worker)
+
+Detection checks mobile first: a React Native or Expo project carries `package.json` with react and would otherwise misdetect as `frontend`.
 
 **Example:**
 
@@ -535,9 +539,9 @@ Detected or configured test framework preference.
 
 **Default:** `"auto"`
 
-**Options:** `"auto"` | `"playwright"` | `"cypress"` | `"jest"` | `"vitest"` | `"pytest"` | `"junit"` | `"go-test"` | `"dotnet-test"` | `"rspec"` | `"other"`
+**Options:** `"auto"` | `"playwright"` | `"cypress"` | `"jest"` | `"vitest"` | `"pytest"` | `"junit"` | `"go-test"` | `"dotnet-test"` | `"rspec"` | `"maestro"` | `"other"`
 
-**Purpose:** Controls which test framework patterns TEA uses for code generation. When set to `"auto"`, TEA detects from project configuration files and manifests. Supports both frontend (Playwright, Cypress, Jest, Vitest) and backend (pytest, JUnit, Go test, dotnet test, RSpec) frameworks.
+**Purpose:** Controls which test framework patterns TEA uses for code generation. When set to `"auto"`, TEA detects from project configuration files and manifests. Supports frontend (Playwright, Cypress, Jest, Vitest), backend (pytest, JUnit, Go test, dotnet test, RSpec), and mobile native (Maestro) frameworks.
 
 **Affects Workflows:**