# TESTING Pattern Scripts & Commands Analysis

**Document:** `TESTING_SCRIPTS_BY_COMMAND.md`
**Pattern:** TESTING (Test Coverage → Automation)
**Purpose:** Improve code coverage and testing automation. Make manual testing easier and less time-consuming for humans.
**Status:** ⚠️ MINIMAL - Only initialization and validation covered. Missing coverage analysis, generation, optimization, automation.

**Related Documentation:**
- [COMMAND-USE-CASE-PATTERNS.md](COMMAND-USE-CASE-PATTERNS.md) - Full pattern definitions
- [CODE_ANALYSIS_SCRIPTS_BY_COMMAND.md](CODE_ANALYSIS_SCRIPTS_BY_COMMAND.md) - CODE-ANALYSIS pattern analysis

---

## Executive Summary

### Current State Analysis

The TESTING pattern is **severely underdeveloped**:
- **Commands:** 8 commands, ~13.7K tokens total
- **Coverage:** Only test initialization and validation
- **Gaps:** No coverage analysis, generation, optimization, or automation
- **Problem:** Commands are repurposed from other patterns (mostly RELEASE validation)

### Key Findings

1. **Fragmented Pattern:** TESTING pattern mixes:
   - Test initialization (`start-testing`) - real testing
   - Release validation (`validate-release-docs`, `validate-github-templates`) - release support
   - Documentation/setup (`uninstall-roadcrew`, `update-roadcrew`, `sync-roadmap`) - ancillary
   - Issue creation (`create-epic`) - administrative

2. **Missing Core Capabilities:**
   - ❌ No coverage analysis (find untested code paths)
   - ❌ No test generation (AI-generate missing tests)
   - ❌ No test optimization (speed, deduplication)
   - ❌ No automation (convert manual QA to automated)
   - ❌ No multi-repo testing (monorepo/multi-repo coordination)

3. **Token Efficiency:** ~13.7K tokens, but only ~3.3K on actual testing
   - 70% of tokens spent on non-testing validation
   - Opportunity to extract common validation logic

### Next Steps (Recommendations)

| Phase | Decision Point | Recommendation |
|-------|---|---|
| **Phase 1** | Extract validation utilities | Create `test-validator.ts` for BRD/PRD/Spec/template validation |
| **Phase 2** | Analyze coverage | Create `coverage-analyzer.ts` for identifying untested code paths |
| **Phase 3** | Generate tests | Create `test-generator.ts` for AI-generating missing test cases |
| **Phase 4** | Optimize testing | Create `test-optimizer.ts` for suite speed and deduplication |
| **Phase 5** | Refactor orchestrator | Refactor `start-testing` to call 4 helper scripts |
| **Decision 5** | New standalone commands | Create `/analyze-test-coverage`, `/generate-test-cases`, `/optimize-test-suite` |

---

## Command Details

### 1. start-testing (STARTER, Parent Orchestrator)

**Tier:** STARTER
**Calls:** 8 (internal functions)
**Tokens:** 3,321
**Role:** Initialize test framework and generate initial tests

**Command Summary:**
- Detects test framework (Jest, Playwright, pytest, Go test)
- Runs automated tests if available
- Guides user through manual test execution
- Coordinates deployment and testing across environments

**Current Capabilities:**
- Pre-flight checks and environment detection
- Schema migration support (Prisma)
- Multi-environment deployment (GitHub Actions, Vercel, Docker, local)
- Automated test execution (Node.js, Python, Go)
- Manual test loop with issue handling
- Completion tracking and next-step guidance

**Key Files & I/O:**
- Reads: `.cursorrules.md`, `memory-bank/techContext.md`, `EPIC-XXX-TEST-PLAN.md`
- Output: Test results, issue reports, PR/release options
- Scope: Assumes implementation already complete

**Scripts Called (Current):**
- None (all logic inline)
- Internal functions: `detectEnvironment()`, `deployToTarget()`, `runAutomatedTests()`, `manualTestLoop()`

**Potential Refactoring:**
- Extract deployment logic → `test-deployer.ts`
- Extract test execution → `test-executor.ts`
- Extract manual test coordination → `test-coordinator.ts`

---

### 2. create-release-pr (FREE, Testing Gate)

**Tier:** FREE
**Calls:** 3
**Tokens:** 1,940
**Role:** Create/validate PR for release (secondary use in TESTING as gate)

**Used In:** RELEASE pattern (primary), TESTING pattern (secondary)
**In TESTING:** Validation checkpoint before merge

**Capabilities:**
- Create PR from epic branch
- Link to epic for context
- Apply appropriate labels

---

### 3. validate-release-docs (FREE, Supporting Test)

**Tier:** FREE
**Calls:** 6
**Tokens:** 3,023
**Role:** Validate BRD/PRD/Spec document quality

**Used In:** RELEASE pattern (primary), TESTING pattern (secondary)
**In TESTING:** Pre-deployment validation

**Capabilities:**
- Validate document structure
- Check template compliance
- Verify downstream compatibility

---

### 4. validate-github-templates (STARTER, Supporting Test)

**Tier:** STARTER
**Calls:** 4
**Tokens:** 1,686
**Role:** Validate GitHub issue/PR templates

**Used In:** TESTING pattern (validation)
**In TESTING:** Pre-deployment template check

**Capabilities:**
- Validate template structure
- Check required fields
- Verify template compatibility

---

### 5. uninstall-roadcrew (FREE, Cleanup)

**Tier:** FREE
**Calls:** 1
**Tokens:** 153
**Role:** Uninstall/clean up before retest

**Not Core Testing:** Cleanup/setup utility, not a testing command
**Better Fit:** Maintenance/Operations pattern (if created)

**Capabilities:**
- Remove Roadcrew installation
- Clean up directories and config

---

### 6. sync-roadmap (FREE, Progress Tracking)

**Tier:** FREE
**Calls:** 0
**Tokens:** 978
**Role:** Sync roadmap progress to track testing phases

**Not Core Testing:** Progress tracking, not a testing command
**Better Fit:** PLANNING pattern documentation sync

**Capabilities:**
- Update progress tracking
- Sync status across docs

---

### 7. update-roadcrew (FREE, Setup)

**Tier:** FREE
**Calls:** 6
**Tokens:** 3,074
**Role:** Update Roadcrew version for testing new features

**Not Core Testing:** Version management, not a testing command
**Better Fit:** Maintenance/Setup pattern

**Capabilities:**
- Update to new Roadcrew version
- Test new features
- Validate upgrade compatibility

---

### 8. create-epic (STARTER, Administrative)

**Tier:** STARTER
**Calls:** 3
**Tokens:** 2,045
**Role:** Create test epics for testing workflows

**Not Core Testing:** Administrative, not a testing command
**Better Fit:** RELEASE pattern issue creation

**Capabilities:**
- Create new epic
- Link to testing phase
- Prepare for test execution

---

## Pattern Gaps & Opportunities

### Gap 1: No Coverage Analysis
**Impact:** Can't identify untested code paths or dead code
**Solution:** Create `coverage-analyzer.ts` script

**What It Does:**
- Parse coverage reports (if available)
- Compare code paths to test cases
- Identify untested branches/functions
- Recommend missing test cases

**Token Estimate:** 200-300 tokens per analysis

---

### Gap 2: No Test Generation
**Impact:** Manual test case creation is time-consuming
**Solution:** Create `test-generator.ts` script

**What It Does:**
- Analyze code functions/modules
- Generate test cases for uncovered paths
- Create template test code
- Suggest assertions based on function signature

**Token Estimate:** 300-400 tokens per generation

---

### Gap 3: No Test Optimization
**Impact:** Test suites grow without pruning, slow down CI
**Solution:** Create `test-optimizer.ts` script

**What It Does:**
- Identify duplicate test cases
- Remove redundant assertions
- Suggest test parallelization opportunities
- Measure test execution time per test

**Token Estimate:** 200-300 tokens per optimization

---

### Gap 4: No Test Automation
**Impact:** QA teams manually test scenarios that should be automated
**Solution:** Create `test-automation.ts` script

**What It Does:**
- Parse manual test documentation
- Convert to automated test format
- Generate Playwright/Cypress scripts
- Create E2E test suites

**Token Estimate:** 400-600 tokens per automation

---

## Proposed Script Extraction

### Helper Scripts (Supporting `start-testing` refactoring)

#### 1. test-validator.ts (NEW)
**Purpose:** Consolidate all validation logic from `validate-release-docs` and `validate-github-templates`

**Functions:**
- `validateDocumentStructure(doc)` - Check doc format
- `validateTemplateCompliance(template)` - Check template structure
- `validateGitHubTemplates(repo)` - Validate GitHub issue/PR templates
- `generateValidationReport()` - Summary of all validation results

**Token Savings:**
- Extract from `validate-release-docs`: 800-1.2K tokens
- Extract from `validate-github-templates`: 400-600 tokens
- Shared utility reduces duplication: 200-300 tokens saved
- **Total:** 1.4-2.1K tokens saved

**Distribution:** Yes (distributed via publish-distribution.sh)

---

#### 2. coverage-analyzer.ts (NEW)
**Purpose:** Analyze code coverage and identify untested paths

**Functions:**
- `readCoverageReport(path)` - Parse coverage JSON
- `analyzeCodePaths(ast)` - Extract all code paths
- `identifyUntested()` - Find gaps in coverage
- `suggestTestCases()` - Recommend missing tests
- `generateCoverageReport()` - Summary report

**Token Savings:**
- Replaces inline logic in new `/analyze-test-coverage` command
- First-time extraction: 300-500 tokens
- Can be used by multiple commands in future

**Distribution:** Yes

---

#### 3. test-generator.ts (NEW)
**Purpose:** AI-generate missing test cases

**Functions:**
- `parseCodeStructure(code)` - Extract functions/modules
- `analyzeFunctionSignature(func)` - Understand inputs/outputs
- `generateTestCases(func)` - Create test templates
- `generateAssertions(func)` - Suggest assertions
- `generateTestFile()` - Create complete test file

**Token Savings:**
- First-time: 400-600 tokens for implementation
- Used by `/generate-test-cases` command
- Reduces command text by 700-900 tokens

**Distribution:** Yes

---

#### 4. test-optimizer.ts (NEW)
**Purpose:** Optimize test suites for speed and completeness

**Functions:**
- `identifyDuplicates(tests)` - Find duplicate test cases
- `analyzeTestCoverage(tests)` - Find redundant assertions
- `measureExecutionTime(tests)` - Profile test speed
- `suggestParallelization()` - Recommend parallelization
- `generateOptimizationPlan()` - Summary of improvements

**Token Savings:**
- First-time: 200-300 tokens
- Used by `/optimize-test-suite` command
- Reduces command text by 400-600 tokens

**Distribution:** Yes

---

### Orchestrator Refactoring

#### start-testing (REFACTORED)
**Current:** 3,321 tokens with all logic inline
**Refactored:** Call 3 helper scripts

**Changes:**
1. Extract deployment logic (already sophisticated, keep inline for now)
2. Call `test-validator.ts` for pre-flight validation
3. Call test framework execution (keep inline - framework-specific)
4. Keep manual test loop (user-interactive, keep inline)

**Token Savings:**
- Extract validation: 400-600 tokens
- Share utility functions: 200-300 tokens
- **Total:** 600-900 tokens saved (18-27% reduction)

---

### New Standalone Commands

#### /analyze-test-coverage (STARTER, NEW)
**Purpose:** Identify untested code paths and coverage gaps

**What It Does:**
- Runs coverage analysis on codebase
- Calls `coverage-analyzer.ts` for analysis
- Generates untested code path report
- Recommends missing test cases

**Token Estimate:** 300-500 tokens (via coverage-analyzer script)

---

#### /generate-test-cases (STARTER, NEW)
**Purpose:** AI-generate missing test cases

**What It Does:**
- Analyzes code structure (via `test-generator.ts`)
- Generates test templates
- Creates test file with assertions
- Offers to run tests immediately

**Token Estimate:** 600-800 tokens (via test-generator script)

---

#### /optimize-test-suite (STARTER, NEW)
**Purpose:** Improve test suite speed and coverage

**What It Does:**
- Analyzes test duplication (via `test-optimizer.ts`)
- Measures test execution times
- Suggests parallelization
- Recommends deduplication

**Token Estimate:** 400-600 tokens (via test-optimizer script)

---

## Tier Impact

### Current Tier Coverage

| Tier | Commands | Tokens | Status |
|------|----------|--------|--------|
| **FREE** | start-testing, create-release-pr, validate-release-docs, uninstall-roadcrew, sync-roadmap, update-roadcrew | ~10.2K | ⚠️ Fragmented |
| **STARTER** | validate-github-templates, create-epic | ~3.7K | ⚠️ Limited |
| **ENTERPRISE** | (none) | 0 | ❌ Gap: multi-repo testing |

### Proposed New Tier Coverage

| Tier | Commands | Tokens | Status |
|------|----------|--------|--------|
| **FREE** | start-testing (refactored), create-release-pr | ~2.4K | ✅ Core testing |
| **STARTER** | validate-github-templates, analyze-test-coverage (NEW), generate-test-cases (NEW), optimize-test-suite (NEW) | ~3.5K + 1.3K new | ✅ Comprehensive |
| **ENTERPRISE** | test-multiplatform (future) | TBD | 🔮 Planned |

---

## Current State Analysis

### Token Distribution

```
TESTING Pattern: ~13.7K tokens total

Core Testing:
  start-testing: 3,321 tokens (24%)
  ✓ Real testing orchestration

Supporting Testing (RELEASE validation):
  validate-release-docs: 3,023 tokens (22%)
  validate-github-templates: 1,686 tokens (12%)
  create-release-pr: 1,940 tokens (14%)
  ✓ Pre-deployment validation

Ancillary (Not core testing):
  uninstall-roadcrew: 153 tokens (1%)
  sync-roadmap: 978 tokens (7%)
  update-roadcrew: 3,074 tokens (22%)
  create-epic: 2,045 tokens (15%)
  ✗ Wrong pattern (maintenance, planning, release)

Misclassified: 6,250 tokens (46%)
  → Should move to appropriate patterns or new "Maintenance" pattern
```

### Command Calls Analysis

```
start-testing: 8 internal functions (no script reuse)
  - detectEnvironment()
  - deployToTarget()
  - runAutomatedTests()
  - manualTestLoop()
  - trackProgress()
  - handleIssues()
  - generateCompletion()

validate-release-docs: 6 calls (shared with validate-github-templates)
validate-github-templates: 4 calls (shared with validate-release-docs)

Opportunity: Extract 2-3 shared validation utilities
```

---

## Decision Framework

### Phase 1: Extract Validation Utilities (Low Risk)
**Goal:** Create `test-validator.ts` consolidating validation logic from `validate-release-docs` and `validate-github-templates`

**Decision Point 1: Should validation be a separate utility or stay embedded?**

**Option A:** Extract as `test-validator.ts`
- Pros: Reusable, reduces duplication, cleaner orchestrator
- Cons: Adds new file, requires refactoring
- Risk: Low (validation logic already proven)
- Tokens: 200-300 tokens saved, +150 tokens for new script

**Option B:** Keep embedded in commands
- Pros: No refactoring needed, self-contained
- Cons: Duplication continues, harder to maintain
- Tokens: No savings

**Recommendation:** **Option A** - Extract as `test-validator.ts`
- Validation logic is common across multiple patterns
- Can be reused by other TESTING improvements
- Foundation for future automation

---

### Phase 2: Create Coverage Analysis (Medium Risk)
**Goal:** Create `coverage-analyzer.ts` and new `/analyze-test-coverage` command

**Decision Point 2: Should coverage analysis be automated or interactive?**

**Option A:** Automated analysis with suggestions
- Coverage report analyzed automatically
- Untested paths identified
- Test case recommendations generated
- Pros: Hands-off, actionable recommendations
- Cons: May miss context-specific needs
- Tokens: 300-500 tokens

**Option B:** Interactive analysis with user guidance
- User runs analysis
- Guided through untested code
- Create tests interactively
- Pros: Context-aware, user-driven
- Cons: More manual, less automation
- Tokens: 400-600 tokens

**Recommendation:** **Option A** - Automated with suggestions
- Aligns with Roadcrew's hands-off automation principle
- Frees up user time
- Suggestions can be accepted or customized

---

### Phase 3: Create Test Generation (High Risk)
**Goal:** Create `test-generator.ts` and new `/generate-test-cases` command

**Decision Point 3: Should generated tests be auto-committed or require review?**

**Option A:** Auto-generate and commit to epic branch
- Generate tests immediately
- Commit with message "Generated tests for functions X, Y, Z"
- Ready to run and iterate
- Pros: Fast iteration, users can modify
- Cons: May have AI quality issues
- Tokens: 600-800 tokens

**Option B:** Generate and ask for review before commit
- Generate tests
- Show preview
- User reviews and approves
- Then commit
- Pros: Quality control, user confidence
- Cons: Extra step, slower workflow
- Tokens: 700-900 tokens

**Recommendation:** **Option A** - Auto-generate and commit
- Tests are temporary, easily modified
- Users can review and fix immediately
- Faster workflow aligns with Roadcrew principles
- Tests run through CI anyway (safety valve)

---

### Phase 4: Create Test Optimization (Low-Medium Risk)
**Goal:** Create `test-optimizer.ts` and new `/optimize-test-suite` command

**Decision Point 4: Should optimization be automatic or suggest-only?**

**Option A:** Suggest optimizations, let user decide
- Analyze test suite
- Recommend deduplication, parallelization, timing
- User applies suggestions manually
- Pros: User remains in control
- Cons: Extra manual work
- Tokens: 300-400 tokens

**Option B:** Apply optimizations automatically
- Analyze and deduplicate automatically
- Remove redundant tests
- Enable parallelization in CI config
- Offer to run optimized suite
- Pros: Hands-off, faster suite
- Cons: May break assumptions
- Tokens: 400-600 tokens

**Recommendation:** **Option A** - Suggest-only approach
- Test deduplication needs context
- Parallelization depends on CI setup
- User should approve changes
- Safer for production workflows

---

### Phase 5: Refactor start-testing Orchestrator (Medium Risk)
**Goal:** Refactor `start-testing` to call helper scripts

**Decision Point 5: Which logic should be extracted to helper scripts?**

**Option A:** Extract only validation (minimal refactoring)
- Call `test-validator.ts` for pre-flight checks
- Keep deployment and test execution inline
- Pros: Minimal refactoring, less risk
- Cons: Limited reusability
- Tokens: 400-600 tokens saved

**Option B:** Extract validation + test execution (medium refactoring)
- Call `test-validator.ts` for validation
- Call new `test-executor.ts` for framework execution
- Keep deployment and manual loop inline
- Pros: Better separation of concerns
- Cons: More refactoring needed
- Tokens: 800-1.2K tokens saved

**Option C:** Full modularization (higher refactoring)
- Call `test-validator.ts`, `test-executor.ts`, `test-coordinator.ts`
- Keep only orchestration logic in `start-testing`
- Pros: Maximum reusability, cleaner code
- Cons: More scripts to maintain, higher risk
- Tokens: 1.2-1.8K tokens saved

**Recommendation:** **Option B** - Extract validation + test execution
- Good balance of reusability and risk
- Test execution is framework-specific but extractable
- Deployment stays inline (environment-specific)
- 800-1.2K tokens saved (24-36% reduction)

---

### Phase 6: Create New Standalone Commands (Low-Medium Risk)
**Goal:** Create 3 new STARTER tier commands for specialized auditing

**Decision Point 6: Should new commands support both code and issue analysis?**

**Option A:** Code-only analysis
- `/analyze-test-coverage` - code coverage only
- `/generate-test-cases` - code test generation only
- `/optimize-test-suite` - test suite only
- Pros: Focused, simple
- Cons: Can't work with GitHub issues
- Tokens: 300-500 per command

**Option B:** Both code + issue support
- Each command can work on code or GitHub issue
- `/analyze-test-coverage --issue #123` mode
- Pros: Flexible, covers more use cases
- Cons: More complex, higher token cost
- Tokens: 500-800 per command

**Recommendation:** **Option A** - Code-only initially
- Simpler implementation
- GitHub issue testing is out of scope for now
- Can add GitHub support in future iteration
- Each command: 300-500 tokens

---

### Phase 7: Rollout Strategy (Low Risk)
**Goal:** Deploy new TESTING pattern improvements

**Decision Point 7: Should rollout be sequential or parallel?**

**Option A:** Sequential (current pattern)
- Phase 1: Extract validation (week 1)
- Phase 2: Create coverage analysis (week 2)
- Phase 3: Create test generation (week 3)
- Phase 4: Create optimization (week 4)
- Phase 5: Refactor orchestrator (week 5)
- Phase 6: Create standalone commands (week 6)
- Timeline: 6 weeks
- Pros: Lower risk, proven approach
- Cons: Slower to market

**Option B:** Parallel (validation utilities separate track)
- Track 1: Validation utilities (week 1)
  - Immediately usable by other patterns
  - Refactor start-testing mid-project
- Track 2: Coverage + generation (weeks 2-3)
  - Doesn't depend on validation refactoring
  - Can proceed independently
- Pros: Faster overall timeline
- Cons: Higher complexity, coordination needed
- Timeline: 4 weeks

**Recommendation:** **Option B** - Parallel with two tracks
- Validation utilities ready in week 1
- Coverage/generation can proceed simultaneously
- Overall timeline: 4 weeks vs 6 weeks
- Risk remains low with clear dependencies

---

## Support Decisions

### Testing Strategy
- **Unit Tests:** All new scripts (`coverage-analyzer.ts`, `test-generator.ts`, `test-optimizer.ts`)
- **Integration Tests:** New commands calling scripts
- **E2E Tests:** Full workflow with real projects
- **Approach:** Mock coverage reports, mock test suites, real test projects

### Measurement & Validation
- **Baseline:** Manual baseline for each new command
- **Automated:** CI/CD tracking via token consumption
- **Quality:** Test accuracy validation (generated tests should find real bugs)
- **Performance:** Measure coverage analysis time, generation speed, optimization impact

### Rollout Order
- **Phase 1 (Week 1):** Validation utilities (test-validator.ts)
- **Phase 2 (Weeks 2-3):** Coverage analysis + test generation (parallel tracks)
- **Phase 3 (Week 4):** Test optimization + orchestrator refactoring
- **Phase 4 (Week 5):** Create standalone commands
- **Production:** All commands tested, documented, and ready for customer distribution

---

## Key Files & Locations

### Existing Commands
- `commands/roadcrew/starter/start-testing.md` - Parent orchestrator
- `commands/roadcrew/free/release-management/validate-release-docs.md` - Validation
- `commands/roadcrew/starter/validate-github-templates.md` - Template validation

### New Scripts (to create)
- `scripts/utils/roadcrew/test-validator.ts` - Validation utilities
- `scripts/utils/roadcrew/coverage-analyzer.ts` - Coverage analysis
- `scripts/utils/roadcrew/test-generator.ts` - Test generation
- `scripts/utils/roadcrew/test-optimizer.ts` - Test optimization

### New Commands (to create)
- `commands/roadcrew/starter/analyze-test-coverage.md`
- `commands/roadcrew/starter/generate-test-cases.md`
- `commands/roadcrew/starter/optimize-test-suite.md`

---

## Summary

**Current TESTING pattern:** Minimal, fragmented, mostly repurposed validation commands

**Proposed improvements:**
1. Extract validation utilities (test-validator.ts) - **Foundation**
2. Create coverage analysis (coverage-analyzer.ts) - **Gap filling**
3. Create test generation (test-generator.ts) - **Automation**
4. Create test optimization (test-optimizer.ts) - **Efficiency**
5. Refactor start-testing orchestrator - **Modularization**
6. Create 3 new standalone commands - **User choice**

**Expected impact:**
- **Token Savings:** 600-1.2K tokens (15-20% of current TESTING pattern)
- **New Commands:** 3 new STARTER commands for specialized testing
- **User Freedom:** Hands-off test generation and optimization
- **Timeline:** 4-5 weeks (parallel tracks)
- **Risk Level:** Low-Medium (well-scoped, proven patterns)

---

## APPENDIX: Cross-Cutting VALIDATION Pattern

**IMPORTANT:** Validation gates that were previously documented in this file have been **extracted into a dedicated cross-cutting VALIDATION pattern** for reusability across all workflows.

### See: [VALIDATION_SCRIPTS_BY_COMMAND.md](VALIDATION_SCRIPTS_BY_COMMAND.md)

This document now contains:
- **7 Validation Gates** (configuration, docs, GitHub, code, tests, closure, handoffs)
- **12 Reusable Helper Scripts** (not duplicated across patterns)
- **5 Orchestrator Commands** (/validate-project-config, /validate-release-docs, /validate-github-issues, /validate-code, /validate-test-state)
- **Implementation Roadmap** (5 weeks, integrated with Epic 128)

### TESTING Pattern Validation Responsibilities

The TESTING pattern now **uses** VALIDATION pattern:
- **Gate 2:** /validate-release-docs (before scope-release)
- **Gate 4:** /validate-test-state (RED state - write-tests)
- **Gate 5:** /validate-test-state (GREEN state - implement-issue)
- **Gate 7:** validate-handoffs.ts (between commands)

TESTING pattern focuses on **test coverage and automation**, while VALIDATION pattern handles **cross-cutting quality checks**.

This separation of concerns enables:
- ✅ Reusable validation across all 8 patterns
- ✅ Consistent quality gates at every lifecycle stage
- ✅ Easier maintenance and updates
- ✅ Clear responsibility boundaries