create-byan-agent 2.1.0 → 2.1.1

package/_bmad/tea/workflows/testarch/atdd/steps-c/step-04-generate-tests.md

@@ -1,228 +0,0 @@
----
-name: 'step-04-generate-tests'
-description: 'Orchestrate parallel FAILING test generation (TDD red phase)'
-nextStepFile: './step-04c-aggregate.md'
----
-
-# Step 4: Orchestrate Parallel FAILING Test Generation
-
-## STEP GOAL
-
-Launch parallel subprocesses to generate FAILING API and E2E tests simultaneously (TDD RED PHASE) for maximum performance.
-
-## MANDATORY EXECUTION RULES
-
-- 📖 Read the entire step file before acting
-- ✅ Speak in `{communication_language}`
-- ✅ Launch TWO subprocesses in PARALLEL
-- ✅ Generate FAILING tests only (TDD red phase)
-- ✅ Wait for BOTH subprocesses to complete
-- ❌ Do NOT generate sequential tests (use subprocesses)
-- ❌ Do NOT generate passing tests (this is red phase)
-- ❌ Do NOT proceed until both subprocesses finish
-
----
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Follow the MANDATORY SEQUENCE exactly
-- 💾 Wait for subprocess outputs
-- 📖 Load the next step only when instructed
-
-## CONTEXT BOUNDARIES:
-
-- Available context: config, acceptance criteria from Step 1, test strategy from Step 3
-- Focus: subprocess orchestration only
-- Limits: do not generate tests directly (delegate to subprocesses)
-- Dependencies: Steps 1-3 outputs
-
----
-
-## MANDATORY SEQUENCE
-
-**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise.
-
-### 1. Prepare Subprocess Inputs
-
-**Generate unique timestamp** for temp file naming:
-
-```javascript
-const timestamp = new Date().toISOString().replace(/[:.]/g, '-');
-```
-
-**Prepare input context for both subprocesses:**
-
-```javascript
-const subprocessContext = {
-  story_acceptance_criteria: /* from Step 1 */,
-  test_strategy: /* from Step 3 */,
-  knowledge_fragments_loaded: /* list of fragments */,
-  config: {
-    test_framework: config.test_framework,
-    use_playwright_utils: config.tea_use_playwright_utils
-  },
-  timestamp: timestamp
-};
-```
-
----
-
-### 2. Launch Subprocess A: Failing API Test Generation
-
-**Launch subprocess in parallel:**
-
-- **Subprocess File:** `./step-04a-subprocess-api-failing.md`
-- **Output File:** `/tmp/tea-atdd-api-tests-${timestamp}.json`
-- **Context:** Pass `subprocessContext`
-- **Execution:** PARALLEL (non-blocking)
-- **TDD Phase:** RED (failing tests)
-
-**System Action:**
-
-```
-🚀 Launching Subprocess A: FAILING API Test Generation (RED PHASE)
-📝 Output: /tmp/tea-atdd-api-tests-${timestamp}.json
-🔴 TDD Phase: RED (tests will fail until feature implemented)
-⏳ Status: Running in parallel...
-```
-
----
-
-### 3. Launch Subprocess B: Failing E2E Test Generation
-
-**Launch subprocess in parallel:**
-
-- **Subprocess File:** `./step-04b-subprocess-e2e-failing.md`
-- **Output File:** `/tmp/tea-atdd-e2e-tests-${timestamp}.json`
-- **Context:** Pass `subprocessContext`
-- **Execution:** PARALLEL (non-blocking)
-- **TDD Phase:** RED (failing tests)
-
-**System Action:**
-
-```
-🚀 Launching Subprocess B: FAILING E2E Test Generation (RED PHASE)
-📝 Output: /tmp/tea-atdd-e2e-tests-${timestamp}.json
-🔴 TDD Phase: RED (tests will fail until feature implemented)
-⏳ Status: Running in parallel...
-```
-
----
-
-### 4. Wait for Both Subprocesses to Complete
-
-**Monitor subprocess execution:**
-
-```
-⏳ Waiting for subprocesses to complete...
-  ├── Subprocess A (API RED): Running... ⟳
-  └── Subprocess B (E2E RED): Running... ⟳
-
-[... time passes ...]
-
-  ├── Subprocess A (API RED): Complete ✅
-  └── Subprocess B (E2E RED): Complete ✅
-
-✅ All subprocesses completed successfully!
-```
-
-**Verify both outputs exist:**
-
-```javascript
-const apiOutputExists = fs.existsSync(`/tmp/tea-atdd-api-tests-${timestamp}.json`);
-const e2eOutputExists = fs.existsSync(`/tmp/tea-atdd-e2e-tests-${timestamp}.json`);
-
-if (!apiOutputExists || !e2eOutputExists) {
-  throw new Error('One or both subprocess outputs missing!');
-}
-```
-
----
-
-### 5. TDD Red Phase Report
-
-**Display TDD status:**
-
-```
-🔴 TDD RED PHASE: Failing Tests Generated
-
-✅ Both subprocesses completed:
-- API Tests: Generated with test.skip()
-- E2E Tests: Generated with test.skip()
-
-📋 All tests assert EXPECTED behavior
-📋 All tests will FAIL until feature implemented
-📋 This is INTENTIONAL (TDD red phase)
-
-Next: Aggregation will verify TDD compliance
-```
-
----
-
-### 6. Performance Report
-
-**Display performance metrics:**
-
-```
-🚀 Performance Report:
-- Execution Mode: PARALLEL (2 subprocesses)
-- API Test Generation: ~X minutes
-- E2E Test Generation: ~Y minutes
-- Total Elapsed: ~max(X, Y) minutes
-- Sequential Would Take: ~(X + Y) minutes
-- Performance Gain: ~50% faster!
-```
-
----
-
-### 7. Proceed to Aggregation
-
-**Load aggregation step:**
-Load next step: `{nextStepFile}`
-
-The aggregation step (4C) will:
-
-- Read both subprocess outputs
-- Verify TDD red phase compliance (all tests have test.skip())
-- Write all test files to disk
-- Generate ATDD checklist
-- Calculate summary statistics
-
----
-
-## EXIT CONDITION
-
-Proceed to Step 4C (Aggregation) when:
-
-- ✅ Subprocess A (API failing tests) completed successfully
-- ✅ Subprocess B (E2E failing tests) completed successfully
-- ✅ Both output files exist and are valid JSON
-- ✅ TDD red phase status reported
-
-**Do NOT proceed if:**
-
-- ❌ One or both subprocesses failed
-- ❌ Output files missing or corrupted
-- ❌ Subprocess generated passing tests (wrong - must be failing)
-
----
-
-## 🚨 SYSTEM SUCCESS/FAILURE METRICS:
-
-### ✅ SUCCESS:
-
-- Both subprocesses launched successfully
-- Both subprocesses completed without errors
-- Output files generated and valid
-- Tests generated with test.skip() (TDD red phase)
-- Parallel execution achieved ~50% performance gain
-
-### ❌ SYSTEM FAILURE:
-
-- Failed to launch subprocesses
-- One or both subprocesses failed
-- Output files missing or invalid
-- Tests generated without test.skip() (wrong phase)
-- Attempted sequential generation instead of parallel
-
-**Master Rule:** TDD RED PHASE requires FAILING tests (with test.skip()). Parallel subprocess execution is MANDATORY for performance.

package/_bmad/tea/workflows/testarch/atdd/steps-c/step-04a-subprocess-api-failing.md

@@ -1,215 +0,0 @@
----
-name: 'step-04a-subprocess-api-failing'
-description: 'Subprocess: Generate FAILING API tests (TDD red phase)'
-subprocess: true
-outputFile: '/tmp/tea-atdd-api-tests-{{timestamp}}.json'
----
-
-# Subprocess 4A: Generate Failing API Tests (TDD Red Phase)
-
-## SUBPROCESS CONTEXT
-
-This is an **isolated subprocess** running in parallel with E2E failing test generation.
-
-**What you have from parent workflow:**
-
-- Story acceptance criteria from Step 1
-- Test strategy and scenarios from Step 3
-- Knowledge fragments loaded: api-request, data-factories, api-testing-patterns
-- Config: test framework, Playwright Utils enabled/disabled
-
-**Your task:** Generate API tests that will FAIL because the feature is not implemented yet (TDD RED PHASE).
-
----
-
-## MANDATORY EXECUTION RULES
-
-- 📖 Read this entire subprocess file before acting
-- ✅ Generate FAILING API tests ONLY
-- ✅ Tests MUST fail when run (feature not implemented yet)
-- ✅ Output structured JSON to temp file
-- ✅ Follow knowledge fragment patterns
-- ❌ Do NOT generate E2E tests (that's subprocess 4B)
-- ❌ Do NOT generate passing tests (this is TDD red phase)
-- ❌ Do NOT run tests (that's step 5)
-
----
-
-## SUBPROCESS TASK
-
-### 1. Identify API Endpoints from Acceptance Criteria
-
-From the story acceptance criteria (Step 1 output), identify:
-
-- Which API endpoints will be created for this story
-- Expected request/response contracts
-- Authentication requirements
-- Expected status codes and error scenarios
-
-**Example Acceptance Criteria:**
-
-```
-Story: User Registration
-- As a user, I can POST to /api/users/register with email and password
-- System returns 201 Created with user object
-- System returns 400 Bad Request if email already exists
-- System returns 422 Unprocessable Entity if validation fails
-```
-
-### 2. Generate FAILING API Test Files
-
-For each API endpoint, create test file in `tests/api/[feature].spec.ts`:
-
-**Test Structure (ATDD - Red Phase):**
-
-```typescript
-import { test, expect } from '@playwright/test';
-// If Playwright Utils enabled:
-// import { apiRequest } from '@playwright-utils/api';
-
-test.describe('[Story Name] API Tests (ATDD)', () => {
-  test.skip('[P0] should register new user successfully', async ({ request }) => {
-    // THIS TEST WILL FAIL - Endpoint not implemented yet
-    const response = await request.post('/api/users/register', {
-      data: {
-        email: 'newuser@example.com',
-        password: 'SecurePass123!',
-      },
-    });
-
-    // Expect 201 but will get 404 (endpoint doesn't exist)
-    expect(response.status()).toBe(201);
-
-    const user = await response.json();
-    expect(user).toMatchObject({
-      id: expect.any(Number),
-      email: 'newuser@example.com',
-    });
-  });
-
-  test.skip('[P1] should return 400 if email exists', async ({ request }) => {
-    // THIS TEST WILL FAIL - Endpoint not implemented yet
-    const response = await request.post('/api/users/register', {
-      data: {
-        email: 'existing@example.com',
-        password: 'SecurePass123!',
-      },
-    });
-
-    expect(response.status()).toBe(400);
-    const error = await response.json();
-    expect(error.message).toContain('Email already exists');
-  });
-});
-```
-
-**CRITICAL ATDD Requirements:**
-
-- ✅ Use `test.skip()` to mark tests as intentionally failing (red phase)
-- ✅ Write assertions for EXPECTED behavior (even though not implemented)
-- ✅ Use realistic test data (not placeholder data)
-- ✅ Test both happy path and error scenarios from acceptance criteria
-- ✅ Use `apiRequest()` helper if Playwright Utils enabled
-- ✅ Use data factories for test data (from data-factories fragment)
-- ✅ Include priority tags [P0], [P1], [P2], [P3]
-
-**Why test.skip():**
-
-- Tests are written correctly for EXPECTED behavior
-- But we know they'll fail because feature isn't implemented
-- `test.skip()` documents this is intentional (TDD red phase)
-- Once feature is implemented, remove `test.skip()` to verify green phase
-
-### 3. Track Fixture Needs
-
-Identify fixtures needed for API tests:
-
-- Authentication fixtures (if endpoints require auth)
-- Data factories (user data, etc.)
-- API client configurations
-
-**Do NOT create fixtures yet** - just track what's needed for aggregation step.
-
----
-
-## OUTPUT FORMAT
-
-Write JSON to temp file: `/tmp/tea-atdd-api-tests-{{timestamp}}.json`
-
-```json
-{
-  "success": true,
-  "subprocess": "atdd-api-tests",
-  "tests": [
-    {
-      "file": "tests/api/user-registration.spec.ts",
-      "content": "[full TypeScript test file content with test.skip()]",
-      "description": "ATDD API tests for user registration (RED PHASE)",
-      "expected_to_fail": true,
-      "acceptance_criteria_covered": [
-        "User can register with email/password",
-        "System returns 201 on success",
-        "System returns 400 if email exists"
-      ],
-      "priority_coverage": {
-        "P0": 1,
-        "P1": 2,
-        "P2": 0,
-        "P3": 0
-      }
-    }
-  ],
-  "fixture_needs": ["userDataFactory"],
-  "knowledge_fragments_used": ["api-request", "data-factories", "api-testing-patterns"],
-  "test_count": 3,
-  "tdd_phase": "RED",
-  "summary": "Generated 3 FAILING API tests for user registration story"
-}
-```
-
-**On Error:**
-
-```json
-{
-  "success": false,
-  "subprocess": "atdd-api-tests",
-  "error": "Error message describing what went wrong",
-  "partial_output": {
-    /* any tests generated before error */
-  }
-}
-```
-
----
-
-## EXIT CONDITION
-
-Subprocess completes when:
-
-- ✅ All API endpoints from acceptance criteria have test files
-- ✅ All tests use `test.skip()` (documented failing tests)
-- ✅ All tests assert EXPECTED behavior (not placeholder assertions)
-- ✅ JSON output written to temp file
-- ✅ Fixture needs tracked
-
-**Subprocess terminates here.** Parent workflow will read output and proceed to aggregation.
-
----
-
-## 🚨 SUBPROCESS SUCCESS METRICS
-
-### ✅ SUCCESS:
-
-- All API tests generated with test.skip()
-- Tests assert expected behavior (not placeholders)
-- JSON output valid and complete
-- No E2E/component/unit tests included (out of scope)
-- Tests follow knowledge fragment patterns
-
-### ❌ FAILURE:
-
-- Generated passing tests (wrong - this is RED phase)
-- Tests without test.skip() (will break CI)
-- Placeholder assertions (expect(true).toBe(true))
-- Did not follow knowledge fragment patterns
-- Invalid or missing JSON output

package/_bmad/tea/workflows/testarch/atdd/steps-c/step-04b-subprocess-e2e-failing.md

@@ -1,212 +0,0 @@
----
-name: 'step-04b-subprocess-e2e-failing'
-description: 'Subprocess: Generate FAILING E2E tests (TDD red phase)'
-subprocess: true
-outputFile: '/tmp/tea-atdd-e2e-tests-{{timestamp}}.json'
----
-
-# Subprocess 4B: Generate Failing E2E Tests (TDD Red Phase)
-
-## SUBPROCESS CONTEXT
-
-This is an **isolated subprocess** running in parallel with API failing test generation.
-
-**What you have from parent workflow:**
-
-- Story acceptance criteria from Step 1
-- Test strategy and user journey scenarios from Step 3
-- Knowledge fragments loaded: fixture-architecture, network-first, selector-resilience
-- Config: test framework, Playwright Utils enabled/disabled
-
-**Your task:** Generate E2E tests that will FAIL because the feature UI is not implemented yet (TDD RED PHASE).
-
----
-
-## MANDATORY EXECUTION RULES
-
-- 📖 Read this entire subprocess file before acting
-- ✅ Generate FAILING E2E tests ONLY
-- ✅ Tests MUST fail when run (UI not implemented yet)
-- ✅ Output structured JSON to temp file
-- ✅ Follow knowledge fragment patterns
-- ❌ Do NOT generate API tests (that's subprocess 4A)
-- ❌ Do NOT generate passing tests (this is TDD red phase)
-- ❌ Do NOT run tests (that's step 5)
-
----
-
-## SUBPROCESS TASK
-
-### 1. Identify User Journeys from Acceptance Criteria
-
-From the story acceptance criteria (Step 1 output), identify:
-
-- Which UI flows will be created for this story
-- User interactions required
-- Expected visual states
-- Success/error messages expected
-
-**Example Acceptance Criteria:**
-
-```
-Story: User Registration
-- As a user, I can navigate to /register page
-- I can fill in email and password fields
-- I can click "Register" button
-- System shows success message and redirects to dashboard
-- System shows error if email already exists
-```
-
-### 2. Generate FAILING E2E Test Files
-
-For each user journey, create test file in `tests/e2e/[feature].spec.ts`:
-
-**Test Structure (ATDD - Red Phase):**
-
-```typescript
-import { test, expect } from '@playwright/test';
-
-test.describe('[Story Name] E2E User Journey (ATDD)', () => {
-  test.skip('[P0] should complete user registration successfully', async ({ page }) => {
-    // THIS TEST WILL FAIL - UI not implemented yet
-    await page.goto('/register');
-
-    // Expect registration form but will get 404 or missing elements
-    await page.fill('[name="email"]', 'newuser@example.com');
-    await page.fill('[name="password"]', 'SecurePass123!');
-    await page.click('button:has-text("Register")');
-
-    // Expect success message and redirect
-    await expect(page.getByText('Registration successful!')).toBeVisible();
-    await page.waitForURL('/dashboard');
-  });
-
-  test.skip('[P1] should show error if email exists', async ({ page }) => {
-    // THIS TEST WILL FAIL - UI not implemented yet
-    await page.goto('/register');
-
-    await page.fill('[name="email"]', 'existing@example.com');
-    await page.fill('[name="password"]', 'SecurePass123!');
-    await page.click('button:has-text("Register")');
-
-    // Expect error message
-    await expect(page.getByText('Email already exists')).toBeVisible();
-  });
-});
-```
-
-**CRITICAL ATDD Requirements:**
-
-- ✅ Use `test.skip()` to mark tests as intentionally failing (red phase)
-- ✅ Write assertions for EXPECTED UI behavior (even though not implemented)
-- ✅ Use resilient selectors: getByRole, getByText, getByLabel (from selector-resilience)
-- ✅ Follow network-first patterns if API calls involved (from network-first)
-- ✅ Test complete user journeys from acceptance criteria
-- ✅ Include priority tags [P0], [P1], [P2], [P3]
-- ✅ Use proper TypeScript types
-- ✅ Deterministic waits (no hard sleeps)
-
-**Why test.skip():**
-
-- Tests are written correctly for EXPECTED UI behavior
-- But we know they'll fail because UI isn't implemented
-- `test.skip()` documents this is intentional (TDD red phase)
-- Once UI is implemented, remove `test.skip()` to verify green phase
-
-### 3. Track Fixture Needs
-
-Identify fixtures needed for E2E tests:
-
-- Authentication fixtures (if journey requires logged-in state)
-- Network mocks (if API calls involved)
-- Test data fixtures
-
-**Do NOT create fixtures yet** - just track what's needed for aggregation step.
-
----
-
-## OUTPUT FORMAT
-
-Write JSON to temp file: `/tmp/tea-atdd-e2e-tests-{{timestamp}}.json`
-
-```json
-{
-  "success": true,
-  "subprocess": "atdd-e2e-tests",
-  "tests": [
-    {
-      "file": "tests/e2e/user-registration.spec.ts",
-      "content": "[full TypeScript test file content with test.skip()]",
-      "description": "ATDD E2E tests for user registration journey (RED PHASE)",
-      "expected_to_fail": true,
-      "acceptance_criteria_covered": [
-        "User can navigate to /register",
-        "User can fill registration form",
-        "System shows success message on registration",
-        "System shows error if email exists"
-      ],
-      "priority_coverage": {
-        "P0": 1,
-        "P1": 1,
-        "P2": 0,
-        "P3": 0
-      }
-    }
-  ],
-  "fixture_needs": ["registrationPageMock"],
-  "knowledge_fragments_used": ["fixture-architecture", "network-first", "selector-resilience"],
-  "test_count": 2,
-  "tdd_phase": "RED",
-  "summary": "Generated 2 FAILING E2E tests for user registration story"
-}
-```
-
-**On Error:**
-
-```json
-{
-  "success": false,
-  "subprocess": "atdd-e2e-tests",
-  "error": "Error message describing what went wrong",
-  "partial_output": {
-    /* any tests generated before error */
-  }
-}
-```
-
----
-
-## EXIT CONDITION
-
-Subprocess completes when:
-
-- ✅ All user journeys from acceptance criteria have test files
-- ✅ All tests use `test.skip()` (documented failing tests)
-- ✅ All tests assert EXPECTED UI behavior (not placeholder assertions)
-- ✅ Resilient selectors used (getByRole, getByText)
-- ✅ JSON output written to temp file
-- ✅ Fixture needs tracked
-
-**Subprocess terminates here.** Parent workflow will read output and proceed to aggregation.
-
----
-
-## 🚨 SUBPROCESS SUCCESS METRICS
-
-### ✅ SUCCESS:
-
-- All E2E tests generated with test.skip()
-- Tests assert expected UI behavior (not placeholders)
-- Resilient selectors used (getByRole, getByText)
-- JSON output valid and complete
-- No API/component/unit tests included (out of scope)
-- Tests follow knowledge fragment patterns
-
-### ❌ FAILURE:
-
-- Generated passing tests (wrong - this is RED phase)
-- Tests without test.skip() (will break CI)
-- Placeholder assertions (expect(true).toBe(true))
-- Brittle selectors used (CSS classes, XPath)
-- Did not follow knowledge fragment patterns
-- Invalid or missing JSON output