bmad-method-test-architecture-enterprise 1.27.3-next.8 → 2.0.0

package/.claude-plugin/marketplace.json

@@ -31,22 +31,23 @@
       "name": "bmad-method-test-architecture-enterprise",
       "source": "./",
       "description": "Master Test Architect module for quality strategy, test automation, CI/CD quality gates, and structured testing education. Part of the BMad Method ecosystem.",
-      "version": "1.27.3-next.8",
+      "version": "2.0.0",
       "author": {
         "name": "Murat K Ozcan (TEA Creator) & Brian (BMad) Madison"
       },
       "skills": [
-        "./src/agents/bmad-tea",
-        "./src/workflows/testarch/bmad-testarch-atdd",
-        "./src/workflows/testarch/bmad-testarch-automate",
-        "./src/workflows/testarch/bmad-testarch-ci",
-        "./src/workflows/testarch/bmad-testarch-evaluate",
-        "./src/workflows/testarch/bmad-testarch-framework",
-        "./src/workflows/testarch/bmad-testarch-nfr",
-        "./src/workflows/testarch/bmad-testarch-test-design",
-        "./src/workflows/testarch/bmad-testarch-test-review",
-        "./src/workflows/testarch/bmad-testarch-trace",
-        "./src/workflows/testarch/bmad-teach-me-testing"
+        "./skills/bmod-tea",
+        "./skills/bmad-tea",
+        "./skills/bmad-testarch-atdd",
+        "./skills/bmad-testarch-automate",
+        "./skills/bmad-testarch-ci",
+        "./skills/bmad-testarch-evaluate",
+        "./skills/bmad-testarch-framework",
+        "./skills/bmad-testarch-nfr",
+        "./skills/bmad-testarch-test-design",
+        "./skills/bmad-testarch-test-review",
+        "./skills/bmad-testarch-trace",
+        "./skills/bmad-teach-me-testing"
       ]
     }
   ]

package/README.md

@@ -8,8 +8,8 @@
 TEA is a standalone BMAD module that delivers risk-based test strategy, test automation guidance, and release gate decisions. It ships:
 
 - one expert agent, Murat, Master Test Architect and Quality Advisor
-- ten workflows spanning Teach Me Testing (TEA Academy), test design, framework setup, CI guidance, ATDD, automation, test review, NFR Evidence Audit, traceability, and Evaluate
-- a 36-row criteria registry that fixes the severity of every reviewable violation, so a score is a lookup rather than a judgment call
+- ten workflows spanning Teach Me Testing (TEA Academy), test design, framework setup, CI guidance, ATDD, automation, test review, NFR Evidence Audit, traceability, and Evaluate ([evaluate your first skill](https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/tutorials/evaluate-your-first-skill/))
+- a 35-row criteria registry that fixes the severity of every reviewable violation, so a score is a lookup rather than a judgment call
 - `tea-test-review`, a headless CLI that runs the review workflow as a CI gate with real exit codes
 - a write-time enforcement hook that blocks the mechanically decidable violations before they reach disk
 
@@ -50,7 +50,7 @@ TEA's answer is not a better prompt. It is to make the work repeatable at three
 
 ### The order you run things
 
-The ten workflows are a directed graph, not a menu. `src/module-help.csv` encodes it.
+The ten workflows are a directed graph, not a menu. `skills/bmod-tea/help/help.md` describes it, and the `bmad` skill reads it to recommend the next step.
 
 ```text
 Phase 3, solutioning, once per project
@@ -70,8 +70,6 @@ Phase 3 order matters and is deliberate: run `test-design` first so NFR evidence
 
 `test-design` is dual-mode. At system level it produces an architecture-facing document and a QA-facing one. Per epic it produces `test-design/test-design-epic-N.md`. `teach-me-testing` sits outside the lifecycle and runs once per learner.
 
-`module-help.csv`'s single `phase` column records the phase a workflow's catalog row is sequenced under (its `preceded-by`/`followed-by` chain), not every phase the workflow can run in. `test-design`'s row is `3-solutioning` because that is the chain the row encodes (`test-design` → `framework`); the epic-level Phase 4 invocation above has no dependency edges of its own and so gets no second row, only this prose.
-
 For the full lifecycle diagram including the BMad phases around TEA, see [TEA Overview](https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/explanation/tea-overview/).
 
 ### One epic, end to end
@@ -105,7 +103,7 @@ Critical Violations:     -{count} × 10
 High Violations:         -{count} × 5
 Medium Violations:       -{count} × 2
 Low Violations:          -{count} × 1
-Bonus (6 categories, each 0 or 5, max +30)
+Bonus (5 categories, each 0 or 5, max +25)
 Final Score:             clamped to 0-100     Grade: A ≥90, B ≥80, C ≥70, D ≥60, else F
 ```
 
@@ -134,7 +132,7 @@ That separation exists because it was measured. Two reviewers of the same four f
 | P0 at 100%, overall ≥ 80%, P1 between 80% and 89%               | **CONCERNS** |
 | Stakeholder-approved waiver with the complete approval contract | **WAIVED**   |
 
-Our epic finishes at P0 100%, P1 87%, overall 84%, so it gates at CONCERNS with the residual risk named rather than passing quietly. Two overlays can lower that result further and can never raise it: a requirement resting only on recorded live verification caps at CONCERNS, and a synthetic coverage oracle below high confidence does the same. WAIVED is never derived; a human sets it, and the artifact demands an approver, approval date, reason, expiry, monitoring plan, remediation owner, and fix target. The authoritative contract is in the [Traceability template](./src/workflows/testarch/bmad-testarch-trace/trace-template.md#waiver-details).
+Our epic finishes at P0 100%, P1 87%, overall 84%, so it gates at CONCERNS with the residual risk named rather than passing quietly. Two overlays can lower that result further and can never raise it: a requirement resting only on recorded live verification caps at CONCERNS, and a synthetic coverage oracle below high confidence does the same. WAIVED is never derived; a human sets it, and the artifact demands an approver, approval date, reason, expiry, monitoring plan, remediation owner, and fix target. The authoritative contract is in the [Traceability template](./skills/bmad-testarch-trace/trace-template.md#waiver-details).
 
 If the run is not gate-eligible at all, because evidence collection was waived, restricted, inaccessible, or deferred, TEA emits no decision rather than computing one on partial evidence.
 
@@ -146,11 +144,11 @@ BMad is a small **agent + workflow engine**. There is no external orchestrator;
 
 | File / Scope                                              | What it does                                                                                                 | When it loads                                                               |
 | --------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------- |
-| `src/agents/bmad-tea/SKILL.md`                            | Murat's activation sequence and critical actions; renders the `{agent.menu}` placeholder                     | First, activates the TEA agent                                              |
-| `src/agents/bmad-tea/customize.toml`                      | Agent customization surface: `[[agent.menu]]` items (code to skill), persona fields, persistent facts, hooks | During agent activation                                                     |
-| `src/workflows/testarch/<workflow>/SKILL.md`              | Workflow entrypoint: resolves workflow customization, picks mode, routes to the first step                   | When a TEA workflow is invoked                                              |
-| `src/workflows/testarch/<workflow>/customize.toml`        | Workflow customization surface: activation hooks, persistent facts, optional `on_complete` behavior          | During workflow activation                                                  |
-| `src/workflows/testarch/<workflow>/workflow.yaml`         | Machine-readable metadata: config bindings, run variables, tool hints, output paths                          | Installer, tooling, and workflow metadata lookups                           |
+| `skills/bmad-tea/SKILL.md`                                | Murat's activation sequence and critical actions; renders the `{agent.menu}` placeholder                     | First, activates the TEA agent                                              |
+| `skills/bmad-tea/customize.toml`                          | Agent customization surface: `[[agent.menu]]` items (code to skill), persona fields, persistent facts, hooks | During agent activation                                                     |
+| `skills/<workflow>/SKILL.md`                              | Workflow entrypoint: resolves workflow customization, picks mode, routes to the first step                   | When a TEA workflow is invoked                                              |
+| `skills/<workflow>/customize.toml`                        | Workflow customization surface: activation hooks, persistent facts, optional `on_complete` behavior          | During workflow activation                                                  |
+| `skills/<workflow>/workflow.yaml`                         | Machine-readable metadata: run variables, tool hints, output paths                                           | Tooling and workflow metadata lookups                                       |
 | `instructions.md`                                         | Workflow-specific summary and operator notes                                                                 | On demand                                                                   |
 | `steps-c/*.md`                                            | **Create** steps: primary execution, 5 to 12 files per workflow, 75 across the module                        | One at a time (just-in-time)                                                |
 | `steps-c/step-NNx-subagent-*.md`                          | **Worker** steps: one isolated dimension each, dispatched in parallel                                        | When an orchestrator step delegates                                         |
@@ -160,10 +158,13 @@ BMad is a small **agent + workflow engine**. There is no external orchestrator;
 | `*-template.md`                                           | Output skeleton with `{PLACEHOLDER}` vars, filled in by steps to produce the artifact                        | Read by steps-c when generating output                                      |
 | `bmad-testarch-test-review/steps-c/criteria-registry.md`  | The 35 scoreable rows, each with a fixed severity and gate class. Severity is read here                      | Read by every review worker before it scores anything                       |
 | `bmad-testarch-framework/resources/hooks/tea-enforce.cjs` | Project-level guardrail for mechanically decidable test-quality violations; framework Create scaffolds it    | Before writes, after writes or shell commands, and when an agent turn stops |
-| `resources/tea-index.csv`                                 | Knowledge fragment index: id, name, description, tags, tier, path. 59 rows                                   | Read before recommendations and by knowledge-loading steps                  |
-| `resources/knowledge/*.md`                                | 59 reusable fragments: standards, patterns, API references, integration mandates                             | Selectively read into context by tier and config flags                      |
+| `skills/bmod-tea/bmod.toml`                               | Module record: version, member skills, setup questions, install messages                                     | Read by `bmad setup tea` and `bmad`                                         |
+| `skills/bmod-tea/roster.toml`                             | Lists Murat as the module's agent                                                                            | Read by roster-aware skills such as party mode                              |
+| `skills/bmod-tea/help/*.md`                               | What each TEA skill is for, when to recommend it, and what each setup answer does                            | Read by the `bmad` skill when routing                                       |
+| `skills/bmod-tea/knowledge/tea-index.csv`                 | Knowledge fragment index: id, name, description, tags, tier, path. 59 rows                                   | Read before recommendations and by knowledge-loading steps                  |
+| `skills/bmod-tea/knowledge/*.md`                          | 59 reusable fragments: standards, patterns, API references, integration mandates                             | Selectively read into context by tier and config flags                      |
 
-Nine copies of the knowledge base exist on purpose: the agent carries one, and so does each of the eight workflows that consult it. Every copy is byte-identical. A workflow skill has to stay self-contained so it can be installed, copied, or invoked without reaching across skill boundaries, so when knowledge changes, propagate the update into the affected workflow resource directories rather than replacing them with a central runtime path. `bmad-teach-me-testing` is the exception; it carries a curated pointer file at `data/tea-resources-index.yaml` instead of the fragments themselves.
+The knowledge base has one copy, in the `bmod-tea` skill. The agent and every workflow that consults it read it as a sibling skill folder, `{skill-root}/../bmod-tea/knowledge`. If `bmod-tea` is missing, the skill says so and offers to install it. `bmad-teach-me-testing` carries a curated pointer file at `data/tea-resources-index.yaml` instead of reading the fragments.
 
 ```mermaid
 flowchart TB
@@ -183,7 +184,7 @@ flowchart TB
 
 ### How It Works at Runtime
 
-**1. Activation.** `/bmad-tea` or `$bmad-tea` loads the agent skill. It resolves its customization block across base, team, and user layers, adopts the persona, loads persistent facts and `_bmad/tea/config.yaml`, greets you, and renders `{agent.menu}` as a numbered table. Naming one clear intent in your first message ("let's design tests for this epic") skips the menu and dispatches directly. A message that supports several menu choices triggers one focused question naming the relevant choices before any workflow starts.
+**1. Activation.** `/bmad-tea` or `$bmad-tea` loads the agent skill. It resolves its customization block across base, team, and user layers, adopts the persona, loads persistent facts and the `core` and `modules.tea` config from `_bmad/config.toml` and its `_bmad/custom/` layers, greets you, and renders `{agent.menu}` as a numbered table. Naming one clear intent in your first message ("let's design tests for this epic") skips the menu and dispatches directly. A message that supports several menu choices triggers one focused question naming the relevant choices before any workflow starts.
 
 **2. Workflow entry.** Direct workflow commands use the installed skill name, such as `/bmad-testarch-automate` or `$bmad-testarch-automate`, depending on the host's invocation syntax. `TA` is the equivalent agent-menu code, available only once TEA is active. Either way, the workflow's `SKILL.md` resolves its own `[workflow]` customization block and asks which mode to run: Create, Resume, Validate, or Edit. Create and Resume both route into `steps-c/`; Validate into `steps-v/`; Edit into `steps-e/`. `test-review` alone supports `headless: true`, which skips the greeting and the menu and runs Create directly. That is how the CLI drives it in CI.
 
@@ -236,16 +237,25 @@ The three passes cover different user-visible moments. `--pre` checks content be
 
 This closes the gap between advisory generation guidance and a later `test-review`. It blocks seven mechanically decidable Absolute rules and warns on one: focused tests, tautological assertions, hard waits, oversized test files, Maestro flows that cannot fail, two Pact parallelism rules, and undocumented disabled tests as the warning. Rules that require semantic judgment stay in `test-review`. The hook fails open on its own errors so a broken guardrail cannot lock the agent out of writing. Agent platforms without a write-time hook API skip installation and rely on `test-review` for enforcement.
 
-**How workflows become commands.** `npx bmad-method install` copies each TEA skill into the host runtime's skill directory under its own name. Invoking that name loads the skill, and the step-file process takes over. The skill name is identical on every platform the BMad installer supports.
+**How workflows become commands.** `npx skills add` copies each TEA skill into the host's skill directory under its own name. Invoking that name loads the skill, and the step-file process takes over. The skill name is the same on every host.
 
 ## Install
 
 ```bash
-npx bmad-method install
-# Select: Test Architect (TEA)
+npx skills add bmad-code-org/bmad-method-test-architecture-enterprise
 ```
 
-**Note:** TEA is automatically added to party mode after installation. Use `/party` to collaborate with TEA alongside other BMad agents.
+This adds the TEA skills and `bmod-tea`, the module record that holds the setup questions and the knowledge base. Then, in your assistant chat, run:
+
+```text
+bmad setup tea
+```
+
+`bmad setup` runs through [uv](https://docs.astral.sh/uv/) (Python 3.11 or later, which uv fetches when it is missing), so install uv first. The `bmad` skill comes from BMad Method core. If you do not have it, add it with `npx skills add bmad-code-org/BMAD-METHOD --skill bmad bmod-core-tools`. Setup asks TEA's questions and writes the answers to `_bmad/config.toml`. Run `bmad setup tea` again later to see or change them.
+
+`npx skills add` installs the head of `main`. To install a release, point it at the release tag instead: `npx skills add https://github.com/bmad-code-org/bmad-method-test-architecture-enterprise/tree/v<version>/skills`.
+
+Murat is listed in the module's roster, so party mode can bring him into a group discussion alongside other BMad agents.
 
 ### Invocation Syntax
 
@@ -306,18 +316,17 @@ Installing this package also installs a `tea-test-review` binary that runs the r
 npx tea-test-review --base origin/main --min-score 80
 ```
 
-It scopes to changed tests (`--base`, `--files`), runs through an agent adapter with a pinned review model, isolates the filesystem, emits a JSON verdict, and separates its exit codes: `0` pass, `1` verdict failure, `2` environment or configuration failure, and `3` agent failure or an unparseable or untrusted report. For example, a missing credential exits `2`, while a runner crash after launch exits `3`.
+It reviews with the skill shipped in its own package, scopes to changed tests (`--base`, `--files`, or `--pr` to look up the base branch), runs through an agent adapter with a pinned review model, isolates the filesystem, emits a JSON verdict, and separates its exit codes: `0` pass, `1` verdict failure, `2` environment or configuration failure, and `3` agent failure or an unparseable or untrusted report. For example, a missing credential exits `2`, while a runner crash after launch exits `3`.
 
 The recommendation is derived from the findings rather than taken from the agent's prose. Any CRITICAL derives Block. Any HIGH, or a score under 70, derives Request Changes. The agent's own stated recommendation is preserved as `reportedRecommendation` when the two disagree. `--waive` exists for the exceptions and requires an expiry.
 
-A copy-paste workflow lives at `cli/examples/pr-test-review.yml`, and the full flag, exit-code, and security reference is at [tea-test-review CLI](https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/reference/tea-test-review-cli/).
+`tea-test-review --github` also opens a check run and keeps one short pull-request comment up to date, and `tea-test-review render` prints the same comment, check-run text or summary from a verdict file for any other CI. Copy-paste workflows live at `cli/examples/pr-test-review.yml` (GitHub Actions) and `cli/examples/gitlab-ci.yaml` (GitLab), and the full flag, exit-code, and security reference is at [tea-test-review CLI](https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/reference/tea-test-review-cli/).
 
 ## Configuration
 
-TEA variables are defined in `src/module.yaml` and prompted during install. Eleven are wired into workflows today; the last one is a placeholder that nothing reads yet.
+TEA's setup questions are declared in `skills/bmod-tea/bmod.toml` and asked by `bmad setup tea`, which writes the answers to `modules.tea` in `_bmad/config.toml`. Every one is read by a workflow today. Team overrides go in `_bmad/custom/config.toml` and personal ones in `_bmad/custom/config.user.toml`; run `bmad setup tea` again to see or change the answers.
 
 - `test_artifacts` — base output folder for test artifacts. Each workflow writes into its own folder under it (`test-design/`, `atdd/`, `automate/`, `test-review/`, `nfr/`, `trace/`, `ci/`, `framework/`), and a file produced once per story, epic, or release carries that scope in its name, such as `trace/gate-decision-epic-16.json`. See [Output Layout](https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/reference/configuration/#output-layout)
-- `tea_evaluations_folder` — base folder for Evaluate's own evaluation folders (string, default `evals`), resolved as `{project-root}/{value}`
 - `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
@@ -325,9 +334,12 @@ TEA variables are defined in `src/module.yaml` and prompted during install. Elev
 - `tea_execution_mode` — how TEA orchestrates multi-step generation and evaluation: auto, subagent, agent-team, sequential (string, default auto)
 - `tea_capability_probe` — probe the runtime before selecting an execution mode (boolean, default true). With it off, TEA honors the configured mode strictly and fails loudly instead of falling back
 - `test_stack_type` — detected or configured stack type (auto, frontend, backend, fullstack, mobile). Mobile is checked before frontend, because a React Native project carries React in `package.json` and would otherwise misdetect as web
-- `ci_platform` — CI platform (auto, github-actions, gitlab-ci, jenkins, azure-devops, harness, circle-ci, other)
 - `test_framework` — detected or configured test framework (auto, Playwright, Cypress, Jest, Vitest, pytest, JUnit, Go test, dotnet test, RSpec, Maestro, other)
-- `risk_threshold` — risk cutoff for mandatory testing. Prompted at install, not yet read by any workflow
+
+Two settings that only one workflow reads are set through that workflow's customization file instead, under `[workflow]`:
+
+- `evaluations_folder` — base folder for Evaluate's own evaluation folders (default `evals`, relative to the project root). Set it in `_bmad/custom/bmad-testarch-evaluate.toml`
+- `ci_platform` — CI platform (auto, github-actions, gitlab-ci, jenkins, azure-devops, harness, circle-ci, other; default auto). Set it in `_bmad/custom/bmad-testarch-ci.toml`
 
 Full option reference: [Configuration](https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/reference/configuration/).
 
@@ -335,8 +347,8 @@ Full option reference: [Configuration](https://bmad-code-org.github.io/bmad-meth
 
 TEA relies on a curated testing knowledge base of 59 fragments, indexed by tier:
 
-- Index: `src/agents/bmad-tea/resources/tea-index.csv`
-- Fragments: `src/agents/bmad-tea/resources/knowledge/`
+- Index: `skills/bmod-tea/knowledge/tea-index.csv`
+- Fragments: `skills/bmod-tea/knowledge/`
 - Tiers: 24 core, 19 extended, 16 specialized
 
 Workflows load only the fragments required for the current task, and the required set is named in the step file rather than inferred from index tags. See [Knowledge Base](https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/reference/knowledge-base/).
@@ -344,21 +356,19 @@ Workflows load only the fragments required for the current task, and the require
 ## Repository Layout
 
 ```text
-src/                     # the shipped module
-├── module.yaml          # install-time variables and post-install notes
-├── module-help.csv      # workflow catalog: menu codes, phases, ordering
-├── agents/bmad-tea/     # SKILL.md, customize.toml, resources/{tea-index.csv, knowledge/}
-└── workflows/testarch/  # ten self-contained workflow skills
-    ├── bmad-teach-me-testing/
-    ├── bmad-testarch-atdd/
-    ├── bmad-testarch-automate/
-    ├── bmad-testarch-ci/
-    ├── bmad-testarch-evaluate/
-    ├── bmad-testarch-framework/        # resources/hooks/tea-enforce.cjs lives here
-    ├── bmad-testarch-nfr/
-    ├── bmad-testarch-test-design/
-    ├── bmad-testarch-test-review/      # steps-c/criteria-registry.md lives here
-    └── bmad-testarch-trace/
+skills/                  # the shipped module, one folder per skill
+├── bmod-tea/            # module record: bmod.toml, roster.toml, help/, knowledge/{tea-index.csv, *.md}
+├── bmad-tea/            # the agent: SKILL.md, customize.toml
+├── bmad-teach-me-testing/
+├── bmad-testarch-atdd/
+├── bmad-testarch-automate/
+├── bmad-testarch-ci/
+├── bmad-testarch-evaluate/
+├── bmad-testarch-framework/        # resources/hooks/tea-enforce.cjs lives here
+├── bmad-testarch-nfr/
+├── bmad-testarch-test-design/
+├── bmad-testarch-test-review/      # steps-c/criteria-registry.md lives here
+└── bmad-testarch-trace/
 
 cli/                     # tea-test-review: the headless CI gate
 docs/                    # source of truth for the docs site
@@ -369,7 +379,7 @@ test/                    # quality gate suites and the six eval harnesses
 
 ## How TEA Keeps Itself Honest
 
-TEA has deterministic checks and live evals. Ten of TEA's eleven skills have behavioral coverage registered in the suite manifest; `bmad-testarch-evaluate` is deferred there until Story 1.16 authors its own suite.
+TEA has deterministic checks and live evals. All eleven of TEA's skills have coverage registered in the suite manifest: ten behavioral suites, and the suite Evaluate authored for `bmad-testarch-evaluate` itself.
 
 ### Current Eval Coverage
 
@@ -383,36 +393,48 @@ The `atdd`, `automate`, `ci`, `framework`, `nfr`, `teach-me-testing`, `test-desi
 | `bmad-teach-me-testing`     | N/A                      | Yes; multi-turn session with seeded wrong quiz answer, review loop, and progress    |
 | `bmad-testarch-atdd`        | 3                        | Yes; one unimplemented fixture and five acceptance criteria                         |
 | `bmad-testarch-automate`    | 5                        | Yes; four hand-authored spec sets against a fixed service and its seeded regression |
-| `bmad-testarch-ci`          | 2                        | Yes; one full request and one minimal request                                       |
-| `bmad-testarch-evaluate`    | N/A                      | No; deferred until Story 1.16 authors its own suite                                 |
+| `bmad-testarch-ci`          | 2                        | Yes; one full request, one minimal request and one request over an evaluation plan  |
+| `bmad-testarch-evaluate`    | N/A                      | Yes; Evaluate-authored, five seeded probes and four clean controls                  |
 | `bmad-testarch-framework`   | 3                        | Yes; install and smoke-test generated scaffold in network-isolated sandbox          |
 | `bmad-testarch-nfr`         | 2                        | Yes; one evidence bundle with known gaps and one clean bundle                       |
 | `bmad-testarch-test-design` | 5                        | Yes; one seeded epic and one clean control epic                                     |
 | `bmad-testarch-test-review` | 2                        | Yes; three files, nine planted defects, and one clean file                          |
 | `bmad-testarch-trace`       | 2                        | Yes; a ten-criterion seeded set and a five-criterion clean set                      |
 
-A passing fragment-selection eval means the workflow loaded the right knowledge. Ten of TEA's eleven skills have behavioral coverage registered in the suite manifest; `bmad-testarch-evaluate` is named in the manifest's deferred array with its owner, missing evidence, and exit condition until Story 1.16 lands its own suite. [How TEA Is Tested](https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/explanation/how-tea-is-tested/) explains the testing hierarchy, exit classes, and evidence model in plain language. The source-controlled [Eval Quality and Behavioral Coverage Roadmap](https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/explanation/eval-quality-roadmap/) records the per-skill contracts, runner work, CI plan, and intended boundary with the upcoming standalone `eval-quality` project. [The eval-quality Command Adapter](https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/explanation/eval-quality-command-adapter/) records how TEA runs the commands those evals measure, and [Adopting eval-quality, One Skill at a Time](https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/explanation/eval-quality-adoption-guide/) is the guide for taking one skill in another BMAD module from asserted quality to measured quality.
+A passing fragment-selection eval means the workflow loaded the right knowledge. All eleven of TEA's skills have coverage registered in the suite manifest; `bmad-testarch-evaluate` is covered by the `evaluate-authored` suite Evaluate wrote and ran on itself, so the manifest's deferred array is empty. [How TEA Is Tested](https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/explanation/how-tea-is-tested/) explains the testing hierarchy, exit classes, and evidence model in plain language. The source-controlled [Eval Quality and Behavioral Coverage Roadmap](https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/explanation/eval-quality-roadmap/) records the per-skill contracts, runner work, CI plan, and intended boundary with the upcoming standalone `eval-quality` project. [The eval-quality Command Adapter](https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/explanation/eval-quality-command-adapter/) records how TEA runs the commands those evals measure, and [Adopting eval-quality, One Skill at a Time](https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/explanation/eval-quality-adoption-guide/) is the guide for taking one skill in another BMAD module from asserted quality to measured quality.
 
 ### Deterministic Checks
 
-`npm test` chains eighty-two checks. That count covers the whole chain: every entry in it is deterministic and credential-free, so the chain and its credential-free subset are the same list. `npm run test:ci-coverage` derives the count from `package.json` and prints it. Twelve of the eighty-two keep the rules, guidance, hook, eval data, eval contracts, diagnostics, and documentation aligned:
+`npm test` chains 163 checks. That count covers the whole chain: every entry in it is deterministic and credential-free, so the chain and its credential-free subset are the same list. `npm run test:ci-coverage` derives the count from `package.json` and prints it. Twelve of the 163 keep the rules, guidance, hook, eval data, eval contracts, diagnostics, and documentation aligned:
 
-- `test:criteria-fragments` fails when a registry row is neither mapped to a knowledge fragment nor declared a known gap. A rule the reviewer scores but no fragment teaches is a rule TEA punishes without ever having explained it. All 36 rows are currently mapped across 50 anchors. Because the declared-gap list is empty, the validator feeds itself a synthetic unmapped row on every run to prove that path still works.
-- `test:doc-counts` runs `eval-quality-gates doc-counts`, which holds a hand-written count on a published page against the source that computes it: the roadmap's per-suite `eval:all` call counts, the knowledge-fragment tier breakdown, this section's own npm-test-chain length, and the fragment-selection case count. A pattern matching no sentence, or more than one, fails the same way a wrong number does, so the entry cannot go stale by drifting out from under its own pattern either.
+- `test:criteria-fragments` fails when a registry row is neither mapped to a knowledge fragment nor declared a known gap. A rule the reviewer scores but no fragment teaches is a rule TEA punishes without ever having explained it. All 35 rows are currently mapped across 51 anchors. Because the declared-gap list is empty, the validator feeds itself a synthetic unmapped row on every run to prove that path still works.
+- `test:doc-counts` runs `eval-quality-gates doc-counts`, which holds a hand-written count on a published page against the source that computes it: the roadmap's per-suite `eval:all` call counts, the knowledge-fragment tier breakdown, this section's own npm-test-chain length, the fragment-selection case count, the replay totals that the test README and the header of the replay suite state, the story count, epic count and appended-story count in the overview of the Evaluate plan, and the lane count in its parallel-lanes section.
+  The plan's source module also refuses a plan whose five lane lists differ between the plan's epics file and its sprint status file, so the gate fails on a story moved, dropped, duplicated or reordered in one file only.
+  A pattern matching no sentence, or more than one, fails the same way a wrong number does, so the entry cannot go stale by drifting out from under its own pattern either.
 - `test:doc-claims` runs `eval-quality-gates doc-claims`, which holds a hand-written prose claim — a named symbol, a transcribed list, a worked JSON example, a named exit code, or a claim whose truth depends on when it was written — against the artifact it describes. A registered dated claim whose sentence was rewritten out from under it fails the same way a wrong symbol name does, so the entry cannot go stale by drifting out from under its own key either.
 - `test:enforce-hook` fails when a new Absolute registry row appears in neither the hook's enforced list nor its deferred list. This prevents a rule from being added without an explicit write-time enforcement decision.
 - `test:atdd-workflow-guidance` holds ATDD generation to one supplied criterion id per executable leaf, one primary scaffold per criterion, a criterion-defining first assertion, and a transition-bearing primary branch for state changes. It also checks every literal API and E2E example title against the same criterion-id format.
 - `test:eval-data` checks that all 24 fragment-selection cases are structurally usable: their workflow context files exist, every expected fragment exists and is indexed for that workflow, and the required and forbidden sets do not overlap. The expected sets come from the workflow step files. This check does not ask an agent to select anything.
 - `test:eval-routing-boundaries` mutates the facts, candidate codes, and missing deciding information in each source-bound routing ambiguity rule. It also rejects duplicate and orphan boundaries, plus any boundary that would turn a clear intent into a clarification.
-- `test:eval-schemas` checks this repository's own eval suite manifest against its schema, confirms that every threshold it declares is the threshold the harness actually applies, that the runner capabilities it declares are the ones the harness grants its runner, and that the preflight argv it declares fails on a missing runner and passes on a present one, and fails when a TEA skill has neither a behavioral suite nor a deferred declaration. A suite list that omits a skill reads as coverage, so the omission has to be an error rather than a silence.
+- `test:eval-schemas` checks this repository's own eval suite manifest against its schema, confirms that every threshold it declares is the threshold the harness actually applies, that the runner capabilities it declares are the ones the harness grants its runner, and that the preflight argv it declares fails on a missing runner and passes on a present one, and fails when a TEA skill has neither a behavioral or Evaluate-authored suite nor a deferred declaration. A suite list that omits a skill reads as coverage, so the omission has to be an error rather than a silence.
 - `test:eval-diagnostics` checks that current result writers emit bounded case and repetition diagnostics, that quality and environment outcomes stay separate, that unstable signatures remain visible, and that the protected 1.3.0 baseline remains readable and byte-for-byte unchanged.
 - `test:nfr-evidence-guidance` holds every NFR worker and the publication audit to the supplied-evidence ledger, exercises supported, missing, and mismatched evidence, rejects contaminating examples, and binds the protected baseline and focused remediation records by digest.
 - `test:contract-oracles` evaluates every oracle in every eval contract with `eval-quality`'s own evaluator, over the stored replay outputs and over constructed selections for all 24 fragment-selection cases, and fails when an oracle faults or disagrees with the harness scorer on the same evidence. The first run found that every regex oracle in the `test-review` contract was refused by the evaluator before it matched anything.
 - `test:evaluate-guidance` parses the Evaluate skill's `SKILL.md` stage list and fails when a stage entry is missing, out of order, or points at a `references/` guide that does not exist.
 
+Four more checks hold the Evaluate documentation:
+
+- `test:docs-build-names` scans every page under `docs/` and fails on a name from how TEA was built: a story id, a decision id, a line of epic narrative, a planning path, a pull request number or a word from the review process.
+  It also fails when an executable command block (a fenced `bash`, `sh`, `shell` or `zsh` block) holds a timestamped run or score ID, which a reader's own run never has.
+- `test:docs-evaluate-sidebar` fails when a page that names `tea-evaluate` or `bmad-testarch-evaluate` is missing from the site sidebar, and when the TEA overview links no page that Evaluate owns.
+- `test:docs-gap-reader` lifts the held-out reader command out of the gaps how-to, runs it over a `gap-view.json` built with a caught, an uncaught and a withheld row, and fails when it crashes or leaves a row unprinted.
+- `test:docs-tutorial` runs the commands of the Evaluate tutorial against its fixture and fails on a command that errors or an output line the page promises and the run does not print.
+
+`test:workflows-lint` runs `actionlint` over every workflow in `.github/workflows/` and the `cli/examples/pr-test-review.yml` template, and fails on any finding. It disables the shellcheck and pyflakes integrations so the answer does not depend on which of those binaries a machine has. With no `actionlint` on `PATH` it fails and names `tools/install-actionlint.sh` rather than skipping, and it proves on every run that a workflow reading a step that does not exist is refused.
+
 These checks produce the same answer from the same repository state. They need no agent credential, network call, or model budget. `test:eval-data` runs through `npm test`, the local pre-commit hook, pull-request quality checks, and the publish workflow.
 
-`test:doc-invocations` runs `eval-quality-gates doc-invocations`, which re-runs every `npm run <script>` this README, the adoption guide, and `test/README.md` document in their CI-usage and individual-suites blocks against the real repository, so a renamed script or a broken example fails the build instead of a reader. Each of the seventeen documented scripts is declared as a full literal spelling, never a shared `npm run` prefix, which is what keeps the gate from ever matching, let alone running, `npm run eval:all` or `npm run release:next` on the same pages; `test:cli` is deliberately left undeclared, since it is a separately sharded suite that takes 12-15 minutes, the wrong fit for a bounded documentation gate. The gate's own entry script is the one real program it is allowed to reach; it refuses anything outside its own hardcoded allowlist before invoking real `npm`, and `test:doc-invocation-entry` holds that allowlist's comment-to-script lookup against all three pages' literal text, line by line, so a swapped or drifted comment fails there even when the script it resolves to would still run.
+`test:doc-invocations` runs `eval-quality-gates doc-invocations`, which re-runs every `npm run <script>` this README, the adoption guide, and `test/README.md` document in their CI-usage and individual-suites blocks against the real repository, so a renamed script or a broken example fails the build instead of a reader. Each of the eighteen documented scripts is declared as a full literal spelling, never a shared `npm run` prefix, which is what keeps the gate from ever matching, let alone running, `npm run eval:all` or `npm run release:next` on the same pages. The gate's own entry script is the one real program it is allowed to reach; it refuses anything outside its own hardcoded allowlist before invoking real `npm`, and `test:doc-invocation-entry` holds that allowlist's comment-to-script lookup against all three pages' literal text, line by line, so a swapped or drifted comment fails there even when the script it resolves to would still run.
 
 ### Start Here
 
@@ -432,7 +454,7 @@ npm run eval:all -- --agent agy
 npm run eval:all -- --agent agy --agent claude --agent codex
 ```
 
-`eval:all` uses two repetitions per fragment-selection case and per routing intent, three repetitions for `test-review`, and two repetitions per `nfr` evidence bundle, per `ci` project, per `test-design` epic, per `trace` fixture set, and per `atdd` story. One runner makes 107 agent calls: 48 fragment selections, 38 routing intents, 3 reviews, 4 audits, 4 pipelines, 4 test designs, 4 traces, and 2 ATDD generations. All three built-in runners make 321 calls.
+`eval:all` uses two repetitions per fragment-selection case and per routing intent, three repetitions for `test-review`, and two repetitions per `nfr` evidence bundle, per `ci` project, per `test-design` epic, per `trace` fixture set, and per `atdd` story. One runner makes 115 agent calls: 48 fragment selections, 38 routing intents, 3 reviews, 4 audits, 12 pipelines, 4 test designs, 4 traces, and 2 ATDD generations. All three built-in runners make 345 calls.
 
 Check the data, executable, login, fixtures, and expected results without making a model call:
 
@@ -554,17 +576,17 @@ npm run eval:fragment-selection -- \
 
 ### What Has to Pass
 
-Every row below is a declared gate. Ten of TEA's eleven skills have behavioral suites registered in the suite manifest; `bmad-testarch-evaluate` is deferred until Story 1.16. Recorded live baselines preserve timestamped history, and [How TEA Is Tested](https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/explanation/how-tea-is-tested/) describes the evidence model. The live thresholds are the ones this repository's own eval suite manifest declares, and `npm run test:eval-schemas` fails when a harness constant and the manifest disagree.
+Every row below is a declared gate. Ten of TEA's eleven skills have behavioral suites registered in the suite manifest, and `bmad-testarch-evaluate` has the Evaluate-authored suite. Recorded live baselines preserve timestamped history, and [How TEA Is Tested](https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/explanation/how-tea-is-tested/) describes the evidence model. The live thresholds are the ones this repository's own eval suite manifest declares, and `npm run test:eval-schemas` fails when a harness constant and the manifest disagree.
 
 | Eval                              | Declared threshold                                                                                                                                                                                                                                                                                                                                                                                 | Declared volume                                                                                            |
 | --------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- |
-| `npm run eval:all -- --agent ...` | All eight live suites below meet their thresholds for the selected runner                                                                                                                                                                                                                                                                                                                          | 48 selections, 38 routing calls, 3 reviews, 4 audits, 4 pipelines, 4 test designs, 4 traces, 2 generations |
+| `npm run eval:all -- --agent ...` | All eight live suites below meet their thresholds for the selected runner                                                                                                                                                                                                                                                                                                                          | 48 selections, 38 routing calls, 3 reviews, 4 audits, 6 pipelines, 4 test designs, 4 traces, 2 generations |
 | Fragment selection                | At least 90% required-fragment recall, at most 10% forbidden-fragment selection, and stable choices across repeated cases                                                                                                                                                                                                                                                                          | 24 cases twice: 48 calls                                                                                   |
 | Test review                       | At least 70% overall recall, 100% CRITICAL recall, an 80% non-false-positive rate, score standard deviation no higher than 3, and a stable verdict                                                                                                                                                                                                                                                 | Three complete reviews                                                                                     |
 | Trace                             | At least 90% criterion-status accuracy and 90% evidence-citation precision; 100% on both discriminating criteria, the gate decision, the gate criteria, the coverage arithmetic, the oracle resolution, the rejected evidence, the waiver validity, and the live evidence; no clean-set false positive, no unstable case, and no fixture mutation                                                  | Two fixture sets twice: 4 calls                                                                            |
 | bmad-tea routing                  | At least 90% route accuracy, 80% reason-token recall, 87.5% scope fidelity, and 75% on both clarification and decline recall; zero confident routes on an intent nothing on the menu serves, zero on one whose menu items are genuinely close, zero clear intents left unrouted, and at most two intents whose answer changes between repetitions                                                  | 19 intents twice: 38 calls                                                                                 |
 | NFR                               | At least 87.5% domain-status accuracy and 90% threshold fidelity; 100% on undecidable domains, the overall status, and domain coverage; no unsupported PASS, no fabricated evidence, no clean-bundle false positive, no duplicate domain section, no disagreement between the gate artifact and the assessment it summarizes, no unstable case, and no fixture mutation                            | Two evidence bundles twice: 4 calls                                                                        |
-| CI                                | Zero parse failures and zero `actionlint` findings; at least 90% requested-element recall and 100% trigger accuracy; zero unrequested elements, zero workflow rule violations, no unstable case, and no fixture mutation                                                                                                                                                                           | Two projects twice: 4 calls                                                                                |
+| CI                                | Zero parse failures and zero `actionlint` findings; at least 97% requested-element recall and 100% trigger accuracy; zero unrequested elements, zero workflow rule violations, no unstable case, and no fixture mutation                                                                                                                                                                           | Six projects twice: 12 calls                                                                               |
 | Test design                       | At least 80% grounded-risk recall, 80% risk precision, and 80% coverage mapping; 100% on the scale compliance, the score arithmetic, the category validity, the band placement, the risk-id shape, the risk-link resolution, and the priority ordering; no unscored risk table, no ungrounded risk, no missed top-severity risk, no risk-ceiling excess, no unstable case, and no fixture mutation | Two epics twice: 4 calls                                                                                   |
 | ATDD                              | 100% red-for-intended-reason rate and criteria coverage; no vacuous pass, no scaffold still skipped after activation, no load error, no non-assertion exit, no unmapped test, no production mutation, and no unstable case                                                                                                                                                                         | One story twice: 2 generation calls, plus execution under NFR9's isolation, which spends no call           |
 | `npm run test:eval-data`          | Every case references valid workflow files and indexed fragments; required and forbidden sets do not overlap                                                                                                                                                                                                                                                                                       | No agent calls                                                                                             |
@@ -596,7 +618,7 @@ npm ci
 npm run test:eval-data          # fragment-selection corpus, static
 npm run test:eval-trace-data    # trace corpus, static
 npm run test:eval-schemas       # manifest against harness constants, and the preflight argv
-npm run test:eval-replay        # 123 stored outputs against the scorers
+npm run test:eval-replay        # stored outputs against the scorers
 ```
 
 Run live evals in a scheduled or manually triggered CI job after installing and authenticating the selected agent CLI:
@@ -616,7 +638,7 @@ Custom workflows are still compatible with TEA, but they are no longer implicitl
 
 1. Package the workflow as custom content or a custom module.
 2. Attach it to `bmad-tea` using the agent customization flow.
-3. Reinstall/update BMAD so the new menu item and workflow are registered.
+3. Install the workflow skill with `npx skills add`, then start a fresh chat so the new menu item is picked up.
 
 See [Extend TEA with Custom Workflows](https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/how-to/customization/extend-tea-with-custom-workflows/) and the BMAD customization guide at [BMAD-METHOD/docs/how-to/customize-bmad.md](https://github.com/bmad-code-org/BMAD-METHOD/blob/main/docs/how-to/customize-bmad.md).
 
@@ -702,7 +724,7 @@ npm run release:major
 
 The workflow performs these steps:
 
-1. ✅ **Validation**: Runs the full `npm test` chain: schema checks, install tests, knowledge checks, criteria-to-fragment traceability, enforce-hook coverage, eval data validation, release metadata, changelog, workflow descriptions, linting, markdown linting, and formatting. The CLI suite (`npm run test:cli`) runs as its own CI job because it takes over twelve minutes
+1. ✅ **Validation**: Runs the full `npm test` chain: schema checks, install tests, knowledge checks, criteria-to-fragment traceability, enforce-hook coverage, eval data validation, release metadata, changelog, workflow descriptions, linting, markdown linting, and formatting. The chain includes the CLI suite (`npm run test:cli`).
 2. ✅ **Version Bump**:
 
 - `next`: derives the next prerelease version and publishes it with dist-tag `next`
@@ -742,10 +764,11 @@ npm view bmad-method-test-architecture-enterprise dist-tags
 **Install TEA:**
 
 ```bash
-npx bmad-method install
-# Select "Test Architect (TEA)"
+npx skills add bmad-code-org/bmad-method-test-architecture-enterprise
 ```
 
+Then run `bmad setup tea` in the assistant chat.
+
 **Test Workflows:** type these in the assistant chat, not in a shell.
 
 ```text
@@ -813,7 +836,7 @@ Before releasing:
 After releasing:
 
 - [ ] Verify NPM publication: `npm view bmad-method-test-architecture-enterprise`
-- [ ] Test installation: `npx bmad-method install`
+- [ ] Test installation: `npx skills add bmad-code-org/bmad-method-test-architecture-enterprise`, then `bmad setup tea`
 - [ ] Verify workflows work
 - [ ] Check GitHub Release created
 - [ ] Monitor for issues