bmad-method-test-architecture-enterprise 2.0.2 → 2.0.3-next.0

package/skills/bmad-tea/SKILL.md

@@ -78,11 +78,11 @@ Dispatch on a clear match by invoking the item's `skill` or executing its `promp
 
 ### Framework and CI Setup Routing
 
-TF invokes `bmad-testarch-framework`, the canonical owner of framework and CI setup. CI invokes the installed `bmad-testarch-ci` compatibility entry with CI scope preset. Preserve both codes, names, custom menu overrides, requested scope and operation. A request for framework and pipeline setup routes directly to TF with `setup_scope = both`. The shared router asks “Do you want CI too?” once when setup leaves CI intent unclear.
+TF invokes `bmad-testarch-framework` for framework setup. CI invokes the same skill with `setup_scope = ci`. Preserve both codes, custom menu overrides, requested scope and operation. A request for framework and pipeline setup routes to TF with `setup_scope = both`. The shared router asks “Do you want CI too?” once when setup leaves CI intent unclear.
 
 ### Test Generation Routing
 
-AT invokes `bmad-testarch-atdd`, the red-mode entry of the canonical `bmad-testarch-automate` skill. TA invokes `bmad-testarch-automate` with expand as its default. Preserve both menu codes, both invocation names, custom menu overrides, the requested operation and any explicit red or expand intent. Red writes acceptance tests before implementation and checks the intended failure; expand adds passing coverage for implemented code. Create runs run-and-heal by default in both modes. Validate and Edit report their own checks without repair. A mixed implemented/unimplemented request still needs the deciding scope or sequence when the user has supplied neither.
+AT invokes `bmad-testarch-automate` with `test_mode = red`. TA invokes the same skill with expand as its default. Preserve both menu codes, custom menu overrides, the requested operation and any explicit red or expand intent. Red writes acceptance tests before implementation and checks the intended failure; expand adds passing coverage for implemented code. Create runs run-and-heal by default in both modes. Validate and Edit report their own checks without repair. A mixed implemented/unimplemented request still needs the deciding scope or sequence when the user has supplied neither.
 
 ### Routing Ambiguity Boundaries
 

package/skills/bmad-tea/customize.toml

@@ -74,13 +74,13 @@ skill = "bmad-testarch-framework"
 
 [[agent.menu]]
 code = "CI"
-description = "Continuous Integration: scaffold CI/CD quality pipeline through the combined framework skill"
-skill = "bmad-testarch-ci"
+description = "Continuous Integration: scaffold a CI/CD quality pipeline through Framework CI scope"
+skill = "bmad-testarch-framework"
 
 [[agent.menu]]
 code = "AT"
-description = "ATDD: generate and verify failing acceptance tests in red mode before development"
-skill = "bmad-testarch-atdd"
+description = "ATDD: generate and verify failing acceptance tests through Automate red mode"
+skill = "bmad-testarch-automate"
 
 [[agent.menu]]
 code = "TA"

package/skills/bmad-teach-me-testing/steps-c/step-04-session-01.md

@@ -93,8 +93,8 @@ Present this content (mostly autonomous, clear and educational):
 
 TEA is a comprehensive test architecture framework that provides:
 
-- **8 Workflows:** Teach Me Testing, Test Design, Framework and CI Setup, Automation (red and expand modes), Test Review, NFR Evidence Audit, Trace, Evaluate. The CI and ATDD commands and their menu codes remain available.
-- **Framework and CI setup:** One `bmad-testarch-framework` skill handles framework only, CI only, or both. The `bmad-testarch-ci` command and `CI` menu code start its CI setup. TEA infers the scope from your prompt and asks "Do you want CI too?" once when unclear in an interactive session. An unattended request with unclear scope sets up the framework only. Create, Resume, Validate, and Edit choose the operation.
+- **8 Workflows:** Teach Me Testing, Test Design, Framework and CI Setup, Automation (red and expand modes), Test Review, NFR Evidence Audit, Trace, Evaluate. The agent's `AT` and `CI` menu codes remain available for Automate red mode and Framework CI scope.
+- **Framework and CI setup:** One `bmad-testarch-framework` skill handles framework only, CI only, or both. Ask that skill for CI setup, or use the agent's `CI` menu code. TEA infers the scope from your prompt and asks "Do you want CI too?" once when unclear in an interactive session. An unattended request with unclear scope sets up the framework only. Create, Resume, Validate, and Edit choose the operation.
 - **59 Knowledge Fragments:** Distilled expertise on patterns, best practices, Playwright Utils
 - **Quality Standards:** Definition of Done with execution limits (no flaky tests, no hard waits, etc.)
 - **Risk-Based Testing:** P0-P3 matrix for prioritizing test coverage

package/skills/bmad-teach-me-testing/steps-c/step-04-session-03.md

@@ -220,7 +220,7 @@ The prompt determines scope; if CI scope is unclear in an interactive session, a
 Framework scope covers stack selection, fixtures, scaffold, scripts, and the write-time quality hook.
 CI scope covers pipeline generation, quality gates, and evaluation-plan rendering.
 For both, agree the stack, framework, and test commands first. Scaffold and pipeline generation can then run in parallel, with joint validation after both finish. A CI request without a framework offers the framework phase first.
-`bmad-testarch-ci` and `CI` still start CI setup, while `TF` starts framework setup.
+`bmad-testarch-framework` handles CI setup when requested; the agent's `CI` code selects that scope, while `TF` starts framework setup.
 Create starts setup, Validate reports checks without repairing outputs, and Edit revises the selected outputs and checks those changes. Resume continues an interrupted run, whatever its scope and operation.
 
 ### 7. Quiz (3 questions)

package/skills/bmad-teach-me-testing/steps-c/step-04-session-05.md

@@ -71,7 +71,7 @@ Save the updated progress file.
 
 **TDD Red Phase:** Write failing tests FIRST
 
-**Automation red mode:** `/bmad-testarch-atdd` and `AT` select red by default. `/bmad-testarch-automate` also supports an explicit red request.
+**Automation red mode:** Ask `/bmad-testarch-automate` for acceptance tests before implementation, or use the agent's `AT` code to select red.
 
 **Create sequence:**
 
@@ -97,7 +97,7 @@ Save the updated progress file.
 
 **Purpose:** Generate tests for existing features
 
-**Automation expand mode:** `/bmad-testarch-automate` and `TA` select expand by default. An explicit mode in the prompt selects red or expand. Unattended runs keep the invoked command's default when mode is unclear.
+**Automation expand mode:** `/bmad-testarch-automate` and `TA` select expand by default. An explicit mode in the prompt selects red or expand. Unattended runs use expand when mode is unclear.
 
 **Create sequence:**
 

package/skills/bmad-testarch-automate/red/instructions.md

@@ -26,8 +26,7 @@ This workflow uses **step-file architecture**:
 
 This instruction file owns red mode after canonical activation.
 Set `test_mode = red` when a direct runner loads this file without the shared router; keep `{skill-root}` canonical.
-Resolve red customization using `{skill-root}/../bmad-testarch-atdd/customize.toml` and the legacy ATDD overrides.
-When that sibling is absent, merge `{skill-root}/red/customize.toml` with `_bmad/custom/bmad-testarch-atdd.toml` and `.user.toml` manually and retain its workflow block.
+Resolve red customization by merging `{skill-root}/red/customize.toml` with `_bmad/custom/bmad-testarch-atdd.toml` and `.user.toml` manually and retain its workflow block.
 Entry activation and operation routing remain in `{skill-root}/SKILL.md`.
 
 ### 1. Configuration Loading

package/skills/bmad-testarch-automate/resources/test-generation-routing.md

@@ -7,33 +7,31 @@ These are separate from the worker execution mode (`tea_execution_mode`) and the
 ## 1. Choose the Operation and Mode
 
 Keep the original request and supplied files.
-Preserve `test_entry` from a compatibility entry, otherwise use `bmad-testarch-automate`.
+Use `bmad-testarch-automate` as `test_entry`. Preserve a legacy `testEntry` value when resuming an existing checkpoint. An AT menu invocation presets red mode; a single explicit user mode overrides that preset.
 Resolve explicit Create, Resume, Validate or Edit wording first.
 A request to generate tests means Create.
 In a headless or autonomous invocation, an unspecified operation defaults to Create without a menu.
 
 Start with `test_mode_defaulted = false`.
 A single explicit `red mode` or `expand mode` is authoritative.
-Otherwise acceptance tests before implementation, `write acceptance tests`, `acceptance test scaffolds`, ATDD, or the TDD red phase selects red; coverage expansion, tests for existing code, or automation selects expand.
+Otherwise an AT menu invocation selects red. Acceptance tests before implementation, `write acceptance tests`, `acceptance test scaffolds`, ATDD, or the TDD red phase also selects red; coverage expansion, tests for existing code, or automation selects expand.
 Treat the invoked command name as an entry default, separate from the user's task wording: mentioning `/bmad-testarch-automate` in an acceptance-test request cannot count as an expand signal.
-When no task mode signal is present, every run mode defaults to red through `bmad-testarch-atdd` and expand through the canonical entry.
-Interactive AT, TA and slash-command invocations with no task wording use those entry defaults without a mode question.
+When no task mode signal is present, default to expand.
 Ask once which mode to use only when explicit task mode signals conflict in an interactive run, including a request that names both `red mode` and `expand mode`.
-A headless or autonomous run with conflicting signals uses the same historical entry default without a question.
-For either entry-default fallback, set `test_mode_defaulted = true` and state the selected default in the final summary.
-An explicit mode in the user's request overrides the entry default.
+A headless or autonomous run with conflicting signals defaults to expand without a question.
+For a defaulted mode, set `test_mode_defaulted = true` and state the selected default in the final summary.
+An explicit mode in the user's request overrides the default.
 
 The following routing examples apply before customization activation:
 
-| Invocation                      | Task signal                 | Run mode                | Selected mode          | Mode question |
-| ------------------------------- | --------------------------- | ----------------------- | ---------------------- | ------------- |
-| AT or `/bmad-testarch-atdd`     | none                        | interactive             | red (entry default)    | no            |
-| TA or `/bmad-testarch-automate` | none                        | interactive             | expand (entry default) | no            |
-| `/bmad-testarch-automate`       | lets write acceptance tests | interactive or headless | red                    | no            |
-| `/bmad-testarch-automate`       | acceptance test scaffolds   | interactive or headless | red                    | no            |
-| either entry                    | red and expand task signals | interactive             | unresolved             | ask once      |
-| AT or `/bmad-testarch-atdd`     | red and expand task signals | headless                | red (entry default)    | no            |
-| TA or `/bmad-testarch-automate` | red and expand task signals | headless                | expand (entry default) | no            |
+| Invocation               | Task signal                 | Run mode                | Selected mode    | Mode question |
+| ------------------------ | --------------------------- | ----------------------- | ---------------- | ------------- |
+| `bmad-testarch-automate` | none                        | interactive             | expand (default) | no            |
+| `bmad-testarch-automate` | lets write acceptance tests | interactive or headless | red              | no            |
+| `bmad-testarch-automate` | acceptance test scaffolds   | interactive or headless | red              | no            |
+| `bmad-testarch-automate` | red and expand task signals | interactive             | unresolved       | ask once      |
+| `bmad-testarch-automate` | red and expand task signals | headless                | expand (default) | no            |
+| `bmad-tea` AT menu       | none                        | interactive or headless | red              | no            |
 
 For Resume with an exact checkpoint path, resolve it against the project root, verify that it exists and is readable, and retain it as `resume_checkpoint_path`. A missing supplied file stops before activation; do not search for a replacement. The checkpoint path itself is not a new target scope.
 Infer the original mode from that supplied checkpoint's `testMode` or its owning artifact folder: `atdd/` is red and `automate/` is expand; legacy `atdd-checklist-*.md` is red and `automation-summary.md` is expand.
@@ -45,12 +43,10 @@ Do not restart Create or execute a completed generation step on an explicit Resu
 
 ## 2. Choose Exactly One Customization Surface
 
-For red set `workflow-skill-root = {skill-root}/../bmad-testarch-atdd` and `workflow-skill-name = bmad-testarch-atdd`.
+For red set `workflow-skill-root = {skill-root}/red` and `workflow-skill-name = bmad-testarch-atdd` to preserve existing customization filenames.
 For expand set `workflow-skill-root = {skill-root}` and `workflow-skill-name = bmad-testarch-automate`.
-When the sibling red compatibility entry is absent, keep `workflow-skill-name = bmad-testarch-atdd` and use `{skill-root}/red/customize.toml` as the red defaults.
-Resolve the red defaults plus `_bmad/custom/bmad-testarch-atdd.toml` and `.user.toml` manually with the activation merge rules; the resolver's directory-name inference cannot resolve this alias from `red/`.
-Canonical-only installs can therefore run red with existing ATDD overrides.
-Record `workflow_customization_manual = true` for this fallback and retain the resolved workflow block for its terminal hook.
+Resolve `{skill-root}/red/customize.toml` plus `_bmad/custom/bmad-testarch-atdd.toml` and `.user.toml` manually with the activation merge rules; the resolver's directory-name inference cannot resolve this customization namespace from `red/`.
+Record `workflow_customization_manual = true` and retain the resolved workflow block for its terminal hook.
 Keep the resolver's workflow namespace and structural merge rules intact.
 Resolve only the selected surface's defaults, team file and user file.
 Red uses `_bmad/custom/bmad-testarch-atdd.toml` and `.user.toml`; expand uses `_bmad/custom/bmad-testarch-automate.toml` and `.user.toml`.

package/skills/bmad-testarch-evaluate/SKILL.md

@@ -63,7 +63,9 @@ Activation is complete. Begin the workflow below.
 
 ## Workflow
 
-Evaluate is one continuous loop over twelve stages, run inline rather than as separate step files: each stage's craft lives in its own `references/` guide, loaded when that stage is reached. Work under `{tea_evaluations_folder}` unless the adopter names another location. On resume, read the existing inspection record, `evaluation.json`, any `requirements.md`, any `<evaluation-folder>/ci/evaluation-ci-plan.json`, and any `{test_artifacts}/evaluate/<evaluationId>/gap-report.md` before choosing a stage. Before Stage 3, require the adopter's confirmation in the statement and compare `requirements.digest` with eval-quality's `digestBytes` over the committed file; otherwise return to intake. Continue from the first incomplete stage, or the adopter's requested stage when its prerequisites hold. `assets/README.md` says how to fill each template under `assets/`.
+Evaluate is one continuous loop over twelve stages, run inline rather than as separate step files: each stage's craft lives in its own `references/` guide, loaded when that stage is reached. Work under `{tea_evaluations_folder}` unless the adopter names another location. On resume, read the existing inspection record, `evaluation.json`, any `requirements.md`, any `authoring-log.md`, any `<evaluation-folder>/ci/evaluation-ci-plan.json`, and any `{test_artifacts}/evaluate/<evaluationId>/gap-report.md` before choosing a stage. Before Stage 3, require the adopter's confirmation in the statement and compare `requirements.digest` with eval-quality's `digestBytes` over the committed file; otherwise return to intake. Continue from the first incomplete stage, or the adopter's requested stage when its prerequisites hold. `assets/README.md` says how to fill each template under `assets/`.
+
+Read `references/authoring-routing.md` before delegating any authoring work. Use its bounded worker tasks and authoring ledger throughout the loop when the host supports subagents.
 
 Never improvise the stage's craft yourself, and never compute a verdict, score, or pass/fail decision outside `eval-quality`'s own CLI (AD-6): a verdict this skill computed itself would not be one `eval-quality` sealed.
 
@@ -97,7 +99,7 @@ Before the first `tea-evaluate check`, load `references/mutation.md` and author
 
 For an adopter installation, run `npm exec --prefix {tea_evaluations_folder} -- tea-evaluate check --evaluation <evaluation-folder>`, then `npm exec --prefix {tea_evaluations_folder} -- eval-quality compile --in <evaluation-folder>/contract.json --out <evaluation-folder>/compiled-contract.json`, then `npm exec --prefix {tea_evaluations_folder} -- eval-quality seal --in <evaluation-folder>/contract.json --out <evaluation-folder>/sealed-brief.json`. For TeA's own package, run `node cli/evaluate.js check --evaluation <evaluation-folder>`, then `./node_modules/.bin/eval-quality compile --in <evaluation-folder>/contract.json --out <evaluation-folder>/compiled-contract.json`, then `./node_modules/.bin/eval-quality seal --in <evaluation-folder>/contract.json --out <evaluation-folder>/sealed-brief.json` from the repository root. The local CLI and binary use that root's one eval-quality installation. Stop at the first nonzero exit. Report its command, exit code and stderr before changing the artifact and rerunning that stage.
 
-After seal succeeds, copy `assets/evaluation-folder.gitignore` to `<evaluation-folder>/.gitignore` before the first preflight creates `runs/`. For an adopter installation, run `npm exec --prefix {tea_evaluations_folder} -- tea-evaluate preflight --evaluation <evaluation-folder> --partition development`; for TeA's own package, run `node cli/evaluate.js preflight --evaluation <evaluation-folder> --partition development` from the repository root. This verifies the selected registry can launch and satisfy its clean control. The flag is required only when `evaluation.json` declares a `partitionPlan`, and a preflight with no `--partition` over one exits 64. Held-out preflight (`--partition held-out`) runs only after the development review. Stop and report the command, exit code and stderr on failure; complete adapter wiring only after preflight succeeds.
+After seal succeeds, copy `assets/evaluation-folder.gitignore` to `<evaluation-folder>/.gitignore` before the first preflight creates `runs/`. Before a live preflight, follow the Git isolation procedure in `references/run.md`; Git worktrees share refs even when their working files are separate. For an adopter installation, run `npm exec --prefix {tea_evaluations_folder} -- tea-evaluate preflight --evaluation <evaluation-folder> --partition development`; for TeA's own package, run `node cli/evaluate.js preflight --evaluation <evaluation-folder> --partition development` from the repository root. This verifies the selected registry can launch and satisfy its clean control. The flag is required only when `evaluation.json` declares a `partitionPlan`, and a preflight with no `--partition` over one exits 64. Held-out preflight (`--partition held-out`) runs only after the development review. Stop and report the command, exit code and stderr on failure; complete adapter wiring only after preflight succeeds.
 
 ### Stage 7: Evaluator
 
@@ -121,7 +123,7 @@ Interpret a weak result and close the gap. Load `references/gaps.md`.
 
 ### Stage 12: CI
 
-Inspect the adopter's repository, place each check in a tier, write `<evaluation-folder>/ci/evaluation-ci-plan.json` and hand it to `bmad-testarch-framework` with CI setup scope. The `bmad-testarch-ci` compatibility entry remains valid. Load `references/ci.md`.
+Inspect the adopter's repository, place each check in a tier, write `<evaluation-folder>/ci/evaluation-ci-plan.json` and hand it to `bmad-testarch-framework` with CI setup scope. Load `references/ci.md`.
 
 ## On Complete
 

package/skills/bmad-testarch-evaluate/assets/inspection-record.md

@@ -51,6 +51,6 @@ Stage 12 appends this section as each inspection finishes.
 - Release flow: `release.yml` on `v*` tags, with `docs/RELEASING.md` naming the tag as the gate.
 - Risk profile: one `critical` behavior (`contract.json`), about forty model calls per live run, nightly and release accepted and per pull request not (the adopter's answer), a missed defect ships within a day (`docs/RELEASING.md`).
 - Tier exits: `pr` 0; `scheduled` not run, `RESERVATION_MODEL_KEY` is absent on this machine; `release` 2, repair owned by Stage 3.
-- Hand-off status: framework skill invoked with CI scope and Create or Edit, or an open item such as a declined baseline or a missing `bmad-testarch-framework` (with no usable `bmad-testarch-ci` compatibility entry).
+- Hand-off status: framework skill invoked with CI scope and Create or Edit, or an open item such as a declined baseline or a missing `bmad-testarch-framework`.
 
 Replace this worked record with the inspected target's facts and source paths. Record the selected target kind and interface in `evaluation.json` alone.

package/skills/bmad-testarch-evaluate/references/authoring-routing.md

@@ -0,0 +1,29 @@
+# Authoring model routing
+
+Use economical subagents for bounded research and candidate drafting. The parent Test Architect owns requirements confirmation, corpus selection, contract and oracle decisions, artifact writes, every CLI gate, score interpretation, and the final report. A worker's answer is a proposal with file and line evidence. It is never a qualified probe or sealed verdict.
+
+## Select a worker at dispatch time
+
+Inspect the current host's available subagent models immediately before dispatch. On Claude, select the latest available Haiku tier. On Codex, select the latest available Luna tier. Do not put a versioned model ID in the dispatch rule or reuse a recorded ID as the next default. If the host does not expose that tier or an exact resolved model, do the task in the parent session and record the fallback. Do not silently substitute another model tier.
+
+Record the provider, requested tier, exact resolved model, host or CLI version when available, and the selection time in `<evaluation-folder>/authoring-log.md`. The logged versioned ID is an audit observation, not a model pin for later dispatches. Recheck availability for a later session.
+
+This routing applies to the agent **authoring** the evaluation. The target model, system prompt, evaluator framework, rubric judge, decoding settings, and isolation conditions are fixed scored conditions. Keep their recorded snapshots and values identical across clean and mutated arms. A model change to any scored condition needs a new comparable run, never an unrecorded worker substitution.
+
+When the adopter asks for the latest target model or model tier, resolve it from the current provider or host catalog before the first live preflight. Do not inherit a versioned adapter default from an older implementation, reuse a prior evaluation's model ID, or assume the host's configured default is current. Record the requested tier, source and time of resolution, exact ID passed to the target, and the same ID in evaluator conditions. Recheck before a new baseline; if the resolved ID changes, update the condition and repeat check, compile, seal, preflight, run, and score. Historical run records retain their original IDs.
+
+## Delegate bounded tasks
+
+Use at most two read-only workers at once. Give each a disjoint source scope, the confirmed requirements statement, a concrete question, a time bound, and this output shape: `candidate`, `source path and line`, `uncertainty`, and `files inspected`. Good tasks are entry-point inventory, failure-history search, candidate boundary cases, candidate mutation locations, and summaries of public evaluator documentation. Workers may draft a probe or oracle fragment as text, but the parent decides whether it enters the corpus or contract.
+
+Keep one writer: the parent. Instruct workers to avoid editing the repository, evaluation folder, policy, or run artifacts; launching targets; running `tea-evaluate` or `eval-quality`; or contacting other workers. Some hosts give subagents writable tools even for a read-only request. Pause parent writes during a worker group. Compare the scoped source and evaluation-file inventory and digests before dispatch and after every worker returns. If files changed, reject the affected drafts, identify the writer, and repair worker-attributed edits before continuing. Never send workers secrets, credentials, private user data, `corpus/held-out/`, a held-out plan, held-out results, or a complete held-out request. When a task cannot be split cleanly, keep it in the parent session.
+
+The parent checks every file and line claim before adopting it. Draft probes still pass `tea-evaluate check`, `eval-quality compile` and `seal`, preflight, scored `run`, and `score` at their normal stages. A cheap worker's confidence or self-reported pass does not replace any gate. If a draft fails a gate, record the failure and repair time in the authoring log.
+
+## Show authoring progress and cost
+
+Start an authoring log in `{test_artifacts}/evaluate/` before Stage 1 inspection, then carry it to `<evaluation-folder>/authoring-log.md` when that folder exists. Record each stage's start and completion time, its artifact paths, and its next gate. For each worker task, record dispatch and completion time, scope, requested tier, resolved model, outcome, retries, parent verification and repair time, and reported input/output tokens or cost when available. Write `unknown` for missing usage. Count parent work separately from worker work. On resume, read the existing log, mark any unfinished worker task interrupted, and continue with new entries rather than replacing prior timings. Keep this log outside `corpus/`, `probes/`, `mutations/`, and `runs/` so it does not alter a corpus digest or sealed run.
+
+For a long target run, use the runtime's progress command when available and report its current phase, completed/planned trials, whole-run elapsed time, and last heartbeat. Report scored trial usage separately from authoring usage; a subtotal is not full-run cost. Continue through `score` before reporting a verdict.
+
+To test savings, compare a parent-only authoring pass with a routed pass using the same confirmed requirements, target revision and model, scoring policy, evaluator conditions, and probe scope. Compare authoring wall time, reported tokens and cost, retries, parent repair time, and gate failures. Compare the resulting clean-control, seeded-defect, and held-out outcomes from eval-quality. Run time and target call cost are separate measurements; authoring routing alone does not shorten a scored target call. Record unknown usage explicitly and make no savings claim from incomplete cost data.

package/skills/bmad-testarch-evaluate/references/ci.md

@@ -1,6 +1,6 @@
 # CI
 
-Run this stage after the evaluation checks clean and a scored run exists (Stages 1 to 11). It writes `<evaluation-folder>/ci/evaluation-ci-plan.json`, the platform-neutral plan that is the only definition of which check runs when and what blocks, then hands the plan to `bmad-testarch-framework` with explicit CI setup scope. The `bmad-testarch-ci` compatibility entry remains valid. Never write a pipeline file here. The plan's schema and placement rules belong to the installed runtime, in `{tea_evaluations_folder}/node_modules/bmad-method-test-architecture-enterprise/cli/lib/evaluate/schemas/evaluation-ci-plan.schema.json` and `{tea_evaluations_folder}/node_modules/bmad-method-test-architecture-enterprise/cli/lib/evaluate/ci-plan.js` (`cli/lib/evaluate/...` from the repository root inside TeA's own package); read them there and copy neither. `npm exec --prefix {tea_evaluations_folder} -- tea-evaluate check --evaluation <evaluation-folder>` reports the plan's findings under the `ci-plan` rule family, so the command that validates the rest of the evaluation validates the plan.
+Run this stage after the evaluation checks clean and a scored run exists (Stages 1 to 11). It writes `<evaluation-folder>/ci/evaluation-ci-plan.json`, the platform-neutral plan that is the only definition of which check runs when and what blocks, then hands the plan to `bmad-testarch-framework` with explicit CI setup scope. Never write a pipeline file here. The plan's schema and placement rules belong to the installed runtime, in `{tea_evaluations_folder}/node_modules/bmad-method-test-architecture-enterprise/cli/lib/evaluate/schemas/evaluation-ci-plan.schema.json` and `{tea_evaluations_folder}/node_modules/bmad-method-test-architecture-enterprise/cli/lib/evaluate/ci-plan.js` (`cli/lib/evaluate/...` from the repository root inside TeA's own package); read them there and copy neither. `npm exec --prefix {tea_evaluations_folder} -- tea-evaluate check --evaluation <evaluation-folder>` reports the plan's findings under the `ci-plan` rule family, so the command that validates the rest of the evaluation validates the plan.
 
 If `check` reports a finding outside the `ci-plan` family, or no scored run exists, name the missing prerequisite and return to its stage before inspecting CI.
 
@@ -48,7 +48,7 @@ The `release` tier is the usual home, since its event is the one that starts the
 Name in the `trigger` of every check on the gating tier each event that starts the gated job's workflow.
 When that workflow also starts on `workflow_dispatch`, as a nightly `deploy.yml` does, list `manual-dispatch` beside `release`, since the CI skill refuses a gate whose job already ran on an event where the tier's evaluation job is skipped.
 The jobs a tier gates are the union of `gates` over the checks the plan places on that tier, so name a job once, on any check of the tier, and a name repeated across the tier's checks is merged.
-`check` accepts a job id and reports any other name under rule `gates`; it cannot tell whether the repository holds that job, which `bmad-testarch-ci` answers when it renders the wait.
+`check` accepts a job id and reports any other name under rule `gates`; it cannot tell whether the repository holds that job, which `bmad-testarch-framework` answers when it renders the wait.
 The wait holds best when the job lives in the workflow file the CI skill edits, which holds the evaluation jobs too: the job then waits through `needs`, and the step refuses the plan when the job already ran in a run where the tier's evaluation job is skipped, such as a deploy on every `push` beside an evaluation job guarded to tags, or when the evaluation job runs on a run the job did not run on before, such as a `workflow_dispatch` the plan adds to a tag-push release file, while a run the render adds that the evaluation job skips is skipped through the wait and is no conflict.
 A job in another workflow file waits through a `workflow_run` trigger, which the step refuses for a pull request tier, for a tier whose evaluation job carries a ref or cron guard, and for a job with its own `needs`, `if:` or ref and event contexts, so hand the CI skill the workflow file that holds the job when you can.
 Leave `gates` out when the inspection found no such job or the adopter declined the gate, and say which in the `reason` of the release entries.
@@ -62,7 +62,7 @@ Place the gameability arm (`gameability`), contract-source freshness (part of `c
 
 Put the live checks where the inspection found a secret and an event: a live `preflight-live` on `merge` when the target needs no secret and the merge flow allows its run time, the held-out partition (`held-out`) on `scheduled` and `release`, judge calibration (`judge-calibration`) on `scheduled` and `release` whenever the contract declares a rubric, and `twin-run` and `strength-comparison` with them. Never place a live check on `pr`. A skill or agent target always needs the runner's model credentials, so its live tiers are `scheduled`, `release` and manual dispatch only; its `trigger` lists `schedule` and `manual-dispatch` for `scheduled` and `release` for `release`, with `manual-dispatch` beside it when the gated workflow starts on `workflow_dispatch`. Without a schedule trigger in the repository, say so in the `reason` and put the set on `release`.
 
-Declare the runner's credential keys as `permittedEnvironmentKeys` through the target's registry `environmentKeys`, which Stage 6 scaffolds and the runtime compiles into the authorization: read them, and add a key name only when a live check needs a credential the registry omits. Keys carry names alone. The plan carries no credential and `bmad-testarch-ci` wires none, so give the adopter the same names as the CI secrets to add for the live tiers.
+Declare the runner's credential keys as `permittedEnvironmentKeys` through the target's registry `environmentKeys`, which Stage 6 scaffolds and the runtime compiles into the authorization: read them, and add a key name only when a live check needs a credential the registry omits. Keys carry names alone. The plan carries no credential and Framework CI setup wires none, so give the adopter the same names as the CI secrets to add for the live tiers.
 
 On Linux the live checks also need the target's registry entry to carry the `egress` authorization for the hosts it reaches.
 A confined Linux target runs in a network namespace with a loopback and nothing else, so read the entry's `egress` and add the model provider's host, port and the addresses the host resolves to now when an item is missing, as the example shows.
@@ -250,7 +250,7 @@ With no accepted baseline, skip the tier runs and record that in the `## CI` sec
 
 ## Hand the plan to framework setup with CI scope
 
-Invoke `bmad-testarch-framework` with explicit CI setup scope and Edit operation on the adopter's pipeline file, naming the plan's path, or Create when the inspection found no pipeline file. The `bmad-testarch-ci` compatibility entry selects the same scope and supports the same operations. Its CI phase detects `ci/evaluation-ci-plan.json` and validates it; the rendering rules belong to `skills/bmad-testarch-framework/ci/steps-c/step-03b-render-evaluation-plans.md` from TEA's repository root. In an installed skill set, resolve it as `{skill-root}/../bmad-testarch-framework/ci/steps-c/step-03b-render-evaluation-plans.md`, where `{skill-root}` is the Evaluate skill root. Setup scope and operation are independent, so this handoff selects CI and preserves an existing framework. CI Edit validates the changed pipeline syntax, injection safety and evaluation-plan rendering/gates; it does not require the adopter's full suite to pass or activate framework hooks. CI Create uses the existing framework contract and its execution gate. Name in the request the concrete event of this repository for each tier it should render, such as `release`: the push of `v*` tags that starts `.github/workflows/release.yml`.
+Invoke `bmad-testarch-framework` with explicit CI setup scope and Edit operation on the adopter's pipeline file, naming the plan's path, or Create when the inspection found no pipeline file. Its CI phase detects `ci/evaluation-ci-plan.json` and validates it; the rendering rules belong to `skills/bmad-testarch-framework/ci/steps-c/step-03b-render-evaluation-plans.md` from TEA's repository root. In an installed skill set, resolve it as `{skill-root}/../bmad-testarch-framework/ci/steps-c/step-03b-render-evaluation-plans.md`, where `{skill-root}` is the Evaluate skill root. Setup scope and operation are independent, so this handoff selects CI and preserves an existing framework. CI Edit validates the changed pipeline syntax, injection safety and evaluation-plan rendering/gates; it does not require the adopter's full suite to pass or activate framework hooks. CI Create uses the existing framework contract and its execution gate. Name in the request the concrete event of this repository for each tier it should render, such as `release`: the push of `v*` tags that starts `.github/workflows/release.yml`.
 That step renders each `gates` entry as a wait of the named job on the evaluation job of the tier, and its summary reports the edit to the job, a name that matches no job and a conflicting gate, so relay that report to the adopter.
 When the plan gates a job, invoke it on the workflow file that holds that job.
-When that skill is not installed, give the adopter the request and the plan's path and record the hand-off as an open item in the inspection record. Stage 12 is complete when the plan passes `check` and the hand-off is made; a declined baseline or a missing `bmad-testarch-framework` (with no usable `bmad-testarch-ci` compatibility entry) stays a named open item in the `## CI` section and does not reopen the stage. Finish with the closing summary: the placement table, the deviations and their reasons, the secrets the live tiers need (the names from `environmentKeys`), the gates adopted, the baseline still to accept, every tier that exited non-zero with the stage that owns its repair, and each publish or deploy job that waits for the evaluation job through `gates`, with every such job the plan leaves ungated and the reason.
+When that skill is not installed, give the adopter the request and the plan's path and record the hand-off as an open item in the inspection record. Stage 12 is complete when the plan passes `check` and the hand-off is made; a declined baseline or a missing `bmad-testarch-framework` stays a named open item in the `## CI` section and does not reopen the stage. Finish with the closing summary: the placement table, the deviations and their reasons, the secrets the live tiers need (the names from `environmentKeys`), the gates adopted, the baseline still to accept, every tier that exited non-zero with the stage that owns its repair, and each publish or deploy job that waits for the evaluation job through `gates`, with every such job the plan leaves ungated and the reason.

package/skills/bmad-testarch-evaluate/references/run.md

@@ -2,6 +2,14 @@
 
 Run from the sealed evaluation folder after its target registry, evaluator, mutations, policy and conditions pass `check`. Save each command, exit status, stderr and resulting artifact path in the run log. Stop the command sequence on a nonzero stage exit; retain diagnostics and route the failure through the gaps guide before retrying. eval-quality alone decides verdict and strength.
 
+## Protect the target's Git state
+
+A `git` workspace makes detached worktrees from `launch.root`. Every worktree of one repository shares its Git common directory, including refs, config and hooks. When confinement is disabled, Evaluate checks that shared state before and after qualification and trials. A branch creation, commit, rebase, fetch, push that updates tracking refs, worktree addition, hook edit, or test that writes refs in another worktree can stop an unconfined run with exit 12 after a costly target call. Separate worktrees alone do not isolate this state.
+
+Before the first live preflight, resolve `launch.root` and run `git -C <launch-root> rev-parse --git-common-dir`. Record the resolved common directory and target commit in the run log. If development or CI-related Git work must continue in the same repository during a long evaluation, use a dedicated clone with its own `.git` directory as `launch.root`. Confirm its common directory differs from the active development repository, update `evaluation.json`, then repeat `check`, `compile`, `seal` and `preflight`. A local clone may share object files but has independent refs; do not add a worktree to the active repository as the substitute.
+
+When the target uses the active repository, reserve a repository-wide Git quiet period before the first live preflight and keep it through `run` and `score`. During that period, do not commit, branch, rebase, fetch, push, add worktrees, edit hooks or config, or run tools that change refs in any worktree sharing its common directory. Read-only status inspection and `tea-evaluate status --follow` can continue. If a run stops for shared Git state, record its command, exit 12 and diagnostic as an infrastructure stop, establish an independent clone or quiet period, and rerun; it has no scored verdict.
+
 ## Install the private latest-spec runtime
 
 In `{tea_evaluations_folder}`, create a private `package.json` with TeA and eval-quality as `devDependencies` at the `latest` spec. The adopter decides whether to track this manifest and its lockfile for reproducibility. Keep the installed versions in the run log. Node >=22.20.0 is required. Install with `npm install --prefix {tea_evaluations_folder}`. Stage 6 installs `assets/evaluation-folder.gitignore` as `<evaluation-folder>/.gitignore` before the first preflight; verify that it still ignores `runs/`, `compiled-contract.json` and `sealed-brief.json` before this run. When `{project-root}` is TeA's own package, invoke `node cli/evaluate.js` from the repository root for TeA commands so the local source is tested. Use the same local engine installation for `eval-quality`.
@@ -56,6 +64,17 @@ npm exec --prefix {tea_evaluations_folder} -- tea-evaluate score --evaluation <e
 
 Use the `invocationId` emitted by `run`; it names `runs/<invocationId>/` and is the value `score --run` accepts. Each trial set has its own `runId`, which is a different identifier. The runtime qualifies mutations against a passing baseline, calibrates any rubric judge, qualifies a sealed-brief agent evaluator on the clean and mutated arms, executes clean and mutated trials through the chosen evaluator, verifies rollback, and seals records and isolation manifests. `score` delegates every probe to eval-quality and persists per-probe diagnostics under `runs/<invocationId>/scores/<scoreInvocationId>/`, plus evidence artifacts, the run-wide `strength-aggregate.json`, `interpretation.json`, `partitions.json` and `gap-view.json`. Preserve both the command exit and each per-probe exit. A clean control should resolve `passed-clean-control` and the seeded defect `caught`; read those states from the evidence artifact. If a development `score` exits 3 with no artifact, read its persisted `score.json`, stdout and stderr diagnostics and route the fault through the gaps guide. For a held-out fault, read only `gap-view.json` and reproduce the class failure in development before inspecting diagnostics.
 
+For a long run, use its invocation ID from another terminal to read progress without disturbing the run:
+
+```sh
+npm exec --prefix {tea_evaluations_folder} -- tea-evaluate status --evaluation <evaluation-folder> --run <invocationId>
+npm exec --prefix {tea_evaluations_folder} -- tea-evaluate status --evaluation <evaluation-folder> --run <invocationId> --follow
+```
+
+Inside TeA, use `node cli/evaluate.js status` with the same arguments. `status` reads the current phase, time spent in that phase, completed and planned trials, whole-run elapsed time, completed phase durations, last heartbeat, and trial usage from the run directory. `--follow` keeps reporting changes until the run ends. The running `run` command also prints periodic heartbeat lines during a long call. If a heartbeat is old, report when it was last seen without claiming the process is still alive. Show the whole-run elapsed time alongside phase timing; the sum of trial durations omits qualification and preflight. Count a shared arm's trials once when reporting totals.
+
+Usage in progress covers scored trials only. Qualification and preflight costs are not fully captured, so full-run cost is unknown even when all trials report. If a trial call lacks complete usage, trial cost is also unknown; the reported amount is a subtotal. An explicit reported zero is a measured zero. Progress carries no verdict and provides no ETA. Continue through `score` to read the evaluation result.
+
 ## Record a before state
 
 A target with known defects fails its clean controls, so `run` stops with exit 11 on the first. Record that starting point with `--before-state` and keep the ordinary run for the fixed target.

package/skills/bmad-testarch-framework/SKILL.md

@@ -68,9 +68,9 @@ Activation is complete. Begin the workflow below.
 
 ## Workflow Architecture
 
-The existing framework steps at the skill root and the CI steps under `ci/` share scope and operation routing. `bmad-testarch-ci` is the compatibility entry point with CI scope preset. Both installed names and the TF/CI menu codes remain available.
+The existing framework steps at the skill root and the CI steps under `ci/` share scope and operation routing. Select CI setup by asking `bmad-testarch-framework` for CI scope.
 
-Create and edit CI phases detect `ci/evaluation-ci-plan.json` and render it through `{skill-root}/ci/steps-c/step-03b-render-evaluation-plans.md`. Evaluate can continue invoking `bmad-testarch-ci` in create or edit mode.
+Create and edit CI phases detect `ci/evaluation-ci-plan.json` and render it through `{skill-root}/ci/steps-c/step-03b-render-evaluation-plans.md`. Evaluate invokes `bmad-testarch-framework` with CI scope in create or edit mode.
 
 ## Initialization Sequence
 

package/skills/bmad-testarch-framework/checklist.md

@@ -266,9 +266,9 @@ Per `playwright-utils-mandate.md`. Skip for Maestro, Cypress, and non-Playwright
 
 ### Workflow Dependencies
 
-- [ ] Can proceed to `ci` workflow after completion
+- [ ] Can proceed to Framework CI scope after completion
 - [ ] Can proceed to `test-design` workflow after completion
-- [ ] Can proceed to `atdd` workflow after completion
+- [ ] Can proceed to Automate red mode after completion
 - [ ] Framework setup compatible with downstream workflows
 
 ---
@@ -301,9 +301,9 @@ Per `playwright-utils-mandate.md`. Skip for Maestro, Cypress, and non-Playwright
 
 **Recommended next workflows:**
 
-1. [ ] Run `ci` workflow to set up CI/CD pipeline
+1. [ ] Run Framework with CI scope to set up the CI/CD pipeline
 2. [ ] Run `test-design` workflow to plan test coverage
-3. [ ] Run `atdd` workflow when ready to develop stories
+3. [ ] Run Automate in red mode when ready to develop stories
 
 ---
 

package/skills/bmad-testarch-framework/ci/checklist.md

@@ -193,7 +193,7 @@ Note: CI setup is typically a one-time task per repo and can be run any time aft
 ### Workflow Dependencies
 
 - [ ] Existing or newly created framework validated against the agreed contract in this run (CI-only existing; both-scope new or reused)
-- [ ] Can proceed to `atdd` workflow after CI setup
+- [ ] Can proceed to Automate red mode after CI setup
 - [ ] Can proceed to `automate` workflow
 - [ ] CI integrates with `gate` workflow
 
@@ -224,7 +224,7 @@ Note: CI setup is typically a one-time task per repo and can be run any time aft
 
 **Recommended next workflows:**
 
-1. [ ] Run `atdd` workflow for test generation
+1. [ ] Run Automate in red mode for acceptance test generation
 2. [ ] Run `automate` workflow for coverage expansion
 3. [ ] Run `gate` workflow for quality gates
 

package/skills/bmad-testarch-framework/ci/instructions.md

@@ -33,7 +33,7 @@ From `workflow.yaml`, resolve:
 
 ### 2. Canonical CI Activation
 
-If invoked through legacy workflow metadata, preset `setup_scope = ci` and `setup_entry = bmad-testarch-ci`, then load `{skill-root}/SKILL.md` and its shared router before executing a phase. Keep the original operation and legacy CI customization. CI instructions, templates and steps resolve under `{skill-root}/ci/`.
+If invoked through legacy workflow metadata, preset `setup_scope = ci`, then load `{skill-root}/SKILL.md` and its shared router before executing a phase. Keep the original operation and CI customization. CI instructions, templates and steps resolve under `{skill-root}/ci/`.
 
 ### 3. First Step
 

package/skills/bmad-testarch-framework/resources/setup-routing.md

@@ -1,6 +1,6 @@
 # Shared Setup Router
 
-Read this resource and `{skill-root}/resources/setup-state.md` completely before activation. `{skill-root}` always names `bmad-testarch-framework`; `{ci-skill-root}` names its sibling `bmad-testarch-ci` when installed. Keep the original request and supplied artifact paths through every handoff.
+Read this resource and `{skill-root}/resources/setup-state.md` completely before activation. `{skill-root}` always names `bmad-testarch-framework`. Keep the original request and supplied artifact paths through every handoff.
 
 ## 1. Read-Only Request Gate: Before Activation
 
@@ -11,7 +11,7 @@ Read effective config and all applicable run/phase history and execute `setup-st
 Resolve `setup_scope` as `framework`, `ci`, or `both`:
 
 - Explicit scope and a supplied operation take priority. Requests mentioning framework and pipeline setup select `both`.
-- A CI pipeline, quality gates, CI artifact target, or the CI entry/menu code presets `ci`.
+- A CI pipeline, quality gates, or CI artifact target selects `ci`.
 - Framework-only wording or a supplied framework artifact selects `framework`.
 - For setup requests whose CI intent remains unclear, ask exactly once: **“Do you want CI too?”** A yes selects `both`; a no selects `framework`. Record `ci_scope_answered = true`. Wait for the answer before any project writes, including custom activation hooks. An unattended/headless run with no scope answer defaults to `framework`, records `ci_scope_defaulted = true`, and says in its completion summary that CI was not included. Explicit or inferred CI intent still selects `ci` or `both` in unattended runs.
 
@@ -27,8 +27,8 @@ Before SKILL.md executes prepend hooks or greets, resolve settings for every req
 
 When scope includes CI:
 
-1. Start with canonical-owned CI defaults: `ci_platform = auto`, empty `activation_steps_prepend`, `activation_steps_append`, `persistent_facts`, and `on_complete`. These defaults make canonical CI functional when the alias directory is absent.
-2. If `{ci-skill-root}/customize.toml` exists, resolve it through `uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {ci-skill-root} --project-root {project-root} --key workflow`. If the alias is absent or the resolver fails, structurally merge the canonical-owned CI defaults, the legacy defaults when present, `_bmad/custom/bmad-testarch-ci.toml`, and `_bmad/custom/bmad-testarch-ci.user.toml`, skipping missing files. All legacy overrides, including migrated platform settings, remain effective even without the installed alias.
+1. Start with CI defaults: `ci_platform = auto`, empty `activation_steps_prepend`, `activation_steps_append`, `persistent_facts`, and `on_complete`.
+2. Structurally merge the CI defaults, `_bmad/custom/bmad-testarch-ci.toml`, and `_bmad/custom/bmad-testarch-ci.user.toml`, skipping missing files. Existing CI overrides, including migrated platform settings, remain effective.
 3. Store the result as `ci_workflow`. SKILL.md executes applicable prepend entries before greeting, loads applicable facts/globs in lexical order, and executes append entries after greeting through `setup-state.md` section 3's individual durable hook protocol. On Resume, resolve current settings and reload applicable facts; skip completed hook entries and halt on uncertain started entries. Save each applicable phase in `activation_completed` only after its activation succeeds. This section resolves settings; it does not replay activation at phase or worker handoffs.
 4. Framework steps use canonical `workflow`. CI steps read `ci_workflow` for their legacy hooks/facts and the effective platform below. Keep `{skill-root}` bound to the canonical directory for every CI asset.
 

package/skills/bmad-testarch-test-design/checklist.md

@@ -188,11 +188,11 @@
 
 ### Workflow Dependencies
 
-- [ ] Can proceed to `/bmad-testarch-atdd` workflow with P0 scenarios
-- [ ] `/bmad-testarch-atdd` is a separate workflow and must be run explicitly (not auto-run)
+- [ ] Can proceed to `/bmad-testarch-automate` red mode with P0 scenarios
+- [ ] `/bmad-testarch-automate` is a separate workflow and must be run explicitly (not auto-run)
 - [ ] Can proceed to `automate` workflow with full coverage plan
 - [ ] Risk assessment informs `gate` workflow criteria
-- [ ] Integrates with `ci` workflow execution order
+- [ ] Integrates with Framework CI scope execution order
 
 ## Accountability & Logistics
 
@@ -415,15 +415,15 @@
 1. [ ] Review risk assessment with team
 2. [ ] Prioritize mitigation for high-priority risks (score ≥6)
 3. [ ] Allocate resources per estimates
-4. [ ] Run `/bmad-testarch-atdd` workflow to generate P0 tests (separate workflow; not auto-run)
+4. [ ] Run `/bmad-testarch-automate` in red mode to generate P0 tests
 5. [ ] Set up test data factories and fixtures
 6. [ ] Schedule team review of test design document
 
 **Recommended next workflows:**
 
-1. [ ] Run `atdd` workflow for P0 test generation
+1. [ ] Run Automate in red mode for P0 test generation
 2. [ ] Run `framework` workflow if not already done
-3. [ ] Run `ci` workflow to configure pipeline stages
+3. [ ] Run Framework with CI scope to configure pipeline stages
 
 ## Rollback Procedure
 

package/skills/bmad-testarch-test-design/resources/test-design-epic-3.example.md

@@ -258,7 +258,7 @@ P0, P1, P2, and P3 describe priority. Execution timing is defined separately bel
 
 ## Follow-on Workflows
 
-- Run `/bmad-testarch-atdd` explicitly for the four P0 scenarios.
+- Run `/bmad-testarch-automate` in red mode explicitly for the four P0 scenarios.
 - Run `/bmad-testarch-automate` for the remaining functional coverage after implementation exists.
 - Run `/bmad-testarch-nfr` when evidence exists for all four NFR domains.
 - Run `/bmad-testarch-trace` to map the approved oracle and apply the release gate.

package/skills/bmad-testarch-test-design/test-design-template.md

@@ -290,7 +290,7 @@ Do not re-list the individual tests here. They are already in the coverage plan.
 
 ## Follow-on Workflows (Manual)
 
-- Run `/bmad-testarch-atdd` to generate failing P0 tests (separate workflow; not auto-run).
+- Run `/bmad-testarch-automate` in red mode to generate failing P0 tests (separate workflow; not auto-run).
 - Run `/bmad-testarch-automate` for broader coverage once implementation exists.
 
 ---

package/skills/bmad-testarch-trace/checklist.md

@@ -16,7 +16,7 @@ This checklist covers **two sequential phases**:
 
 - [ ] A coverage oracle is available or inferred (formal requirements, spec, resolvable external pointer, or synthetic journeys)
 - [ ] Test suite exists (or gaps are acknowledged and documented)
-- [ ] If tests are missing, recommend `/bmad-testarch-atdd` (trace does not run it automatically)
+- [ ] If tests are missing, recommend `/bmad-testarch-automate` with the applicable red or expand mode (trace does not run it automatically)
 - [ ] Test directory path is correct (`test_dir` variable)
 - [ ] Story file is accessible (if using BMad mode)
 - [ ] Knowledge base is loaded (test-priorities, traceability, risk-governance)
@@ -673,7 +673,7 @@ This list is the definition of waiver validity. `steps-c/step-05-gate-decision.m
 
 - If PASS (both phases): Proceed to deployment
 - If WARN/CONCERNS: Address gaps/issues, proceed with monitoring
-- If FAIL (either phase): Run `/bmad-testarch-atdd` for missing tests, fix issues, re-run `/bmad-testarch-trace`
+- If FAIL (either phase): Run `/bmad-testarch-automate` for missing tests, fix issues, re-run `/bmad-testarch-trace`
 - If WAIVED: Deploy with approved waiver, schedule remediation
 
 ---

package/skills/bmad-testarch-trace/steps-c/step-04-analyze-gaps.md

@@ -374,7 +374,7 @@ const recommendations = [];
 if (criticalGaps.length > 0) {
   recommendations.push({
     priority: 'URGENT',
-    action: `Run /bmad-testarch-atdd for ${criticalGaps.length} P0 requirements`,
+    action: `Run /bmad-testarch-automate for ${criticalGaps.length} P0 requirements: red mode where behavior is missing; expand mode where behavior exists but tests are incomplete`,
     requirements: criticalGaps.map((r) => r.id),
   });
 }

package/skills/bmad-testarch-trace/trace-template.md

@@ -29,7 +29,7 @@ oracleLedger: []
 
 ---
 
-Note: This workflow does not generate tests. If gaps exist, run `/bmad-testarch-atdd` or `/bmad-testarch-automate` to create coverage.
+Note: This workflow does not generate tests. If gaps exist, run `/bmad-testarch-automate` in red mode before implementation or expand mode for existing code.
 
 ## PHASE 1: REQUIREMENTS TRACEABILITY
 

package/skills/bmod-tea/bmod.toml

@@ -2,14 +2,12 @@
 
 [bmod]
 code = "tea"
-version = "2.0.2"
+version = "2.0.3-next.0"
 update_source = "github:bmad-code-org/bmad-method-test-architecture-enterprise/skills"
 skills = [
   "bmad-tea",
   "bmad-teach-me-testing",
-  "bmad-testarch-atdd",
   "bmad-testarch-automate",
-  "bmad-testarch-ci",
   "bmad-testarch-evaluate",
   "bmad-testarch-framework",
   "bmad-testarch-nfr",
@@ -22,7 +20,7 @@ pre_install_message = ""
 post_install_message = '''
 TEA is ready. Talk to Murat (bmad-tea) or start with Test Design (bmad-testarch-test-design).
 
-Playwright Utils, Pact.js Utils, the Playwright CLI or MCP servers, and the SmartBear MCP each need their own install. Test Framework (bmad-testarch-framework) installs the utils packages and owns framework and CI setup. Continuous Integration (bmad-testarch-ci) remains its CI entry. Test Automation (bmad-testarch-automate) owns red and expand test generation with run-and-heal enabled by default; ATDD (bmad-testarch-atdd) starts red mode. Existing commands and customizations keep working. Ask bmad how to set up the rest.
+Playwright Utils, Pact.js Utils, the Playwright CLI or MCP servers, and the SmartBear MCP each need their own install. Test Framework (bmad-testarch-framework) installs the utils packages and owns framework and CI setup. Test Automation (bmad-testarch-automate) owns red and expand test generation with run-and-heal enabled by default. Existing CI and ATDD customizations keep working through their respective modes. Ask bmad how to set up the rest.
 '''
 
 # Asked by `bmad setup` in this order. Members read each answer as modules.tea.<key>.

package/skills/bmod-tea/help/help.md

@@ -8,9 +8,7 @@ This document covers the skills of the `tea` module: what each one gives the use
 - `bmad-teach-me-testing`: teaches testing fundamentals in 7 sessions (TEA Academy), with a progress file, session notes and a completion summary. Recommend it to someone learning testing, at any phase.
 - `bmad-testarch-test-design`: risk-based test planning, producing a test design document. Recommend it during solutioning, before tests or a framework exist. Afterwards offer `bmad-testarch-framework`.
 - `bmad-testarch-framework`: owns production-ready framework and CI setup, with framework-only, CI-only, or both scope. It installs Playwright Utils or Pact.js Utils when enabled. Recommend it during solutioning, after test design. When CI scope cannot be inferred from the request, interactive runs ask whether to include CI. Unattended runs default to framework only and state in the summary that CI was excluded.
-- `bmad-testarch-ci`: starts the framework skill with CI scope preset. Recommend it when the user asks only for CI. It keeps existing CI customizations and saved progress and offers framework setup in the same run when a framework is missing.
-- `bmad-testarch-atdd`: starts the combined test-generation skill in red mode, writes failing acceptance tests and an ATDD checklist before a story is implemented, and verifies the intended missing behavior. Recommend it after a story is created. Afterwards offer the dev story skill.
-- `bmad-testarch-automate`: owns test generation in red or expand mode. Expand mode writes tests for implemented code, runs them, heals test defects for up to three rounds by default, and reports product defects. Recommend it during implementation, after ATDD or once code exists. Recommend it with red mode when the user asks for acceptance tests before implementation.
+- `bmad-testarch-automate`: owns test generation in red or expand mode. Red mode writes failing acceptance tests and an ATDD checklist before implementation, then verifies the intended missing behavior. Expand mode writes tests for implemented code, runs them, heals test defects for up to three rounds by default, and reports product defects. Recommend red mode after a story is created and expand mode once code exists.
 - `bmad-testarch-evaluate`: builds and runs a scored, evidence-backed evaluation of an agent, skill, workflow or tool-use system. Recommend it after automation when the target's behavior needs proof. Afterwards offer `bmad-testarch-framework` with CI scope to enforce it.
 - `bmad-testarch-test-review`: audits test quality with a 0-100 score and a review report. Recommend it after tests are written. Afterwards offer `bmad-testarch-trace`.
 - `bmad-testarch-nfr`: audits the evidence for non-functional requirements and writes an NFR report. Recommend it after automation, before a release.

package/skills/bmod-tea/help/integrations.md

@@ -6,7 +6,7 @@ Each setup answer is `modules.tea.<key>` in `_bmad/config.toml`. `bmad setup tea
 
 - `test_stack_type = "auto"` detects the project type from manifest files. Mobile: `.maestro/` or `maestro/` flows, `app.json` with expo or react-native, `Podfile`, `android/app/build.gradle`, `*.xcodeproj`, `pubspec.yaml`. Frontend: `package.json` with react, vue or angular, `playwright.config.*`, `vite.config.*`. Backend: `pyproject.toml`, `pom.xml`, `go.mod`, `*.csproj`, `Gemfile`, `Cargo.toml`. Full-stack: both frontend and backend indicators. Mobile is checked first, because a React Native project also has `package.json` with react.
 - `test_framework = "auto"` detects the framework the same way.
-- The CI platform is detected by `bmad-testarch-ci` from `.github/workflows/`, `.gitlab-ci.yml`, `Jenkinsfile`, `azure-pipelines.yml`, `.harness/` or `.circleci/config.yml`. To fix one, set `ci_platform` in `_bmad/custom/bmad-testarch-ci.toml`.
+- The CI platform is detected by `bmad-testarch-framework` from `.github/workflows/`, `.gitlab-ci.yml`, `Jenkinsfile`, `azure-pipelines.yml`, `.harness/` or `.circleci/config.yml`. To override detection, set `ci_platform` in `_bmad/custom/bmad-testarch-framework.toml`.
 
 ## Execution mode