bmad-method-test-architecture-enterprise 3.0.0 → 3.0.2

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (9) hide show
  1. package/.claude-plugin/marketplace.json +1 -1
  2. package/package.json +4 -5
  3. package/skills/bmad-tea-test-design/checklist.md +1 -1
  4. package/skills/bmad-tea-test-design/resources/test-design-epic-3.example.md +31 -33
  5. package/skills/bmad-tea-test-design/steps-c/step-03-risk-and-testability.md +8 -1
  6. package/skills/bmad-tea-test-design/steps-c/step-04-coverage-plan.md +2 -1
  7. package/skills/bmad-tea-test-design/test-design-qa-template.md +14 -14
  8. package/skills/bmad-tea-test-design/test-design-template.md +1 -1
  9. package/skills/bmod-tea/bmod.toml +1 -1
package/.claude-plugin/marketplace.json CHANGED
@@ -31,7 +31,7 @@
31
31
  "name": "bmad-method-test-architecture-enterprise",
32
32
  "source": "./",
33
33
  "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.",
34
- "version": "3.0.0",
34
+ "version": "3.0.2",
35
35
  "author": {
36
36
  "name": "Murat K Ozcan (TEA Creator) & Brian (BMad) Madison"
37
37
  },
package/package.json CHANGED
@@ -1,7 +1,7 @@
1
1
  {
2
2
  "$schema": "https://json.schemastore.org/package.json",
3
3
  "name": "bmad-method-test-architecture-enterprise",
4
- "version": "3.0.0",
4
+ "version": "3.0.2",
5
5
  "description": "Master Test Architect for quality strategy, test automation, and release gates",
6
6
  "keywords": [
7
7
  "bmad",
@@ -91,10 +91,9 @@
91
91
  "prepare": "command -v husky >/dev/null 2>&1 && husky || exit 0",
92
92
  "prepublishOnly": "node tools/guard-publish.js",
93
93
  "regenerate:doc-claim-hash": "node tools/regenerate-doc-claim-hash.mjs",
94
- "release:major": "gh workflow run publish.yaml -f channel=latest -f bump=major",
95
- "release:minor": "gh workflow run publish.yaml -f channel=latest -f bump=minor",
96
- "release:next": "gh workflow run publish.yaml -f channel=next",
97
- "release:patch": "gh workflow run publish.yaml -f channel=latest -f bump=patch",
94
+ "release:major": "gh workflow run publish.yaml -f bump=major",
95
+ "release:minor": "gh workflow run publish.yaml -f bump=minor",
96
+ "release:patch": "gh workflow run publish.yaml -f bump=patch",
98
97
  "test": "npm run test:conflict-markers && npm run test:schemas && npm run test:install && npm run test:evaluate-guidance && npm run test:evaluate-authoring && npm run test:evaluate-gap-loop && npm run test:evaluate-dogfood && npm run test:evaluate-check && npm run test:evaluate-compare && npm run test:evaluate-before-state && npm run test:evaluate-ci-gates && npm run test:evaluate-ci-tiers && npm run test:evaluate-ci-repositories:tagged-release-pr && npm run test:evaluate-ci-repositories:tagged-release-merge && npm run test:evaluate-ci-repositories:tagged-release-release && npm run test:evaluate-ci-repositories:nightly-deploy-pr && npm run test:evaluate-ci-repositories:nightly-deploy-merge && npm run test:evaluate-ci-repositories:nightly-deploy-scheduled && npm run test:evaluate-ci-repositories:nightly-deploy-release && npm run test:evaluate-ci-render && npm run test:evaluate-pr-mcp && npm run test:evaluate-pr-api && npm run test:evaluate-pr-suite && npm run test:evaluate-pr-workflow && npm run test:evaluate-pr-tool-use && npm run test:evaluate-pr-promptfoo && npm run test:evaluate-pr-ai-feature && npm run test:evaluate-pr-test-review && npm run test:evaluate-pr-gap-loop && npm run test:evaluate-pr-learn && npm run test:evaluate-pr-tutorial && npm run test:evaluate-partitions && npm run test:evaluate-partition-plans-views-and-check && npm run test:evaluate-partition-plans-preflight-and-run && npm run test:evaluate-partition-plans-score && npm run test:evaluate-partition-plans-attempts-seal-and-mappings && npm run test:evaluate-partition-plans-attempts-records && npm run test:evaluate-partition-plans-attempts-gameability && npm run test:evaluate-interpret && npm run test:evaluate-calibration && npm run test:evaluate-boundaries && npm run test:evaluate-preflight && npm run test:evaluate-isolation-conformance && npm run test:evaluate-mutation:qualification-basics && npm run test:evaluate-mutation:qualification-guards && npm run test:evaluate-mutation:recovery && npm run test:evaluate-mutation:journals && npm run test:evaluate-run && npm run test:evaluate-progress && npm run test:evaluate-aggregate && npm run test:evaluate-confinement && npm run test:evaluate-confinement-audit && npm run test:evaluate-confinement-history && npm run test:evaluate-confinement-git-state && npm run test:evaluate-confinement-network && npm run test:evaluate-held-inputs && npm run test:evaluate-arms-historical && npm run test:evaluate-arms-deployments && npm run test:evaluate-evaluators && npm run test:evaluate-evaluators-agent-version && npm run test:evaluate-agents && npm run test:evaluate-agents-importers && npm run test:evaluate-agents-sealed-brief && npm run test:evaluate-held-attempts && npm run test:evaluate-private && npm run test:evaluate-records && npm run test:evaluate-mcp && npm run test:evaluate-api && npm run test:evaluate-workflow && npm run test:evaluate-tool-use && npm run test:evaluate-promptfoo && npm run test:evaluate-learned-framework && npm run test:docs-tutorial && npm run test:knowledge && npm run test:criteria-fragments && npm run test:doc-count-sources && npm run test:planning-doc-sources && npm run test:doc-counts && npm run test:doc-claim-sources && npm run test:doc-claims && npm run test:doc-invocation-entry && npm run test:doc-invocations && npm run test:doc-link-anchors && npm run test:docs-build-names && npm run test:docs-evaluate-sidebar && npm run test:docs-gap-reader && npm run test:enforce-hook && npm run test:framework-scaffold && npm run test:isolation-primitives && npm run test:atdd-isolation && npm run test:atdd-net-guard && npm run test:atdd-scoring && npm run test:atdd-workflow-guidance && npm run test:generation-healing && npm run test:framework-scaffold-install-isolation && npm run test:transcript-harness && npm run test:suite-manifest && npm run test:teach-me-testing-scoring && npm run test:teach-cli && npm run test:eval-data && npm run test:eval-atdd-data && npm run test:eval-ci-data && npm run test:eval-framework-scaffold-data && npm run test:eval-nfr-data && npm run test:nfr-validate-corpus && npm run test:nfr-evidence-guidance && npm run test:nfr-cli && npm run test:eval-test-design-data && npm run test:eval-trace-data && npm run test:eval-routing-data && npm run test:eval-routing-boundaries && npm run test:eval-routing-evidence && npm run test:eval-transcript-data && npm run test:eval-teach-me-testing-data && npm run test:eval-schemas && npm run test:eval-diagnostics && npm run test:eval-replay && npm run test:eval-quality-corpus && npm run test:schema-versions && npm run test:contract-sources && npm run test:contracts && npm run test:contract-oracles && npm run test:probe-sources && npm run test:test-design-qualification && npm run test:test-review-qualification && npm run test:trace-qualification && npm run test:nfr-qualification && npm run test:ci-qualification && npm run test:probe-corpus && npm run test:compare-dominance && npm run test:compare-eval-runs && npm run test:trial-set-scoring && npm run test:automate-cli && npm run test:automate-generation-evidence && npm run test:automate-eval-fixture && npm run test:eval-automate-data && npm run test:clock-port && npm run test:probe-conformance && npm run test:corpus-conformance && npm run test:file-system-conformance && npm run test:file-system-port && npm run test:probe-targets && npm run test:port-totality && npm run test:ci-coverage && npm run test:ci-coverage-filters && npm run test:install-actionlint && npm run test:workflows-lint && npm run test:install-linux-sandbox && npm run test:shards && npm run test:groups && npm run test:cli && npm run test:workflow-cli && npm run test:migrate-customizations && npm run test:framework-cli && npm run test:test-review-pr-scope && npm run test:test-review-report && npm run test:test-review-rubric && npm run test:bmad-output-gated && npm run test:release-metadata && npm run test:release-notes && npm run test:lockfile-age && npm run test:lockfile-age-cache && npm run test:licences && npm run test:supply-chain && npm run test:boundary && npm run test:direction && npm run test:lineage && npm run test:guard-publish && npm run test:layering-boundary-lineage && npm run test:changelog && npm run test:tea-workflow-descriptions && npm run test:docs-mermaid && npm run test:llms-headroom && npm run validate:schemas && npm run lint && npm run lint:md && npm run format:check",
99
98
  "test:atdd-isolation": "node test/test-atdd-isolation.js",
100
99
  "test:atdd-net-guard": "node test/test-atdd-net-guard.js",
package/skills/bmad-tea-test-design/checklist.md CHANGED
@@ -304,7 +304,7 @@
304
304
  - [ ] **Test Coverage Plan** with P0/P1/P2/P3 sections
305
305
  - [ ] Priority sections have ONLY "Criteria" (no execution context)
306
306
  - [ ] Note at top: "P0/P1/P2/P3 = priority, NOT execution timing"
307
- - [ ] Test tables with columns: Test ID | Requirement | Test Level | Risk Link | Notes
307
+ - [ ] Test tables with columns: Test IDs | Requirement | Test Level | Risk Link | Test Count | Notes; one risk-linked row per scored risk
308
308
  - [ ] **NFR Test Coverage Plan** section
309
309
  - [ ] Maps NFR category to requirement/threshold, planned validation, tool/level, evidence artifact, and priority
310
310
  - [ ] Lists missing thresholds or missing evidence sources
package/skills/bmad-tea-test-design/resources/test-design-epic-3.example.md CHANGED
@@ -29,10 +29,10 @@ lastSaved: '2026-08-17'
29
29
  **Coverage Summary:**
30
30
 
31
31
  - P0: 4 scenarios
32
- - P1: 6 scenarios
33
- - P2: 5 scenarios
32
+ - P1: 8 scenarios
33
+ - P2: 3 scenarios
34
34
  - P3: 2 scenarios
35
- - Total: 17 scenarios, estimated at 41 to 63 hours across 1.5 to 2.5 weeks
35
+ - Total: 17 scenarios, estimated at 42 to 64 hours across 1.5 to 2.5 weeks
36
36
 
37
37
  Risk score determines the required governance action. Test priority is assigned separately from business criticality, user impact, workaround availability, and execution value. For example, R-005 scores 3 while its audit-event scenario is P1 because missing actor and role history has compliance impact; the score does not hold it at P2 or P3 automatically.
38
38
 
@@ -110,16 +110,17 @@ This plan names future evidence. Final PASS, CONCERNS, and FAIL decisions belong
110
110
 
111
111
  P0, P1, P2, and P3 describe priority. Execution timing is defined separately below. Risk score is a supporting signal and never assigns priority by itself.
112
112
 
113
+ Each scored risk has one risk-linked row at the level where its failure first becomes observable. Rows with `-` cover no scored risk.
114
+
113
115
  ### P0: Critical
114
116
 
115
117
  **Criteria:** The scenario protects a core authorization or membership-integrity path, has no safe workaround, and a failure would block release.
116
118
 
117
- | Test ID | Requirement | Test Level | Risk Link | Notes |
118
- | --------- | ---------------------------------------------------------- | ---------- | ------------ | -------------------------------- |
119
- | 3-API-001 | Reject a role change for a member in another tenant | API | R-001 | Direct tenant-boundary proof |
120
- | 3-API-002 | Reject granting Owner through the role-change endpoint | API | R-001 | Immutable Owner policy |
121
- | 3-API-003 | Accepting the same invitation twice creates one membership | API | R-002 | Concurrent duplicate submissions |
122
- | 3-E2E-001 | Invited member accepts once and enters the correct tenant | E2E | R-002, R-003 | Core user journey |
119
+ | Test IDs | Requirement | Test Level | Risk Link | Test Count | Notes |
120
+ | -------------------- | ----------------------------------------------------------- | ---------- | --------- | ---------: | ----------------------------------------------------------------------- |
121
+ | 3-API-001, 3-API-002 | Reject a cross-tenant role change and reject granting Owner | API | R-001 | 2 | Tenant authorization crosses one service's HTTP contract |
122
+ | 3-API-003 | Accepting the same invitation twice creates one membership | API | R-002 | 1 | Idempotency crosses one service's HTTP contract; concurrent submissions |
123
+ | 3-E2E-001 | Invited member accepts once and enters the correct tenant | E2E | - | 1 | Core user journey |
123
124
 
124
125
  **Total P0:** 4 scenarios, about 14 to 20 hours
125
126
 
@@ -127,39 +128,36 @@ P0, P1, P2, and P3 describe priority. Execution timing is defined separately bel
127
128
 
128
129
  **Criteria:** Important common workflows, integration boundaries, and high-impact error handling with a workable recovery path.
129
130
 
130
- | Test ID | Requirement | Test Level | Risk Link | Notes |
131
- | ---------- | ------------------------------------------------------------ | ----------- | --------- | ------------------------------ |
132
- | 3-E2E-002 | Administrator invites a new Member and sees Pending status | E2E | R-004 | One browser happy path |
133
- | 3-API-004 | Reject an expired invitation token | API | R-003 | Boundary time fixed by fixture |
134
- | 3-API-005 | Reject a revoked invitation token | API | R-003 | No membership created |
135
- | 3-API-006 | Retry after provider timeout returns the original invitation | API | R-004 | Idempotency by invitation ID |
136
- | 3-INT-001 | Role update emits actor, tenant, old role, and new role | Integration | R-005 | Audit event contract |
137
- | 3-COMP-001 | Role selector hides Owner and disables the current Owner | Component | R-001 | User-level interaction API |
131
+ | Test IDs | Requirement | Test Level | Risk Link | Test Count | Notes |
132
+ | ------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | ----------- | --------- | ---------: | ----------------------------------------------------------------------------- |
133
+ | 3-API-004, 3-API-005, 3-API-007 | Reject expired and revoked tokens; a cancelled invitation cannot be used | API | R-003 | 3 | Token status is decided at one service's HTTP contract; no membership created |
134
+ | 3-API-006, 3-API-008 | Retry after provider timeout returns the original invitation; resend rotates the token and the old token becomes invalid | API | R-004 | 2 | Idempotency by invitation ID at one service's HTTP contract |
135
+ | 3-INT-001 | Role update emits actor, tenant, old role, and new role | Integration | R-005 | 1 | Audit event crosses one event boundary |
136
+ | 3-E2E-002 | Administrator invites a new Member and sees Pending status | E2E | - | 1 | One browser happy path |
137
+ | 3-COMP-001 | Role selector hides Owner and disables the current Owner | Component | - | 1 | User-level interaction API |
138
138
 
139
- **Total P1:** 6 scenarios, about 16 to 24 hours
139
+ **Total P1:** 8 scenarios, about 20 to 30 hours
140
140
 
141
141
  ### P2: Medium
142
142
 
143
143
  **Criteria:** Secondary workflows and bounded edge cases whose failure has a practical workaround.
144
144
 
145
- | Test ID | Requirement | Test Level | Risk Link | Notes |
146
- | ---------- | ---------------------------------------------------------- | ---------- | --------- | ---------------------------------- |
147
- | 3-API-007 | Cancel a pending invitation | API | R-003 | Subsequent acceptance rejected |
148
- | 3-API-008 | Resend reuses the logical invitation and rotates the token | API | R-004 | Old token becomes invalid |
149
- | 3-COMP-002 | Invalid email displays field-level guidance | Component | None | Atomic validation behavior |
150
- | 3-COMP-003 | Pending invitation table handles long names | Component | R-006 | Layout at supported small viewport |
151
- | 3-UNIT-001 | Invitation expiry comparison handles the exact boundary | Unit | R-003 | Fake clock, no wall-clock wait |
145
+ | Test IDs | Requirement | Test Level | Risk Link | Test Count | Notes |
146
+ | ---------- | ------------------------------------------------------- | ---------- | --------- | ---------: | ------------------------------------------------------ |
147
+ | 3-COMP-003 | Pending invitation table handles long names | Component | R-006 | 1 | One rendered table; layout at supported small viewport |
148
+ | 3-COMP-002 | Invalid email displays field-level guidance | Component | - | 1 | Atomic validation behavior |
149
+ | 3-UNIT-001 | Invitation expiry comparison handles the exact boundary | Unit | - | 1 | Fake clock, no wall-clock wait |
152
150
 
153
- **Total P2:** 5 scenarios, about 8 to 14 hours
151
+ **Total P2:** 3 scenarios, about 5 to 9 hours
154
152
 
155
153
  ### P3: Low
156
154
 
157
155
  **Criteria:** Exploratory checks and benchmarks that inform future optimization.
158
156
 
159
- | Test ID | Requirement | Test Level | Risk Link | Notes |
160
- | ---------- | --------------------------------------------- | ----------- | --------- | --------------------------------------- |
161
- | 3-EXP-001 | Keyboard-only review of the invitation dialog | Exploratory | None | Record accessibility observations |
162
- | 3-PERF-001 | Establish a provisional bulk-invite baseline | Performance | R-007 | Informational until the SLO is approved |
157
+ | Test IDs | Requirement | Test Level | Risk Link | Test Count | Notes |
158
+ | ---------- | --------------------------------------------- | ---------- | --------- | ---------: | ------------------------------------------------------------------------------- |
159
+ | 3-PERF-001 | Establish a provisional bulk-invite baseline | API | R-007 | 1 | k6 against one service's HTTP contract; informational until the SLO is approved |
160
+ | 3-EXP-001 | Keyboard-only review of the invitation dialog | E2E | - | 1 | Exploratory session; record accessibility observations |
163
161
 
164
162
  **Total P3:** 2 scenarios, about 3 to 5 hours
165
163
 
@@ -176,10 +174,10 @@ P0, P1, P2, and P3 describe priority. Execution timing is defined separately bel
176
174
  | Priority | Scenarios | Estimate | Complexity Drivers |
177
175
  | --------- | --------: | ------------------ | ------------------------------------------------ |
178
176
  | P0 | 4 | 14 to 20 hours | Two-tenant setup, concurrency, authorization |
179
- | P1 | 6 | 16 to 24 hours | Provider stub, audit event capture, browser path |
180
- | P2 | 5 | 8 to 14 hours | Boundary fixtures and component states |
177
+ | P1 | 8 | 20 to 30 hours | Provider stub, audit event capture, browser path |
178
+ | P2 | 3 | 5 to 9 hours | Boundary fixtures and component states |
181
179
  | P3 | 2 | 3 to 5 hours | Benchmark setup and exploratory recording |
182
- | **Total** | **17** | **41 to 63 hours** | **About 1.5 to 2.5 weeks** |
180
+ | **Total** | **17** | **42 to 64 hours** | **About 1.5 to 2.5 weeks** |
183
181
 
184
182
  ### Prerequisites
185
183
 
package/skills/bmad-tea-test-design/steps-c/step-03-risk-and-testability.md CHANGED
@@ -63,8 +63,15 @@ Using `risk-governance.md` and `probability-impact.md` (if loaded):
63
63
  - Ground every risk in an explicit statement from the supplied epic or a named artifact loaded for this run. Record the supporting statement in the risk description or mitigation notes so another reader can trace the row.
64
64
  - Keep the register bounded by the scope supported by the supplied epic or a named artifact loaded for this run. Do not add plausible risks merely because they are common in other systems. If a concern has no supporting statement, record it as an assumption or clarification outside the risk register.
65
65
  - Treat controls explicitly described as already satisfied as scope constraints. Verify them with regression assertions in the coverage plan. A hypothetical implementation violating a stated read-only, local-only, privacy, or rollout constraint needs evidence of a new exposure before it becomes a scored risk.
66
- - Consolidate conditions that share a failure mechanism, consequence, and mitigation into one risk. Keep individual trigger and boundary cases in the coverage plan. For example, a stale cached timestamp and a missed refresh event can be one display-freshness risk; absent-value and disabled-flag rendering can share one conditional-visibility risk when the same visibility guard controls both.
66
+ - Derive the register by this procedure so the same epic yields the same rows on every run:
67
+ 1. List the gap statements in the supplied sources. A gap statement says a control is absent, a behavior is known to be unsafe or destructive, a target is unmeasured or unmet, an exposure is unprotected, or a release cannot be reversed.
68
+ 2. Merge two statements only when they describe the same missing control. A target and a retry policy, or a missing control and a separate exposure, stay separate even inside one story.
69
+ 3. Register exactly one scored risk per merged gap statement. Acceptance criteria and stories that only restate intended behavior verify that behavior through coverage rows. They add no scored risk unless they also state a gap.
70
+ 4. When the supplied sources state no gap at all, register one residual risk for each story, owned by that story and scored from its most likely failure. Do not merge stories and do not split a story. When any gap statement exists, add no residual risks.
71
+ 5. Keep trigger and boundary cases of one risk in the coverage plan. A stale cached timestamp and a missed refresh event belong to the risk of the story that renders the value.
67
72
  - 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.
73
+ - 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.
74
+ - 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.
68
75
  - 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.
69
76
  - 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.
70
77
  - Classify by category: TECH / SEC / PERF / DATA / BUS / OPS
package/skills/bmad-tea-test-design/steps-c/step-04-coverage-plan.md CHANGED
@@ -47,7 +47,8 @@ For each requirement or risk-driven scenario:
47
47
  - Map NFR-derived risks to planned validation scenarios and evidence sources
48
48
  - Use the exact `Risk ID` assigned in the risk register in every `Risk Link` cell. A prose description alone is not a traceable mapping.
49
49
  - 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.
50
- - Give every material risk at least one coverage row whose `Test Level` is suitable for that risk under `test-levels-framework.md`. Explain the suitability in the row notes when the level is not obvious. Preserve the risk ID when rows are split across priorities or test levels.
50
+ - 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`.
51
+ - Place a risk's row under the one priority heading that matches its consequence. A risk never appears under two priority headings.
51
52
 
52
53
  **Priority rules:** decide each priority on business impact, user reach, and workaround
53
54
  availability. Risk score is supporting evidence and is not a required condition for any priority.
package/skills/bmad-tea-test-design/test-design-qa-template.md CHANGED
@@ -183,10 +183,10 @@ test('example test @p0', async ({ apiRequest }) => {
183
183
 
184
184
  **Criteria:** Critical business, security, data-integrity, or compliance impact with no safe workaround. Risk score is supporting evidence and is not a required condition.
185
185
 
186
- | Test ID | Requirement | Test Level | Risk Link | Notes |
187
- | ---------- | ------------- | ---------- | --------- | ------- |
188
- | **P0-001** | {Requirement} | {Level} | {R-ID} | {Notes} |
189
- | **P0-002** | {Requirement} | {Level} | {R-ID} | {Notes} |
186
+ | Test IDs | Requirement | Test Level | Risk Link | Test Count | Notes |
187
+ | ---------- | ------------- | ---------- | --------- | ---------: | ------- |
188
+ | **P0-001** | {Requirement} | {Level} | {R-ID} | {N} | {Notes} |
189
+ | **P0-002** | {Requirement} | {Level} | {R-ID} | {N} | {Notes} |
190
190
 
191
191
  **Total P0:** ~{N} tests
192
192
 
@@ -196,10 +196,10 @@ test('example test @p0', async ({ apiRequest }) => {
196
196
 
197
197
  **Criteria:** Core, frequent, or complex behavior with material user reach and a limited workaround. Risk score is supporting evidence and is not a required condition.
198
198
 
199
- | Test ID | Requirement | Test Level | Risk Link | Notes |
200
- | ---------- | ------------- | ---------- | --------- | ------- |
201
- | **P1-001** | {Requirement} | {Level} | {R-ID} | {Notes} |
202
- | **P1-002** | {Requirement} | {Level} | {R-ID} | {Notes} |
199
+ | Test IDs | Requirement | Test Level | Risk Link | Test Count | Notes |
200
+ | ---------- | ------------- | ---------- | --------- | ---------: | ------- |
201
+ | **P1-001** | {Requirement} | {Level} | {R-ID} | {N} | {Notes} |
202
+ | **P1-002** | {Requirement} | {Level} | {R-ID} | {N} | {Notes} |
203
203
 
204
204
  **Total P1:** ~{N} tests
205
205
 
@@ -209,9 +209,9 @@ test('example test @p0', async ({ apiRequest }) => {
209
209
 
210
210
  **Criteria:** Secondary behavior with narrower user reach and an acceptable workaround. Risk score is supporting evidence and is not a required condition.
211
211
 
212
- | Test ID | Requirement | Test Level | Risk Link | Notes |
213
- | ---------- | ------------- | ---------- | --------- | ------- |
214
- | **P2-001** | {Requirement} | {Level} | {R-ID} | {Notes} |
212
+ | Test IDs | Requirement | Test Level | Risk Link | Test Count | Notes |
213
+ | ---------- | ------------- | ---------- | --------- | ---------: | ------- |
214
+ | **P2-001** | {Requirement} | {Level} | {R-ID} | {N} | {Notes} |
215
215
 
216
216
  **Total P2:** ~{N} tests
217
217
 
@@ -221,9 +221,9 @@ test('example test @p0', async ({ apiRequest }) => {
221
221
 
222
222
  **Criteria:** Rare, cosmetic, or experimental behavior with minimal impact and an easy workaround. Risk score is supporting evidence and is not a required condition.
223
223
 
224
- | Test ID | Requirement | Test Level | Risk Link | Notes |
225
- | ---------- | ------------- | ---------- | --------- | ------- |
226
- | **P3-001** | {Requirement} | {Level} | {R-ID} | {Notes} |
224
+ | Test IDs | Requirement | Test Level | Risk Link | Test Count | Notes |
225
+ | ---------- | ------------- | ---------- | --------- | ---------: | ------- |
226
+ | **P3-001** | {Requirement} | {Level} | {R-ID} | {N} | {Notes} |
227
227
 
228
228
  **Total P3:** ~{N} tests
229
229
 
package/skills/bmad-tea-test-design/test-design-template.md CHANGED
@@ -131,7 +131,7 @@ workaround. Risk score is supporting evidence and is not a required condition.
131
131
  | {requirement} | E2E | R-001 | 3 | QA | {notes} |
132
132
  | {requirement} | API | R-002 | 5 | QA | {notes} |
133
133
 
134
- Use the exact `Risk ID` from the risk assessment in `Risk Link`. Select `Test Level` using `test-levels-framework.md`; explain the suitability in `Notes` when the level is not obvious. Every material risk must appear in at least one coverage row at a test level that can establish it.
134
+ Use the exact `Risk ID` from the risk assessment in `Risk Link`. Every scored risk has exactly one risk-linked row, at the one level where its failure first becomes observable: Unit with no boundary, Component for one rendered interface unit, Integration across one owned store, queue, file, or event boundary, API across one service's HTTP contract, E2E across two or more deployables, a user journey, or a deadline on real devices. State the mechanism, boundary, and level in `Notes`, list the scenarios there, and put their number in `Test Count`. Rows that cover no scored risk use `-`.
135
135
 
136
136
  **Total P0**: {p0_count} tests, {p0_hours} hours
137
137
 
package/skills/bmod-tea/bmod.toml CHANGED
@@ -2,7 +2,7 @@
2
2
 
3
3
  [bmod]
4
4
  code = "tea"
5
- version = "3.0.0"
5
+ version = "3.0.2"
6
6
  update_source = "github:bmad-code-org/bmad-method-test-architecture-enterprise/skills"
7
7
  skills = [
8
8
  "bmad-tea",