bmad-method-test-architecture-enterprise 3.3.0 → 3.4.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 generation in red and expand modes with automatic run-and-heal, combined framework and CI setup, CI/CD quality gates, and structured testing education. Existing CI and ATDD customizations can be migrated to the new skill names. Part of the BMad Method ecosystem.",
-      "version": "3.3.0",
+      "version": "3.4.0",
       "author": {
         "name": "Murat K Ozcan (TEA Creator) & Brian (BMad) Madison"
       },

package/cli/lib/evaluate/test-design-replay.js

@@ -101,8 +101,9 @@ function scoreRun(set, design, categories) {
     // Every row is checked, and a row under a heading that declares no range is a
     // band failure. Counting only the rows that sat under a declared range let a
     // single rangeless heading exempt them: `### Medium/Low-Priority Risks`, the
-    // literal heading test-design-qa-template.md ships, took the denominator to
-    // zero and a score-9 risk filed beneath it scored a clean 100%. `banded` is
+    // heading test-design-qa-template.md shipped before it declared `(Score 1-5)`,
+    // took the denominator to zero and a score-9 risk filed beneath it scored a
+    // clean 100%. `banded` is
     // therefore `rows` and the question is how many of them were placed correctly.
     shape.banded += 1;
     const placed = bandFor(risk.headings);

package/package.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://json.schemastore.org/package.json",
   "name": "bmad-method-test-architecture-enterprise",
-  "version": "3.3.0",
+  "version": "3.4.0",
   "description": "Master Test Architect for quality strategy, test automation, and release gates",
   "keywords": [
     "bmad",
@@ -156,7 +156,7 @@
     "test:eval-routing-evidence": "node test/test-routing-evidence.js",
     "test:eval-schemas": "node tools/validate-eval-schemas.js",
     "test:eval-teach-me-testing-data": "node test/eval-teach-me-testing.js --validate-only",
-    "test:eval-test-design-data": "node test/eval-test-design.js --validate-only && node test/test-test-design-grounding.js",
+    "test:eval-test-design-data": "node test/eval-test-design.js --validate-only && node test/test-test-design-grounding.js && node test/test-test-design-editorial.js",
     "test:eval-trace-data": "node test/eval-trace.js --validate-only",
     "test:eval-transcript-data": "node test/eval-transcript.js --validate-only",
     "test:evaluate-agents": "node test/test-evaluate-evaluators.js --group=agents",

package/skills/bmad-tea-automate/red/atdd-checklist-template.md

@@ -55,7 +55,7 @@ inputDocuments: []
 - **Checklist Path:** `{test_artifacts}/atdd/atdd-checklist-{story_key}.md`
 - **Generated Test Files:** `{e2e_test_file_path}`, `{api_test_file_path}`, `{component_test_file_path}`
 
-If this story came from BMM `create-story`, mirror these artifact paths into the story's `Dev Notes` so `dev-story` can discover and activate the red-phase scaffolds.
+If this story is implemented with BMM `bmad-build`, list these artifact paths in its spec (Code Map and the tasks that turn them green) so the implementation agent discovers and activates the red-phase scaffolds. On BMAD releases before 6.12, mirror them into the `create-story` story's `Dev Notes` for `dev-story` instead.
 
 ---
 

package/skills/bmad-tea-automate/red/resources/atdd-checklist-2-4-guest-checkout.example.md

@@ -63,7 +63,7 @@ Shoppers currently must create an account before they can pay, and cart abandonm
 - **Checklist Path:** `docs/test-artifacts/atdd/atdd-checklist-2-4-guest-checkout.md`
 - **Generated Test Files:** `tests/e2e/guest-checkout.spec.ts`, `tests/api/guest-checkout.spec.ts`
 
-If this story came from BMM `create-story`, mirror these artifact paths into the story's `Dev Notes` so `dev-story` can discover and activate the red-phase scaffolds.
+If this story is implemented with BMM `bmad-build`, list these artifact paths in its spec (Code Map and the tasks that turn them green) so the implementation agent discovers and activates the red-phase scaffolds. On BMAD releases before 6.12, mirror them into the `create-story` story's `Dev Notes` for `dev-story` instead.
 
 ---
 

package/skills/bmad-tea-automate/red/steps-c/step-01-preflight-and-context.md

@@ -86,7 +86,7 @@ If any are missing: **HALT** and notify the user.
   - With neither, use a slug of the story title: lowercase; replace every run of characters outside `a-z` and `0-9` with a single `-`; trim leading and trailing `-`; truncate to 64 characters
 - Use that `story_key` for the `{outputFile}` basename so all checklist and handoff paths stay consistent
 - If `story_id` is still unavailable after metadata/H1/filename parsing, set it to the final `story_key` so `story_id` is never empty
-- Preserve `{story_file}` as a tracked artifact path for later handoff into BMM `dev-story`
+- Preserve `{story_file}` as a tracked artifact path for later handoff into BMM `bmad-build` (`dev-story` before BMAD 6.12)
 - If a test design covers this story, read it for P0-P3 priorities and risks. Look in `{test_artifacts}/test-design/` first (`test-design-epic-{epic_num}.md` for the story's epic, then the system-level `test-design-qa.md` and `test-design-architecture.md`), then the legacy root `{test_artifacts}/` for the same names. Record the path you loaded in `inputDocuments`, or state that no test design was found in either location.
 
 ---

package/skills/bmad-tea-automate/red/steps-c/step-05-validate-and-complete.md

@@ -89,7 +89,7 @@ Report:
 - Checklist output path
 - Story key / story file handoff path
 - Key risks or assumptions
-- Next recommended workflow (usually `dev-story`; `automate` comes after implementation)
+- Next recommended workflow (usually BMM `bmad-build`, or `dev-story` before BMAD 6.12; `automate` comes after implementation)
 
 ---
 

package/skills/bmad-tea-test-design/checklist.md

@@ -56,7 +56,7 @@
 - [ ] Test levels selected (E2E/API/Component/Unit)
 - [ ] No duplicate coverage across levels
 - [ ] Priority levels assigned (P0/P1/P2/P3)
-- [ ] P0 scenarios meet strict criteria (blocks core + high risk + no workaround)
+- [ ] P0 scenarios meet strict criteria (critical business, security, data-integrity, or compliance consequence + no safe workaround)
 - [ ] NFR-derived risks mapped to planned validation scenarios
 - [ ] Planned NFR evidence artifacts documented without final PASS/CONCERNS/FAIL decisions
 - [ ] Data prerequisites identified
@@ -233,6 +233,39 @@
 - [ ] Regression scope defined per impacted service
 - [ ] Cross-team coordination noted where needed
 
+## Document Quality (All Outputs)
+
+**Applies to every output: the epic document in epic-level mode, and both documents plus the handoff in system-level mode.** These items check the Editorial Contract in `steps-c/step-05-generate-output.md`.
+
+### Clear Instructions
+
+- [ ] Each instruction names the actor, action, condition, and expected result wherever the sources provide them
+- [ ] Prerequisites, conditions, and warnings appear before the action they govern
+- [ ] Instructions that combine several actions or conditions are split into separate steps, and no condition was lost in the split
+- [ ] One name per concept; repository names and domain terms match the sources exactly
+- [ ] No filler sentences, promotional claims, or vague attribution; citations are kept
+- [ ] Emojis appear only where the template uses them as markers, such as the Quick Guide tiers
+- [ ] No banned-word list was applied: exact technical terms such as test harness and test vector remain
+
+### Evidence and Uncertainty
+
+- [ ] Missing details remain visible as `UNKNOWN`, open assumptions, or clarification items; none was invented to complete a sentence
+- [ ] Observed facts, planned checks, assumptions, and unknowns read as what they are
+- [ ] Planned tests read as planned; no planned test is described as run, verified, or passing
+- [ ] Confidence statements and unverified behavior from the sources are still stated
+
+### Protected Content
+
+- [ ] Requirement, risk, and test IDs, requirement-to-test mappings, source links, evidence references, and exclusions match the decisions of steps 3 and 4
+- [ ] Risk categories, probabilities, impacts, scores, owners, mitigations, and timelines match the decisions of steps 3 and 4
+- [ ] Test levels, priorities, preconditions, test data, sequences, assertions, negative cases, cleanup, and dependencies are intact
+- [ ] Thresholds, units, comparison operators, timeouts, retry counts, quantifiers, and negations are exact
+- [ ] Literal commands, paths, code, regular expressions, payloads, Unicode test data, and expected strings are exact
+- [ ] Priority headings open with `P0`, `P1`, `P2`, or `P3`, and every risk-band heading states its score range
+- [ ] No scored risk table or coverage table sits under a heading that opens or ends with Example or Illustration, a heading that ends with Reference, or a paragraph opening `Example:`, `Worked example:`, or `Illustration:`
+- [ ] No scored risk table or coverage table sits inside a blockquote or callout
+- [ ] Validation ran on the saved files after the last edit, and every check affected by a later fix was rerun
+
 ## System-Level Mode: Two-Document Validation
 
 **When in system-level mode (PRD + ADR input), validate BOTH documents:**
@@ -349,9 +382,9 @@
 - [ ] Dates and authors match across documents
 - [ ] ADR and PRD references consistent
 
-### Document Quality (Anti-Bloat Check)
+### System-Level Anti-Bloat Check
 
-**CRITICAL: Check for bloat and repetition across BOTH documents.**
+**CRITICAL: Check for bloat and repetition across BOTH documents.** Document Quality (All Outputs) covers wording and tone.
 
 - [ ] **No repeated notes 10+ times** (e.g., "Timing is pessimistic until R-005 fixed" on every section)
 - [ ] **Repeated information consolidated** (write once at top, reference briefly if needed)
@@ -360,10 +393,6 @@
 - [ ] **Architecture doc**: Concerns-focused, NOT implementation-focused
 - [ ] **QA doc**: Implementation-focused, NOT theory-focused
 - [ ] **Clear separation**: Architecture = WHAT and WHY, QA = HOW
-- [ ] **Professional tone**: No AI slop markers
-  - [ ] Avoid excessive ✅/❌ emojis (use sparingly, only when adding clarity)
-  - [ ] Avoid "absolutely", "excellent", "fantastic", overly enthusiastic language
-  - [ ] Write professionally and directly
 - [ ] **Architecture doc length**: Target ~150-200 lines max (focus on actionable concerns only)
 - [ ] **QA doc length**: Keep concise, remove bloat sections
 
@@ -406,6 +435,8 @@
 - [ ] **System-level mode:** Both documents validated (if applicable)
 - [ ] **System-level mode:** Handoff document validated (if applicable)
 - [ ] **Epic-level mode:** Single document validated (if applicable)
+- [ ] Document Quality (All Outputs) passed for every output
+- [ ] Final validation ran after the last edit to every output
 - [ ] Team review scheduled (if required)
 
 ## Post-Workflow Actions
@@ -441,7 +472,7 @@ If workflow fails:
 
 **Issue**: Too many P0 tests
 
-- **Solution**: Apply strict P0 criteria - must block core AND high risk AND no workaround
+- **Solution**: Apply strict P0 criteria - must have a critical business, security, data-integrity, or compliance consequence AND no safe workaround
 
 **Issue**: Risk scores all high
 

package/skills/bmad-tea-test-design/steps-c/step-03-risk-and-testability.md

@@ -72,7 +72,7 @@ Using `risk-governance.md` and `probability-impact.md` (if loaded):
 - Preserve the risk table columns `Risk ID`, `Category`, `Description`, `Probability`, `Impact`, and `Score`. Add a separate source-evidence column when useful. State the failure consequence in `Description` and cite the supporting input.
 - Open each `Description` with the source statement's own key words for the gap, such as the verbs and nouns the epic uses for the missing control, the unsafe behavior, or the unmet target, then state the consequence. A reader searching the epic for those words finds the row.
 - Give every risk table the header its band has in the template. The delimiter row and every body row carry exactly as many cells as that header. Put owner and timeline text inside the `Mitigation` or `Action` cell when the band's header has no column for them.
-- Assign unique canonical IDs `R-001`, `R-002`, and so on. Preserve those IDs in coverage, mitigations, summaries, and handoffs. Keep epic or story identity in the document run key.
+- Assign unique canonical IDs `R-001`, `R-002`, and so on, numbered in the order the risks' gap statements first appear in the supplied sources. Read the sources in the order step 2 lists them for the mode, and each source from top to bottom. A merged risk takes the position of its earliest statement. Residual risks, registered when no gap statement exists, are numbered in story order. Within each band table, list rows in ID order. Preserve those IDs in coverage, mitigations, summaries, and handoffs. Keep epic or story identity in the document run key.
 - Preserve explicit score ranges in risk-band headings: high score 6 or greater, medium score 3 to 4, and low score 1 to 2. For a band with no identified risk, state that absence outside the table and leave its table body empty.
 - Classify by category: TECH / SEC / PERF / DATA / BUS / OPS
 - Score Probability (1–3) and Impact (1–3)

package/skills/bmad-tea-test-design/steps-c/step-04-coverage-plan.md

@@ -47,19 +47,26 @@ For each requirement or risk-driven scenario:
 - Map NFR-derived risks to planned validation scenarios and evidence sources
 - Use the exact `Risk ID` assigned in the risk register in every `Risk Link` cell. A prose description alone is not a traceable mapping.
 - Each `Test Level` cell contains exactly one canonical value: E2E, API, Component, Integration, or Unit. Put performance, operational, device, and other qualifiers in scenario descriptions or notes.
-- Give every scored risk exactly one risk-linked coverage row, and give it the single test level where the failure first becomes observable. The failure crosses no boundary: Unit. It lives in one rendered interface unit: Component. It crosses one owned store, queue, file, or event boundary: Integration. It crosses the HTTP or contract boundary of one service: API. It spans two or more deployables, a user journey, or a deadline measured on real devices: E2E. Name the risk's mechanism, the boundary it crosses, and the resulting level in the row notes. Record the individual scenarios in the row's `Notes` and their number in `Test Count`; do not add a second row for the same risk. Rows that cover no scored risk use `-` in `Risk Link`.
+- Give every scored risk exactly one risk-linked coverage row, and give it the single test level where the failure first becomes observable. The failure crosses no boundary: Unit. It lives in one rendered interface unit: Component. It crosses one owned store, queue, file, or event boundary: Integration. It crosses the HTTP or contract boundary of one service: API. It spans two or more deployables, a user journey, or a deadline measured on real devices: E2E. When the mechanism fits more than one description, settle the level with these rules:
+  - Use the boundary of the component that lacks the control or behaves unsafely. The system whose response triggers the failure does not set the level.
+  - Classify the failure as the sources describe it today, with the components they name. A mitigation component the sources do not name, such as a new configuration value or a policy extracted for testing, does not set the level.
+  - For an absent control, take the level of the behavior that control would govern, as the sources describe that behavior. Absence of a control does not by itself make a risk Unit.
+  - A missing release, rollout, or disable control for a build that users install, such as a mobile or desktop app, spans the shipped build and the system that would switch it: E2E. A switch read inside one service takes that service's boundary.
+
+  Name the risk's mechanism, the boundary it crosses, and the resulting level in the row notes. Record the individual scenarios in the row's `Notes` and their number in `Test Count`; do not add a second row for the same risk. Rows that cover no scored risk use `-` in `Risk Link`.
+
 - Place a risk's row under the one priority heading that matches its consequence. A risk never appears under two priority headings.
 
 **Priority rules:** decide each priority on business impact, user reach, and workaround
 availability. Risk score is supporting evidence and is not a required condition for any priority.
-Walk the Priority Decision Tree in `test-priorities-matrix.md` for each scenario.
+Walk the Priority Decision Tree in `test-priorities-matrix.md` for each scenario. Wherever that fragment assigns P0, in its criteria, checklist, decision tree, or example function, the P0 holds only when both P0 conditions below hold; otherwise assign P1 or lower.
 
 - P0: Critical business, security, data-integrity, or compliance impact with no safe workaround
 - P1: Core, frequent, or complex behavior with material user reach and a limited workaround
 - P2: Secondary behavior with narrower user reach and an acceptable workaround
 - P3: Rare, cosmetic, or experimental behavior with minimal impact and an easy workaround
 
-Record the failure consequence and the source-supported workaround in the primary coverage row's notes. Preserve these four priority criteria in the published plan. Evaluate a performance budget or an operational control through its documented business consequence before assigning its test priority. Assess a workaround against the original failure consequence, before proposed mitigations. A valid workaround preserves essential business operation and resolves the affected state. Pausing the application, leaving a core user action unresolved, or suppressing a symptom needs a source-backed recovery path before it can justify a lower priority. Record the evidence for recoverability; mark it unresolved when the source provides none. Separate an acceptance threshold from the consequence of missing it. For a latency or throughput target, state whether the source establishes a critical business deadline, permanent loss, blocked essential operation, or bounded degradation while work remains recoverable. Record an unstated business consequence as a clarification. Assign P0 when the documented consequence meets the critical-impact criterion. A release acceptance target can still have P1 coverage when the documented consequence is material degradation. An empty priority band is valid; explain why the planned scenarios belong to the assigned bands. When every primary risk has the same priority, justify how each consequence meets that criterion.
+Record the failure consequence and the source-supported workaround in the primary coverage row's notes. Preserve these four priority criteria in the published plan. Evaluate a performance budget or an operational control through its documented business consequence before assigning its test priority. Assess a workaround against the original failure consequence, before proposed mitigations. A valid workaround preserves essential business operation and resolves the affected state. Pausing the application, leaving a core user action unresolved, or suppressing a symptom needs a source-backed recovery path before it can justify a lower priority. Record the evidence for recoverability; mark it unresolved when the source provides none. Separate an acceptance threshold from the consequence of missing it. For a latency or throughput target, state whether the source establishes a critical business deadline, permanent loss, blocked essential operation, or bounded degradation while work remains recoverable. Record an unstated business consequence as a clarification. Assign P0 only when both conditions hold: the documented consequence is a critical business, security, data-integrity, or compliance impact, and no safe workaround exists. A missing workaround alone leaves a risk at P1 or lower. Judge each risk on its own documented consequence. A risk whose consequence is that another registered risk's harm lasts longer or reaches more users takes P1 or lower, and the risk that causes the harm carries the P0 scenarios. This does not apply when the sources mandate the missing control itself, or when no registered risk carries the harm the control would limit; judge those on the critical-impact criterion. A release acceptance target can still have P1 coverage when the documented consequence is material degradation. An empty priority band is valid; explain why the planned scenarios belong to the assigned bands. When every primary risk has the same priority, justify how each consequence meets that criterion.
 
 ---
 

package/skills/bmad-tea-test-design/steps-c/step-05-generate-output.md

@@ -9,7 +9,7 @@ progressFile: '{test_artifacts}/test-design/test-design-progress-{run_key}.md'
 
 ## STEP GOAL
 
-Write the final test-design document(s) using the correct template(s), then validate against the checklist.
+Write the final test-design document(s) using the correct template(s), polish them under the Editorial Contract, then validate the saved outputs against the checklist.
 
 ## MANDATORY EXECUTION RULES
 
@@ -135,8 +135,53 @@ Epic-level mode remains single-worker by default (one output artifact).
 
 ---
 
+## Editorial Contract
+
+This contract governs the wording of every Create-mode output: the epic document, both system-level documents, and the handoff. Apply it while populating templates in section 2, and again as the final cleanup in section 4. It needs no separate prompt or extra pass from the user.
+
+It edits prose only. Scope, risk scores, priorities, coverage, risk acceptance, and release criteria keep the values steps 3 and 4 decided. When editing exposes a substantive defect, such as a missing scenario, a wrong score, or an unmapped risk, return to the step that owns that decision, fix it there, and carry the fix forward. Never repair it as a wording change.
+
+When rules conflict, resolve them in this order: technical correctness and evidence, then the template and parser contracts, then reviewer comprehension, then style.
+
+### Writing Rules
+
+- Replace filler with a concrete statement, or delete it when no information is lost.
+- State the actor, action, condition, and expected result whenever the sources provide them. When a needed detail is missing, keep the gap visible as `UNKNOWN`, an open assumption, or a clarification item, and leave it unfilled.
+- Use one name per concept. Keep the exact repository names and domain terms the sources use.
+- Put prerequisites, conditions, and warnings before the action they govern.
+- Split an instruction that combines several actions or conditions into separate steps. Keep complete sentences and the context a reader needs; a shorter sentence that loses a condition is a defect.
+- Keep rationale, scenario references, and execution instructions in the template sections that already hold them.
+- Remove promotional claims and vague attribution such as "industry best practice says". Keep citations, and make clear which statements are observed facts, planned checks, assumptions, or unknowns.
+- Write planned verification as planned. A test that has not run never reads as run, verified, or passing.
+
+### Protected Content
+
+Keep these exact, in meaning and in text, through every edit:
+
+- Requirement, risk, and test IDs; requirement-to-test mappings; source links and evidence references; explicit exclusions.
+- Risk category, probability, impact, score, owner, mitigation, and timeline decisions.
+- Test levels and priorities; preconditions, test data, sequence, assertions, negative cases, cleanup, and dependencies.
+- Thresholds, units, comparison operators, timeouts, retry counts, quantifiers, and negations.
+- Assumptions, unknowns, confidence statements, unverified behavior, unresolved owners, and missing acceptance criteria.
+- Literal commands, paths, symbols, code, regular expressions, payloads, Unicode test data, and expected strings.
+- Required filenames, headings, table headers, status values, and handoff keys.
+
+Downstream scoring reads the documents by structure, so structure is protected too:
+
+- Priority section headings open with `P0`, `P1`, `P2`, or `P3`. Keep that opening when rewording a heading.
+- Risk-band headings state their score range, for example `(Score ≥6)`. Keep the range.
+- A heading that opens or ends with Example or Illustration, a heading that ends with Reference, and a paragraph that opens `Example:`, `Worked example:`, or `Illustration:` mark the tables after them as reference material, and scoring skips them. Never place a scored risk table or coverage table under such a label, and never add such a label above one.
+- Scoring also skips every table inside a blockquote. Keep scored risk and coverage tables out of blockquotes and callouts.
+- Keep the canonical risk and coverage column names from the templates.
+
+This contract sets no banned-word or punctuation list. Terms such as test harness and test vector can be exact technical language. A reusable safety requirement stays even when it also applies to other projects. Keep uncertainty wherever the sources are uncertain. Keep every required document; the system-level pair stays two documents.
+
+---
+
 ## 2. Populate Templates
 
+Write each output with the Editorial Contract applied from the start.
+
 Ensure the outputs include:
 
 - Risk assessment matrix
@@ -150,19 +195,7 @@ Ensure the outputs include:
 
 ---
 
-## 3. Validation
-
-Validate the output(s) against:
-
-- `checklist.md` in this workflow folder
-- [ ] CLI sessions cleaned up (no orphaned browsers)
-- [ ] Temp artifacts stored under `{test_artifacts}/test-design/`
-
-If any checklist criteria are missing, fix before completion.
-
----
-
-## 4. Generate BMAD Handoff Document (System-Level Mode Only)
+## 3. Generate BMAD Handoff Document (System-Level Mode Only)
 
 **If this is a system-level test design** (not component/feature level):
 
@@ -178,15 +211,30 @@ If any checklist criteria are missing, fix before completion.
 
 ---
 
-## 5. Polish Output
+## 4. Polish Output
+
+Review every output saved so far, including the handoff in system-level mode, and finish all edits before section 5:
+
+1. **Apply the Editorial Contract**: Make the final wording pass. Compare each edited passage with its draft and confirm the Protected Content is unchanged.
+2. **Remove duplication**: Progressive-append workflow may have created repeated sections — consolidate
+3. **Verify consistency**: Ensure terminology, risk scores, and references are consistent throughout, and that the handoff carries the same risk IDs, scores, and priorities as the test design
+4. **Check completeness**: All template sections should be populated or explicitly marked N/A
+5. **Table schema**: Preserve the canonical risk and coverage column names from the templates. Verify every scored risk has one unique `R-<three digits>` ID, every coverage link preserves that exact ID, and every risk-band heading states its score range. Probability, Impact, and Score cells contain only bare integers; explain each judgment in prose and verify Score equals Probability × Impact. Empty bands contain no risk rows; describe the absence in prose outside the table. Keep each risk description readable and traceable to its source.
+6. **Format cleanup**: Ensure markdown formatting is clean (tables aligned, headers consistent, no orphaned references)
+
+---
+
+## 5. Validate Final Outputs
 
-Before finalizing, review the complete output document for quality:
+Validate after the last edit to every output. Read the saved files from disk: the epic document in epic-level mode, or both system-level documents and the handoff in system-level mode.
+
+Validate the output(s) against:
+
+- `checklist.md` in this workflow folder
+- [ ] CLI sessions cleaned up (no orphaned browsers)
+- [ ] Temp artifacts stored under `{test_artifacts}/test-design/`
 
-1. **Remove duplication**: Progressive-append workflow may have created repeated sections — consolidate
-2. **Verify consistency**: Ensure terminology, risk scores, and references are consistent throughout
-3. **Check completeness**: All template sections should be populated or explicitly marked N/A
-4. **Table schema**: Preserve the canonical risk and coverage column names from the templates. Verify every scored risk has one unique `R-<three digits>` ID, every coverage link preserves that exact ID, and every risk-band heading states its score range. Probability, Impact, and Score cells contain only bare integers; explain each judgment in prose and verify Score equals Probability × Impact. Empty bands contain no risk rows; describe the absence in prose outside the table. Keep each risk description readable and traceable to its source.
-5. **Format cleanup**: Ensure markdown formatting is clean (tables aligned, headers consistent, no orphaned references)
+If any checklist criteria are missing, fix before completion. A fix that changes a saved output reopens validation for the content it touched: rerun the risk, coverage, and cross-document checks after a risk or coverage change, the handoff checks after a handoff change, and the Document Quality checks after any wording change. Completion waits until the last rerun passes with no further edits.
 
 ---
 

package/skills/bmad-tea-test-design/steps-e/step-02-apply-edit.md

@@ -23,6 +23,9 @@ Apply the requested edits to the selected output and confirm changes.
 ### Step-Specific Rules:
 
 - 🎯 Only apply edits explicitly requested by the user
+- 🚫 Leave text the user did not ask to change exactly as it is; the Create-mode editorial polish does not run here
+- ✅ Write new or changed text under the Writing Rules of the Editorial Contract in `{skill-root}/steps-c/step-05-generate-output.md`
+- ✅ Change a protected value (an ID, score, priority, threshold, or heading) when the user asks for that change, and update every value and reference that depends on it: Score = Probability × Impact, the risk's score band, its coverage links, and its rows in the other system-level document and the handoff. Keep the canonical columns and the parser-sensitive heading rules intact, and leave protected content outside the requested change exactly as it is
 
 ## EXECUTION PROTOCOLS:
 

package/skills/bmad-tea-test-design/steps-v/step-01-validate.md

@@ -27,6 +27,7 @@ Validate outputs using the workflow checklist and record findings.
 - 🎯 Validate against `{validationChecklist}`
 - 🚫 Do not skip checks
 - 🚫 Never overwrite an existing validation report
+- 🚫 Report Document Quality findings without rewriting any validated output
 
 ## EXECUTION PROTOCOLS:
 

package/skills/bmad-tea-test-design/test-design-qa-template.md

@@ -115,7 +115,7 @@ test('example test @p0', async ({ apiRequest }) => {
 | ---------- | -------- | ------------------- | ----------- | ---------------------------- |
 | **{R-ID}** | {CAT}    | {Brief description} | **{Score}** | {How QA validates this risk} |
 
-### Medium/Low-Priority Risks
+### Medium/Low-Priority Risks (Score 1-5)
 
 | Risk ID | Category | Description         | Score   | QA Test Coverage             |
 | ------- | -------- | ------------------- | ------- | ---------------------------- |

package/skills/bmod-tea/bmod.toml

@@ -2,7 +2,7 @@
 
 [bmod]
 code = "tea"
-version = "3.3.0"
+version = "3.4.0"
 update_source = "github:bmad-code-org/bmad-method-test-architecture-enterprise/skills"
 skills = [
   "bmad-tea",