bmad-method-test-architecture-enterprise 3.2.0 → 3.4.0

package/skills/bmad-tea-evaluate/SKILL.md

@@ -21,6 +21,17 @@ You will continue to operate with your given name, identity, and communication_s
 - `{skill-name}` resolves to the skill directory's basename.
 - Resolve sibling files such as `references/...` and `assets/...` from `{skill-root}`.
 
+## Execution Authority
+
+Resolve intent before activation, customization resolution or any hook. Ordinary evaluation keeps its current workflow unchanged. Native clean/mutated trials, run comparison and baseline acceptance retain their existing authority and meaning.
+
+An explicit native compare/accept request keeps that command's authority, including a request that mentions consistency while comparing saved runs. Saved-result consistency is an experiment route only when the user asks to analyze variability in existing results. Resolve contextual words such as “these results” from the conversation before choosing a route.
+
+- Saved-result consistency or explicitly requested offline experiment analysis: load `references/configuration-experiments.md` and take its offline route directly. Suppress prepend, append and completion hooks. Do not run configuration resolver scripts, model calls, judge calls or fresh trials. Return after reporting the saved evidence.
+- Fresh repeatability or a one-factor configuration experiment: load `references/configuration-experiments.md` directly. Suppress prepend, append and completion hooks throughout this route. No hook can grant execution or spending authority.
+- “Is it repeatable?” without a saved/fresh choice: clarify saved records versus fresh runs before executing anything.
+- Ordinary evaluation, ordinary offline record evaluation or native compare/accept (including comparing saved runs): proceed with On Activation below. Do not load the experiment guide, analyze experiments or add trials after the normal result.
+
 ## On Activation
 
 Before resolving customizations or running hooks, inspect `{project-root}/_bmad/custom/` for `bmad-testarch-evaluate.toml` and `bmad-testarch-evaluate.user.toml`. If either exists, stop and tell the user to run `npx --package=bmad-method-test-architecture-enterprise@3 tea-migrate-customizations --project-root {project-root}`. Resolve any reported manual merge, then start a fresh chat. Do not continue with default settings while legacy overrides remain.

package/skills/bmad-tea-evaluate/references/configuration-experiments.md

@@ -0,0 +1,37 @@
+# Optional saved-result and configuration experiments
+
+Enter only after explicit experiment intent. Return directly after this route; activation and completion hooks stay suppressed. Ordinary Evaluate, native clean/mutated trials, native comparison and baseline acceptance keep their existing flow.
+
+## Route by intent
+
+- “Check how consistent the saved results from my latest Test Design evaluation are. Use only existing records. Do not rerun anything or make model calls.” means offline analysis.
+- “Compare Test Design at medium versus high reasoning effort on the same model” means a live proposal with a spending boundary.
+- “Compare Test Design model A versus B” means a one-factor proposal. “Compare one prompt-region change for Test Design” means a proposal that reports the unavailable prompt-region adapter before any spending approval.
+- “Run a fresh repeatability experiment” means a live proposal.
+- “Is it repeatable?” needs one clarification: existing saved results or fresh runs. Dispatch nothing before the answer.
+
+## Offline analysis
+
+Own discovery, input preparation, reader invocation and the report. Ask for the saved-run path or search root only when none is known from the conversation or evaluation output. Use the latest compatible records under that root and state every selected path. Do not ask the user to edit JSON, copy provenance or execute helper commands.
+
+Run the installed `tea-evaluate experiment --search-root <root> --out <new-report-directory>`, or use `--saved <exact-directory>`. In this repository use `node cli/evaluate.js experiment`. These commands read saved bytes and replay the deterministic Test Design scorer; they launch no target, model, judge or subprocess. Never invoke preflight, run, custom hooks or capture to fill a gap in saved evidence.
+
+Supported inputs are sealed legacy Test Design reader directories, native retained per-attempt directories and new experiment directories. Preserve original records and integrity files. For missing diagnostics, input identities or resources, report the resulting limitation. Use shipped ground truth only for matching native cases and input identity. An incompatible corpus needs its original companion ground truth through the legacy reader; this route cannot invent an adapter.
+
+No retrospective success threshold is invented. Explain spread, counts, recorded native stability and deterministic scorer replay separately. Historical receipts stay historical. A descriptive finding, a native gate failure, an inconclusive result, selection clearance and a confirmed recommendation remain distinct.
+
+## Live proposal and authority
+
+Check capability and corpus feasibility before asking for spending approval. Current Claude/Codex adapters cannot prove applied effort or enforce an all-in money cap. Codex also lacks verified money telemetry. Explain these blockers and dispatch zero attempts. Subscription access supplies no verified zero-dollar budget. The native corpus has two independent cases; selection consumes both, leaving no unseen confirmation cases. Repetitions cannot repair this limit. No corpus expansion is authorized.
+
+For a supported future mechanism or a labeled deterministic test double, batch consequential choices into one concrete plan approval: intended outcome, allowed quality loss or required improvement, critical failures, useful saving or latency limits, cases, repeats, retry bound, elapsed estimate, confirmation scope and verified all-in USD cap including overhead. Reuse previously approved thresholds only when they apply to the same identity. Missing decisions remain pending. Preparing a proposal grants no dispatch authority.
+
+The controller freezes declaration, native input/scorer identities, gates, analysis, schedule, stopping rules and execution identity before approval. Approval binds the exact plan digest and cap. The local unsigned journal validates recorded lifecycle order and bindings. It cannot prove tail completeness, resist wholesale rechaining or establish independent wall-clock chronology. Exposure history covers this experiment; prior candidate exposure is unknown. Every dispatch reserves its verified bound first. Failed, partial, canceled, timed-out and retried attempts stay in the archive and spending ledger. Missing telemetry, rejected capture integrity, archival failure or an unresolved reservation stops further dispatch. Recovery reports preserve originals and partial archives, and never rerun an unsettled attempt.
+
+The public CLI supports offline analysis, blocked native proposals through `--propose`, and reservation inspection through `--recover`. It supplies no approval or execution command. Approval and execution APIs currently serve the labeled deterministic integration tests; the native capability blockers prevent using those APIs to run providers.
+
+The implementation's process doubles are labeled `deterministic-test-double`. They verify orchestration and capture and establish no provider quality or savings. Paid smoke runs require separate approval. Production changes, defaults, baseline acceptance and recommendation adoption each retain their own authority.
+
+## Report
+
+Give a short result, what the evidence establishes, what remains unknown, all-attempt cost and resource limits, and links to the selected records and report. Name blockers precisely and give the next supported action. Keep this route optional; never start it after a routine evaluation result without explicit intent.

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.2.0"
+version = "3.4.0"
 update_source = "github:bmad-code-org/bmad-method-test-architecture-enterprise/skills"
 skills = [
   "bmad-tea",

package/skills/bmod-tea/help/help.md

@@ -9,7 +9,7 @@ This document covers the skills of the `tea` module: what each one gives the use
 - `bmad-tea-test-design`: risk-based test planning, producing a test design document. Recommend it during solutioning, before tests or a framework exist. Afterwards offer `bmad-tea-framework`.
 - `bmad-tea-framework`: owns production-ready framework and CI setup, with framework-only, CI-only, or both scope. It installs Playwright Utils or Pact.js Utils when enabled. Recommend it during solutioning, after test design. When CI scope cannot be inferred from the request, interactive runs ask whether to include CI. Unattended runs default to framework only and state in the summary that CI was excluded.
 - `bmad-tea-automate`: owns test generation in red or expand mode. Red mode writes failing acceptance tests and an ATDD checklist before implementation, then verifies the intended missing behavior. Expand mode writes tests for implemented code, runs them, heals test defects for up to three rounds by default, and reports product defects. Recommend red mode after a story is created and expand mode once code exists.
-- `bmad-tea-evaluate`: builds and runs a scored, evidence-backed evaluation of an agent, skill, workflow or tool-use system. Recommend it after automation when the target's behavior needs proof. Afterwards offer `bmad-tea-framework` with CI scope to enforce it.
+- `bmad-tea-evaluate`: builds and runs a scored, evidence-backed evaluation of an agent, skill, workflow or tool-use system. Recommend it after automation when the target's behavior needs proof. Afterwards offer `bmad-tea-framework` with CI scope to enforce it. On explicit request, Evaluate also analyzes saved native Test Design consistency offline or prepares a bounded fresh/configuration proposal. “Is it repeatable?” first clarifies saved records versus new runs. Native live experiments remain blocked by telemetry and enforceable-budget gaps; ordinary evaluation gains no extra experiment work.
 - `bmad-tea-test-review`: audits test quality with a 0-100 score and a review report. Recommend it after tests are written. Afterwards offer `bmad-tea-trace`.
 - `bmad-tea-nfr`: audits the evidence for non-functional requirements and writes an NFR report. Recommend it after automation, before a release.
 - `bmad-tea-trace`: maps requirements to tests in a traceability matrix and makes the PASS, CONCERNS, FAIL or WAIVED gate decision. Recommend it after test review, for the release gate.