bmad-method-test-architecture-enterprise 2.0.1 → 2.0.2-next.0

package/skills/bmad-testarch-trace/checklist.md

@@ -254,6 +254,8 @@ Knowledge fragments referenced:
 
 ## PHASE 2: QUALITY GATE DECISION
 
+The automated gate applies Step 5's coverage thresholds, oracle-confidence overlay, and live-evidence overlay. Test execution reports, NFR audits, code coverage, and burn-in results supply supporting context when available. Record their findings and missing evidence; these assessments have their own quality decisions. Report filed waivers separately and preserve the automated Trace decision.
+
 **Note**: Phase 2 always emits `{e2e_trace_summary_output}` (`trace/e2e-trace-summary-{run_key}.json`); gate decision fields are populated only when `allow_gate: true` and `collection_status` resolves to `COLLECTED`.
 
 ---
@@ -262,7 +264,7 @@ Knowledge fragments referenced:
 
 ### Evidence Gathering
 
-- [ ] Test execution results obtained (CI/CD pipeline, test framework reports)
+- [ ] Available test execution results read and cited (CI/CD pipeline, test framework reports)
 - [ ] Story/epic/release file identified and read
 - [ ] Test design document discovered in `{test_artifacts}/test-design/` (legacy: the root of `{test_artifacts}`) or explicitly provided (if available)
 - [ ] Traceability matrix discovered or explicitly provided (available from Phase 1)
@@ -274,16 +276,15 @@ Knowledge fragments referenced:
 ### Evidence Validation
 
 - [ ] Evidence freshness validated (warn if >7 days old, recommend re-running workflows)
-- [ ] All required assessments available or user acknowledged gaps
-- [ ] Test results are complete (not partial or interrupted runs)
-- [ ] Test results match current codebase (not from outdated branch)
+- [ ] Phase 1 coverage matrix available; missing supporting assessments recorded
+- [ ] Available test execution reports are complete and match the current codebase
 
 ### Knowledge Base Loading
 
 - [ ] `risk-governance.md` loaded successfully
 - [ ] `probability-impact.md` loaded successfully
 - [ ] `test-quality.md` loaded successfully
-- [ ] `test-priorities.md` loaded successfully
+- [ ] `test-priorities-matrix.md` loaded successfully
 - [ ] `ci-burn-in.md` loaded (if burn-in results available)
 
 ---
@@ -300,7 +301,7 @@ Knowledge fragments referenced:
 
 ### Step 2: Evidence Parsing
 
-**Test Results:**
+**Test Results (when execution reports are available):**
 
 - [ ] Total test count extracted
 - [ ] Passed test count extracted
@@ -337,31 +338,28 @@ Knowledge fragments referenced:
 
 **P0 Criteria Evaluation:**
 
-- [ ] P0 test pass rate evaluated (must be 100%)
 - [ ] P0 oracle-item coverage evaluated (must be 100%)
-- [ ] Security issues count evaluated (must be 0)
-- [ ] Critical NFR failures evaluated (must be 0)
-- [ ] Flaky tests evaluated (must be 0 if burn-in enabled)
+- [ ] Available execution, security, NFR, and stability findings recorded as supporting evidence
 - [ ] P0 decision recorded: PASS or FAIL
 
 **P1 Criteria Evaluation:**
 
-- [ ] P1 test pass rate evaluated (threshold: min_p1_pass_rate)
 - [ ] P1 oracle-item coverage evaluated (PASS >=90%, CONCERNS 80-89%, FAIL <80%)
-- [ ] Overall test pass rate evaluated (threshold: min_overall_pass_rate)
 - [ ] Overall oracle coverage evaluated (threshold: >=80%)
 - [ ] Code coverage considered if available (informational unless explicitly required by policy)
-- [ ] P1 decision recorded: PASS or CONCERNS
+- [ ] P1 decision recorded: PASS, CONCERNS, or FAIL
 
 **P2/P3 Criteria Evaluation:**
 
-- [ ] P2 failures tracked (informational, don't block if allow_p2_failures: true)
-- [ ] P3 failures tracked (informational, don't block if allow_p3_failures: true)
+- [ ] P2/P3 coverage included in the overall coverage threshold
+- [ ] Available P2/P3 execution failures recorded as supporting evidence
 - [ ] Residual risks documented
 
 **Final Decision:**
 
-- [ ] Decision determined: PASS / CONCERNS / FAIL / WAIVED
+- [ ] Eligible automated decision determined: PASS / CONCERNS / FAIL
+- [ ] Oracle-confidence and live-evidence overlays applied in Step 5's order
+- [ ] Ineligible runs omit gate signals and record why the gate was skipped
 - [ ] Decision rationale documented
 - [ ] Decision is deterministic (follows rules, not arbitrary)
 
@@ -370,14 +368,14 @@ Knowledge fragments referenced:
 **Gate Decision Document Created:**
 
 - [ ] Story/epic/release info section complete (ID, title, description, links)
-- [ ] Decision clearly stated (PASS / CONCERNS / FAIL / WAIVED)
+- [ ] Automated decision clearly stated (PASS / CONCERNS / FAIL, or gate skipped)
 - [ ] Decision date recorded
 - [ ] Evaluator recorded (user or agent name)
 
 **Evidence Summary Documented:**
 
-- [ ] Test results summary complete (total, passed, failed, pass rates)
-- [ ] Coverage summary complete (P0/P1 criteria, code coverage)
+- [ ] Available test execution results summarized; missing reports recorded
+- [ ] Coverage summary complete (P0/P1 criteria, code coverage when available)
 - [ ] NFR validation summary complete (security, performance, reliability, maintainability)
 - [ ] Flakiness summary complete (burn-in iterations, flaky test count)
 
@@ -417,12 +415,11 @@ Knowledge fragments referenced:
 
 ### Step 5: Status Updates and Notifications
 
-**Gate YAML Created:**
+**Gate JSON Created When Eligible:**
 
-- [ ] Gate YAML snippet generated with decision and criteria
-- [ ] Evidence references included in YAML
-- [ ] Next steps included in YAML
-- [ ] YAML file saved to output folder
+- [ ] Gate JSON generated with decision and criteria
+- [ ] Evidence references and rationale included in JSON
+- [ ] JSON file saved to `{gate_decision_output}`
 
 **Stakeholder Notification Generated:**
 
@@ -454,7 +451,7 @@ Knowledge fragments referenced:
 **Accuracy:**
 
 - [ ] Decision matches applied criteria rules
-- [ ] Test results match CI/CD pipeline output
+- [ ] Available test execution results match cited CI/CD pipeline output
 - [ ] Coverage percentages match reports
 - [ ] NFR status matches assessment document
 - [ ] No contradictions or inconsistencies
@@ -466,12 +463,12 @@ Knowledge fragments referenced:
 - [ ] Stakeholders can understand next steps
 - [ ] Recommendations are actionable
 
-### Gate YAML
+### Gate JSON
 
 **Format:**
 
-- [ ] YAML is valid (no syntax errors)
-- [ ] All required fields present (target, decision, date, evaluator, criteria, evidence)
+- [ ] JSON is valid (no syntax errors)
+- [ ] Schema 0.1.0 fields match Step 5's slim gate contract
 - [ ] Field values are correct data types (numbers, strings, dates)
 
 **Content:**
@@ -487,14 +484,14 @@ Knowledge fragments referenced:
 ### Decision Integrity
 
 - [ ] Decision is deterministic (follows rules, not arbitrary)
-- [ ] P0 failures result in FAIL decision (unless waived)
-- [ ] Security issues result in FAIL decision (unless waived - but should never be waived)
-- [ ] Waivers have business justification and approver (if WAIVED)
+- [ ] P0 coverage below 100% results in FAIL
+- [ ] Fresh live failures cap a passing decision at CONCERNS as Step 5 defines
+- [ ] Filed waivers are validated and reported separately from the derived decision
 - [ ] Residual risks are documented (if CONCERNS or WAIVED)
 
 ### Evidence-Based
 
-- [ ] Decision is based on actual test results (not guesses)
+- [ ] Decision follows the coverage matrix and available test execution results
 - [ ] All claims are supported by evidence
 - [ ] No assumptions without documentation
 - [ ] Evidence sources are cited (CI run IDs, report URLs)
@@ -519,8 +516,8 @@ Knowledge fragments referenced:
 
 ### CI/CD Pipeline
 
-- [ ] Gate YAML is CI/CD-compatible
-- [ ] YAML can be parsed by pipeline automation
+- [ ] Gate JSON is CI/CD-compatible
+- [ ] JSON can be parsed by pipeline automation
 - [ ] Decision can be used to block/allow deployments
 - [ ] Evidence references are accessible to pipeline
 
@@ -546,7 +543,7 @@ Knowledge fragments referenced:
 ### Traceability
 
 - [ ] Gate decision traceable to story/epic/release
-- [ ] Evidence traceable to specific test runs
+- [ ] Evidence traceable to cited tests and to specific runs when execution reports exist
 - [ ] Assessments traceable to workflows that created them
 - [ ] Waiver traceable to approver (if applicable)
 
@@ -563,8 +560,8 @@ Knowledge fragments referenced:
 
 ### Missing Evidence
 
-- [ ] If no test design doc exists in `{test_artifacts}/test-design/` or the legacy root, decision still possible with test results + trace
-- [ ] If `trace/traceability-matrix-{run_key}.md` missing, decision still possible with test results (but Phase 1 should provide it)
+- [ ] If no test design doc exists in `{test_artifacts}/test-design/` or the legacy root, decision still possible from the Phase 1 matrix
+- [ ] If no test execution report exists, decision follows the Phase 1 matrix and records the missing runtime evidence
 - [ ] If no NFR assessment exists in `{test_artifacts}/nfr/` or the legacy root, NFR validation marked as NOT ASSESSED
 - [ ] If code coverage missing, coverage criterion marked as NOT ASSESSED
 - [ ] User acknowledged gaps in evidence or provided alternative proof
@@ -578,7 +575,7 @@ Knowledge fragments referenced:
 
 ### Conflicting Evidence
 
-- [ ] Conflicts between test results and assessments resolved
+- [ ] Conflicts between available test results and assessments resolved
 - [ ] Most recent/authoritative source identified
 - [ ] Conflict resolution documented in decision rationale
 - [ ] User consulted if conflict cannot be resolved

package/skills/bmad-testarch-trace/steps-c/step-01-load-context.md

@@ -82,6 +82,10 @@ Resolve the oracle in this order:
      - `P2`: secondary workflows and edge scenarios
      - `P3`: low-risk polish or optional flows
 
+Persist `oracleLedger` in this step's progress YAML frontmatter as an array of `{id, requirement, priority, source}` records: one row per item with its stable ID, requirement text, priority, and source reference. An explicit priority in the selected oracle is authoritative for that item's coverage statistics. Infer a priority with `test-priorities-matrix.md` only when the oracle leaves it unspecified, and record that inference. A mapped test's own priority describes the test and never changes the oracle item's priority. Carry this ledger through mapping and gap analysis, including resumed runs.
+
+For local source files, read numbered lines before recording each ledger source reference. When the source declares an item's ID and priority, cite that line. For an inferred item, cite numbered source lines that support its requirement; the generated ID and priority stay in the ledger. Check each source line independently because headings and criteria may span different numbers of lines.
+
 Record the resolved oracle metadata in step output/frontmatter using consistent keys:
 
 - `coverageBasis` (`acceptance_criteria` | `synthetic_requirements` | `openapi_endpoints` | `user_journeys`) — the type of oracle selected for coverage tracing
@@ -218,6 +222,7 @@ oracleConfidence: '{resolved oracle_confidence}'
 oracleResolutionMode: '{resolved oracle_resolution_mode}'
 oracleSources: ['{resolved oracle source 1}', '{resolved oracle source 2}']
 externalPointerStatus: '{resolved external_pointer_status}'
+oracleLedger: [{ id: '{oracle item id}', requirement: '{requirement text}', priority: '{P0-P3}', source: '{source reference}' }]
 ---
 ```
 

package/skills/bmad-testarch-trace/steps-c/step-02-discover-tests.md

@@ -234,6 +234,7 @@ Capture explicit coverage signals so Phase 1 can detect common blind spots:
 - API endpoint coverage
   - Inventory endpoints referenced by requirements/specs and endpoints exercised by API tests
   - Mark endpoints with no direct tests
+  - Count an endpoint as directly tested when an API test calls its route and asserts a response. A test can exercise the endpoint while leaving a specific requirement unproved. Record missing permission-denied assertions under authentication/authorization coverage.
 - Authentication/authorization coverage
   - Detect tests for login/session/token flows and permission-denied paths
   - Mark auth/authz requirements with missing negative-path tests

package/skills/bmad-testarch-trace/steps-c/step-03-map-criteria.md

@@ -39,6 +39,7 @@ Create the traceability matrix linking the resolved oracle items to tests.
 
 For each resolved oracle item (formal requirement, endpoint/spec item, or synthetic journey):
 
+- Copy its ID, requirement text, and priority from Step 1's persisted oracle ledger. Preserve explicit source priorities through every matrix heading and statistics bucket. Keep each mapped test's priority in the test record as a separate field.
 - Map to matching tests
 - Mark coverage status: FULL / PARTIAL / NONE / UNIT-ONLY / INTEGRATION-ONLY. `checklist.md`'s "Coverage Classification" section is the definition; **read it before classifying anything**, and apply the rule it turns on:
   - Classification is decided by what the evidence **establishes** about the criterion. The number of levels the evidence spans does not set the status.
@@ -46,6 +47,10 @@ For each resolved oracle item (formal requirement, endpoint/spec item, or synthe
   - **UNIT-ONLY** and **INTEGRATION-ONLY** are for the case where a _missing_ level is what leaves the criterion unestablished: unit tests only, against a criterion stating an HTTP status or a rendered state; or API/component tests only, against a criterion stating branch-level logic that needs unit proof. "The only evidence is API-level" is not by itself INTEGRATION-ONLY.
 - Cite every mapped test as a backticked `` `path:line` `` pair, the form `trace-template.md` and `resources/traceability-matrix.example.md` both use. The backticks are the delimiter, so a path holding a space survives whole. An undelimited pair written into prose has no boundary but the file extension, and a path with a space in it is then read only from its last space-free segment onward.
 - Record test level and priority
+- For every accepted static test, cite its declaration once and each assertion that establishes a fact named by the criterion once within that criterion's evidence block. Cite both an asserted state and an asserted property that ties it to the stated condition, such as `expired` state and the token's expiry timestamp.
+- A status assertion on a prerequisite request is setup evidence. A 200 response before revocation does not establish that a later request is rejected. Cite a response status when the criterion requires it or the status itself establishes the outcome, such as 403 for denied access. When a later state or value assertion proves the outcome, omit an earlier 2xx response assertion on the action that produced it.
+- For a criterion that asks for a ready job and a signed link, cite the ready-state and signed-link assertions. An earlier 202 response only shows that creation was accepted. Apply the same rule to other intermediate 2xx responses.
+- Use the exact assertion line; for a multiline assertion, use its opening line. Use one project-relative path spelling throughout, including rejected evidence. Strip the project root directory from paths inside that project. Do not cite setup or action lines as separate anchors. Explain their role beside the assertion anchors. Before Step 4, remove duplicate `path:line` pairs from each criterion block, including pairs repeated in prose.
 - Preserve each mapped test's stable identity fields (`id`, `title`, `file`, `line`, `level`, status flags) so Phase 1 can deduplicate unique tests before JSON export
 - Record heuristic signals:
   - Endpoint coverage present/missing (for API-impacting items)
@@ -64,6 +69,8 @@ That is the rule for this workflow, and it fixes what every count derived from `
 
 Record every such test in `rejectedEvidence` against the criterion it claims, with the reason its assertions fall short. Carry the list forward for Step 4 and persist it into the progress document so a resumed Step 4 can read it. A reader needs to see that the test was read and turned down: a test that claims a criterion and then vanishes from the report is indistinguishable from a test nobody found.
 
+Use the test's explicit ID when its source declares one. Otherwise set `test_id` to its project-relative `file:line` declaration anchor. Do not assign a new sequence number to a rejected test.
+
 ```javascript
 // One entry per test whose name claims a criterion its assertions do not establish.
 // Shape only; the entries come from reading the tests against the criterion text.

package/skills/bmad-testarch-trace/steps-c/step-04-analyze-gaps.md

@@ -116,6 +116,10 @@ Resolution precedence:
 2. `tea_execution_mode` from config
 3. Runtime capability fallback (when probing enabled)
 
+### 0b. Reconcile the Oracle Ledger
+
+Before classifying gaps, compare every matrix item's ID and priority with Step 1's persisted oracle ledger. Require exactly one matrix item per oracle item and unchanged priorities. Correct any drift from the ledger before using the matrix in Sections 1 and 3. Repeat this check when resuming a saved mapping.
+
 ### 1. Gap Analysis
 
 **Identify uncovered requirements:**
@@ -147,7 +151,7 @@ const lowGaps = uncoveredRequirements.filter((req) => req.priority === 'P3');
 
 ### 2. Coverage Heuristics Checks
 
-Use the heuristics inventory from Step 2 and mapped criteria from Step 3 to flag common coverage blind spots:
+Use the heuristics inventory from Step 2 and mapped criteria from Step 3 to flag common coverage blind spots. Carry Step 2's endpoint inventory through unchanged: endpoint reachability comes from API calls and response assertions, while missing permission-denied assertions appear in the auth gap list.
 
 ```javascript
 const endpointCoverageGaps = coverageHeuristics?.endpoints_without_tests || [];
@@ -286,6 +290,20 @@ const liveEvidence = {
   stale: staleCount,
   unverifiable: unverifiableCount,
   failed: countDisposition('fail'),
+  fresh_failed: liveRecordsForRollup.filter((record) => {
+    if (record.disposition !== 'fail') return false;
+    const recorded = String(record.recorded_source_sha || '')
+      .trim()
+      .toLowerCase();
+    const current = String(currentSourceSha || '')
+      .trim()
+      .toLowerCase();
+    return (
+      /^[0-9a-f]{7,64}$/.test(recorded) &&
+      /^[0-9a-f]{7,64}$/.test(current) &&
+      (recorded.startsWith(current) || current.startsWith(recorded))
+    );
+  }).length,
   contradicted: countDisposition('contradicted'),
   blocked: countDisposition('blocked'),
   skipped: countDisposition('skipped'),
@@ -690,7 +708,28 @@ const coverageMatrix = {
 
 **Write to temp file for Phase 2:**
 
+Recount `FULL` rows before saving. The overall count must equal the sum of the four priority counts and the number of `FULL` requirement rows. If any count differs, correct the statistics from the mapped rows and repeat this check. `PARTIAL`, `UNIT-ONLY`, and `INTEGRATION-ONLY` do not count as fully covered.
+
 ```javascript
+const rows = coverageMatrix.requirements;
+const statistics = coverageMatrix.coverage_statistics;
+const priorities = ['P0', 'P1', 'P2', 'P3'];
+const fullRows = rows.filter((row) => row.coverage === 'FULL');
+const countedByPriority = priorities.reduce((count, priority) => count + statistics.priority_breakdown[priority].covered, 0);
+if (
+  statistics.total_requirements !== rows.length ||
+  statistics.fully_covered !== fullRows.length ||
+  statistics.fully_covered !== countedByPriority ||
+  statistics.overall_coverage_percentage !== safePct(fullRows.length, rows.length) ||
+  priorities.some(
+    (priority) =>
+      statistics.priority_breakdown[priority].total !== rows.filter((row) => row.priority === priority).length ||
+      statistics.priority_breakdown[priority].covered !== fullRows.filter((row) => row.priority === priority).length,
+  )
+) {
+  throw new Error('Coverage totals disagree with mapped requirement rows; correct Phase 1 statistics before saving');
+}
+
 const outputPath = '{tempOutputFile}';
 fs.writeFileSync(outputPath, JSON.stringify(coverageMatrix, null, 2), 'utf8');
 

package/skills/bmad-testarch-trace/steps-c/step-05-gate-decision.md

@@ -92,6 +92,21 @@ if (
   );
 }
 const priorityBreakdown = stats.priority_breakdown;
+// Check Phase 1 counts again before they become the published summary and gate inputs.
+// Repair the Phase 1 matrix from its requirement rows and rerun this check on mismatch.
+const requirementRows = coverageMatrix.requirements || [];
+const fullRequirementRows = requirementRows.filter((row) => row.coverage === 'FULL');
+const priorityNames = ['P0', 'P1', 'P2', 'P3'];
+if (
+  stats.total_requirements !== requirementRows.length ||
+  stats.fully_covered !== fullRequirementRows.length ||
+  priorityNames.reduce((sum, priority) => sum + priorityBreakdown[priority].covered, 0) !== fullRequirementRows.length ||
+  priorityNames.some(
+    (priority) => priorityBreakdown[priority].covered !== fullRequirementRows.filter((row) => row.priority === priority).length,
+  )
+) {
+  throw new Error('Phase 1 coverage totals disagree with mapped requirement rows; correct the matrix before gate evaluation');
+}
 const p0Coverage = priorityBreakdown.P0.percentage;
 const p1Coverage = priorityBreakdown.P1.percentage;
 const hasP1Requirements = (priorityBreakdown.P1.total || 0) > 0;
@@ -328,6 +343,12 @@ if (!gateEligible) {
   // A live result is a one-time observation of one commit with no artifact anyone can re-run, so a
   // requirement resting only on it is capped at CONCERNS. This overlay only ever lowers PASS or
   // annotates an existing CONCERNS; it can never lift a FAIL.
+  const freshLiveFailures = liveEvidence.fresh_failed ?? (liveEvidence.freshness === 'fresh' ? liveEvidence.failed : 0);
+  if (freshLiveFailures > 0 && gateDecision === 'PASS') {
+    gateDecision = 'CONCERNS';
+    rationale = `${rationale} ${freshLiveFailures} fresh live verification failure(s) require investigation.`;
+  }
+
   if (liveOnlyCoveredRequirements > 0 && ['PASS', 'CONCERNS'].includes(gateDecision)) {
     gateDecision = 'CONCERNS';
     // Appended rather than replaced so the coverage numbers that produced the base decision survive.
@@ -741,7 +762,7 @@ fs.writeFileSync('{e2e_trace_summary_output}', JSON.stringify(e2eTraceSummary, n
 console.log(`✅ e2e trace summary written to {e2e_trace_summary_output}`);
 ```
 
-**Optional: emit `gate-decision-{run_key}.json`** to `{gate_decision_output}` for pipelines that only need the gate signal without the full summary:
+**Emit `gate-decision-{run_key}.json` whenever gate-eligible** to `{gate_decision_output}` for pipelines that consume the gate signal:
 
 ```javascript
 // Construct and write only when gate evaluation was performed and produced a meaningful decision.

package/skills/bmad-testarch-trace/trace-template.md

@@ -15,6 +15,7 @@ oracleConfidence: ''
 oracleResolutionMode: ''
 oracleSources: []
 externalPointerStatus: ''
+oracleLedger: []
 ---
 
 # Traceability Matrix & Gate Decision - {TRACE_TARGET_LABEL}

package/skills/bmad-testarch-trace/workflow.yaml

@@ -37,7 +37,7 @@ variables:
 # writes another scope's files. Inputs stay at the root of {test_artifacts}.
 default_output_file: "{test_artifacts}/trace/traceability-matrix-{run_key}.md"
 e2e_trace_summary_output: "{test_artifacts}/trace/e2e-trace-summary-{run_key}.json" # Machine-readable summary consumed by CI/CD and reporting pipelines
-gate_decision_output: "{test_artifacts}/trace/gate-decision-{run_key}.json" # Optional downstream gate signal for CI/CD enforcement
+gate_decision_output: "{test_artifacts}/trace/gate-decision-{run_key}.json" # Required downstream gate signal when gate-eligible
 
 # e2e-trace-summary-{run_key}.json schema (emitted by step-05 to {e2e_trace_summary_output} at workflow completion)
 # schema_version: "0.3.0"   (0.2.0 added the live_evidence block and the by_level.live bucket; 0.3.0 added the waivers block)
@@ -45,7 +45,7 @@ gate_decision_output: "{test_artifacts}/trace/gate-decision-{run_key}.json" # Op
 # repo / collection_mode / collection_status / inventory_basis / gate_basis / source_sha
 # target: { type, id, label } / decision_mode / evaluator / confidence
 # oracle: { resolution_mode, confidence, sources[], external_pointer_status, synthetic }
-# gate_status: PASS | CONCERNS | FAIL | WAIVED   (only when allow_gate is true and collection_status is COLLECTED)
+# gate_status: PASS | CONCERNS | FAIL   (only when allow_gate is true and collection_status is COLLECTED)
 # coverage: { inventory{covered,total,pct}, priority_breakdown{P0..P3}, by_level{e2e,api,component,unit,live,other} }
 # tests: { files, cases, skipped_cases, fixme_cases, pending_cases }
 # risk_summary: { critical_open, high_open, medium_open, low_open }
@@ -87,7 +87,7 @@ gate_decision_output: "{test_artifacts}/trace/gate-decision-{run_key}.json" # Op
 # Required tools
 required_tools:
   - read_file # Read story, test files, BMad artifacts
-  - write_file # Create traceability matrix, gate YAML
+  - write_file # Create traceability matrix, summary JSON, gate JSON
   - list_files # Discover test files
   - search_repo # Find tests by test ID, describe blocks
   - glob # Find test files matching patterns

package/skills/bmod-tea/bmod.toml

@@ -2,7 +2,7 @@
 
 [bmod]
 code = "tea"
-version = "2.0.1"
+version = "2.0.2-next.0"
 update_source = "github:bmad-code-org/bmad-method-test-architecture-enterprise/skills"
 skills = [
   "bmad-tea",