bmad-method-test-architecture-enterprise 1.7.2 → 1.13.0

package/.claude-plugin/marketplace.json

@@ -0,0 +1,33 @@
+{
+  "name": "bmad-method-test-architecture-enterprise",
+  "owner": {
+    "name": "Murat K Ozcan (TEA Creator) & Brian (BMad) Madison"
+  },
+  "license": "MIT",
+  "homepage": "https://github.com/bmad-code-org/bmad-method-test-architecture-enterprise",
+  "repository": "https://github.com/bmad-code-org/bmad-method-test-architecture-enterprise",
+  "keywords": ["bmad", "test-architect", "testing", "quality", "automation", "playwright", "test-engineering"],
+  "plugins": [
+    {
+      "name": "bmad-method-test-architecture-enterprise",
+      "source": "./",
+      "description": "Master Test Architect module for quality strategy, test automation, CI/CD quality gates, and structured testing education. Part of the BMad Method ecosystem.",
+      "version": "1.13.0",
+      "author": {
+        "name": "Murat K Ozcan (TEA Creator) & Brian (BMad) Madison"
+      },
+      "skills": [
+        "./src/agents/bmad-tea",
+        "./src/workflows/testarch/bmad-testarch-atdd",
+        "./src/workflows/testarch/bmad-testarch-automate",
+        "./src/workflows/testarch/bmad-testarch-ci",
+        "./src/workflows/testarch/bmad-testarch-framework",
+        "./src/workflows/testarch/bmad-testarch-nfr",
+        "./src/workflows/testarch/bmad-testarch-test-design",
+        "./src/workflows/testarch/bmad-testarch-test-review",
+        "./src/workflows/testarch/bmad-testarch-trace",
+        "./src/workflows/testarch/bmad-teach-me-testing"
+      ]
+    }
+  ]
+}

package/.github/workflows/manual-release.yaml

@@ -17,7 +17,6 @@ on:
 
 permissions:
   contents: write
-  packages: write
 
 jobs:
   release:
@@ -34,16 +33,22 @@ jobs:
         with:
           node-version-file: ".nvmrc"
           cache: npm
-          registry-url: https://registry.npmjs.org
+          registry-url: "https://registry.npmjs.org"
 
       - name: Install dependencies
         run: npm ci
 
-      - name: Run tests and validation
+      - name: Verify npm credentials
+        env:
+          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
         run: |
-          npm run validate:schemas
-          npm run format:check
-          npm run lint
+          if [ -z "$NODE_AUTH_TOKEN" ]; then
+            echo "NPM_TOKEN secret is not configured." >&2
+            exit 1
+          fi
+
+      - name: Run tests and validation
+        run: npm test
 
       - name: Configure Git
         run: |
@@ -57,17 +62,64 @@ jobs:
             *)          npm version ${{ github.event.inputs.version_bump }} --no-git-tag-version ;;
           esac
 
-      - name: Get new version and previous tag
+      - name: Sync marketplace version
+        run: |
+          node <<'NODE'
+          const fs = require('node:fs');
+
+          const packageJson = JSON.parse(fs.readFileSync('package.json', 'utf8'));
+          const marketplacePath = '.claude-plugin/marketplace.json';
+          const marketplace = JSON.parse(fs.readFileSync(marketplacePath, 'utf8'));
+          const plugin = (marketplace.plugins || []).find((entry) => entry && entry.name === packageJson.name);
+
+          if (!plugin) {
+            throw new Error(`Marketplace entry not found for ${packageJson.name}`);
+          }
+
+          plugin.version = packageJson.version;
+          fs.writeFileSync(marketplacePath, `${JSON.stringify(marketplace, null, 2)}\n`);
+          NODE
+
+      - name: Validate release metadata
+        run: npm run test:release-metadata
+
+      - name: Get new version and release metadata
         id: version
         run: |
-          echo "new_version=$(node -p "require('./package.json').version")" >> $GITHUB_OUTPUT
+          NEW_VERSION=$(node -p "require('./package.json').version")
+          echo "new_version=$NEW_VERSION" >> $GITHUB_OUTPUT
           echo "previous_tag=$(git describe --tags --abbrev=0 2>/dev/null || echo 'v0.0.0')" >> $GITHUB_OUTPUT
+          case "$NEW_VERSION" in
+            *-alpha.*) echo "npm_tag=alpha" >> $GITHUB_OUTPUT ;;
+            *-beta.*) echo "npm_tag=beta" >> $GITHUB_OUTPUT ;;
+            *) echo "npm_tag=latest" >> $GITHUB_OUTPUT ;;
+          esac
 
       - name: Commit version bump
         run: |
-          git add .
+          git add package.json package-lock.json .claude-plugin/marketplace.json
           git commit -m "release: bump to v${{ steps.version.outputs.new_version }}"
 
+      - name: Create and push tag
+        run: |
+          # Check if tag already exists
+          if git rev-parse "v${{ steps.version.outputs.new_version }}" >/dev/null 2>&1; then
+            echo "Tag v${{ steps.version.outputs.new_version }} already exists, skipping tag creation"
+          else
+            git tag -a "v${{ steps.version.outputs.new_version }}" -m "Release v${{ steps.version.outputs.new_version }}"
+            git push origin "v${{ steps.version.outputs.new_version }}"
+          fi
+
+      - name: Publish to npm
+        env:
+          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
+        run: |
+          if [ "${{ steps.version.outputs.npm_tag }}" = "latest" ]; then
+            npm publish
+          else
+            npm publish --tag "${{ steps.version.outputs.npm_tag }}"
+          fi
+
       - name: Generate release notes
         id: release_notes
         run: |
@@ -135,41 +187,15 @@ jobs:
           cat release_notes.md >> $GITHUB_OUTPUT
           echo "EOF" >> $GITHUB_OUTPUT
 
-      - name: Create and push tag
+      - name: Push changes to release branch
         run: |
-          # Check if tag already exists
-          if git rev-parse "v${{ steps.version.outputs.new_version }}" >/dev/null 2>&1; then
-            echo "Tag v${{ steps.version.outputs.new_version }} already exists, skipping tag creation"
+          if git push origin HEAD:${GITHUB_REF_NAME} 2>/dev/null; then
+            echo "✅ Successfully pushed to ${GITHUB_REF_NAME} branch"
           else
-            git tag -a "v${{ steps.version.outputs.new_version }}" -m "Release v${{ steps.version.outputs.new_version }}"
-            git push origin "v${{ steps.version.outputs.new_version }}"
-          fi
-
-      - name: Push changes to main
-        run: |
-          if git push origin HEAD:main 2>/dev/null; then
-            echo "✅ Successfully pushed to main branch"
-          else
-            echo "⚠️ Could not push to main (protected branch). This is expected."
+            echo "⚠️ Could not push to ${GITHUB_REF_NAME} (protected branch). This is expected."
             echo "📝 Version bump and tag were created successfully."
           fi
 
-      - name: Publish to NPM
-        env:
-          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
-        run: |
-          VERSION="${{ steps.version.outputs.new_version }}"
-          if [[ "$VERSION" == *"alpha"* ]]; then
-            echo "Publishing alpha prerelease version with --tag alpha"
-            npm publish --tag alpha
-          elif [[ "$VERSION" == *"beta"* ]]; then
-            echo "Publishing beta prerelease version with --tag latest"
-            npm publish --tag latest
-          else
-            echo "Publishing stable version with --tag latest"
-            npm publish --tag latest
-          fi
-
       - name: Create GitHub Release
         uses: softprops/action-gh-release@v2
         with:
@@ -185,11 +211,6 @@ jobs:
           echo "## 🎉 Successfully released v${{ steps.version.outputs.new_version }}!" >> $GITHUB_STEP_SUMMARY
           echo "" >> $GITHUB_STEP_SUMMARY
           echo "### 📦 Distribution" >> $GITHUB_STEP_SUMMARY
-          echo "- **NPM**: Published to npmjs.org" >> $GITHUB_STEP_SUMMARY
+          echo "- **NPM Package**: https://www.npmjs.com/package/bmad-method-test-architecture-enterprise" >> $GITHUB_STEP_SUMMARY
+          echo "- **NPM Dist-tag**: \`${{ steps.version.outputs.npm_tag }}\`" >> $GITHUB_STEP_SUMMARY
           echo "- **GitHub Release**: https://github.com/bmad-code-org/bmad-method-test-architecture-enterprise/releases/tag/v${{ steps.version.outputs.new_version }}" >> $GITHUB_STEP_SUMMARY
-          echo "" >> $GITHUB_STEP_SUMMARY
-          echo "### ✅ Installation" >> $GITHUB_STEP_SUMMARY
-          echo "\`\`\`bash" >> $GITHUB_STEP_SUMMARY
-          echo "npx bmad-method install" >> $GITHUB_STEP_SUMMARY
-          echo "# Select \"Test Architect\"" >> $GITHUB_STEP_SUMMARY
-          echo "\`\`\`" >> $GITHUB_STEP_SUMMARY

package/.github/workflows/quality.yaml

@@ -110,5 +110,8 @@ jobs:
       - name: Run agent schema validation tests
         run: npm run test:schemas
 
+      - name: Validate release metadata
+        run: npm run test:release-metadata
+
       - name: Test agent compilation components
         run: npm run test:install

package/CHANGELOG.md

@@ -19,7 +19,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ### Added
 
-- **Playwright CLI Integration**: New `playwright-cli.md` knowledge fragment (35 total)
+- **Playwright CLI Integration**: New `playwright-cli.md` knowledge fragment (42 total)
 - **Browser Automation Config**: New `tea_browser_automation` config with 4 modes: `auto`, `cli`, `mcp`, `none`
 - **Auto Mode Heuristic**: Smart CLI/MCP selection per workflow action with fallback
 - **How-To Guide**: `docs/how-to/customization/configure-browser-automation.md`
@@ -146,7 +146,7 @@ All workflows implement the **trivariate step pattern** (Create/Edit/Validate):
   - Feature Flags & Testing Patterns (2 fragments)
   - Playwright-Utils Integration (6 fragments)
 - **Context Engineering**: Dynamic fragment loading per workflow
-- **CSV-Based Index**: `src/testarch/tea-index.csv` for fragment management
+- **CSV-Based Index**: `src/agents/bmad-tea/resources/tea-index.csv` for fragment management
 - **Consistency**: Ensures standardized outputs across workflows
 
 #### Documentation

package/README.md

@@ -1,5 +1,8 @@
 # Test Architect (TEA)
 
+[![Python Version](https://img.shields.io/badge/python-%3E%3D3.10-blue?logo=python&logoColor=white)](https://www.python.org)
+[![uv](https://img.shields.io/badge/uv-package%20manager-blueviolet?logo=uv)](https://docs.astral.sh/uv/)
+
 TEA (Test Engineering Architect) is a standalone BMAD module that delivers risk-based test strategy, test automation guidance, and release gate decisions. It provides a single expert agent (Murat, Master Test Architect and Quality Advisor) and nine workflows spanning Teach Me Testing (TEA Academy), framework setup, test design, ATDD, automation, traceability, NFR assessment, CI guidance, and test review.
 
 Docs: <https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/>
@@ -160,8 +163,8 @@ TEA variables are defined in `src/module.yaml` and prompted during install:
 
 TEA relies on a curated testing knowledge base:
 
-- Index: `src/testarch/tea-index.csv`
-- Fragments: `src/testarch/knowledge/`
+- Index: `src/agents/bmad-tea/resources/tea-index.csv`
+- Fragments: `src/agents/bmad-tea/resources/knowledge/`
 
 Workflows load only the fragments required for the current task to stay focused and compliant.
 
@@ -183,9 +186,11 @@ src/
 │       ├── bmad-testarch-test-design/
 │       ├── bmad-testarch-test-review/
 │       └── bmad-testarch-trace/
-└── testarch/
-    ├── tea-index.csv
-    └── knowledge/
+└── agents/
+    └── bmad-tea/
+        └── resources/
+            ├── tea-index.csv
+            └── knowledge/
 ```
 
 ## Extending TEA
@@ -209,7 +214,7 @@ See `CONTRIBUTING.md` for guidelines.
 
 ## Publishing TEA to NPM
 
-TEA uses an automated release workflow that handles versioning, tagging, NPM publishing, and GitHub releases.
+TEA uses an automated release workflow that handles versioning, metadata sync, tagging, NPM publishing, and GitHub releases.
 
 ### Prerequisites (One-Time Setup)
 
@@ -224,13 +229,18 @@ TEA uses an automated release workflow that handles versioning, tagging, NPM pub
    # Check package.json settings
    cat package.json | grep -A 3 "publishConfig"
    # Should show: "access": "public"
+   if grep -Eq '"private"[[:space:]]*:[[:space:]]*true' package.json; then
+     echo '❌ package.json must not set "private": true'
+   else
+     echo '✅ package.json is publishable ("private": true not present)'
+   fi
    ```
 
 ### Release Process
 
 #### Option 1: Using npm Scripts (Recommended)
 
-From your local terminal after merging to `main`:
+From your local terminal after merging to the release branch you want to publish, typically `main`:
 
 ```bash
 # Beta release (first release or testing)
@@ -254,46 +264,47 @@ npm run release:major
 1. Go to **Actions** tab in GitHub
 2. Click **"Manual Release"** workflow
 3. Click **"Run workflow"**
-4. Select version bump type (alpha, beta, patch, minor, major)
-5. Click **"Run workflow"**
+4. Choose the branch to release, typically `main`
+5. Select version bump type (alpha, beta, patch, minor, major)
+6. Click **"Run workflow"**
 
 ### What Happens Automatically
 
 The workflow performs these steps:
 
-1. ✅ **Validation**: Runs all tests, linting, and format checks
-2. ✅ **Version Bump**: Updates `package.json` version
-   - `beta`: 0.1.0 → 0.1.1-beta.0
-   - `alpha`: 0.1.0 → 0.1.1-alpha.0
-   - `patch`: 0.1.0 → 0.1.1
-   - `minor`: 0.1.0 → 0.2.0
-   - `major`: 0.1.0 → 1.0.0
+1. ✅ **Validation**: Runs the full `npm test` suite, including schema checks, install tests, knowledge checks, linting, markdown linting, formatting, and release metadata validation
+2. ✅ **Version Bump**: Updates `package.json`, `package-lock.json`, and `.claude-plugin/marketplace.json`
+   - `beta`: 1.12.3 → 1.12.4-beta.0
+   - `alpha`: 1.12.3 → 1.12.4-alpha.0
+   - `patch`: 1.12.3 → 1.12.4
+   - `minor`: 1.12.3 → 1.13.0
+   - `major`: 1.12.3 → 2.0.0
 3. ✅ **Commit**: Creates version bump commit
-4. ✅ **Tag**: Creates git tag (e.g., v0.1.1-beta.0)
-5. ✅ **Push**: Pushes tag to GitHub
-6. ✅ **Publish**: Publishes to NPM registry
-   - Alpha → `npm install --tag alpha`
-   - Beta → `npm install` (tagged as `latest`)
-   - Stable → `npm install` (tagged as `latest`)
+4. ✅ **Tag**: Creates git tag (e.g., v1.12.4-beta.0)
+5. ✅ **Publish**: Publishes to NPM registry
+   - Alpha → dist-tag `alpha` (`npm install bmad-method-test-architecture-enterprise@alpha`)
+   - Beta → dist-tag `beta` (`npm install bmad-method-test-architecture-enterprise@beta`)
+   - Stable → dist-tag `latest` (`npm install bmad-method-test-architecture-enterprise`)
+6. ✅ **Push**: Pushes the version bump commit back to the selected branch when permitted, and always pushes the tag
 7. ✅ **GitHub Release**: Creates release with auto-generated notes
-8. ✅ **Summary**: Displays installation instructions
+8. ✅ **Summary**: Displays installation instructions and distribution links
 
 ### Version Bump Strategy
 
 **For TEA Module:**
 
-- **Beta (0.1.x-beta.x)**: Pre-1.0 testing, used for initial releases
-- **Alpha (0.1.x-alpha.x)**: Early development, experimental features
-- **Patch (0.1.x)**: Bug fixes, no new features
-- **Minor (0.x.0)**: New features, backwards compatible
-- **Major (x.0.0)**: Breaking changes (e.g., 1.0.0 release)
+- **Beta (`1.12.x-beta.x`)**: Release candidate testing on the next patch line
+- **Alpha (`1.12.x-alpha.x`)**: Early development and experimental validation
+- **Patch (`1.12.x`)**: Bug fixes, no breaking changes
+- **Minor (`1.x.0`)**: New features, backwards compatible
+- **Major (`x.0.0`)**: Breaking changes
 
 **Recommended Release Path:**
 
-1. `0.1.0` → `0.1.1-beta.0` (first beta)
+1. `1.12.3` → `1.12.4-beta.0` (first beta)
 2. Test beta with early adopters
-3. `0.1.1-beta.0` → `0.1.1-beta.1` (fixes)
-4. When stable: `0.1.1-beta.1` → `1.0.0` (official release)
+3. `1.12.4-beta.0` → `1.12.4-beta.1` (fixes)
+4. When stable: `1.12.4-beta.1` → `1.12.4`
 
 ### Verify Publication
 
@@ -324,10 +335,10 @@ If you need to unpublish a version:
 
 ```bash
 # Unpublish specific version (within 72 hours)
-npm unpublish bmad-method-test-architecture-enterprise@0.1.1-beta.0
+npm unpublish bmad-method-test-architecture-enterprise@1.12.4-beta.0
 
 # Deprecate version (preferred for older releases)
-npm deprecate bmad-method-test-architecture-enterprise@0.1.1-beta.0 "Use version X.Y.Z instead"
+npm deprecate bmad-method-test-architecture-enterprise@1.12.4-beta.0 "Use version X.Y.Z instead"
 ```
 
 ### Troubleshooting
@@ -349,7 +360,7 @@ npm deprecate bmad-method-test-architecture-enterprise@0.1.1-beta.0 "Use version
 
 **"Git push failed (protected branch)":**
 
-- This is expected for protected `main` branch
+- This is expected for a protected release branch
 - The tag and version bump are still created
 - You may need to manually merge the version bump commit
 
@@ -377,6 +388,17 @@ After releasing:
 
 ---
 
+## Community
+
+- [Discord](https://discord.gg/gk8jAdXWmj) — Get help, share ideas, collaborate
+- [YouTube](https://youtube.com/@BMadCode) — Tutorials, master class, and more
+- [X / Twitter](https://x.com/BMadCode)
+- [Website](https://bmadcode.com)
+
+## Support BMad
+
+BMad is free for everyone and always will be. Star this repo, [buy me a coffee](https://buymeacoffee.com/bmad), or email [contact@bmadcode.com](mailto:contact@bmadcode.com) for corporate sponsorship.
+
 ## License
 
 See `LICENSE`.

package/docs/explanation/engagement-models.md

@@ -100,7 +100,7 @@ Decision: Skip TEA, keep what works
 
 **You Bring:**
 
-- Requirements (user stories, acceptance criteria)
+- Coverage oracle inputs (requirements, specs, external system-of-record pointers, or analyzable source)
 - Development environment
 - Project context
 

package/docs/explanation/knowledge-base-system.md

@@ -87,10 +87,10 @@ Without a knowledge base:
 
 **1. Manifest Defines Fragments**
 
-`src/testarch/tea-index.csv`:
+`src/agents/bmad-tea/resources/tea-index.csv`:
 
 ```csv
-id,name,description,tags,fragment_file
+id,name,description,tags,tier,fragment_file
 test-quality,Test Quality,Execution limits and isolation rules,"quality,standards",knowledge/test-quality.md
 network-first,Network-First Safeguards,Intercept-before-navigate workflow,"network,stability",knowledge/network-first.md
 fixture-architecture,Fixture Architecture,Composable fixture patterns,"fixtures,architecture",knowledge/fixture-architecture.md
@@ -109,7 +109,7 @@ Identifies fragments needed for ATDD:
 - fixture-architecture.md (reusable fixtures)
 - data-factories.md (test data)
 
-Loads only these 5 fragments (not all 35)
+Loads only these 5 fragments (not all 42)
 Generates tests following these patterns
 ```
 
@@ -294,7 +294,7 @@ await page.waitForTimeout(3000);
 
 ### Dynamic Fragment Selection
 
-TEA doesn't load all 35 fragments at once:
+TEA doesn't load all 42 fragments at once:
 
 ```
 
@@ -316,7 +316,7 @@ Skips:
 - feature-flags.md (not relevant)
 - file-utils.md (not relevant)
 
-Result: 5 relevant fragments loaded, 30 skipped
+Result: 5 relevant fragments loaded, 37 skipped
 
 ```
 

package/docs/explanation/step-file-architecture.md

@@ -269,13 +269,13 @@ Step files explicitly load knowledge fragments:
 ```markdown
 ## Step 2: Load Knowledge Fragments
 
-Consult `{project-root}/_bmad/tea/testarch/tea-index.csv` and load:
+Consult `{project-root}/_bmad/tea/agents/bmad-tea/resources/tea-index.csv` and load:
 
 1. **fixture-architecture** - For composable fixture patterns
 2. **api-request** - For API test patterns
 3. **network-first** - For network handling patterns
 
-Read each fragment from `{project-root}/_bmad/tea/testarch/knowledge/`.
+Read each fragment from `{project-root}/_bmad/tea/agents/bmad-tea/resources/knowledge/`.
 
 These fragments are your quality guidelines - use their patterns in generated tests.
 ```

package/docs/explanation/tea-overview.md

@@ -23,7 +23,7 @@ BMad does not mandate TEA. There are five valid ways to use it (or skip it). Pic
    - Skip all TEA workflows. Use your existing team testing approach.
 
 2. **TEA Solo (Standalone)**
-   - Use TEA on a non-BMad project. Bring your own requirements, acceptance criteria, and environments.
+   - Use TEA on a non-BMad project. Bring your own requirements, specs, system-of-record pointers, or analyzable source tree, plus environments.
    - Typical sequence: `test-design` (system or epic) -> `atdd` and/or `automate` -> optional `test-review` -> `trace` for coverage and gate decisions.
    - Run `framework` or `ci` only if you want TEA to scaffold the harness or pipeline; they work best after you decide the stack/architecture.
 
@@ -69,7 +69,7 @@ If you are unsure, default to the integrated path for your track and adjust late
 | `framework`   | Playwright/Cypress scaffold, `.env.example`, `.nvmrc`, sample specs                           | Use when no production-ready harness exists          | -                                                                                                                                    |
 | `ci`          | CI workflow, selective test scripts, secrets checklist                                        | Platform-aware (GitHub Actions default)              | -                                                                                                                                    |
 | `test-design` | Combined risk assessment, mitigation plan, and coverage strategy                              | Risk scoring + optional exploratory mode             | **+ Exploratory**: Interactive UI discovery with browser automation (uncover actual functionality)                                   |
-| `atdd`        | Failing acceptance tests + implementation checklist                                           | TDD red phase + optional recording mode              | **+ Recording**: UI selectors verified with live browser; API tests benefit from trace analysis                                      |
+| `atdd`        | Red-phase acceptance test scaffolds + implementation checklist                                | TDD red phase + optional recording mode              | **+ Recording**: UI selectors verified with live browser; API tests benefit from trace analysis                                      |
 | `automate`    | Prioritized specs, fixtures, README/script updates, DoD summary                               | Optional healing/recording, avoid duplicate coverage | **+ Healing**: Visual debugging + trace analysis for test fixes; **+ Recording**: Verified selectors (UI) + network inspection (API) |
 | `test-review` | Test quality review report with 0-100 score, violations, fixes                                | Reviews tests against knowledge base patterns        | -                                                                                                                                    |
 | `nfr-assess`  | NFR assessment report with actions                                                            | Focus on security/performance/reliability            | -                                                                                                                                    |
@@ -426,7 +426,7 @@ Optional MCP integration for design-time broker interaction in contract testing
 2. [How to Set Up a Test Framework with TEA](/docs/how-to/workflows/setup-test-framework.md) - Scaffold Playwright or Cypress
 3. [How to Set Up CI Pipeline with TEA](/docs/how-to/workflows/setup-ci.md) - Configure CI/CD with selective testing
 4. [How to Run Test Design with TEA](/docs/how-to/workflows/run-test-design.md) - Risk-based test planning (system or epic)
-5. [How to Run ATDD with TEA](/docs/how-to/workflows/run-atdd.md) - Generate failing tests before implementation
+5. [How to Run ATDD with TEA](/docs/how-to/workflows/run-atdd.md) - Generate red-phase test scaffolds before implementation
 6. [How to Run Automate with TEA](/docs/how-to/workflows/run-automate.md) - Expand test coverage after implementation
 7. [How to Run Test Review with TEA](/docs/how-to/workflows/run-test-review.md) - Audit test quality (0-100 scoring)
 8. [How to Run NFR Assessment with TEA](/docs/how-to/workflows/run-nfr-assess.md) - Validate non-functional requirements

package/docs/glossary/index.md

@@ -129,11 +129,11 @@ Terminology reference for Test Architect (TEA).
 | **ATDD**                     | Acceptance Test-Driven Development — Generating failing acceptance tests BEFORE implementation (TDD red phase).                                                                                                              |
 | **Burn-in Testing**          | Running tests multiple times (typically 5-10 iterations) to detect flakiness and intermittent failures.                                                                                                                      |
 | **Component Testing**        | Testing UI components in isolation using framework-specific tools (Cypress Component Testing or Vitest + React Testing Library).                                                                                             |
-| **Coverage Traceability**    | Mapping acceptance criteria to implemented tests with classification (FULL/PARTIAL/NONE) to identify gaps and measure completeness.                                                                                          |
+| **Coverage Traceability**    | Mapping coverage oracle items such as requirements, contract endpoints, external pointers, or inferred journeys to implemented tests with classification (FULL/PARTIAL/NONE) to identify gaps and measure completeness.      |
 | **Epic-Level Test Design**   | Test planning per epic (Phase 4) focusing on risk assessment, priorities, and coverage strategy for that specific epic.                                                                                                      |
 | **Fixture Architecture**     | Pattern of building pure functions first, then wrapping in framework-specific fixtures for testability, reusability, and composition.                                                                                        |
 | **Gate Decision**            | Go/no-go decision for release with four outcomes: PASS ✅ (ready), CONCERNS ⚠️ (proceed with mitigation), FAIL ❌ (blocked), WAIVED ⏭️ (approved despite issues).                                                            |
-| **Knowledge Fragment**       | Individual markdown file in TEA's knowledge base covering a specific testing pattern or practice (35 fragments total).                                                                                                       |
+| **Knowledge Fragment**       | Individual markdown file in TEA's knowledge base covering a specific testing pattern or practice (42 fragments total).                                                                                                       |
 | **Browser Automation**       | Playwright CLI and/or MCP servers enabling live browser interaction during test generation. CLI provides token-efficient stateless commands; MCP provides rich stateful automation. Configured via `tea_browser_automation`. |
 | **Network-First Pattern**    | Testing pattern that waits for actual network responses instead of fixed timeouts to avoid race conditions and flakiness.                                                                                                    |
 | **NFR Assessment**           | Validation of non-functional requirements (security, performance, reliability, maintainability) with evidence-based decisions.                                                                                               |

package/docs/how-to/customization/extend-tea-with-custom-workflows.md

@@ -60,6 +60,35 @@ Then choose a normal update path so BMAD re-applies the customization and refres
 - Do not rely on old embedded-TEA behavior where local workflows appeared to be attached automatically.
 - Do not keep custom workflow logic only in chat instructions. Put it in a real workflow or module so it survives updates.
 
+## Path-Safe Authoring for GitHub Copilot and Other Workspace-Root Runtimes
+
+Some IDE skill runners, including GitHub Copilot slash commands in VS Code, execute commands from the **workspace root**, not from the folder that contains the installed `SKILL.md`.
+
+Author custom TEA skills and workflows with that constraint in mind:
+
+- Use `{skill-root}` for files that live inside the installed skill package.
+- Use `{project-root}` for files that live in the target repository.
+- Do not assume `scripts/...`, `workflow.md`, `./instructions.md`, or `steps-c/...` will resolve relative to the current markdown file unless you explicitly anchor them.
+
+Use patterns like these:
+
+```md
+Read `{skill-root}/workflow.md` and follow it exactly.
+Load `{skill-root}/steps-c/step-01-preflight.md`.
+Run: `python3 {skill-root}/scripts/resolve_customization.py --key inject`
+Read `{project-root}/_bmad/tea/config.yaml`.
+```
+
+Avoid patterns like these:
+
+```md
+Read `workflow.md`
+Load `steps-c/step-01-preflight.md`
+Run: `python3 scripts/resolve_customization.py --key inject`
+```
+
+This keeps the same skill portable across Codex, Claude Code, GitHub Copilot, and other runtimes that install skills into different directories.
+
 ## When to Use Which Approach
 
 - **Project-specific workflow**: add custom content and attach it to `bmad-tea`