bmad-method-test-architecture-enterprise 2.0.4-next.4 → 3.0.0

package/cli/trace.js

@@ -50,8 +50,8 @@ function execute(options, registerOutputGuard = () => {}) {
   const levels = options.coverageLevels.split(',').map((level) => level.trim().toLowerCase());
   if (levels.length === 0 || levels.some((level) => !['e2e', 'api', 'component', 'unit', 'live'].includes(level)))
     throw new Error('--coverage-levels must list e2e, api, component, unit, or live.');
-  const skillRoot = resolveWorkflowSkill({ projectRoot, skillName: 'bmad-testarch-trace', skillRoot: options.skillRoot });
-  const resolvedConfig = resolveTeaConfig({ projectRoot, skillRoot, skillName: 'bmad-testarch-trace' });
+  const skillRoot = resolveWorkflowSkill({ projectRoot, skillName: 'bmad-tea-trace', skillRoot: options.skillRoot });
+  const resolvedConfig = resolveTeaConfig({ projectRoot, skillRoot, skillName: 'bmad-tea-trace' });
   const rawArtifacts = resolvedConfig.configSnapshot.modules.tea.test_artifacts;
   if (typeof rawArtifacts !== 'string' || !rawArtifacts.trim())
     throw new Error('test_artifacts in the TEA config must be a nonempty string.');

package/cli/transcript-runner.js

@@ -17,7 +17,7 @@
  * state a session needs across turns is whatever the agent (or, in a scripted
  * proof, the stand-in for one) chooses to leave in the workspace. That is what
  * keeps this command reusable for a story this one does not know about:
- * Story 6.11 measures `bmad-teach-me-testing`, a real multi-turn teaching
+ * Story 6.11 measures `bmad-tea-teach-me-testing`, a real multi-turn teaching
  * session, through the same engine and the same runner.
  *
  * The prompt belongs to whichever caller is driving the session — the

package/package.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://json.schemastore.org/package.json",
   "name": "bmad-method-test-architecture-enterprise",
-  "version": "2.0.4-next.4",
+  "version": "3.0.0",
   "description": "Master Test Architect for quality strategy, test automation, and release gates",
   "keywords": [
     "bmad",
@@ -38,6 +38,7 @@
     "tea-evaluate": "cli/evaluate.js",
     "tea-fragment-selection-runner": "cli/fragment-selection-runner.js",
     "tea-framework": "cli/framework.js",
+    "tea-migrate-customizations": "cli/migrate-customizations.js",
     "tea-nfr": "cli/nfr.js",
     "tea-nfr-runner": "cli/nfr-runner.js",
     "tea-routing-runner": "cli/routing-runner.js",
@@ -94,7 +95,7 @@
     "release:minor": "gh workflow run publish.yaml -f channel=latest -f bump=minor",
     "release:next": "gh workflow run publish.yaml -f channel=next",
     "release:patch": "gh workflow run publish.yaml -f channel=latest -f bump=patch",
-    "test": "npm run test:conflict-markers && npm run test:schemas && npm run test:install && npm run test:evaluate-guidance && npm run test:evaluate-authoring && npm run test:evaluate-gap-loop && npm run test:evaluate-dogfood && npm run test:evaluate-check && npm run test:evaluate-compare && npm run test:evaluate-before-state && npm run test:evaluate-ci-gates && npm run test:evaluate-ci-tiers && npm run test:evaluate-ci-repositories:tagged-release-pr && npm run test:evaluate-ci-repositories:tagged-release-merge && npm run test:evaluate-ci-repositories:tagged-release-release && npm run test:evaluate-ci-repositories:nightly-deploy-pr && npm run test:evaluate-ci-repositories:nightly-deploy-merge && npm run test:evaluate-ci-repositories:nightly-deploy-scheduled && npm run test:evaluate-ci-repositories:nightly-deploy-release && npm run test:evaluate-ci-render && npm run test:evaluate-pr-mcp && npm run test:evaluate-pr-api && npm run test:evaluate-pr-suite && npm run test:evaluate-pr-workflow && npm run test:evaluate-pr-tool-use && npm run test:evaluate-pr-promptfoo && npm run test:evaluate-pr-ai-feature && npm run test:evaluate-pr-test-review && npm run test:evaluate-pr-gap-loop && npm run test:evaluate-pr-learn && npm run test:evaluate-pr-tutorial && npm run test:evaluate-partitions && npm run test:evaluate-partition-plans-views-and-check && npm run test:evaluate-partition-plans-preflight-and-run && npm run test:evaluate-partition-plans-score && npm run test:evaluate-partition-plans-attempts-seal-and-mappings && npm run test:evaluate-partition-plans-attempts-records && npm run test:evaluate-partition-plans-attempts-gameability && npm run test:evaluate-interpret && npm run test:evaluate-calibration && npm run test:evaluate-boundaries && npm run test:evaluate-preflight && npm run test:evaluate-isolation-conformance && npm run test:evaluate-mutation:qualification-basics && npm run test:evaluate-mutation:qualification-guards && npm run test:evaluate-mutation:recovery && npm run test:evaluate-mutation:journals && npm run test:evaluate-run && npm run test:evaluate-progress && npm run test:evaluate-aggregate && npm run test:evaluate-confinement && npm run test:evaluate-confinement-audit && npm run test:evaluate-confinement-history && npm run test:evaluate-confinement-git-state && npm run test:evaluate-confinement-network && npm run test:evaluate-held-inputs && npm run test:evaluate-arms-historical && npm run test:evaluate-arms-deployments && npm run test:evaluate-evaluators && npm run test:evaluate-evaluators-agent-version && npm run test:evaluate-agents && npm run test:evaluate-agents-importers && npm run test:evaluate-agents-sealed-brief && npm run test:evaluate-held-attempts && npm run test:evaluate-private && npm run test:evaluate-records && npm run test:evaluate-mcp && npm run test:evaluate-api && npm run test:evaluate-workflow && npm run test:evaluate-tool-use && npm run test:evaluate-promptfoo && npm run test:evaluate-learned-framework && npm run test:docs-tutorial && npm run test:knowledge && npm run test:criteria-fragments && npm run test:doc-count-sources && npm run test:planning-doc-sources && npm run test:doc-counts && npm run test:doc-claim-sources && npm run test:doc-claims && npm run test:doc-invocation-entry && npm run test:doc-invocations && npm run test:doc-link-anchors && npm run test:docs-build-names && npm run test:docs-evaluate-sidebar && npm run test:docs-gap-reader && npm run test:enforce-hook && npm run test:framework-scaffold && npm run test:isolation-primitives && npm run test:atdd-isolation && npm run test:atdd-net-guard && npm run test:atdd-scoring && npm run test:atdd-workflow-guidance && npm run test:generation-healing && npm run test:framework-scaffold-install-isolation && npm run test:transcript-harness && npm run test:suite-manifest && npm run test:teach-me-testing-scoring && npm run test:teach-cli && npm run test:eval-data && npm run test:eval-atdd-data && npm run test:eval-ci-data && npm run test:eval-framework-scaffold-data && npm run test:eval-nfr-data && npm run test:nfr-validate-corpus && npm run test:nfr-evidence-guidance && npm run test:nfr-cli && npm run test:eval-test-design-data && npm run test:eval-trace-data && npm run test:eval-routing-data && npm run test:eval-routing-boundaries && npm run test:eval-routing-evidence && npm run test:eval-transcript-data && npm run test:eval-teach-me-testing-data && npm run test:eval-schemas && npm run test:eval-diagnostics && npm run test:eval-replay && npm run test:eval-quality-corpus && npm run test:schema-versions && npm run test:contract-sources && npm run test:contracts && npm run test:contract-oracles && npm run test:probe-sources && npm run test:test-design-qualification && npm run test:test-review-qualification && npm run test:trace-qualification && npm run test:nfr-qualification && npm run test:ci-qualification && npm run test:probe-corpus && npm run test:compare-dominance && npm run test:compare-eval-runs && npm run test:trial-set-scoring && npm run test:automate-cli && npm run test:automate-generation-evidence && npm run test:automate-eval-fixture && npm run test:eval-automate-data && npm run test:clock-port && npm run test:probe-conformance && npm run test:corpus-conformance && npm run test:file-system-conformance && npm run test:file-system-port && npm run test:probe-targets && npm run test:port-totality && npm run test:ci-coverage && npm run test:ci-coverage-filters && npm run test:install-actionlint && npm run test:workflows-lint && npm run test:install-linux-sandbox && npm run test:shards && npm run test:groups && npm run test:cli && npm run test:workflow-cli && npm run test:framework-cli && npm run test:test-review-pr-scope && npm run test:test-review-report && npm run test:test-review-rubric && npm run test:bmad-output-gated && npm run test:release-metadata && npm run test:release-notes && npm run test:lockfile-age && npm run test:lockfile-age-cache && npm run test:licences && npm run test:supply-chain && npm run test:boundary && npm run test:direction && npm run test:lineage && npm run test:guard-publish && npm run test:layering-boundary-lineage && npm run test:changelog && npm run test:tea-workflow-descriptions && npm run test:docs-mermaid && npm run test:llms-headroom && npm run validate:schemas && npm run lint && npm run lint:md && npm run format:check",
+    "test": "npm run test:conflict-markers && npm run test:schemas && npm run test:install && npm run test:evaluate-guidance && npm run test:evaluate-authoring && npm run test:evaluate-gap-loop && npm run test:evaluate-dogfood && npm run test:evaluate-check && npm run test:evaluate-compare && npm run test:evaluate-before-state && npm run test:evaluate-ci-gates && npm run test:evaluate-ci-tiers && npm run test:evaluate-ci-repositories:tagged-release-pr && npm run test:evaluate-ci-repositories:tagged-release-merge && npm run test:evaluate-ci-repositories:tagged-release-release && npm run test:evaluate-ci-repositories:nightly-deploy-pr && npm run test:evaluate-ci-repositories:nightly-deploy-merge && npm run test:evaluate-ci-repositories:nightly-deploy-scheduled && npm run test:evaluate-ci-repositories:nightly-deploy-release && npm run test:evaluate-ci-render && npm run test:evaluate-pr-mcp && npm run test:evaluate-pr-api && npm run test:evaluate-pr-suite && npm run test:evaluate-pr-workflow && npm run test:evaluate-pr-tool-use && npm run test:evaluate-pr-promptfoo && npm run test:evaluate-pr-ai-feature && npm run test:evaluate-pr-test-review && npm run test:evaluate-pr-gap-loop && npm run test:evaluate-pr-learn && npm run test:evaluate-pr-tutorial && npm run test:evaluate-partitions && npm run test:evaluate-partition-plans-views-and-check && npm run test:evaluate-partition-plans-preflight-and-run && npm run test:evaluate-partition-plans-score && npm run test:evaluate-partition-plans-attempts-seal-and-mappings && npm run test:evaluate-partition-plans-attempts-records && npm run test:evaluate-partition-plans-attempts-gameability && npm run test:evaluate-interpret && npm run test:evaluate-calibration && npm run test:evaluate-boundaries && npm run test:evaluate-preflight && npm run test:evaluate-isolation-conformance && npm run test:evaluate-mutation:qualification-basics && npm run test:evaluate-mutation:qualification-guards && npm run test:evaluate-mutation:recovery && npm run test:evaluate-mutation:journals && npm run test:evaluate-run && npm run test:evaluate-progress && npm run test:evaluate-aggregate && npm run test:evaluate-confinement && npm run test:evaluate-confinement-audit && npm run test:evaluate-confinement-history && npm run test:evaluate-confinement-git-state && npm run test:evaluate-confinement-network && npm run test:evaluate-held-inputs && npm run test:evaluate-arms-historical && npm run test:evaluate-arms-deployments && npm run test:evaluate-evaluators && npm run test:evaluate-evaluators-agent-version && npm run test:evaluate-agents && npm run test:evaluate-agents-importers && npm run test:evaluate-agents-sealed-brief && npm run test:evaluate-held-attempts && npm run test:evaluate-private && npm run test:evaluate-records && npm run test:evaluate-mcp && npm run test:evaluate-api && npm run test:evaluate-workflow && npm run test:evaluate-tool-use && npm run test:evaluate-promptfoo && npm run test:evaluate-learned-framework && npm run test:docs-tutorial && npm run test:knowledge && npm run test:criteria-fragments && npm run test:doc-count-sources && npm run test:planning-doc-sources && npm run test:doc-counts && npm run test:doc-claim-sources && npm run test:doc-claims && npm run test:doc-invocation-entry && npm run test:doc-invocations && npm run test:doc-link-anchors && npm run test:docs-build-names && npm run test:docs-evaluate-sidebar && npm run test:docs-gap-reader && npm run test:enforce-hook && npm run test:framework-scaffold && npm run test:isolation-primitives && npm run test:atdd-isolation && npm run test:atdd-net-guard && npm run test:atdd-scoring && npm run test:atdd-workflow-guidance && npm run test:generation-healing && npm run test:framework-scaffold-install-isolation && npm run test:transcript-harness && npm run test:suite-manifest && npm run test:teach-me-testing-scoring && npm run test:teach-cli && npm run test:eval-data && npm run test:eval-atdd-data && npm run test:eval-ci-data && npm run test:eval-framework-scaffold-data && npm run test:eval-nfr-data && npm run test:nfr-validate-corpus && npm run test:nfr-evidence-guidance && npm run test:nfr-cli && npm run test:eval-test-design-data && npm run test:eval-trace-data && npm run test:eval-routing-data && npm run test:eval-routing-boundaries && npm run test:eval-routing-evidence && npm run test:eval-transcript-data && npm run test:eval-teach-me-testing-data && npm run test:eval-schemas && npm run test:eval-diagnostics && npm run test:eval-replay && npm run test:eval-quality-corpus && npm run test:schema-versions && npm run test:contract-sources && npm run test:contracts && npm run test:contract-oracles && npm run test:probe-sources && npm run test:test-design-qualification && npm run test:test-review-qualification && npm run test:trace-qualification && npm run test:nfr-qualification && npm run test:ci-qualification && npm run test:probe-corpus && npm run test:compare-dominance && npm run test:compare-eval-runs && npm run test:trial-set-scoring && npm run test:automate-cli && npm run test:automate-generation-evidence && npm run test:automate-eval-fixture && npm run test:eval-automate-data && npm run test:clock-port && npm run test:probe-conformance && npm run test:corpus-conformance && npm run test:file-system-conformance && npm run test:file-system-port && npm run test:probe-targets && npm run test:port-totality && npm run test:ci-coverage && npm run test:ci-coverage-filters && npm run test:install-actionlint && npm run test:workflows-lint && npm run test:install-linux-sandbox && npm run test:shards && npm run test:groups && npm run test:cli && npm run test:workflow-cli && npm run test:migrate-customizations && npm run test:framework-cli && npm run test:test-review-pr-scope && npm run test:test-review-report && npm run test:test-review-rubric && npm run test:bmad-output-gated && npm run test:release-metadata && npm run test:release-notes && npm run test:lockfile-age && npm run test:lockfile-age-cache && npm run test:licences && npm run test:supply-chain && npm run test:boundary && npm run test:direction && npm run test:lineage && npm run test:guard-publish && npm run test:layering-boundary-lineage && npm run test:changelog && npm run test:tea-workflow-descriptions && npm run test:docs-mermaid && npm run test:llms-headroom && npm run validate:schemas && npm run lint && npm run lint:md && npm run format:check",
     "test:atdd-isolation": "node test/test-atdd-isolation.js",
     "test:atdd-net-guard": "node test/test-atdd-net-guard.js",
     "test:atdd-scoring": "node test/test-atdd-scoring.js",
@@ -241,6 +242,7 @@
     "test:llms-headroom": "node test/test-llms-headroom.js",
     "test:lockfile-age": "eval-quality-gates lockfile-age",
     "test:lockfile-age-cache": "node test/test-generate-lockfile-age-cache.js",
+    "test:migrate-customizations": "node test/test-migrate-customizations.js",
     "test:nfr-cli": "node --test test/test-nfr-cli.js",
     "test:nfr-evidence-guidance": "node test/test-nfr-evidence-guidance.js",
     "test:nfr-qualification": "node test/test-nfr-qualification.js",
@@ -304,7 +306,7 @@
     "include": [
       "cli/**",
       "tools/**",
-      "skills/bmad-testarch-framework/resources/hooks/**"
+      "skills/bmad-tea-framework/resources/hooks/**"
     ],
     "lines": 78,
     "reporter": [

package/skills/bmad-tea/SKILL.md

@@ -19,6 +19,8 @@ You are Murat, the Master Test Architect and Quality Advisor. You lead risk-base
 
 ## On Activation
 
+Before resolving the agent menu, inspect `{project-root}/_bmad/custom/bmad-tea.toml` and `{project-root}/_bmad/custom/bmad-tea.user.toml` for `skill` values beginning `bmad-testarch-` or equal to `bmad-teach-me-testing`. If found, stop and tell the user to run `npx --package=bmad-method-test-architecture-enterprise@3 tea-migrate-customizations --project-root {project-root}`. A migration conflict requires the manual merge named by that command. Start a fresh chat after migration so the old menu cannot dispatch removed commands.
+
 ### Step 1: Resolve the Agent Block
 
 Run: `uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --project-root {project-root} --key agent`
@@ -78,11 +80,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` 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.
+TF invokes `bmad-tea-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-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.
+AT invokes `bmad-tea-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

@@ -60,37 +60,37 @@ principles = [
 [[agent.menu]]
 code = "TMT"
 description = "Teach Me Testing — interactive learning companion with 7 progressive sessions from fundamentals to advanced practices"
-skill = "bmad-teach-me-testing"
+skill = "bmad-tea-teach-me-testing"
 
 [[agent.menu]]
 code = "TD"
 description = "Test Design — risk assessment, NFR planning, and coverage strategy for system or epic scope"
-skill = "bmad-testarch-test-design"
+skill = "bmad-tea-test-design"
 
 [[agent.menu]]
 code = "TF"
 description = "Test Framework: initialize framework architecture and optional CI/CD quality pipeline"
-skill = "bmad-testarch-framework"
+skill = "bmad-tea-framework"
 
 [[agent.menu]]
 code = "CI"
 description = "Continuous Integration: scaffold a CI/CD quality pipeline through Framework CI scope"
-skill = "bmad-testarch-framework"
+skill = "bmad-tea-framework"
 
 [[agent.menu]]
 code = "AT"
 description = "ATDD: generate and verify failing acceptance tests through Automate red mode"
-skill = "bmad-testarch-automate"
+skill = "bmad-tea-automate"
 
 [[agent.menu]]
 code = "TA"
 description = "Test Automation: generate prioritized tests in expand mode, run and heal test defects, and report product defects"
-skill = "bmad-testarch-automate"
+skill = "bmad-tea-automate"
 
 [[agent.menu]]
 code = "EV"
 description = "Evaluate — build and run a scored, evidence-backed evaluation of an agent, skill, workflow, or tool-use system, with seeded-defect proof and CI enforcement"
-skill = "bmad-testarch-evaluate"
+skill = "bmad-tea-evaluate"
 
 [[agent.menu]]
 code = "GATE"
@@ -100,14 +100,14 @@ prompt = "Help the user run the release gate path. First determine which evidenc
 [[agent.menu]]
 code = "RV"
 description = "Review Tests — perform a quality check against written tests using comprehensive knowledge base and best practices"
-skill = "bmad-testarch-test-review"
+skill = "bmad-tea-test-review"
 
 [[agent.menu]]
 code = "NR"
 description = "NFR Evidence Audit — assess implemented NFR evidence and recommend actions"
-skill = "bmad-testarch-nfr"
+skill = "bmad-tea-nfr"
 
 [[agent.menu]]
 code = "TR"
 description = "Trace Coverage — map requirements to tests (Phase 1) and make quality gate decision (Phase 2)"
-skill = "bmad-testarch-trace"
+skill = "bmad-tea-trace"

package/skills/{bmad-testarch-automate → bmad-tea-automate}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: bmad-testarch-automate
+name: bmad-tea-automate
 description: 'Generate tests in red or expand mode and run-and-heal new tests. Use when the user says "lets expand test coverage", "I want to automate tests", "lets write acceptance tests", or "I want to do ATDD"'
 ---
 
@@ -28,6 +28,8 @@ The router selects exactly one customization surface; activation below uses that
 
 ## On Activation
 
+Before resolving customizations or running hooks, inspect `{project-root}/_bmad/custom/` for `bmad-testarch-automate.toml`, `bmad-testarch-automate.user.toml`, `bmad-testarch-atdd.toml`, and `bmad-testarch-atdd.user.toml`. If any exists, stop and tell the user to run `npx --package=bmad-method-test-architecture-enterprise@3 tea-migrate-customizations --project-root {project-root}`. Resolve any reported manual merge, then start a fresh chat. Do not continue with default settings while legacy overrides remain.
+
 ### Step 1: Resolve the Workflow Block
 
 When `workflow_customization_manual = true`, use the already resolved red workflow block and skip this resolver command.

package/skills/{bmad-testarch-automate → bmad-tea-automate}/checklist.md

@@ -548,7 +548,7 @@ Check the generation deliverables below and record the shared loop's actual exec
 **Resolution:**
 
 - **HALT workflow** - framework is required
-- Message: "Framework scaffolding required. Run `/bmad-testarch-framework` first."
+- Message: "Framework scaffolding required. Run `/bmad-tea-framework` first."
 - User must run framework workflow before automate
 
 ### Issue: No automation targets identified

package/skills/{bmad-testarch-nfr → bmad-tea-automate}/customize.toml

@@ -1,6 +1,6 @@
 # DO NOT EDIT -- overwritten on every update.
 #
-# Workflow customization surface for bmad-testarch-nfr. Mirrors the
+# Workflow customization surface for bmad-tea-automate. Mirrors the
 # agent customization shape under the [workflow] namespace.
 
 [workflow]

package/skills/{bmad-testarch-automate → bmad-tea-automate}/red/customize.toml

@@ -1,6 +1,6 @@
 # DO NOT EDIT -- overwritten on every update.
 #
-# Workflow customization surface for bmad-testarch-atdd. Mirrors the
+# Workflow customization surface for bmad-tea-atdd. Mirrors the
 # agent customization shape under the [workflow] namespace.
 
 [workflow]

package/skills/{bmad-testarch-automate → bmad-tea-automate}/red/instructions.md

@@ -26,7 +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 by merging `{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-tea-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 → bmad-tea-automate}/red/workflow.yaml

@@ -1,5 +1,5 @@
-# Test Architect workflow: bmad-testarch-atdd
-name: bmad-testarch-atdd
+# Test Architect workflow: bmad-tea-atdd
+name: bmad-tea-atdd
 # prettier-ignore
 description: 'Generate red-phase acceptance test scaffolds using TDD cycle. Use when the user says "lets write acceptance tests" or "I want to do ATDD"'
 

package/skills/{bmad-testarch-automate → bmad-tea-automate}/resources/test-generation-routing.md

@@ -7,7 +7,7 @@ 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.
-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.
+Use `bmad-tea-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.
@@ -15,7 +15,7 @@ In a headless or autonomous invocation, an unspecified operation defaults to Cre
 Start with `test_mode_defaulted = false`.
 A single explicit `red mode` or `expand mode` is authoritative.
 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.
+Treat the invoked command name as an entry default, separate from the user's task wording: mentioning `/bmad-tea-automate` in an acceptance-test request cannot count as an expand signal.
 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 defaults to expand without a question.
@@ -24,14 +24,14 @@ 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 |
-| ------------------------ | --------------------------- | ----------------------- | ---------------- | ------------- |
-| `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            |
+| Invocation          | Task signal                 | Run mode                | Selected mode    | Mode question |
+| ------------------- | --------------------------- | ----------------------- | ---------------- | ------------- |
+| `bmad-tea-automate` | none                        | interactive             | expand (default) | no            |
+| `bmad-tea-automate` | lets write acceptance tests | interactive or headless | red              | no            |
+| `bmad-tea-automate` | acceptance test scaffolds   | interactive or headless | red              | no            |
+| `bmad-tea-automate` | red and expand task signals | interactive             | unresolved       | ask once      |
+| `bmad-tea-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.
@@ -43,13 +43,13 @@ 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}/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`.
-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/`.
+For red set `workflow-skill-root = {skill-root}/red` and `workflow-skill-name = bmad-tea-atdd` to select the red customization namespace.
+For expand set `workflow-skill-root = {skill-root}` and `workflow-skill-name = bmad-tea-automate`.
+Resolve `{skill-root}/red/customize.toml` plus `_bmad/custom/bmad-tea-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`.
+Red uses `_bmad/custom/bmad-tea-atdd.toml` and `.user.toml`; expand uses `_bmad/custom/bmad-tea-automate.toml` and `.user.toml`.
 
 Run selected prepend hooks, load selected persistent facts, load config, greet, then run selected append hooks in that order.
 The selected mode's `workflow.on_complete` executes at its original terminal after outputs are saved, including Validate and Edit.

package/skills/{bmad-testarch-automate → bmad-tea-automate}/workflow.yaml

@@ -1,5 +1,5 @@
-# Test Architect workflow: bmad-testarch-automate
-name: bmad-testarch-automate
+# Test Architect workflow: bmad-tea-automate
+name: bmad-tea-automate
 # prettier-ignore
 description: 'Generate tests in red or expand mode and run-and-heal new tests. Use when the user says "lets expand test coverage", "I want to automate tests", "lets write acceptance tests", or "I want to do ATDD"'
 

package/skills/{bmad-testarch-evaluate → bmad-tea-evaluate}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: bmad-testarch-evaluate
+name: bmad-tea-evaluate
 description: 'Run scored behavioral evaluations and repair gaps. Use when the user says "evaluate this agent" or "I want proof this behaves correctly"'
 ---
 
@@ -23,6 +23,8 @@ You will continue to operate with your given name, identity, and communication_s
 
 ## On Activation
 
+Before resolving customizations or running hooks, inspect `{project-root}/_bmad/custom/` for `bmad-testarch-evaluate.toml` and `bmad-testarch-evaluate.user.toml`. If either exists, stop and tell the user to run `npx --package=bmad-method-test-architecture-enterprise@3 tea-migrate-customizations --project-root {project-root}`. Resolve any reported manual merge, then start a fresh chat. Do not continue with default settings while legacy overrides remain.
+
 ### Step 1: Resolve the Workflow Block
 
 Run: `uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --project-root {project-root} --key workflow`
@@ -123,7 +125,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. 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-tea-framework` with CI setup scope. Load `references/ci.md`.
 
 ## On Complete
 

package/skills/{bmad-testarch-evaluate → bmad-tea-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`.
+- 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-tea-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 → bmad-tea-evaluate}/customize.toml

@@ -1,6 +1,6 @@
 # DO NOT EDIT -- overwritten on every update.
 #
-# Workflow customization surface for bmad-testarch-evaluate. Mirrors the
+# Workflow customization surface for bmad-tea-evaluate. Mirrors the
 # agent customization shape under the [workflow] namespace.
 
 [workflow]

package/skills/{bmad-testarch-evaluate → bmad-tea-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. 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-tea-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-framework` 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-tea-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.
@@ -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. 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-tea-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-tea-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-tea-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` 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-tea-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-framework → bmad-tea-framework}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: bmad-testarch-framework
+name: bmad-tea-framework
 description: 'Initialize test framework and CI/CD setup for browser, backend or mobile stacks. Use when the user says "lets setup test framework" or "I want to initialize testing framework"'
 ---
 
@@ -26,6 +26,8 @@ Before activation hooks or project writes, load `{skill-root}/resources/setup-ro
 
 ## On Activation
 
+Before resolving customizations or running hooks, inspect `{project-root}/_bmad/custom/` for `bmad-testarch-framework.toml`, `bmad-testarch-framework.user.toml`, `bmad-testarch-ci.toml`, and `bmad-testarch-ci.user.toml`. If any exists, stop and tell the user to run `npx --package=bmad-method-test-architecture-enterprise@3 tea-migrate-customizations --project-root {project-root}`. Resolve any reported manual merge, then start a fresh chat. Do not continue with default settings while legacy overrides remain.
+
 ### Step 1: Resolve the Workflow Block
 
 Run: `uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --project-root {project-root} --key workflow`
@@ -68,9 +70,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. Select CI setup by asking `bmad-testarch-framework` for CI scope.
+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-tea-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 invokes `bmad-testarch-framework` with CI scope 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-tea-framework` with CI scope in create or edit mode.
 
 ## Initialization Sequence
 

package/skills/bmad-tea-framework/ci/customize.toml

@@ -0,0 +1,10 @@
+# DO NOT EDIT -- overwritten on every update.
+# CI scope defaults for bmad-tea-framework. Project overrides live in
+# _bmad/custom/bmad-tea-ci.toml and bmad-tea-ci.user.toml.
+
+[workflow]
+activation_steps_prepend = []
+activation_steps_append = []
+persistent_facts = []
+on_complete = ""
+ci_platform = "auto"

package/skills/{bmad-testarch-framework → bmad-tea-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`, 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/`.
+When the CI menu code selects this phase, 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 → bmad-tea-framework}/customize.toml

@@ -1,6 +1,6 @@
 # DO NOT EDIT -- overwritten on every update.
 #
-# Workflow customization surface for bmad-testarch-framework. Mirrors the
+# Workflow customization surface for bmad-tea-framework. Mirrors the
 # agent customization shape under the [workflow] namespace.
 
 [workflow]
@@ -38,5 +38,5 @@ persistent_facts = []
 on_complete = ""
 
 # Explicit canonical team/user override wins; otherwise CI alias ci_platform applies.
-# The default auto value does not mask a migrated bmad-testarch-ci override.
+# The default auto value does not mask a migrated bmad-tea-ci override.
 ci_platform = "auto"

package/skills/{bmad-testarch-framework → bmad-tea-framework}/resources/framework-setup-progress.example.md

@@ -164,7 +164,7 @@ This project runs on Claude Code, which supports tool hooks, so the hook was ins
   `pactConfigGlobs` stayed empty: no pact vitest config exists (see Contract Testing above). `excludeGlobs` stayed empty: no k6 scripts in this project.
 
 - All three hooks (`--pre`, `--post`, `--stop`) registered under `hooks` in `.claude/settings.json`, merged into the file's existing content: the project already had an unrelated `permissions` block, which was preserved as-is.
-- `tests/README.md` now documents that enforced rules come from the `Absolute`-severity rows of the `bmad-testarch-test-review` criteria registry (for example, the H1 hard-wait pattern and the H5 file-length ceiling), not from the hook itself, and that a rule can be turned off per project via `disabledRules` in `.tea/enforce-config.json` provided the reason is stated in the commit.
+- `tests/README.md` now documents that enforced rules come from the `Absolute`-severity rows of the `bmad-tea-test-review` criteria registry (for example, the H1 hard-wait pattern and the H5 file-length ceiling), not from the hook itself, and that a rule can be turned off per project via `disabledRules` in `.tea/enforce-config.json` provided the reason is stated in the commit.
 
 ---
 

package/skills/{bmad-testarch-framework → bmad-tea-framework}/resources/hooks/tea-enforce.cjs

@@ -8,7 +8,7 @@
  *
  * WHAT IT ENFORCES, AND WHAT IT DELIBERATELY DOES NOT
  *
- * Every rule here is a row from `bmad-testarch-test-review/steps-c/criteria-registry.md`,
+ * Every rule here is a row from `bmad-tea-test-review/steps-c/criteria-registry.md`,
  * gated `Absolute` there, and mechanically decidable by pattern. That is a small
  * subset on purpose. The registry's Absolute rows that need a judgment a regex
  * cannot make (C5 mock-asserted-against-itself, C6 unreachable assertion, H3
@@ -79,7 +79,7 @@ const crypto = require('node:crypto');
 const fs = require('node:fs');
 const path = require('node:path');
 
-const REGISTRY_PATH = 'bmad-testarch-test-review/steps-c/criteria-registry.md';
+const REGISTRY_PATH = 'bmad-tea-test-review/steps-c/criteria-registry.md';
 
 // ---------------------------------------------------------------------------
 // Configuration

package/skills/{bmad-testarch-framework → bmad-tea-framework}/resources/setup-phase-completion.md

@@ -26,7 +26,7 @@ Edit/Validate results and hook failures never mutate historical Create checkpoin
 
 ## 2. Phase Handoff and CI Hook
 
-After the operation's completion criteria are satisfied, journal `phase-handoff` before the applicable phase hook. CI uses the resolved `ci_workflow.on_complete`; an installed alias may resolve it with `uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {ci-skill-root} --project-root {project-root} --key workflow.on_complete`. Missing alias/resolver failure uses the canonical-owned defaults plus already merged legacy overrides. Empty hooks record a skipped result.
+After the operation's completion criteria are satisfied, journal `phase-handoff` before the applicable phase hook. CI uses the retained `ci_workflow.on_complete` from activation. Empty hooks record a skipped result.
 
 Execute the CI hook with key `ci.on_complete` through `setup-state.md` section 3: save its exact instruction and started marker before execution, skip completed entries, halt on uncertain started entries, and save completion only after success. A failed phase hook leaves this operation's journal in progress. Create can mirror its hook state to its own phase checkpoint; Edit/Validate preserve old Create checkpoint contents.
 

package/skills/{bmad-testarch-framework → bmad-tea-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`. 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-tea-framework`. Keep the original request and supplied artifact paths through every handoff.
 
 ## 1. Read-Only Request Gate: Before Activation
 
@@ -29,8 +29,8 @@ Before SKILL.md executes prepend hooks or greets, resolve settings for every req
 
 When scope includes CI:
 
-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.
+1. Read `{skill-root}/ci/customize.toml` for 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-tea-ci.toml`, and `_bmad/custom/bmad-tea-ci.user.toml`, skipping missing override 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-framework → bmad-tea-framework}/resources/setup-run-progress.example.md

@@ -4,7 +4,7 @@ recovery_decision: 'fresh'
 workflowStatus: 'in-progress'
 setup_scope: 'both'
 setup_operation: 'create'
-setup_entry: 'bmad-testarch-framework'
+setup_entry: 'bmad-tea-framework'
 ci_scope_answered: true
 ci_scope_defaulted: false
 framework_first_accepted: false

package/skills/{bmad-testarch-framework → bmad-tea-framework}/steps-c/step-04-docs-and-scripts.md

@@ -84,11 +84,11 @@ Document that `maestro test` needs a booted simulator or emulator and an install
 
 The knowledge fragments are advisory and `test-review` is post-hoc. Between the two sits the write itself, and nothing occupied it: a `.only`, a `waitForTimeout`, or a `Thread.sleep` could be written, committed, and only caught at review. This step installs the hook that blocks the write instead.
 
-Install it whenever the agent platform supports tool hooks. Claude Code does, through `.claude/settings.json`. Cursor, Windsurf, and Codex do not have an equivalent write-time interception point today, so on those platforms skip this section, say so in the summary, and note that `bmad-testarch-test-review` remains the enforcement path.
+Install it whenever the agent platform supports tool hooks. Claude Code does, through `.claude/settings.json`. Cursor, Windsurf, and Codex do not have an equivalent write-time interception point today, so on those platforms skip this section, say so in the summary, and note that `bmad-tea-test-review` remains the enforcement path.
 
 ### 3.1 Copy the hook script
 
-Copy `{skill-root}/resources/hooks/tea-enforce.cjs` to `{project-root}/.claude/hooks/tea-enforce.cjs` **byte for byte**. Do not retype it, do not trim it, and do not "adapt" its rule table: the rules are generated from `bmad-testarch-test-review/steps-c/criteria-registry.md` and a test in the TEA repo asserts the two still agree. A locally edited copy silently opts the project out of that guarantee.
+Copy `{skill-root}/resources/hooks/tea-enforce.cjs` to `{project-root}/.claude/hooks/tea-enforce.cjs` **byte for byte**. Do not retype it, do not trim it, and do not "adapt" its rule table: the rules are generated from `bmad-tea-test-review/steps-c/criteria-registry.md` and a test in the TEA repo asserts the two still agree. A locally edited copy silently opts the project out of that guarantee.
 
 The script has no dependencies and runs on the Node that installed TEA. The `.cjs` extension is deliberate so it keeps working in a project whose `package.json` sets `"type": "module"`.
 

package/skills/{bmad-testarch-framework → bmad-tea-framework}/workflow.yaml

@@ -1,5 +1,5 @@
-# Test Architect workflow: bmad-testarch-framework
-name: bmad-testarch-framework
+# Test Architect workflow: bmad-tea-framework
+name: bmad-tea-framework
 # prettier-ignore
 description: 'Initialize test framework and CI/CD setup for browser, backend or mobile stacks. Use when the user says "lets setup test framework" or "I want to initialize testing framework"'
 

package/skills/{bmad-testarch-nfr → bmad-tea-nfr}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: bmad-testarch-nfr
+name: bmad-tea-nfr
 description: 'Audit NFR evidence for performance, security, reliability, and maintainability. Use when implementation evidence exists and the user says "audit NFR evidence", "audit NFRs", or "evaluate non-functional requirements"'
 ---
 
@@ -22,6 +22,8 @@ You will continue to operate with your given name, identity, and communication_s
 
 ## On Activation
 
+Before resolving customizations or running hooks, inspect `{project-root}/_bmad/custom/` for `bmad-testarch-nfr.toml` and `bmad-testarch-nfr.user.toml`. If either exists, stop and tell the user to run `npx --package=bmad-method-test-architecture-enterprise@3 tea-migrate-customizations --project-root {project-root}`. Resolve any reported manual merge, then start a fresh chat. Do not continue with default settings while legacy overrides remain.
+
 ### Step 1: Resolve the Workflow Block
 
 Run: `uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --project-root {project-root} --key workflow`

package/skills/{bmad-testarch-nfr → bmad-tea-nfr}/checklist.md

@@ -397,9 +397,9 @@ The template ends with this snippet and every audit writes it. It is the machine
 
 **Next Actions:**
 
-- If PASS ✅: Run `/bmad-testarch-trace` Phase 2 for the release gate decision, or release
-- If CONCERNS ⚠️: Address HIGH/CRITICAL issues, re-run `/bmad-testarch-nfr`
-- If FAIL ❌: Resolve FAIL status NFRs, re-run `/bmad-testarch-nfr`
+- If PASS ✅: Run `/bmad-tea-trace` Phase 2 for the release gate decision, or release
+- If CONCERNS ⚠️: Address HIGH/CRITICAL issues, re-run `/bmad-tea-nfr`
+- If FAIL ❌: Resolve FAIL status NFRs, re-run `/bmad-tea-nfr`
 
 **Critical Issues:** {COUNT}
 **High Priority Issues:** {COUNT}