bmad-method-test-architecture-enterprise 2.0.1-next.2 → 2.0.1-next.3

package/.claude-plugin/marketplace.json

@@ -30,8 +30,8 @@
     {
       "name": "bmad-method-test-architecture-enterprise",
       "source": "./",
-      "description": "Master Test Architect module for quality strategy, test automation, CI/CD quality gates, and structured testing education. Part of the BMad Method ecosystem.",
-      "version": "2.0.1-next.2",
+      "description": "Master Test Architect module for quality strategy, test automation, combined framework and CI setup, CI/CD quality gates, and structured testing education. The CI skill remains a compatibility entry. Part of the BMad Method ecosystem.",
+      "version": "2.0.1-next.3",
       "author": {
         "name": "Murat K Ozcan (TEA Creator) & Brian (BMad) Madison"
       },

package/README.md

@@ -57,7 +57,7 @@ Each workflow can run directly in a fresh session.
 | ---------------------------------------------------------------------------------------------------------------------------------- | ---------------------------- | ---- | ------------------------------------------------------ |
 | [Teach Me Testing](https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/how-to/workflows/teach-me-testing/)    | `/bmad-teach-me-testing`     | TMT  | Learn testing through seven sessions                   |
 | [Test Design](https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/how-to/workflows/run-test-design/)          | `/bmad-testarch-test-design` | TD   | Plan risks, coverage, and NFR evidence                 |
-| [Framework Setup](https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/how-to/workflows/setup-test-framework/) | `/bmad-testarch-framework`   | TF   | Scaffold a test framework                              |
+| [Framework Setup](https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/how-to/workflows/setup-test-framework/) | `/bmad-testarch-framework`   | TF   | Set up a test framework, CI, or both                   |
 | [CI Setup](https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/how-to/workflows/setup-ci/)                    | `/bmad-testarch-ci`          | CI   | Connect tests and quality checks to CI                 |
 | [ATDD](https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/how-to/workflows/run-atdd/)                        | `/bmad-testarch-atdd`        | AT   | Write acceptance scaffolds before implementation       |
 | [Automate](https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/how-to/workflows/run-automate/)                | `/bmad-testarch-automate`    | TA   | Add coverage to implemented features                   |
@@ -66,6 +66,11 @@ Each workflow can run directly in a fresh session.
 | [Evaluate](https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/tutorials/evaluate-your-first-skill/)          | `/bmad-testarch-evaluate`    | EV   | Build and run a behavioral evaluation                  |
 | [Trace](https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/how-to/workflows/run-trace/)                      | `/bmad-testarch-trace`       | TR   | Map requirements to tests and decide a release gate    |
 
+Framework and CI setup share one skill, `bmad-testarch-framework`.
+Ask for framework only, CI only, or both; TEA infers the scope from your prompt and asks "Do you want CI too?" once when CI scope is unclear in an interactive session. An unattended request with unclear scope runs framework setup only and states that CI was excluded.
+`/bmad-testarch-ci` and the `CI` menu code still work and start the same skill's CI setup, with your existing CI customizations.
+Create, Resume, Validate, and Edit remain available for the selected setup scope.
+
 For Codex, replace the leading `/` in the table with `$`.
 The agent menu also accepts `GATE` to route you through test review, NFR evidence audit, and trace Phase 2.
 

package/package.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://json.schemastore.org/package.json",
   "name": "bmad-method-test-architecture-enterprise",
-  "version": "2.0.1-next.2",
+  "version": "2.0.1-next.3",
   "description": "Master Test Architect for quality strategy, test automation, and release gates",
   "keywords": [
     "bmad",

package/skills/bmad-tea/SKILL.md

@@ -76,6 +76,10 @@ Otherwise render `{agent.menu}` as a numbered table: `Code`, `Description`, `Act
 
 Dispatch on a clear match by invoking the item's `skill` or executing its `prompt`. Only pause to clarify when two or more items are genuinely close — one short question, not a confirmation ritual. When nothing on the menu fits, just continue the conversation; chat, clarifying questions, and the `bmad` skill are always fair game.
 
+### 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.
+
 ### Routing Ambiguity Boundaries
 
 Before dispatching, list the menu items directly supported by facts in the user's message. One supported item is a clear route. Two or more supported items require the missing deciding information when the user has supplied no priority, sequence, or requested deliverable that selects one.

package/skills/bmad-tea/customize.toml

@@ -69,12 +69,12 @@ skill = "bmad-testarch-test-design"
 
 [[agent.menu]]
 code = "TF"
-description = "Test Framework — initialize production-ready test framework architecture"
+description = "Test Framework: initialize framework architecture and optional CI/CD quality pipeline"
 skill = "bmad-testarch-framework"
 
 [[agent.menu]]
 code = "CI"
-description = "Continuous Integration — recommend and scaffold CI/CD quality pipeline"
+description = "Continuous Integration: scaffold CI/CD quality pipeline through the combined framework skill"
 skill = "bmad-testarch-ci"
 
 [[agent.menu]]

package/skills/bmad-teach-me-testing/data/session-content-map.yaml

@@ -28,7 +28,7 @@ sessions:
       - "What is TEA"
       - "TEA Lite approach"
       - "Engagement models"
-      - "9 workflows overview"
+      - "10 workflows overview"
 
   session-02-concepts:
     docs:
@@ -79,6 +79,7 @@ sessions:
     workflows_referenced:
       - framework
     key_concepts:
+      - "Framework setup scope: framework, CI, or both; CI setup command"
       - "Fixture composition"
       - "Network interception patterns"
       - "Data factory pattern"

package/skills/bmad-teach-me-testing/data/tea-resources-index.yaml

@@ -20,11 +20,13 @@ documentation:
         local: "/docs/how-to/workflows/setup-test-framework.md"
         online: "/how-to/workflows/setup-test-framework/"
         workflow: framework
+        description: "One setup skill for framework, CI, or both; prompt selects scope"
 
       - name: "Set Up CI Pipeline"
         local: "/docs/how-to/workflows/setup-ci.md"
         online: "/how-to/workflows/setup-ci/"
         workflow: ci
+        description: "CI setup through the framework skill"
 
       - name: "Test Design"
         local: "/docs/how-to/workflows/run-test-design.md"

package/skills/bmad-teach-me-testing/resources/tea-completion-summary.example.md

@@ -45,7 +45,7 @@ average_score: 92
 Dana Whitfield has demonstrated proficiency in:
 
 - ✅ **Testing Fundamentals:** Risk-based testing, test pyramid, test types, P0-P3 prioritization
-- ✅ **TEA Methodology:** 9 workflows (Teach Me Testing, Framework, Test Design, ATDD, Automate, Test Review, Trace, NFR, CI)
+- ✅ **TEA Methodology:** 10 workflows (Teach Me Testing, Framework, Test Design, ATDD, Automate, Test Review, Trace, NFR, CI, Evaluate)
 - ✅ **Architecture Patterns:** Fixture composition, network-first patterns, data factories, step-file architecture
 - ✅ **Test Design:** Risk assessment (Probability × Impact), coverage planning, test levels framework
 - ✅ **Test Development:** ATDD red-green TDD approach, test automation, API testing patterns

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

@@ -94,6 +94,7 @@ Present this content (mostly autonomous, clear and educational):
 TEA is a comprehensive test architecture framework that provides:
 
 - **10 Workflows:** Teach Me Testing, Test Design, Framework, CI, ATDD, Automate, Test Review, NFR Evidence Audit, Trace, Evaluate
+- **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.
 - **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
@@ -306,7 +307,7 @@ duration: '30 min'
 
 ## Key Concepts Covered
 
-1. **TEA Framework:** 9 workflows + 59 knowledge fragments + quality standards
+1. **TEA Framework:** 10 workflows + 59 knowledge fragments + quality standards
 2. **Risk-Based Testing:** P0-P3 prioritization matrix
 3. **Quality Standards:** Definition of Done (no flaky tests, no hard waits, stateless, self-cleaning)
 4. **Engagement Models:** Lite, Solo, Integrated, Enterprise, Brownfield

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

@@ -213,6 +213,16 @@ const user = createUser(); // defaults
 
 **Documentation:** <https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/explanation/step-file-architecture/>"
 
+### 6a. Teaching: Framework and CI Setup
+
+Explain that `bmad-testarch-framework` is one setup skill for framework only, CI only, or both.
+The prompt determines scope; if CI scope is unclear in an interactive session, ask once: "Do you want CI too?" An unattended request with unclear scope sets up the framework only and states that CI was excluded.
+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.
+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)
 
 "### ✅ Knowledge Check"

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

@@ -170,7 +170,7 @@ average_score: { average_score }
 {user_name} has demonstrated proficiency in:
 
 - ✅ **Testing Fundamentals:** Risk-based testing, test pyramid, test types, P0-P3 prioritization
-- ✅ **TEA Methodology:** 9 workflows (Teach Me Testing, Framework, Test Design, ATDD, Automate, Test Review, Trace, NFR, CI)
+- ✅ **TEA Methodology:** 10 workflows (Teach Me Testing, Framework, Test Design, ATDD, Automate, Test Review, Trace, NFR, CI, Evaluate)
 - ✅ **Architecture Patterns:** Fixture composition, network-first patterns, data factories, step-file architecture
 - ✅ **Test Design:** Risk assessment (Probability × Impact), coverage planning, test levels framework
 - ✅ **Test Development:** ATDD red-green TDD approach, test automation, API testing patterns
@@ -283,7 +283,7 @@ You've successfully completed the entire TEA Academy curriculum!
 **You're now equipped to:**
 
 - Write high-quality tests following TEA principles
-- Use all 9 TEA workflows effectively
+- Use all 10 TEA workflows effectively
 - Apply risk-based testing (P0-P3 prioritization)
 - Implement architecture patterns (fixtures, network-first)
 - Maintain quality through Test Review and Trace

package/skills/bmad-teach-me-testing/templates/completion-summary-template.md

@@ -45,7 +45,7 @@ average_score: { { average_score } }
 {{user_name}} has demonstrated proficiency in:
 
 - ✅ **Testing Fundamentals:** Risk-based testing, test pyramid, test types
-- ✅ **TEA Methodology:** 9 workflows, engagement models, quality standards
+- ✅ **TEA Methodology:** 10 workflows, engagement models, quality standards
 - ✅ **Architecture Patterns:** Fixtures, network-first patterns, data factories
 - ✅ **Test Design:** Risk assessment, coverage planning, P0-P3 prioritization
 - ✅ **Test Development:** ATDD red-green approach, test automation

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

@@ -3,87 +3,12 @@ name: bmad-testarch-ci
 description: 'Scaffold CI/CD quality pipeline with test execution. Use when the user says "lets setup CI pipeline" or "I want to create quality gates"'
 ---
 
-# CI/CD Pipeline Setup
+# CI/CD Setup Compatibility Entry
 
-**Goal:** Scaffold CI/CD quality pipeline with test execution, burn-in loops, and artifact collection.
+`bmad-testarch-framework` owns framework and CI setup. This installed name and the CI menu code forward to its CI phase.
 
-**Role:** You are the Master Test Architect.
+1. Preserve the original request, its supplied artifacts, and its create/resume/validate/edit operation. Preset `setup_scope = ci` and `setup_entry = bmad-testarch-ci`. An explicit request for both scopes sets `setup_scope = both`.
+2. Set `ci-skill-root` to this directory. Set `skill-root` to its sibling `bmad-testarch-framework` directory. Require its `SKILL.md`, `{skill-root}/resources/setup-routing.md`, and `{skill-root}/ci/steps-c/step-01-preflight.md`. If any are missing, explain that the canonical framework skill is missing or older than combined setup support and offer to install/update it with `npx skills add bmad-code-org/bmad-method-test-architecture-enterprise --skill bmad-testarch-framework`; continue only after installation succeeds and all three required files exist.
+3. Load `{skill-root}/SKILL.md` completely and execute its activation and shared router with the preset scope and original operation. Keep `{skill-root}` bound to that canonical directory throughout all phases. Do not run a second mode menu or CI-scope question.
 
-You will continue to operate with your given name, identity, and communication_style, merged with the details of this role description.
-
-## Conventions
-
-- Bare paths (e.g. `instructions.md`) resolve from the skill root.
-- `{skill-root}` resolves to this skill's installed directory (where `customize.toml` lives).
-- `{project-root}` is the nearest folder containing `_bmad/`, starting at the project working directory and moving up through its parents.
-- `{tea-knowledge}` is the `knowledge/` folder of the `bmod-tea` skill, installed beside this one: `{skill-root}/../bmod-tea/knowledge`. `tea-index.csv` there lists every fragment by a path relative to that folder.
-- `{skill-name}` resolves to the skill directory's basename.
-- Resolve sibling workflow files such as `instructions.md`, `checklist.md`, `steps-c/...`, `steps-e/...`, `steps-v/...`, and templates from `{skill-root}`.
-
-## On Activation
-
-### 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`
-
-**If the script fails**, resolve the `workflow` block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:
-
-1. `{skill-root}/customize.toml` — defaults
-2. `{project-root}/_bmad/custom/{skill-name}.toml` — team overrides
-3. `{project-root}/_bmad/custom/{skill-name}.user.toml` — personal overrides
-
-Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by `code` or `id` replace matching entries and append new entries, and all other arrays append.
-
-### Step 2: Execute Prepend Steps
-
-Execute each entry in `{workflow.activation_steps_prepend}` in order before proceeding.
-
-### Step 3: Load Persistent Facts
-
-Treat every entry in `{workflow.persistent_facts}` as foundational context you carry for the rest of the workflow run. Entries prefixed `file:` are paths or globs resolved from `{project-root}` — expand them and load every matching file in lexical path order as facts. All other entries are facts verbatim.
-
-### Step 4: Load Config
-
-Run `uv run {project-root}/_bmad/scripts/resolve_config.py --project-root {project-root} --key core --key modules.tea`. If the script fails, merge `{project-root}/_bmad/config.toml`, `{project-root}/_bmad/custom/config.toml` and `{project-root}/_bmad/custom/config.user.toml` yourself, in that order, with the merge rules above. If `_bmad/config.toml` is missing or has no `modules.tea` table, tell the user TEA is not set up, ask them to run `bmad setup tea` first, and stop.
-
-Each `core` and `modules.tea` key is available as `{<key>}`, and as `config.<key>` in later steps. Replace `{project-root}` inside a value with the project root. Setup answers are strings: read `"true"` and `"false"` as booleans.
-
-If `{tea-knowledge}/tea-index.csv` does not exist, the TEA knowledge base is not installed. Tell the user, offer to install it with `npx skills add bmad-code-org/bmad-method-test-architecture-enterprise --skill bmod-tea`, run that on a yes, and stop until it is there.
-
-### Step 5: Greet the User
-
-Greet `{user_name}`, speaking in `{communication_language}`.
-
-### Step 6: Execute Append Steps
-
-Execute each entry in `{workflow.activation_steps_append}` in order.
-
-Activation is complete. Begin the workflow below.
-
-## Workflow Architecture
-
-This workflow uses **tri-modal step-file architecture**:
-
-- **Create mode (steps-c/)**: primary execution flow for new runs and resume continuation
-- **Validate mode (steps-v/)**: validation against checklist
-- **Edit mode (steps-e/)**: revise existing outputs
-
-Create and edit modes both detect `ci/evaluation-ci-plan.json` files and render them into the pipeline (`steps-c/step-03b-render-evaluation-plans.md`). The Evaluate skill's CI stage invokes this workflow in edit mode on an existing pipeline file, or in create mode when the repository has none, once it has written a plan.
-
-## Initialization Sequence
-
-### 1. Mode Determination
-
-"Welcome to the workflow. What would you like to do?"
-
-- **[C] Create** — Run the workflow from the beginning
-- **[R] Resume** — Resume an interrupted Create workflow
-- **[V] Validate** — Validate existing outputs
-- **[E] Edit** — Edit existing outputs
-
-### 2. Route to First Step
-
-- **If C:** Load `{skill-root}/steps-c/step-01-preflight.md`
-- **If R:** Load `{skill-root}/steps-c/step-01b-resume.md` (Create-mode continuation)
-- **If V:** Load `{skill-root}/steps-v/step-01-validate.md`
-- **If E:** Load `{skill-root}/steps-e/step-01-assess.md`
+The canonical router resolves this entry's `customize.toml`, `_bmad/custom/bmad-testarch-ci.toml`, and `_bmad/custom/bmad-testarch-ci.user.toml` when the CI phase activates. It preserves legacy activation steps, persistent facts, `ci_platform`, and `on_complete` hooks. Existing CI checkpoint and validation-report paths remain under `{test_artifacts}/ci/`, including their legacy migration rules.

package/skills/bmad-testarch-ci/bmod.toml

@@ -1,3 +1,4 @@
 [skill]
 bmod = "bmod-tea"
 source = "github:bmad-code-org/bmad-method-test-architecture-enterprise/skills"
+required_skills = ["bmad-testarch-framework"]

package/skills/bmad-testarch-ci/workflow.yaml

@@ -6,13 +6,16 @@ description: 'Scaffold CI/CD quality pipeline with test execution. Use when the
 # Config (test_artifacts, user_name, languages) is resolved at activation in SKILL.md from modules.tea and core.
 date: system-generated
 
+# Compatibility metadata. Canonical framework SKILL.md activates shared routing with CI scope.
 # Workflow components
-installed_path: "."
-instructions: "./instructions.md"
-validation: "./checklist.md"
+installed_path: "../bmad-testarch-framework"
+instructions: "../bmad-testarch-framework/ci/instructions.md"
+validation: "../bmad-testarch-framework/ci/checklist.md"
 
 # Variables and inputs
 variables:
+  setup_scope: "ci" # preset by compatibility entry
+  setup_entry: "bmad-testarch-ci"
   test_dir: "{project-root}/tests" # Root test directory
   test_stack_type: "auto" # auto, frontend, backend, fullstack, mobile - detected or user override
   test_framework: "auto" # auto, playwright, cypress, jest, vitest - detected or user override

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

@@ -121,7 +121,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-ci`. 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. The `bmad-testarch-ci` compatibility entry remains valid. 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: done, or an open item such as a declined baseline or a missing `bmad-testarch-ci`.
+- 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).
 
 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/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-ci`. 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. 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.
 
 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.
 
@@ -16,7 +16,7 @@ Worked example. `.github/workflows/ci.yml` runs on `pull_request` and `push` to
 
 ## Inspect the merge flow
 
-Read branch protection and the merge method: whether the default branch accepts direct pushes, whether a review is required, and whether a merge queue serializes merges. Every repository has a post-merge event, the push to the default branch or, with a queue, the pipeline run on the queued commit. Squash merges and the absence of a queue are therefore no reason to move a `merge` check. The reason to move one is cost or risk the adopter states: a live preflight that outlasts the time the merge flow allows, for example. Step-03b of `bmad-testarch-ci` maps the tier to the event.
+Read branch protection and the merge method: whether the default branch accepts direct pushes, whether a review is required, and whether a merge queue serializes merges. Every repository has a post-merge event, the push to the default branch or, with a queue, the pipeline run on the queued commit. Squash merges and the absence of a queue are therefore no reason to move a `merge` check. The reason to move one is cost or risk the adopter states: a live preflight that outlasts the time the merge flow allows, for example. The framework skill's CI rendering step maps the tier to the event.
 
 Worked example. `CONTRIBUTING.md` says "Merges go through the merge queue, which re-runs the `test` check on the queued commit", and `ci.yml` lists `merge_group`. The post-merge run exists, so a live preflight that needs no secret keeps its `merge` default and its reason cites `ci.yml` and `CONTRIBUTING.md`. If `CONTRIBUTING.md` instead capped the post-merge run at ten minutes and the preflight took forty, the reason for moving it to `release` would cite that cap.
 
@@ -248,9 +248,9 @@ An adopter who declines leaves the baseline an open item, and the closing summar
 
 With no accepted baseline, skip the tier runs and record that in the `## CI` section. After the baseline is accepted, run `npm exec --prefix {tea_evaluations_folder} -- tea-evaluate ci --evaluation <evaluation-folder> --tier <tier>` for each tier that can run on this machine (`pr` always, and each live tier whose target launches here and whose credentials exist) and show the adopter each exit. A blocking exit names the stage that owns its repair, and Stage 11's guide lists the repair for each exit: an oracle that disagrees with its scorer returns to Stage 5, and a strength floor on a class with no eligible probe returns to Stage 3 or Stage 8. Record the exit and that stage in the `## CI` section, tell the adopter, and carry on with the hand-off. Record every tier the plan places a check on, with its exit or the reason it was not run.
 
-## Hand the plan to the CI skill
+## Hand the plan to framework setup with CI scope
 
-Invoke `bmad-testarch-ci` in edit mode on the adopter's pipeline file, naming the plan's path, or in create mode when the inspection found no pipeline file. Its steps detect `ci/evaluation-ci-plan.json` and validate it, and the rendering rules belong to its `steps-c/step-03b-render-evaluation-plans.md`. 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. 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`.
 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-ci` 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` (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.

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

@@ -1,11 +1,11 @@
 ---
 name: bmad-testarch-framework
-description: 'Initialize test framework with Playwright or Cypress. Use when the user says "lets setup test framework" or "I want to initialize testing 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"'
 ---
 
-# Test Framework Setup
+# Test Framework and CI Setup
 
-**Goal:** Initialize a production-ready test framework architecture (Playwright or Cypress) with fixtures, helpers, and configuration.
+**Goal:** Set up a production-ready test framework, a CI/CD quality pipeline, or both, with stack selection, fixtures, helpers, hooks, quality gates, and evaluation-plan rendering.
 
 **Role:** You are the Master Test Architect.
 
@@ -20,6 +20,10 @@ You will continue to operate with your given name, identity, and communication_s
 - `{skill-name}` resolves to the skill directory's basename.
 - Resolve sibling workflow files such as `instructions.md`, `checklist.md`, `steps-c/...`, `steps-e/...`, `steps-v/...`, and templates from `{skill-root}`.
 
+## Read-Only Request Gate
+
+Before activation hooks or project writes, load `{skill-root}/resources/setup-routing.md` and execute its section 1. This settles scope and any missing-framework offer; a decline stops the run. Preserve preset scope and operation from the CI adapter.
+
 ## On Activation
 
 ### Step 1: Resolve the Workflow Block
@@ -34,13 +38,15 @@ Run: `uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skil
 
 Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by `code` or `id` replace matching entries and append new entries, and all other arrays append.
 
+When scope includes CI, resolve `ci_workflow` through `resources/setup-routing.md` section 2 before any CI hook, greeting, contract freeze or worker launch. Retain canonical `workflow` separately for explicit platform precedence. This resolution reads settings only; the activation stages below execute the applicable hooks and facts.
+
 ### Step 2: Execute Prepend Steps
 
-Execute each entry in `{workflow.activation_steps_prepend}` in order before proceeding.
+When scope includes framework, execute each entry in `{workflow.activation_steps_prepend}` in order through `{skill-root}/resources/setup-state.md` section 3. CI-only skips framework prepend/append hooks, persistent facts and completion hooks. When scope includes CI, execute each `ci_workflow.activation_steps_prepend` entry through the same durable protocol now, before config/greeting. The request gate has recovered the current run and persisted its journal before this step. Save each entry's started marker before executing it, skip completed entries, and halt on any started entry with an uncertain outcome.
 
 ### Step 3: Load Persistent Facts
 
-Treat every entry in `{workflow.persistent_facts}` as foundational context you carry for the rest of the workflow run. Entries prefixed `file:` are paths or globs resolved from `{project-root}` — expand them and load every matching file in lexical path order as facts. All other entries are facts verbatim.
+When scope includes framework, treat every entry in `{workflow.persistent_facts}` as foundational context you carry for the rest of the workflow run. When scope includes CI, load `ci_workflow.persistent_facts` here under the same rules. CI-only loads its CI facts and skips framework facts. Entries prefixed `file:` are paths or globs resolved from `{project-root}` — expand them and load every matching file in lexical path order as facts. All other entries are facts verbatim.
 
 ### Step 4: Load Config
 
@@ -56,32 +62,34 @@ Greet `{user_name}`, speaking in `{communication_language}`.
 
 ### Step 6: Execute Append Steps
 
-Execute each entry in `{workflow.activation_steps_append}` in order.
+After greeting, execute each applicable append entry through the same individual durable hook protocol: framework `{workflow.activation_steps_append}` when scope includes framework, then `ci_workflow.activation_steps_append` when scope includes CI. Save each applicable phase in `activation_completed` after its entries succeed. Preserve the full journal and hook ledger through every scope and operation Resume.
 
 Activation is complete. Begin the workflow below.
 
 ## Workflow Architecture
 
-This workflow uses **tri-modal step-file 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.
 
-- **Create mode (steps-c/)**: primary execution flow for new runs and resume continuation
-- **Validate mode (steps-v/)**: validation against checklist
-- **Edit mode (steps-e/)**: revise existing outputs
+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.
 
 ## Initialization Sequence
 
-### 1. Mode Determination
-
-"Welcome to the workflow. What would you like to do?"
-
-- **[C] Create** — Run the workflow from the beginning
-- **[R] Resume** — Resume an interrupted Create workflow
-- **[V] Validate** — Validate existing outputs
-- **[E] Edit** — Edit existing outputs
+Load `{skill-root}/resources/setup-routing.md` completely. Continue sections 2 through 4 after the read-only gate and canonical activation. Its checkpoint, customization, and completion rules apply to every step below. Do not repeat canonical activation or the scope question.
 
-### 2. Route to First Step
+### Framework Phase
 
 - **If C:** Load `{skill-root}/steps-c/step-01-preflight.md`
-- **If R:** Load `{skill-root}/steps-c/step-01b-resume.md` (Create-mode continuation)
+- **If R:** Load `{skill-root}/steps-c/step-01b-resume.md` only for a legacy Create checkpoint without a journal next position. Journal-backed Resume dispatches its saved C/E/V next file/subsection directly.
 - **If V:** Load `{skill-root}/steps-v/step-01-validate.md`
 - **If E:** Load `{skill-root}/steps-e/step-01-assess.md`
+
+### CI Phase
+
+CI settings and applicable activation hooks were handled in the activation stages above. Keep `{skill-root}` bound to the canonical framework directory; do not replay CI activation at phase handoff.
+
+- **If C:** Load `{skill-root}/ci/steps-c/step-01-preflight.md`
+- **If R:** Load `{skill-root}/ci/steps-c/step-01b-resume.md` only for a legacy Create checkpoint without a journal next position. Journal-backed Resume dispatches its saved C/E/V next file/subsection directly.
+- **If V:** Load `{skill-root}/ci/steps-v/step-01-validate.md`
+- **If E:** Load `{skill-root}/ci/steps-e/step-01-assess.md`
+
+For both scope, the coordinator runs the applicable framework and CI phases under the same operation and agreed contract. Read `resources/setup-parallel.md` before concurrent generation. Every phase terminal loads `{skill-root}/resources/setup-phase-completion.md`; completion occurs after all requested phases satisfy their operation-specific completion criteria.

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

@@ -1,5 +1,7 @@
 # Test Framework Setup - Validation Checklist
 
+Apply scaffold creation criteria to newly created frameworks. Validate evaluates the selected existing artifacts and records non-applicable criteria with reasons; it never repairs outputs. Edit re-checks only changed outputs and their direct dependencies. Reusing an existing framework for combined CI setup uses its existing commands and CI preflight contract, without this scaffold checklist or hook integrity checks.
+
 This checklist ensures the framework workflow completes successfully and all deliverables meet quality standards.
 
 ---

package/skills/{bmad-testarch-ci → bmad-testarch-framework/ci}/checklist.md

@@ -1,8 +1,10 @@
 # CI/CD Pipeline Setup - Validation Checklist
 
+For Create, evaluate all applicable setup criteria. Validate reports failures and unavailable execution prerequisites without repair; Edit checks only changed outputs and their direct dependencies. A completed Validate report can contain FAIL criteria. Existing or reused frameworks do not need framework scaffold creation criteria. Use the contract's observed `test_surfaces` and frameworks to decide browser/device criteria; a frontend or mobile application with only unit/API tests does not require browser/device jobs, installs or caches.
+
 ## Prerequisites
 
-- [ ] Git repository initialized (`.git/` exists)
+- [ ] Git repository initialized (`.git` directory or worktree marker exists)
 - [ ] Git remote configured (`git remote -v` shows origin)
 - [ ] Test framework configured (appropriate config for detected stack type)
 - [ ] Local tests pass (test command succeeds)
@@ -48,8 +50,8 @@ Note: CI setup is typically a one-time task per repo and can be run any time aft
 - [ ] Node version matches project
 - [ ] Test directory paths correct
 - [ ] Stack-conditional steps applied:
-  - [ ] Browser install included for frontend/fullstack stacks
-  - [ ] Browser install omitted for backend-only stacks
+  - [ ] Browser install included when a browser test surface is declared
+  - [ ] Browser install omitted when no browser test surface is declared
   - [ ] Test commands match detected framework
 
 ### Step 3: Parallel Sharding
@@ -61,18 +63,18 @@ Note: CI setup is typically a one-time task per repo and can be run any time aft
 
 ### Step 4: Burn-In Loop
 
-- [ ] Burn-in job created (frontend/fullstack stacks) or intentionally skipped (backend-only)
+- [ ] Burn-in job created for an applicable browser/device surface or intentionally skipped with a reason
 - [ ] 10 iterations configured (when enabled)
 - [ ] Proper exit on failure (`|| exit 1`)
 - [ ] Runs on appropriate triggers (PR, cron)
 - [ ] Failure artifacts uploaded
-- [ ] Backend-only stacks: burn-in skipped by default (documented reason: targets UI flakiness)
+- [ ] Unit/API-only suites: UI burn-in skipped by default (documented reason: no browser/device test surface)
 
 ### Step 5: Caching Configuration
 
 - [ ] Dependency cache configured (npm/yarn)
 - [ ] Cache key uses lockfile hash
-- [ ] Browser cache configured (Playwright/Cypress)
+- [ ] Browser cache configured when Playwright/Cypress browsers are required
 - [ ] Restore-keys defined for fallback
 - [ ] Cache paths correct for platform
 
@@ -190,7 +192,7 @@ Note: CI setup is typically a one-time task per repo and can be run any time aft
 
 ### Workflow Dependencies
 
-- [ ] `framework` workflow completed first
+- [ ] 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` workflow
 - [ ] CI integrates with `gate` workflow

package/skills/{bmad-testarch-ci → bmad-testarch-framework/ci}/instructions.md

@@ -31,18 +31,19 @@ From `workflow.yaml`, resolve:
 - `date` (`test_artifacts`, `user_name`, `communication_language` and `document_output_language` come from activation)
 - `test_dir`, and `ci_platform` from `{workflow.ci_platform}`
 
-### 2. First Step
+### 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/`.
+
+### 3. First Step
 
 Load, read completely, and execute:
-`{skill-root}/steps-c/step-01-preflight.md`
+`{skill-root}/ci/steps-c/step-01-preflight.md`
 
-### 3. Evaluation Plans
+### 4. Evaluation Plans
 
 Step 3b renders every `ci/evaluation-ci-plan.json` it finds into the pipeline, in create mode and, through the edit steps, in edit mode.
 
-### 4. Resume Support
-
-If the user selects **Resume** mode, load, read completely, and execute:
-`{skill-root}/steps-c/step-01b-resume.md`
+### 5. Resume Support
 
-This checks the output document for progress tracking frontmatter and routes to the next incomplete step.
+Resume follows the saved position in `setup-run-progress.md`. Only a legacy Create checkpoint with no saved journal position loads `{skill-root}/ci/steps-c/step-01b-resume.md` after recovering any missing contract through read-only inventory. This loader then routes directly to the next incomplete step.