Running TEA for Enterprise Projects

Running TEA for Enterprise Projects

Use TEA on enterprise projects with compliance, security, audit, and regulatory requirements. This guide covers NFR planning, NFR Evidence Audit, audit trails, and evidence collection.

When to Use This

• Enterprise track projects (not Quick Flow or simple BMad Method)
• Compliance requirements (SOC 2, HIPAA, GDPR, etc.)
• Security-critical applications (finance, healthcare, government)
• Audit trail requirements
• Strict NFR thresholds (performance, security, reliability)

Prerequisites

• BMad installed with the Enterprise track selected
• Compliance requirements documented
• Stakeholders identified (who approves gates)

Every command below is a TEA skill. On Codex, swap the leading / for $. Full invocation rules: Invoking a TEA Skill.

Enterprise-Specific TEA Skills

NFR Evidence Audit (/bmad-tea-nfr)

Audit implementation evidence against your security, performance, and compliance thresholds.

When: Release Gate, or earlier only when implementation evidence already exists. Use test-design in Phase 3 to plan NFR thresholds and evidence.

What you give it:

Categories: Security, Performance, Reliability, Maintainability

Security thresholds:
- Zero critical vulnerabilities (project release policy)
- All endpoints require authentication
- Data encrypted at rest (approved encryption configuration)
- Audit logging on all data access

Evidence:
- Security scan: reports/nessus-scan.pdf
- Penetration test: reports/pentest-2026-01.pdf
- Compliance audit: reports/soc2-evidence.zip

Output: NFR evidence audit with PASS/CONCERNS/FAIL for each category.

Trace with Audit Evidence (/bmad-tea-trace)

Purpose: Requirements traceability with an audit trail. Auditors, certification bodies, and regulators all ask for requirements-to-test mapping in a form they can read.

When: Phase 2 (brownfield baseline), Phase 4 (refresh), Release Gate

What you give Phase 1:

Requirements: PRD.md (with compliance requirements)
Test location: tests/

Phase 1 produces trace/traceability-matrix-{run_key}.md under {test_artifacts}, with the requirement-to-test mapping, compliance requirement coverage, gap prioritization, and recommendations. The run_key names the scope, such as epic-4 or release-v1-2-0, so each audit period keeps its own matrix.

Phase 2 adds the gate decision to the same report: an evidence summary, the decision criteria, the rationale, and a sign-off section for approvers. When the collection is gate-eligible, it also writes the machine-readable decision to trace/gate-decision-{run_key}.json for CI.

Test Design with Compliance Focus (/bmad-tea-test-design)

Purpose: Risk assessment with compliance and security focus. Security architecture has to line up, compliance requirements have to be testable, and performance requirements are contractual.

When: Phase 3 (system-level), Phase 4 (epic-level)

What you give it:

Mode: System-level

Focus areas:
- Security architecture (authentication, authorization, encryption)
- Performance requirements (SLA: P99 <200ms)
- Compliance (HIPAA PHI handling, audit logging)

System-level mode produces two documents in test-design/: test-design-architecture.md (security gaps, compliance requirements, performance SLOs, audit logging validation) for the Architecture team, and test-design-qa.md (security testing strategy, compliance test mapping, performance testing plan) for QA.

Enterprise TEA Lifecycle

The BMad Method module provides research, prd, and architecture. The /bmad-tea-* commands are TEA skills.

Phase 1: Discovery (Optional but Recommended)

Run the BMM research workflow on industry compliance (SOC 2, HIPAA, GDPR), security standards (OWASP Top 10), and performance benchmarks (industry P99).

Phase 2: Planning (Required)

1. Define NFRs early. Run the BMM prd workflow and record the agreed thresholds with the evidence planned for each: security requirements (authentication, encryption), performance SLAs (response time, throughput), reliability targets (uptime, RTO, RPO), and compliance mandates (data retention, audit logs).
2. Baseline (brownfield only). Run /bmad-tea-trace Phase 1 to establish baseline coverage before new work.

Phase 3: Solutioning (Required)

1. Architecture with testability review. Run the BMM architecture workflow. System-level test design needs the finished architecture, so run /bmad-tea-test-design at system-level scope after it, focused on NFR thresholds and planned evidence, security architecture testability, performance testing strategy, and compliance requirement mapping.
2. Test infrastructure. Run /bmad-tea-framework. Tell it you need separate test environments (dev, staging, prod-mirror), secure test data handling for PHI and PII, and audit logging in tests. To set up CI in the same run, ask for the framework and CI together and give it the step 3 requirements; that run covers step 3, so skip it.
3. CI/CD with compliance. If step 2 set up the framework alone, run /bmad-tea-framework again and ask for CI. Tell it you need secrets management (Vault, AWS Secrets Manager), test isolation, artifact retention for the compliance audit trail, and access controls over who can run production tests.

Phase 4: Implementation (Required)

Per epic:

1. /bmad-tea-test-design at epic level, focused on compliance, security, and performance for this epic
2. /bmad-tea-automate in red mode (optional) to generate tests including security and compliance scenarios
3. A developer implements the story
4. /bmad-tea-automate to expand coverage, including compliance edge cases
5. /bmad-tea-test-review to audit quality (example policy: above 80 per epic, rising to above 85 at release)
6. /bmad-tea-trace Phase 1 to refresh coverage and verify compliance requirements are tested

Release Gate (Required)

1. Final NFR evidence audit. Run /bmad-tea-nfr across all categories that have evidence, using the latest performance tests and security scans.
2. Final quality audit. Run /bmad-tea-test-review over the full suite, answering tests/ for scope.
3. Gate decision. Run /bmad-tea-trace Phase 2 after Phase 1. Trace Phase 2 derives the coverage decision when allow_gate is true and the collection status is COLLECTED. It reads the Phase 1 matrix from trace/ and takes the test design and the NFR audit as context; the derived decision is PASS, CONCERNS, or FAIL. Trace validates any filed waiver and reports it alongside the unchanged decision. Keep test execution results, the quality audit, and the NFR audit in the release record and assess each under your release policy. Missing execution results are a gap in release evidence and do not skip the trace gate.
4. Archive for audit. Keep test results, coverage reports, NFR audits, gate decisions, and approver signatures according to the retention policy your compliance team approves.

Enterprise-Specific Requirements

The artifacts, approvals, and checklists below are example project policy for your compliance team to adapt; TEA does not enforce them.

Evidence Collection

Artifacts auditors ask for:

• Requirements traceability matrix
• Test execution results (with timestamps)
• NFR evidence audit reports
• Security scan results
• Performance test results
• Gate decision records
• Approver signatures

Storage:

compliance/
├── 2026-Q1/
│   ├── release-v1.2.0/
│   │   ├── trace/
│   │   │   ├── traceability-matrix-release-v1-2-0.md
│   │   │   ├── e2e-trace-summary-release-v1-2-0.json
│   │   │   └── gate-decision-release-v1-2-0.json
│   │   ├── test-review/
│   │   │   └── test-review-system.md
│   │   ├── nfr/
│   │   │   └── nfr-assessment-system.md
│   │   ├── test-results/
│   │   ├── security-scans/
│   │   └── approvals.pdf

Confirm retention periods with your compliance team for each artifact type.

Approver Workflows

Example multi-level approval:

## Gate Approvals Required

### Technical Approval

- [ ] QA Lead: Test coverage adequate
- [ ] Tech Lead: Technical quality acceptable
- [ ] Security Lead: Security requirements met

### Business Approval

- [ ] Product Manager: Business requirements met
- [ ] Compliance Officer: Regulatory requirements met

### Executive Approval (for major releases)

- [ ] VP Engineering: Overall quality acceptable
- [ ] CTO: Architecture approved for production

Compliance Checklists

Example controls to discuss with your SOC 2 auditor:

## Example Security Evidence Checklist

### Access Controls

- [ ] All API endpoints require authentication
- [ ] Authorization tested for all protected resources
- [ ] Session management secure (token expiration tested)

### Audit Logging

- [ ] All data access logged
- [ ] Logs immutable (append-only)
- [ ] Log retention policy enforced

### Data Protection

- [ ] Data encrypted at rest (tested)
- [ ] Data encrypted in transit (HTTPS enforced)
- [ ] PII handling compliant (masking tested)

### Testing Evidence

- [ ] Test coverage meets the project threshold
- [ ] Security tests passing (100%)
- [ ] Traceability matrix complete

Example controls for a system that handles PHI:

## Example PHI Protection Checklist

### PHI Protection

- [ ] PHI encrypted at rest under the approved security policy
- [ ] PHI encrypted in transit under the approved security policy
- [ ] PHI access logged (audit trail)

### Access Controls

- [ ] Role-based access control (RBAC tested)
- [ ] Minimum necessary access (tested)
- [ ] Authentication strong (MFA tested)

### Breach Notification

- [ ] Breach detection tested
- [ ] Notification workflow tested
- [ ] Incident response plan tested

Enterprise Tips

Start with Security

Security failures block everything else in enterprise, so make security requirements Priority 1:

1. Document all security requirements
2. Generate security tests with /bmad-tea-automate in red mode
3. Run the security test suite
4. Pass the security audit before moving forward

Example: RBAC Testing

Vanilla Playwright:

test('should enforce role-based access', async ({ request }) => {
  // Login as regular user
  const userResp = await request.post('/api/auth/login', {
    data: { email: 'user@example.com', password: 'pass' },
  });
  const { token: userToken } = await userResp.json();

  // Try to access admin endpoint
  const adminResp = await request.get('/api/admin/users', {
    headers: { Authorization: `Bearer ${userToken}` },
  });

  expect(adminResp.status()).toBe(403); // Forbidden
});

With Playwright Utils:

tests/api/admin-users.spec.ts

import { test, expect } from '../support/merged-fixtures';

test('regular user is denied the admin endpoint', async ({ apiRequest, authToken }) => {
  // authToken belongs to the default user your auth provider signs in
  const { status } = await apiRequest({
    method: 'GET',
    path: '/api/admin/users',
    headers: { Authorization: `Bearer ${authToken}` },
  });

  expect(status).toBe(403);
});

test.describe('as admin', () => {
  test.use({ authOptions: { userIdentifier: 'admin' } });

  test('admin can list users', async ({ apiRequest, authToken }) => {
    const { status, body } = await apiRequest({
      method: 'GET',
      path: '/api/admin/users',
      headers: { Authorization: `Bearer ${authToken}` },
    });

    expect(status).toBe(200);
    expect(body).toBeInstanceOf(Array);
  });
});

The spec imports the project’s one fixture module, tests/support/merged-fixtures.ts, which merges apiRequest with the auth fixtures (Integrate Playwright Utils sets it up; use your configured test_dir in place of tests/). authToken needs an auth provider registered with setAuthProvider that performs a real login or token exchange for each user identifier; see auth-session configuration. These tests send the token as a Bearer header. A browser test using the same fixtures gets a page opened with the provider’s saved storage state.

Set Higher Quality Thresholds

Example enterprise policy:

• Quality score: above 85
• P0 coverage: 100%
• P1 coverage: above 95%
• Overall coverage: above 85%

Set targets from the risks and contracts that apply to your project. Trace derives its decision from fixed thresholds: P0 at 100%, P1 at 90% or more for PASS, and overall at 80% or more. Your approvers apply a stricter policy to the percentages the report shows.

Document Everything

Auditors need:

• Why decisions were made (rationale)
• Who approved (signatures)
• When (timestamps)
• What evidence (test results, scan reports)

Keep TEA reports with their referenced evidence and record approvals in your release process.

Schedule Compliance Testing Early

Book penetration tests and independent audits during planning. Confirm lead times with the provider.

Use External Validators

Don’t self-certify: use an external firm for penetration tests, an independent auditor for security audits, a certification body for compliance, and a load testing service for performance. TEA organizes test evidence for independent review.

Related Guides

Skill Guides:

• How to Run NFR Evidence Audit: Deep dive on evidence auditing
• How to Run Trace: Gate decisions with evidence
• How to Run Test Review: Quality audits
• How to Run Test Design: Compliance-focused planning

Use-Case Guides:

• Using TEA with Existing Tests: Brownfield patterns

Customization:

• Integrate Playwright Utils: utilities

Understanding the Concepts

• Engagement Models: Enterprise model explained
• Risk-Based Testing: Probability × impact scoring
• Test Quality Standards: Enterprise quality thresholds
• TEA Overview: Complete TEA lifecycle

Reference

• TEA Command Reference: Skill commands
• TEA Configuration: Enterprise config options
• Knowledge Base Index: Testing patterns
• Glossary: TEA terminology