bmad-method-test-architecture-enterprise 1.23.2 → 1.23.3-next.1

package/.claude-plugin/marketplace.json

@@ -31,7 +31,7 @@
       "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.23.2",
+      "version": "1.23.3-next.1",
       "author": {
         "name": "Murat K Ozcan (TEA Creator) & Brian (BMad) Madison"
       },

package/CHANGELOG.md

@@ -7,6 +7,25 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+### Fixed
+
+- Validate mode now writes a scope-specific, timestamped report for each run instead of reusing one fixed filename. Artifact validation reports record the exact files checked, and every validate workflow atomically reserves its report through exclusive creation with collision retry, so sequential and parallel QA runs retain independent history (#140).
+
+## [1.23.3] - 2026-08-19
+
+### Removed
+
+- Stale BMad Builder run artifacts from the skills migration. `e295715` carried 16 `validation-report-20260127-*.md` files, two per workflow across the eight `bmad-testarch-*` workflows, recording a 2026-01-27 validation run. Every one of them asserted `workflow.md present: YES` for a file that no longer exists in any workflow (it became `SKILL.md` in that same migration), and every step-file count and line count in them disagreed with the tree they shipped alongside. Each workflow directory is a published skill root in `.claude-plugin/marketplace.json`, so these were shipping to consumers as skill payload, where a wrong file listing is worse than no file listing.
+- The nine authoring-time workflow plans: `workflow-plan.md` in each of the eight `bmad-testarch-*` workflows, plus `workflow-plan-teach-me-testing.md`. Nothing in `src/`, `test/`, `tools/`, `cli/`, or the docs read them; the only inbound references were from the validation reports removed above. Seven of the eight listed a step set that no longer matched their own directory, and the `teach-me-testing` one was a 950-line build-session log carrying `status: FOUNDATION_COMPLETE` frontmatter and a `cp -r` deployment instruction pointing at an external project root. Like the reports, they shipped inside a skill root.
+- Three orphaned scripts from the TEA migration, each with zero inbound references from `package.json`, CI, or the pre-commit hook. `test/validate-agent-schema.js` was a stale copy of `tools/validate-agent-schema.js` whose own usage line named the `tools/` path; it globbed the abandoned `src/{core,modules/*}/agents/` layout and printed `No agent files found` when run. `test/unit-test-schema.js` failed one of its own three assertions and exited 0 regardless, so wiring it up would have gated nothing. `tools/verify-paths.js` was a one-off checker for leftover BMM references, and the migration it guarded is finished.
+- Dead ignore entries that never matched anything in this repository's history: `test/template-test-generator/**` and its two sibling globs, `tools/template-test-generator/test-scenarios/**`, `test-project-install/**`, `sample-project/**`, `src/modules/*/sub-modules/**`, and `.bundler-temp/**` from `eslint.config.mjs`; `test-output/*` from `.gitignore`, along with its redundant `build/*.txt` entry, which `build/` already covers.
+
+### Fixed
+
+- `docs/explanation/step-file-architecture.md` no longer claims the workflows carry committed validation reports "each scoring 100%". No score appears anywhere in the 16 reports the sentence described, so the claim was unverifiable against its own evidence before those reports were removed. The section now states what validation checks and that its output is a point-in-time reading of the working tree rather than a committed artifact.
+- `docs/explanation/eval-quality-roadmap.md` is reachable from the documentation site. It was the only page in `docs/explanation/` missing from the Starlight sidebar in `website/astro.config.mjs`, so it built and published but could only be found through the direct link in `README.md`.
+- `test/README.md` names the validator the suite actually loads. It cited `tools/schema/agent.js`, while `test/test-agent-schema.js` requires the byte-identical copy at `test/schema/agent.js`.
+
 ## [1.23.1] - 2026-08-16
 
 ### Changed

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

@@ -194,9 +194,7 @@ Users do not need to know any of this to run a workflow. What they see is consis
 
 ## Validation
 
-Eight of the nine TEA workflows carry BMad Builder validation reports at `src/workflows/testarch/<workflow>/validation-report-*.md`, each scoring 100%. `bmad-teach-me-testing` has no validation report.
-
-Validation checks for granular instructions, explicit exit conditions, context injection in every step, strict action boundaries, and subagent support where the workflow supports it.
+Every workflow is validated with BMad Builder, which checks for granular instructions, explicit exit conditions, context injection in every step, strict action boundaries, and subagent support where the workflow supports it. Validation runs against the working tree at the time it is invoked, so its output is a point-in-time reading rather than a durable artifact; the reports are not committed. Re-run BMad Builder validation after editing a step file, and read the result from that run.
 
 All nine workflows have been exercised against real projects: `teach-me-testing` across a multi-session flow with persisted progress, `test-design` against a real story and epic, `automate` against real codebases, `atdd` for the red phase with failing tests confirmed, `test-review` against known good and bad suites, `nfr-assess` against a complex system, `trace` for both the coverage matrix and the gate decision, `framework` for Playwright and Cypress scaffolds, and `ci` for GitHub Actions and GitLab CI generation.
 

package/docs/reference/configuration.md

@@ -474,6 +474,14 @@ Paths are relative to `{test_artifacts}` unless noted. Deliverables are declared
 
 `trace` also reads an optional input it never writes: `live-verification-results.json`. Any producer may write it (an agent, a shell script, a CI job, or a person recording an outcome by hand). See [Live Verification Results](/docs/reference/live-verification-results.md) for the contract.
 
+### Validation Report History
+
+Validate mode preserves every report as a separate artifact. The eight artifact-producing workflows write `{workflow}-validation-report-{validation_scope}-{run_timestamp}.md` under `{test_artifacts}`. The workflow identifier is `atdd`, `automate`, `ci`, `framework`, `nfr-assess`, `test-design`, `test-review`, or `trace`.
+
+`validation_scope` identifies what was checked, such as `story-1-2`, `epic-9`, `system`, or `pull-request-123`. `run_timestamp` is the UTC start time with milliseconds in `YYYYMMDDTHHmmssSSSZ` format. Each report also records the exact project-relative paths of its validated artifacts. Validate mode atomically reserves the resolved path with exclusive creation. A collision produces a fresh timestamp and retry, so two concurrent runs cannot claim the same report.
+
+The `teach-me-testing` workflow validates its own workflow definition rather than a selected output scope. Its reports use `workflow-validation/teach-me-testing-validation-{run_timestamp}.md` under `{test_artifacts}` and follow the same no-overwrite rule.
+
 ---
 
 ## Environment Variables

package/eslint.config.mjs

@@ -11,9 +11,6 @@ export default [
       'dist/**',
       'coverage/**',
       '**/*.min.js',
-      'test/template-test-generator/**',
-      'test/template-test-generator/**/*.js',
-      'test/template-test-generator/**/*.md',
       'test/fixtures/**',
       'test/fixtures/**/*.yaml',
       '_bmad/**',
@@ -31,11 +28,6 @@ export default [
       '.agentvibes/**',
       '.kiro/**',
       '.roo/**',
-      'test-project-install/**',
-      'sample-project/**',
-      'tools/template-test-generator/test-scenarios/**',
-      'src/modules/*/sub-modules/**',
-      '.bundler-temp/**',
     ],
   },
 

package/package.json

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

package/src/workflows/testarch/bmad-teach-me-testing/steps-v/step-v-01-validate.md

@@ -4,7 +4,7 @@ description: 'Validate teach-me-testing workflow quality against BMAD standards'
 
 workflowPath: '{skill-root}'
 checklistFile: '{skill-root}/checklist.md'
-validationReport: '{test_artifacts}/workflow-validation/teach-me-testing-validation-{date}.md'
+validationReport: '{test_artifacts}/workflow-validation/teach-me-testing-validation-{run_timestamp}.md'
 ---
 
 # Validate Step 1: Quality Validation
@@ -30,6 +30,7 @@ To systematically validate the teach-me-testing workflow against BMAD quality st
 
 - 🎯 Focus on comprehensive validation
 - 🚫 FORBIDDEN to skip any checks
+- 🚫 Never overwrite an existing validation report
 - 💬 Report findings clearly
 
 ## EXECUTION PROTOCOLS:
@@ -40,7 +41,11 @@ To systematically validate the teach-me-testing workflow against BMAD quality st
 
 ## MANDATORY SEQUENCE
 
-### 1. Validation Start
+### 1. Resolve Unique Report Path
+
+Set `run_timestamp` to the current UTC time with milliseconds in `YYYYMMDDTHHmmssSSSZ` format and resolve `{validationReport}`. Atomically reserve that path using an exclusive-create operation that fails if the file already exists. A separate existence check followed by a normal write is forbidden. On collision, generate a fresh timestamp, resolve a new path, and retry exclusive creation until it succeeds. Initialize the reserved file with `workflow: teach-me-testing`, `run_timestamp`, and `status: IN_PROGRESS`. This run may update only the file it reserved. If the workflow stops, leave that reservation in place. Never delete, truncate, or reuse a report from another run. Always refuse to overwrite prior validation history.
+
+### 2. Validation Start
 
 "**Validating Workflow: teach-me-testing**
 
@@ -59,7 +64,7 @@ This will validate:
 
 **Starting validation...**"
 
-### 2. Foundation Structure Validation
+### 3. Foundation Structure Validation
 
 **Check:**
 
@@ -72,7 +77,7 @@ This will validate:
 
 Report findings: Pass/Fail for each check.
 
-### 3. Template Validation
+### 4. Template Validation
 
 **Check templates/:**
 
@@ -85,7 +90,7 @@ Report findings: Pass/Fail for each check.
 
 Report findings.
 
-### 4. Step File Validation (CREATE Mode)
+### 5. Step File Validation (CREATE Mode)
 
 **For each of 12 steps in steps-c/:**
 
@@ -100,7 +105,7 @@ Report findings.
 
 Report findings per step.
 
-### 5. Data File Validation
+### 6. Data File Validation
 
 **Check data/:**
 
@@ -112,7 +117,7 @@ Report findings per step.
 
 Report findings.
 
-### 6. Content Quality Validation
+### 7. Content Quality Validation
 
 **Check session steps:**
 
@@ -125,7 +130,7 @@ Report findings.
 
 Report findings.
 
-### 7. State Management Validation
+### 8. State Management Validation
 
 **Check continuable workflow features:**
 
@@ -138,7 +143,7 @@ Report findings.
 
 Report findings.
 
-### 8. User Experience Validation
+### 9. User Experience Validation
 
 **Check UX:**
 
@@ -151,14 +156,15 @@ Report findings.
 
 Report findings.
 
-### 9. Generate Validation Report
+### 10. Generate Validation Report
 
-Create {validationReport}:
+Replace the `IN_PROGRESS` body in this run's reserved {validationReport} with:
 
 ```markdown
 ---
 workflow: teach-me-testing
 validation_date: { current_date }
+run_timestamp: { run_timestamp }
 validator: TEA Validation Workflow
 overall_status: PASS / FAIL / PASS_WITH_WARNINGS
 ---
@@ -231,7 +237,7 @@ overall_status: PASS / FAIL / PASS_WITH_WARNINGS
 **Status:** {READY_FOR_PRODUCTION / NEEDS_FIXES / PASS_WITH_MINOR_ISSUES}
 ```
 
-### 10. Display Results
+### 11. Display Results
 
 "**Validation Complete!**
 

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

@@ -1,7 +1,7 @@
 ---
 name: 'step-01-validate'
 description: 'Validate workflow outputs against checklist'
-outputFile: '{test_artifacts}/atdd-validation-report.md'
+outputFile: '{test_artifacts}/atdd-validation-report-{validation_scope}-{run_timestamp}.md'
 validationChecklist: '{skill-root}/checklist.md'
 ---
 
@@ -26,6 +26,7 @@ Validate outputs using the workflow checklist and record findings.
 
 - 🎯 Validate against `{validationChecklist}`
 - 🚫 Do not skip checks
+- 🚫 Never overwrite an existing validation report
 
 ## EXECUTION PROTOCOLS:
 
@@ -34,7 +35,7 @@ Validate outputs using the workflow checklist and record findings.
 
 ## CONTEXT BOUNDARIES:
 
-- Available context: workflow outputs and checklist
+- Available context: user-selected workflow outputs and checklist
 - Focus: validation only
 - Limits: do not modify outputs in this step
 
@@ -42,17 +43,25 @@ Validate outputs using the workflow checklist and record findings.
 
 **CRITICAL:** Follow this sequence exactly.
 
-### 1. Load Checklist
+### 1. Select Scope and Resolve Report Path
+
+Use the artifact paths the user supplied with the Validate request. If none were supplied, list the likely outputs for this workflow and ask which exact file or files to validate. When several candidates exist, do not guess.
+
+Read the selected artifacts. Derive `validation_scope` from their shared story, epic, system, pull request, or other meaningful scope. Use an artifact basename without its extension when no broader scope is available. Normalize the value to lowercase ASCII with only letters, numbers, and single hyphens. Remove leading and trailing hyphens. Ask for a short scope label if normalization leaves an empty value.
+
+Set `run_timestamp` to the current UTC time with milliseconds in `YYYYMMDDTHHmmssSSSZ` format and resolve `{outputFile}` with both values. Atomically reserve that path using an exclusive-create operation that fails if the file already exists. A separate existence check followed by a normal write is forbidden. On collision, generate a fresh timestamp, resolve a new path, and retry exclusive creation until it succeeds. Initialize the reserved file with `validation_scope`, `run_timestamp`, `validated_artifacts`, and `status: IN_PROGRESS`. This run may update only the file it reserved. If the workflow stops, leave that reservation in place. Never delete, truncate, or reuse a report from another run. Always refuse to overwrite prior validation history.
+
+### 2. Load Checklist
 
 Read `{validationChecklist}` and list all criteria.
 
-### 2. Validate Outputs
+### 3. Validate Outputs
 
 Evaluate outputs against each checklist item.
 
-### 3. Write Report
+### 4. Write Report
 
-Write a validation report to `{outputFile}` with PASS/WARN/FAIL per section.
+Replace the `IN_PROGRESS` body in this run's reserved `{outputFile}` with the final validation report. Include PASS/WARN/FAIL per section plus the original `validation_scope`, `run_timestamp`, and `validated_artifacts` metadata. Record every selected artifact using its exact project-relative path.
 
 ## 🚨 SYSTEM SUCCESS/FAILURE METRICS:
 
@@ -60,6 +69,7 @@ Write a validation report to `{outputFile}` with PASS/WARN/FAIL per section.
 
 - Validation report written
 - All checklist items evaluated
+- All selected artifacts recorded in the report
 
 ### ❌ SYSTEM FAILURE:
 

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

@@ -1,7 +1,7 @@
 ---
 name: 'step-01-validate'
 description: 'Validate workflow outputs against checklist'
-outputFile: '{test_artifacts}/automate-validation-report.md'
+outputFile: '{test_artifacts}/automate-validation-report-{validation_scope}-{run_timestamp}.md'
 validationChecklist: '{skill-root}/checklist.md'
 ---
 
@@ -26,6 +26,7 @@ Validate outputs using the workflow checklist and record findings.
 
 - 🎯 Validate against `{validationChecklist}`
 - 🚫 Do not skip checks
+- 🚫 Never overwrite an existing validation report
 
 ## EXECUTION PROTOCOLS:
 
@@ -34,7 +35,7 @@ Validate outputs using the workflow checklist and record findings.
 
 ## CONTEXT BOUNDARIES:
 
-- Available context: workflow outputs and checklist
+- Available context: user-selected workflow outputs and checklist
 - Focus: validation only
 - Limits: do not modify outputs in this step
 
@@ -42,17 +43,25 @@ Validate outputs using the workflow checklist and record findings.
 
 **CRITICAL:** Follow this sequence exactly.
 
-### 1. Load Checklist
+### 1. Select Scope and Resolve Report Path
+
+Use the artifact paths the user supplied with the Validate request. If none were supplied, list the likely outputs for this workflow and ask which exact file or files to validate. When several candidates exist, do not guess.
+
+Read the selected artifacts. Derive `validation_scope` from their shared story, epic, system, pull request, or other meaningful scope. Use an artifact basename without its extension when no broader scope is available. Normalize the value to lowercase ASCII with only letters, numbers, and single hyphens. Remove leading and trailing hyphens. Ask for a short scope label if normalization leaves an empty value.
+
+Set `run_timestamp` to the current UTC time with milliseconds in `YYYYMMDDTHHmmssSSSZ` format and resolve `{outputFile}` with both values. Atomically reserve that path using an exclusive-create operation that fails if the file already exists. A separate existence check followed by a normal write is forbidden. On collision, generate a fresh timestamp, resolve a new path, and retry exclusive creation until it succeeds. Initialize the reserved file with `validation_scope`, `run_timestamp`, `validated_artifacts`, and `status: IN_PROGRESS`. This run may update only the file it reserved. If the workflow stops, leave that reservation in place. Never delete, truncate, or reuse a report from another run. Always refuse to overwrite prior validation history.
+
+### 2. Load Checklist
 
 Read `{validationChecklist}` and list all criteria.
 
-### 2. Validate Outputs
+### 3. Validate Outputs
 
 Evaluate outputs against each checklist item.
 
-### 3. Write Report
+### 4. Write Report
 
-Write a validation report to `{outputFile}` with PASS/WARN/FAIL per section.
+Replace the `IN_PROGRESS` body in this run's reserved `{outputFile}` with the final validation report. Include PASS/WARN/FAIL per section plus the original `validation_scope`, `run_timestamp`, and `validated_artifacts` metadata. Record every selected artifact using its exact project-relative path.
 
 ## 🚨 SYSTEM SUCCESS/FAILURE METRICS:
 
@@ -60,6 +69,7 @@ Write a validation report to `{outputFile}` with PASS/WARN/FAIL per section.
 
 - Validation report written
 - All checklist items evaluated
+- All selected artifacts recorded in the report
 
 ### ❌ SYSTEM FAILURE:
 

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

@@ -1,7 +1,7 @@
 ---
 name: 'step-01-validate'
 description: 'Validate workflow outputs against checklist'
-outputFile: '{test_artifacts}/ci-validation-report.md'
+outputFile: '{test_artifacts}/ci-validation-report-{validation_scope}-{run_timestamp}.md'
 validationChecklist: '{skill-root}/checklist.md'
 ---
 
@@ -26,6 +26,7 @@ Validate outputs using the workflow checklist and record findings.
 
 - 🎯 Validate against `{validationChecklist}`
 - 🚫 Do not skip checks
+- 🚫 Never overwrite an existing validation report
 
 ## EXECUTION PROTOCOLS:
 
@@ -34,7 +35,7 @@ Validate outputs using the workflow checklist and record findings.
 
 ## CONTEXT BOUNDARIES:
 
-- Available context: workflow outputs and checklist
+- Available context: user-selected workflow outputs and checklist
 - Focus: validation only
 - Limits: do not modify outputs in this step
 
@@ -42,15 +43,23 @@ Validate outputs using the workflow checklist and record findings.
 
 **CRITICAL:** Follow this sequence exactly.
 
-### 1. Load Checklist
+### 1. Select Scope and Resolve Report Path
+
+Use the artifact paths the user supplied with the Validate request. If none were supplied, list the likely outputs for this workflow and ask which exact file or files to validate. When several candidates exist, do not guess.
+
+Read the selected artifacts. Derive `validation_scope` from their shared story, epic, system, pull request, or other meaningful scope. Use an artifact basename without its extension when no broader scope is available. Normalize the value to lowercase ASCII with only letters, numbers, and single hyphens. Remove leading and trailing hyphens. Ask for a short scope label if normalization leaves an empty value.
+
+Set `run_timestamp` to the current UTC time with milliseconds in `YYYYMMDDTHHmmssSSSZ` format and resolve `{outputFile}` with both values. Atomically reserve that path using an exclusive-create operation that fails if the file already exists. A separate existence check followed by a normal write is forbidden. On collision, generate a fresh timestamp, resolve a new path, and retry exclusive creation until it succeeds. Initialize the reserved file with `validation_scope`, `run_timestamp`, `validated_artifacts`, and `status: IN_PROGRESS`. This run may update only the file it reserved. If the workflow stops, leave that reservation in place. Never delete, truncate, or reuse a report from another run. Always refuse to overwrite prior validation history.
+
+### 2. Load Checklist
 
 Read `{validationChecklist}` and list all criteria.
 
-### 2. Validate Outputs
+### 3. Validate Outputs
 
 Evaluate outputs against each checklist item.
 
-### 2a. Script Injection Scan
+### 3a. Script Injection Scan
 
 Scan all generated YAML workflow files for unsafe interpolation patterns inside `run:` blocks.
 
@@ -64,9 +73,9 @@ Scan all generated YAML workflow files for unsafe interpolation patterns inside
 
 **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
+### 4. Write Report
 
-Write a validation report to `{outputFile}` with PASS/WARN/FAIL per section.
+Replace the `IN_PROGRESS` body in this run's reserved `{outputFile}` with the final validation report. Include PASS/WARN/FAIL per section plus the original `validation_scope`, `run_timestamp`, and `validated_artifacts` metadata. Record every selected artifact using its exact project-relative path.
 
 ## 🚨 SYSTEM SUCCESS/FAILURE METRICS:
 
@@ -74,6 +83,7 @@ Write a validation report to `{outputFile}` with PASS/WARN/FAIL per section.
 
 - Validation report written
 - All checklist items evaluated
+- All selected artifacts recorded in the report
 
 ### ❌ SYSTEM FAILURE:
 

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

@@ -1,7 +1,7 @@
 ---
 name: 'step-01-validate'
 description: 'Validate workflow outputs against checklist'
-outputFile: '{test_artifacts}/framework-validation-report.md'
+outputFile: '{test_artifacts}/framework-validation-report-{validation_scope}-{run_timestamp}.md'
 validationChecklist: '{skill-root}/checklist.md'
 ---
 
@@ -26,6 +26,7 @@ Validate outputs using the workflow checklist and record findings.
 
 - 🎯 Validate against `{validationChecklist}`
 - 🚫 Do not skip checks
+- 🚫 Never overwrite an existing validation report
 
 ## EXECUTION PROTOCOLS:
 
@@ -34,7 +35,7 @@ Validate outputs using the workflow checklist and record findings.
 
 ## CONTEXT BOUNDARIES:
 
-- Available context: workflow outputs and checklist
+- Available context: user-selected workflow outputs and checklist
 - Focus: validation only
 - Limits: do not modify outputs in this step
 
@@ -42,17 +43,25 @@ Validate outputs using the workflow checklist and record findings.
 
 **CRITICAL:** Follow this sequence exactly.
 
-### 1. Load Checklist
+### 1. Select Scope and Resolve Report Path
+
+Use the artifact paths the user supplied with the Validate request. If none were supplied, list the likely outputs for this workflow and ask which exact file or files to validate. When several candidates exist, do not guess.
+
+Read the selected artifacts. Derive `validation_scope` from their shared story, epic, system, pull request, or other meaningful scope. Use an artifact basename without its extension when no broader scope is available. Normalize the value to lowercase ASCII with only letters, numbers, and single hyphens. Remove leading and trailing hyphens. Ask for a short scope label if normalization leaves an empty value.
+
+Set `run_timestamp` to the current UTC time with milliseconds in `YYYYMMDDTHHmmssSSSZ` format and resolve `{outputFile}` with both values. Atomically reserve that path using an exclusive-create operation that fails if the file already exists. A separate existence check followed by a normal write is forbidden. On collision, generate a fresh timestamp, resolve a new path, and retry exclusive creation until it succeeds. Initialize the reserved file with `validation_scope`, `run_timestamp`, `validated_artifacts`, and `status: IN_PROGRESS`. This run may update only the file it reserved. If the workflow stops, leave that reservation in place. Never delete, truncate, or reuse a report from another run. Always refuse to overwrite prior validation history.
+
+### 2. Load Checklist
 
 Read `{validationChecklist}` and list all criteria.
 
-### 2. Validate Outputs
+### 3. Validate Outputs
 
 Evaluate outputs against each checklist item.
 
-### 3. Write Report
+### 4. Write Report
 
-Write a validation report to `{outputFile}` with PASS/WARN/FAIL per section.
+Replace the `IN_PROGRESS` body in this run's reserved `{outputFile}` with the final validation report. Include PASS/WARN/FAIL per section plus the original `validation_scope`, `run_timestamp`, and `validated_artifacts` metadata. Record every selected artifact using its exact project-relative path.
 
 ## 🚨 SYSTEM SUCCESS/FAILURE METRICS:
 
@@ -60,6 +69,7 @@ Write a validation report to `{outputFile}` with PASS/WARN/FAIL per section.
 
 - Validation report written
 - All checklist items evaluated
+- All selected artifacts recorded in the report
 
 ### ❌ SYSTEM FAILURE:
 

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

@@ -1,7 +1,7 @@
 ---
 name: 'step-01-validate'
 description: 'Validate workflow outputs against checklist'
-outputFile: '{test_artifacts}/nfr-assess-validation-report.md'
+outputFile: '{test_artifacts}/nfr-assess-validation-report-{validation_scope}-{run_timestamp}.md'
 validationChecklist: '{skill-root}/checklist.md'
 ---
 
@@ -26,6 +26,7 @@ Validate outputs using the workflow checklist and record findings.
 
 - 🎯 Validate against `{validationChecklist}`
 - 🚫 Do not skip checks
+- 🚫 Never overwrite an existing validation report
 
 ## EXECUTION PROTOCOLS:
 
@@ -34,7 +35,7 @@ Validate outputs using the workflow checklist and record findings.
 
 ## CONTEXT BOUNDARIES:
 
-- Available context: workflow outputs and checklist
+- Available context: user-selected workflow outputs and checklist
 - Focus: validation only
 - Limits: do not modify outputs in this step
 
@@ -42,17 +43,25 @@ Validate outputs using the workflow checklist and record findings.
 
 **CRITICAL:** Follow this sequence exactly.
 
-### 1. Load Checklist
+### 1. Select Scope and Resolve Report Path
+
+Use the artifact paths the user supplied with the Validate request. If none were supplied, list the likely outputs for this workflow and ask which exact file or files to validate. When several candidates exist, do not guess.
+
+Read the selected artifacts. Derive `validation_scope` from their shared story, epic, system, pull request, or other meaningful scope. Use an artifact basename without its extension when no broader scope is available. Normalize the value to lowercase ASCII with only letters, numbers, and single hyphens. Remove leading and trailing hyphens. Ask for a short scope label if normalization leaves an empty value.
+
+Set `run_timestamp` to the current UTC time with milliseconds in `YYYYMMDDTHHmmssSSSZ` format and resolve `{outputFile}` with both values. Atomically reserve that path using an exclusive-create operation that fails if the file already exists. A separate existence check followed by a normal write is forbidden. On collision, generate a fresh timestamp, resolve a new path, and retry exclusive creation until it succeeds. Initialize the reserved file with `validation_scope`, `run_timestamp`, `validated_artifacts`, and `status: IN_PROGRESS`. This run may update only the file it reserved. If the workflow stops, leave that reservation in place. Never delete, truncate, or reuse a report from another run. Always refuse to overwrite prior validation history.
+
+### 2. Load Checklist
 
 Read `{validationChecklist}` and list all criteria.
 
-### 2. Validate Outputs
+### 3. Validate Outputs
 
 Evaluate outputs against each checklist item.
 
-### 3. Write Report
+### 4. Write Report
 
-Write a validation report to `{outputFile}` with PASS/WARN/FAIL per section.
+Replace the `IN_PROGRESS` body in this run's reserved `{outputFile}` with the final validation report. Include PASS/WARN/FAIL per section plus the original `validation_scope`, `run_timestamp`, and `validated_artifacts` metadata. Record every selected artifact using its exact project-relative path.
 
 ## 🚨 SYSTEM SUCCESS/FAILURE METRICS:
 
@@ -60,6 +69,7 @@ Write a validation report to `{outputFile}` with PASS/WARN/FAIL per section.
 
 - Validation report written
 - All checklist items evaluated
+- All selected artifacts recorded in the report
 
 ### ❌ SYSTEM FAILURE:
 

package/src/workflows/testarch/bmad-testarch-test-design/steps-v/step-01-validate.md

@@ -1,7 +1,7 @@
 ---
 name: 'step-01-validate'
 description: 'Validate workflow outputs against checklist'
-outputFile: '{test_artifacts}/test-design-validation-report.md'
+outputFile: '{test_artifacts}/test-design-validation-report-{validation_scope}-{run_timestamp}.md'
 validationChecklist: '{skill-root}/checklist.md'
 ---
 
@@ -26,6 +26,7 @@ Validate outputs using the workflow checklist and record findings.
 
 - 🎯 Validate against `{validationChecklist}`
 - 🚫 Do not skip checks
+- 🚫 Never overwrite an existing validation report
 
 ## EXECUTION PROTOCOLS:
 
@@ -34,7 +35,7 @@ Validate outputs using the workflow checklist and record findings.
 
 ## CONTEXT BOUNDARIES:
 
-- Available context: workflow outputs and checklist
+- Available context: user-selected workflow outputs and checklist
 - Focus: validation only
 - Limits: do not modify outputs in this step
 
@@ -42,17 +43,25 @@ Validate outputs using the workflow checklist and record findings.
 
 **CRITICAL:** Follow this sequence exactly.
 
-### 1. Load Checklist
+### 1. Select Scope and Resolve Report Path
+
+Use the artifact paths the user supplied with the Validate request. If none were supplied, list the likely outputs for this workflow and ask which exact file or files to validate. When several candidates exist, do not guess.
+
+Read the selected artifacts. Derive `validation_scope` from their shared story, epic, system, pull request, or other meaningful scope. Use an artifact basename without its extension when no broader scope is available. Normalize the value to lowercase ASCII with only letters, numbers, and single hyphens. Remove leading and trailing hyphens. Ask for a short scope label if normalization leaves an empty value.
+
+Set `run_timestamp` to the current UTC time with milliseconds in `YYYYMMDDTHHmmssSSSZ` format and resolve `{outputFile}` with both values. Atomically reserve that path using an exclusive-create operation that fails if the file already exists. A separate existence check followed by a normal write is forbidden. On collision, generate a fresh timestamp, resolve a new path, and retry exclusive creation until it succeeds. Initialize the reserved file with `validation_scope`, `run_timestamp`, `validated_artifacts`, and `status: IN_PROGRESS`. This run may update only the file it reserved. If the workflow stops, leave that reservation in place. Never delete, truncate, or reuse a report from another run. Always refuse to overwrite prior validation history.
+
+### 2. Load Checklist
 
 Read `{validationChecklist}` and list all criteria.
 
-### 2. Validate Outputs
+### 3. Validate Outputs
 
 Evaluate outputs against each checklist item.
 
-### 3. Write Report
+### 4. Write Report
 
-Write a validation report to `{outputFile}` with PASS/WARN/FAIL per section.
+Replace the `IN_PROGRESS` body in this run's reserved `{outputFile}` with the final validation report. Include PASS/WARN/FAIL per section plus the original `validation_scope`, `run_timestamp`, and `validated_artifacts` metadata. Record every selected artifact using its exact project-relative path.
 
 ## 🚨 SYSTEM SUCCESS/FAILURE METRICS:
 
@@ -60,6 +69,7 @@ Write a validation report to `{outputFile}` with PASS/WARN/FAIL per section.
 
 - Validation report written
 - All checklist items evaluated
+- All selected artifacts recorded in the report
 
 ### ❌ SYSTEM FAILURE: