bmad-method-test-architecture-enterprise 1.22.2 → 1.22.3-next.0

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.22.2",
+      "version": "1.22.3-next.0",
       "author": {
         "name": "Murat K Ozcan (TEA Creator) & Brian (BMad) Madison"
       },

package/CHANGELOG.md

@@ -7,6 +7,12 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+### Fixed
+
+- `test-design` progress checkpoints now carry run identity, so a run for one epic no longer clobbers an interrupted run for another ([#128](https://github.com/bmad-code-org/bmad-method-test-architecture-enterprise/issues/128)). Every create-mode step wrote to a single fixed `{test_artifacts}/test-design-progress.md`, and each step's save appended to whatever was already there, so a second epic's run merged its content and its `stepsCompleted` into the first epic's checkpoint; resuming the first epic afterwards read the second epic's state. `step-01-detect-mode.md` now resolves `run_scope` and `run_key` (`system`, or `epic-{epic_num}`) before the first save, checkpoints are written to `{test_artifacts}/test-design-progress-{run_key}.md`, and the frontmatter carries `runScope` and `runKey`. Resolving `epic_num` in step 1 also removes the late "if `epic_num` is unclear, ask the user" prompt in `step-05-generate-output.md`, so a plan and its checkpoint always name the same run.
+- `test-design` create mode no longer merges two runs into one checkpoint. When a checkpoint already exists for the same scope, step 1 reports its `lastStep` and `lastSaved` and asks whether to resume or start over, and starting over replaces the file instead of appending to it.
+- `test-design` resume mode selects the checkpoint belonging to the run being resumed, asks which run to continue when several checkpoints exist and no scope was named, and refuses a checkpoint whose `runKey` does not match. Checkpoints written under the old fixed name are detected, confirmed with the user, and migrated.
+
 ## [1.22.2] - 2026-08-14
 
 ### Added

package/docs/how-to/workflows/run-test-design.md

@@ -63,6 +63,21 @@ For epic-level:
 
 TEA generates test design document(s) based on mode.
 
+## Interrupting and Resuming a Run
+
+Each run saves its progress to its own checkpoint under `{test_artifacts}`:
+
+| Run          | Checkpoint                         |
+| ------------ | ---------------------------------- |
+| System-level | `test-design-progress-system.md`   |
+| Epic-level   | `test-design-progress-epic-{N}.md` |
+
+The workflow resolves that name in its first step, from the mode and the epic you named. Interrupting a run for one epic and then running test design for another epic leaves the first epic's checkpoint untouched, so you can come back to it.
+
+Pick **[R] Resume** to continue. Name the scope you want (for example "resume epic 3") when checkpoints exist for more than one run; without a scope TEA lists the candidates and asks. TEA refuses to resume a checkpoint that belongs to a different run rather than continuing into it.
+
+Checkpoints written before this behavior existed use the old fixed name `test-design-progress.md`. Resume picks that file up, asks you to confirm which run it belongs to, and migrates it to the new name.
+
 ## What You Get
 
 **System-Level Output (TWO Documents):**

package/docs/reference/configuration.md

@@ -432,25 +432,26 @@ Outputs currently land directly under `{test_artifacts}` at the paths listed bel
 
 ## TEA Output Files
 
-Paths are relative to `{test_artifacts}` unless noted. Each is declared in the workflow's `workflow.yaml`.
-
-| Workflow           | Output                                                                                        |
-| ------------------ | --------------------------------------------------------------------------------------------- |
-| `test-design`      | `test-design-architecture.md` and `test-design-qa.md` (system-level writes both)              |
-| `test-design`      | `test-design/{project_name}-handoff.md` (system-level; feeds BMAD `create-epics-and-stories`) |
-| `test-design`      | `test-design-epic-{epic_num}.md` (epic-level)                                                 |
-| `framework`        | `{project-root}/tests/README.md`                                                              |
-| `atdd`             | `atdd-checklist-{story_key}.md`                                                               |
-| `automate`         | `automation-summary.md`                                                                       |
-| `test-review`      | `test-review.md` (override per run with the `output_file_override` variable)                  |
-| `nfr-assess`       | `nfr-assessment.md`                                                                           |
-| `trace`            | `traceability-matrix.md`                                                                      |
-| `trace`            | `e2e-trace-summary.json` (machine-readable summary for CI/CD and reporting)                   |
-| `trace`            | `gate-decision.json` (emitted only when the collection is gate-eligible)                      |
-| `ci`               | `{project-root}/.github/workflows/test.yml` (GitHub Actions default; per-platform otherwise)  |
-| `teach-me-testing` | `teaching-progress/{user_name}-tea-progress.yaml`                                             |
-| `teach-me-testing` | `tea-academy/{user_name}/session-{N}-notes.md`                                                |
-| `teach-me-testing` | `tea-academy/{user_name}/tea-completion-summary.md`                                           |
+Paths are relative to `{test_artifacts}` unless noted. Deliverables are declared in the workflow's `workflow.yaml`; resume checkpoints are declared in the step files that write them.
+
+| Workflow           | Output                                                                                              |
+| ------------------ | --------------------------------------------------------------------------------------------------- |
+| `test-design`      | `test-design-architecture.md` and `test-design-qa.md` (system-level writes both)                    |
+| `test-design`      | `test-design/{project_name}-handoff.md` (system-level; feeds BMAD `create-epics-and-stories`)       |
+| `test-design`      | `test-design-epic-{epic_num}.md` (epic-level)                                                       |
+| `test-design`      | `test-design-progress-{run_key}.md` (resume checkpoint; `run_key` is `system` or `epic-{epic_num}`) |
+| `framework`        | `{project-root}/tests/README.md`                                                                    |
+| `atdd`             | `atdd-checklist-{story_key}.md`                                                                     |
+| `automate`         | `automation-summary.md`                                                                             |
+| `test-review`      | `test-review.md` (override per run with the `output_file_override` variable)                        |
+| `nfr-assess`       | `nfr-assessment.md`                                                                                 |
+| `trace`            | `traceability-matrix.md`                                                                            |
+| `trace`            | `e2e-trace-summary.json` (machine-readable summary for CI/CD and reporting)                         |
+| `trace`            | `gate-decision.json` (emitted only when the collection is gate-eligible)                            |
+| `ci`               | `{project-root}/.github/workflows/test.yml` (GitHub Actions default; per-platform otherwise)        |
+| `teach-me-testing` | `teaching-progress/{user_name}-tea-progress.yaml`                                                   |
+| `teach-me-testing` | `tea-academy/{user_name}/session-{N}-notes.md`                                                      |
+| `teach-me-testing` | `tea-academy/{user_name}/tea-completion-summary.md`                                                 |
 
 `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.
 

package/package.json

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

package/src/workflows/testarch/bmad-testarch-test-design/SKILL.md

@@ -84,4 +84,6 @@ This workflow uses **tri-modal step-file architecture**:
 - **If V:** Load `{skill-root}/steps-v/step-01-validate.md`
 - **If E:** Load `{skill-root}/steps-e/step-01-assess.md`
 
-Resume mode reads explicit progress metadata from the progress file (`workflowStatus`, `nextStep`, `totalSteps`) and falls back to legacy `lastStep` data when needed.
+Each run writes its own progress checkpoint at `{test_artifacts}/test-design-progress-{run_key}.md`, where `run_key` is `system` for a system-level run and `epic-{epic_num}` for an epic-level one. Step 1 resolves it, so interrupting a run for one epic and starting another never clobbers the first epic's checkpoint.
+
+Resume mode selects the checkpoint matching the run being resumed, asks when several exist and no scope was named, and refuses to continue a checkpoint whose `runKey` belongs to a different run. It reads explicit progress metadata (`workflowStatus`, `nextStep`, `totalSteps`) and falls back to legacy `lastStep` data when needed.

package/src/workflows/testarch/bmad-testarch-test-design/instructions.md

@@ -55,7 +55,7 @@ Load, read completely, and execute:
 If the user selects **Resume** mode, load, read completely, and execute:
 `{skill-root}/steps-c/step-01b-resume.md`
 
-This checks the output document for progress tracking frontmatter and routes to the next incomplete step.
+This selects the progress checkpoint belonging to the run being resumed, reads its progress tracking frontmatter, and routes to the next incomplete step. Checkpoints are named `test-design-progress-{run_key}.md` under `{test_artifacts}`, so each epic and the system-level run keep their own.
 
 ---
 

package/src/workflows/testarch/bmad-testarch-test-design/steps-c/step-01-detect-mode.md

@@ -1,15 +1,16 @@
 ---
 name: 'step-01-detect-mode'
-description: 'Determine system-level vs epic-level mode and validate prerequisites'
+description: 'Determine system-level vs epic-level mode, resolve run identity, and validate prerequisites'
 nextStepFile: '{skill-root}/steps-c/step-02-load-context.md'
-outputFile: '{test_artifacts}/test-design-progress.md'
+resumeStepFile: '{skill-root}/steps-c/step-01b-resume.md'
+outputFile: '{test_artifacts}/test-design-progress-{run_key}.md'
 ---
 
 # Step 1: Detect Mode & Prerequisites
 
 ## STEP GOAL
 
-Determine whether to run **System-Level** or **Epic-Level** test design, and confirm required inputs are available.
+Determine whether to run **System-Level** or **Epic-Level** test design, resolve the run identity that names this run's progress checkpoint, and confirm required inputs are available.
 
 ## MANDATORY EXECUTION RULES
 
@@ -98,33 +99,75 @@ State which mode you will use and why. Then proceed.
 
 ---
 
-### 4. Save Progress
+## 4. Resolve Run Identity
+
+Every run writes a progress checkpoint whose filename carries the run's identity, so an interrupted run for one scope is never clobbered by a run for another. Resolve `run_scope` and `run_key` **now**, before any progress is saved.
+
+### System-Level Mode
+
+Set `run_scope` to `system-level` and `run_key` to `system`. A project has one system-level test design, so every system-level run shares this checkpoint.
+
+### Epic-Level Mode
+
+Set `run_scope` to `epic-level`, then resolve `epic_num` here rather than at output time:
+
+1. Use the epic the user named in this invocation.
+2. Otherwise take the epic number from the epic and story documents identified in the prerequisite check, reading it from document metadata, the H1 heading, or the filename.
+3. If `epic_num` is still ambiguous, list the candidate epics and ask the user which one this run covers. **Halt** until they answer.
+
+Set `run_key` to `epic-{epic_num}`.
+
+If the epic carries no number, derive a stable slug from its title and use that in place of the number:
+
+- lowercase the title
+- collapse runs of whitespace to a single `-`
+- strip every character that is not alphanumeric or `-`
+- trim leading and trailing hyphens
+- truncate to 64 characters
+
+Carry `epic_num`, `run_scope`, and `run_key` forward through every remaining step. Step 5 writes `{test_artifacts}/test-design-epic-{epic_num}.md` from the same `epic_num`, so a plan and its checkpoint always name the same run.
+
+---
+
+## 5. Check for an Existing Checkpoint
+
+Check whether `{outputFile}` already exists. A checkpoint at this path belongs to a previous run of the **same** scope; checkpoints for other scopes live under their own filenames and are never read or written here.
+
+- **Does not exist:** this is a fresh run. Proceed to Save Progress.
+- **Exists with `workflowStatus: 'in-progress'`:** a previous run for this scope was interrupted. Display its `lastStep` and `lastSaved`, then ask:
+
+  > "An unfinished test-design run for `{run_key}` was last saved {lastSaved} at step {lastStep}. Resume it, or start over? Starting over replaces the checkpoint."
+
+  **Halt** until the user answers. If they resume, load `{resumeStepFile}`, read it completely, and execute it. If they start over, replace `{outputFile}` entirely in Save Progress.
+
+- **Exists with `workflowStatus: 'completed'`:** a finished run for this scope. Replace `{outputFile}` entirely in Save Progress.
+
+**Never merge two runs into one checkpoint.** A `stepsCompleted` array carried over from a prior run makes the resume dashboard and its routing report steps this run never performed.
+
+---
+
+### 6. Save Progress
 
 **Save this step's accumulated work to `{outputFile}`.**
 
-- **If `{outputFile}` does not exist** (first save), create it with YAML frontmatter:
-
-  ```yaml
-  ---
-  workflowStatus: 'in-progress'
-  totalSteps: 5
-  stepsCompleted: ['step-01-detect-mode']
-  lastStep: 'step-01-detect-mode'
-  nextStep: '{nextStepFile}'
-  lastSaved: '{date}'
-  ---
-  ```
-
-  Then write this step's output below the frontmatter.
-
-- **If `{outputFile}` already exists**, update:
-  - Set `workflowStatus: 'in-progress'`
-  - Set `totalSteps: 5`
-  - Add `'step-01-detect-mode'` to `stepsCompleted` array (only if not already present)
-  - Set `lastStep: 'step-01-detect-mode'`
-  - Set `nextStep: '{nextStepFile}'`
-  - Set `lastSaved: '{date}'`
-  - Append this step's output to the appropriate section of the document.
+Write the file with YAML frontmatter, replacing any prior content as decided in the previous section:
+
+```yaml
+---
+runScope: '{run_scope}'
+runKey: '{run_key}'
+workflowStatus: 'in-progress'
+totalSteps: 5
+stepsCompleted: ['step-01-detect-mode']
+lastStep: 'step-01-detect-mode'
+nextStep: '{nextStepFile}'
+lastSaved: '{date}'
+---
+```
+
+Then write this step's output below the frontmatter.
+
+`runScope` and `runKey` are this run's identity. Later steps carry both forward unchanged, and Resume mode refuses to continue a checkpoint whose `runKey` does not match the run being resumed.
 
 Load next step: `{nextStepFile}`
 
@@ -133,8 +176,12 @@ Load next step: `{nextStepFile}`
 ### ✅ SUCCESS:
 
 - Step completed in full with required outputs
+- `run_scope` and `run_key` resolved before the first save, and the checkpoint written to the path they name
+- Any pre-existing checkpoint for this scope was reported to the user and either resumed or replaced
 
 ### ❌ SYSTEM FAILURE:
 
 - Skipped sequence steps or missing outputs
+- Saving progress before run identity is resolved, or writing to a checkpoint path that carries no run identity
+- Appending this run's progress to a checkpoint left by a previous run
   **Master Rule:** Skipping steps is FORBIDDEN.

package/src/workflows/testarch/bmad-testarch-test-design/steps-c/step-01b-resume.md

@@ -1,14 +1,16 @@
 ---
 name: 'step-01b-resume'
-description: 'Resume interrupted workflow from last completed step'
-outputFile: '{test_artifacts}/test-design-progress.md'
+description: 'Resume an interrupted run from its own checkpoint, matched by run identity'
+outputFile: '{test_artifacts}/test-design-progress-{run_key}.md'
+progressGlob: '{test_artifacts}/test-design-progress-*.md'
+legacyOutputFile: '{test_artifacts}/test-design-progress.md'
 ---
 
 # Step 1b: Resume Workflow
 
 ## STEP GOAL
 
-Resume an interrupted workflow by loading the existing output document, displaying progress, and routing to the next incomplete step.
+Resume an interrupted workflow by selecting the checkpoint that belongs to the run being resumed, loading its progress, displaying it, and routing to the next incomplete step.
 
 ## MANDATORY EXECUTION RULES
 
@@ -24,19 +26,40 @@ Resume an interrupted workflow by loading the existing output document, displayi
 
 ## CONTEXT BOUNDARIES:
 
-- Available context: Output document with progress frontmatter
-- Focus: Load progress and route to next step
-- Limits: Do not re-execute completed steps
-- Dependencies: Output document must exist from a previous run
+- Available context: progress checkpoints written by previous runs
+- Focus: Select the correct run's checkpoint, load its progress, and route to the next step
+- Limits: Do not re-execute completed steps; do not resume a checkpoint belonging to a different run
+- Dependencies: A checkpoint must exist from a previous run of the same scope
 
 ## MANDATORY SEQUENCE
 
 **CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise.
 
-### 1. Load Output Document
+### 1. Select the Run to Resume
 
-Read `{outputFile}` and parse YAML frontmatter for:
+Each run writes its own checkpoint at `{outputFile}`, where `run_key` is `system` for system-level runs and `epic-{epic_num}` for epic-level runs. Build the candidate list:
 
+1. List every file matching `{progressGlob}`.
+2. Also check `{legacyOutputFile}`. Runs from before checkpoints carried run identity wrote to that fixed name.
+
+Then select one:
+
+- **No candidates:** display "⚠️ **No previous progress found.** There is no checkpoint to resume from. Please use **[C] Create** to start a fresh workflow run." **Halt.**
+
+- **The user named a scope in this invocation** (a specific epic, or system-level): resolve `run_key` exactly as `step-01-detect-mode.md` does, then select `{outputFile}` for that key. If no checkpoint exists for it, display "⚠️ **No progress found for `{run_key}`.** Checkpoints exist for: {list of candidate run keys}. Use **[C] Create** to start a run for `{run_key}`, or name one of the listed scopes." **Halt.** Never fall back to another scope's checkpoint.
+
+- **Exactly one candidate and no scope named:** select it and state which run it belongs to before continuing.
+
+- **More than one candidate and no scope named:** list each candidate with its `runKey`, `lastStep`, and `lastSaved`, and ask which run to resume. **Halt** until the user answers.
+
+---
+
+### 2. Load the Selected Checkpoint
+
+Read the selected checkpoint and parse YAML frontmatter for:
+
+- `runScope` — `system-level` or `epic-level`
+- `runKey` — this run's identity
 - `workflowStatus` — overall workflow state (`in-progress` or `completed`)
 - `totalSteps` — total number of create-mode workflow steps
 - `stepsCompleted` — array of completed step names
@@ -44,6 +67,10 @@ Read `{outputFile}` and parse YAML frontmatter for:
 - `nextStep` — next step file to execute
 - `lastSaved` — timestamp of last save
 
+**Run identity check.** When the user named a scope in this invocation, `runKey` must equal the `run_key` resolved for it. If it does not, display "⚠️ **Checkpoint belongs to a different run** (`{runKey}`, not `{run_key}`). Refusing to resume." **Halt.** Do not read its progress state and do not report its `workflowStatus`. When the user named no scope, adopt the checkpoint's own `runScope` and `runKey` as this run's identity.
+
+**Legacy checkpoint migration.** If `runKey` is absent, the checkpoint predates run identity and cannot be proven to belong to any scope. Ask the user which run it covers (a specific epic, or system-level) and **halt** until they answer. Resolve `run_scope` and `run_key` from their answer exactly as `step-01-detect-mode.md` does, write the checkpoint's content to `{outputFile}` with `runScope` and `runKey` added, delete `{legacyOutputFile}`, and continue from the migrated file.
+
 If `workflowStatus`, `totalSteps`, or `nextStep` are missing (legacy progress file), infer them from `lastStep` using this mapping:
 
 - `'step-01-detect-mode'` → `workflowStatus: 'in-progress'`, `totalSteps: 5`, `nextStep: './step-02-load-context.md'`
@@ -52,20 +79,15 @@ If `workflowStatus`, `totalSteps`, or `nextStep` are missing (legacy progress fi
 - `'step-04-coverage-plan'` → `workflowStatus: 'in-progress'`, `totalSteps: 5`, `nextStep: './step-05-generate-output.md'`
 - `'step-05-generate-output'` → `workflowStatus: 'completed'`, `totalSteps: 5`, `nextStep: ''`
 
-**If `{outputFile}` does not exist**, display:
-
-"⚠️ **No previous progress found.** There is no output document to resume from. Please use **[C] Create** to start a fresh workflow run."
-
-**THEN:** Halt. Do not proceed.
-
 ---
 
-### 2. Display Progress Dashboard
+### 3. Display Progress Dashboard
 
 Display:
 
 "📋 **Workflow Resume — Test Design and Risk Assessment**
 
+**Run:** {runKey} ({runScope})
 **Workflow status:** {workflowStatus}
 **Last saved:** {lastSaved}
 **Last completed step:** {lastStep}
@@ -74,7 +96,7 @@ Display:
 
 ---
 
-### 3. Route to Next Step
+### 4. Route to Next Step
 
 If `workflowStatus` is `'completed'`, display:
 "✅ **All steps completed.** Use **[V] Validate** to review outputs or **[E] Edit** to make revisions."
@@ -93,7 +115,7 @@ If `nextStep` is one of the known create-mode step files below, load it, read co
 
 **THEN:** Halt.
 
-The existing content in `{outputFile}` provides context from previously completed steps.
+The existing content in the selected checkpoint provides context from previously completed steps. Every later step continues writing to that same checkpoint, so `runScope` and `runKey` stay unchanged for the rest of the run.
 
 ---
 
@@ -101,16 +123,19 @@ The existing content in `{outputFile}` provides context from previously complete
 
 ### ✅ SUCCESS:
 
-- Output document loaded and parsed correctly
+- The checkpoint belonging to the requested run was selected, and any ambiguity was resolved by asking
+- Checkpoint loaded and parsed correctly
 - Explicit or legacy progress state resolved correctly
-- Progress dashboard displayed accurately
+- Progress dashboard displayed accurately, including run identity
 - Routed to correct next step
 
 ### ❌ SYSTEM FAILURE:
 
-- Not loading output document
+- Resuming a checkpoint whose `runKey` differs from the run being resumed
+- Silently picking one checkpoint when several exist
+- Not loading the checkpoint
 - Incorrect progress display
 - Routing to wrong step
 - Re-executing completed steps
 
-**Master Rule:** Resume MUST route to the exact next incomplete step. Never re-execute completed steps.
+**Master Rule:** Resume MUST route to the exact next incomplete step of the run it was asked to resume. Never re-execute completed steps, and never continue another run's checkpoint.

package/src/workflows/testarch/bmad-testarch-test-design/steps-c/step-02-load-context.md

@@ -3,7 +3,7 @@ name: 'step-02-load-context'
 description: 'Load documents, configuration, and knowledge fragments for the chosen mode'
 nextStepFile: '{skill-root}/steps-c/step-03-risk-and-testability.md'
 knowledgeIndex: './resources/tea-index.csv'
-outputFile: '{test_artifacts}/test-design-progress.md'
+outputFile: '{test_artifacts}/test-design-progress-{run_key}.md'
 ---
 
 # Step 2: Load Context & Knowledge Base
@@ -81,6 +81,8 @@ Extract:
 
 ### Epic-Level Mode (Phase 4)
 
+Load documents for the epic identified by the `epic_num` resolved in step 1. Do not widen the scope to other epics and do not re-derive `epic_num`.
+
 Load:
 
 - Epic and story docs with acceptance criteria
@@ -221,6 +223,8 @@ Summarize what was loaded and confirm with the user if anything is missing.
 
   ```yaml
   ---
+  runScope: '{run_scope}'
+  runKey: '{run_key}'
   workflowStatus: 'in-progress'
   totalSteps: 5
   stepsCompleted: ['step-02-load-context']
@@ -233,6 +237,7 @@ Summarize what was loaded and confirm with the user if anything is missing.
   Then write this step's output below the frontmatter.
 
 - **If `{outputFile}` already exists**, update:
+  - Leave `runScope` and `runKey` exactly as step 1 wrote them
   - Set `workflowStatus: 'in-progress'`
   - Set `totalSteps: 5`
   - Add `'step-02-load-context'` to `stepsCompleted` array (only if not already present)

package/src/workflows/testarch/bmad-testarch-test-design/steps-c/step-03-risk-and-testability.md

@@ -2,7 +2,7 @@
 name: 'step-03-risk-and-testability'
 description: 'Perform testability review (system-level) and risk assessment'
 nextStepFile: '{skill-root}/steps-c/step-04-coverage-plan.md'
-outputFile: '{test_artifacts}/test-design-progress.md'
+outputFile: '{test_artifacts}/test-design-progress-{run_key}.md'
 ---
 
 # Step 3: Testability & Risk Assessment
@@ -96,6 +96,8 @@ Summarize the highest risks and their mitigation priorities.
 
   ```yaml
   ---
+  runScope: '{run_scope}'
+  runKey: '{run_key}'
   workflowStatus: 'in-progress'
   totalSteps: 5
   stepsCompleted: ['step-03-risk-and-testability']
@@ -108,6 +110,7 @@ Summarize the highest risks and their mitigation priorities.
   Then write this step's output below the frontmatter.
 
 - **If `{outputFile}` already exists**, update:
+  - Leave `runScope` and `runKey` exactly as step 1 wrote them
   - Set `workflowStatus: 'in-progress'`
   - Set `totalSteps: 5`
   - Add `'step-03-risk-and-testability'` to `stepsCompleted` array (only if not already present)

package/src/workflows/testarch/bmad-testarch-test-design/steps-c/step-04-coverage-plan.md

@@ -2,7 +2,7 @@
 name: 'step-04-coverage-plan'
 description: 'Design test coverage, priorities, execution strategy, and estimates'
 nextStepFile: '{skill-root}/steps-c/step-05-generate-output.md'
-outputFile: '{test_artifacts}/test-design-progress.md'
+outputFile: '{test_artifacts}/test-design-progress-{run_key}.md'
 ---
 
 # Step 4: Coverage Plan & Execution Strategy
@@ -111,6 +111,8 @@ Define thresholds:
 
   ```yaml
   ---
+  runScope: '{run_scope}'
+  runKey: '{run_key}'
   workflowStatus: 'in-progress'
   totalSteps: 5
   stepsCompleted: ['step-04-coverage-plan']
@@ -123,6 +125,7 @@ Define thresholds:
   Then write this step's output below the frontmatter.
 
 - **If `{outputFile}` already exists**, update:
+  - Leave `runScope` and `runKey` exactly as step 1 wrote them
   - Set `workflowStatus: 'in-progress'`
   - Set `totalSteps: 5`
   - Add `'step-04-coverage-plan'` to `stepsCompleted` array (only if not already present)

package/src/workflows/testarch/bmad-testarch-test-design/steps-c/step-05-generate-output.md

@@ -2,7 +2,7 @@
 name: 'step-05-generate-output'
 description: 'Generate output documents with adaptive orchestration (agent-team, subagent, or sequential)'
 outputFile: '{test_artifacts}/test-design-epic-{epic_num}.md'
-progressFile: '{test_artifacts}/test-design-progress.md'
+progressFile: '{test_artifacts}/test-design-progress-{run_key}.md'
 ---
 
 # Step 5: Generate Outputs & Validate
@@ -119,7 +119,7 @@ If `resolvedMode` is `agent-team` or `subagent`, these two documents can be gene
 Generate **one** document:
 
 - `{outputFile}` using `test-design-template.md`
-- If `epic_num` is unclear, ask the user
+- Use the `epic_num` resolved in step 1. It is the value that named this run's progress checkpoint, so the plan and its checkpoint always identify the same run. Do not re-derive it and do not ask the user again.
 
 Epic-level mode remains single-worker by default (one output artifact).
 
@@ -198,6 +198,8 @@ Summarize:
 
   ```yaml
   ---
+  runScope: '{run_scope}'
+  runKey: '{run_key}'
   workflowStatus: 'completed'
   totalSteps: 5
   stepsCompleted: ['step-05-generate-output']
@@ -210,6 +212,7 @@ Summarize:
   Then write this step's output below the frontmatter.
 
 - **If `{progressFile}` already exists**, update:
+  - Leave `runScope` and `runKey` exactly as step 1 wrote them
   - Set `workflowStatus: 'completed'`
   - Set `totalSteps: 5`
   - Add `'step-05-generate-output'` to `stepsCompleted` array (only if not already present)

package/src/workflows/testarch/bmad-testarch-test-design/workflow-plan.md

@@ -20,3 +20,4 @@
 
 - {test_artifacts}/test-design-qa.md (system-level)
 - {test_artifacts}/test-design-epic-{epic_num}.md (epic-level)
+- {test_artifacts}/test-design-progress-{run_key}.md (resume checkpoint; run_key is `system` or `epic-{epic_num}`)