agentvibes 2.13.7 → 2.13.8

package/.bmad/bmm/testarch/knowledge/visual-debugging.md

@@ -1,524 +0,0 @@
-# Visual Debugging and Developer Ergonomics
-
-## Principle
-
-Fast feedback loops and transparent debugging artifacts are critical for maintaining test reliability and developer confidence. Visual debugging tools (trace viewers, screenshots, videos, HAR files) turn cryptic test failures into actionable insights, reducing triage time from hours to minutes.
-
-## Rationale
-
-**The Problem**: CI failures often provide minimal context—a timeout, a selector mismatch, or a network error—forcing developers to reproduce issues locally (if they can). This wastes time and discourages test maintenance.
-
-**The Solution**: Capture rich debugging artifacts **only on failure** to balance storage costs with diagnostic value. Modern tools like Playwright Trace Viewer, Cypress Debug UI, and HAR recordings provide interactive, time-travel debugging that reveals exactly what the test saw at each step.
-
-**Why This Matters**:
-
-- Reduces failure triage time by 80-90% (visual context vs logs alone)
-- Enables debugging without local reproduction
-- Improves test maintenance confidence (clear failure root cause)
-- Catches timing/race conditions that are hard to reproduce locally
-
-## Pattern Examples
-
-### Example 1: Playwright Trace Viewer Configuration (Production Pattern)
-
-**Context**: Capture traces on first retry only (balances storage and diagnostics)
-
-**Implementation**:
-
-```typescript
-// playwright.config.ts
-import { defineConfig } from '@playwright/test';
-
-export default defineConfig({
-  use: {
-    // Visual debugging artifacts (space-efficient)
-    trace: 'on-first-retry', // Only when test fails once
-    screenshot: 'only-on-failure', // Not on success
-    video: 'retain-on-failure', // Delete on pass
-
-    // Context for debugging
-    baseURL: process.env.BASE_URL || 'http://localhost:3000',
-
-    // Timeout context
-    actionTimeout: 15_000, // 15s for clicks/fills
-    navigationTimeout: 30_000, // 30s for page loads
-  },
-
-  // CI-specific artifact retention
-  reporter: [
-    ['html', { outputFolder: 'playwright-report', open: 'never' }],
-    ['junit', { outputFile: 'results.xml' }],
-    ['list'], // Console output
-  ],
-
-  // Failure handling
-  retries: process.env.CI ? 2 : 0, // Retry in CI to capture trace
-  workers: process.env.CI ? 1 : undefined,
-});
-```
-
-**Opening and Using Trace Viewer**:
-
-```bash
-# After test failure in CI, download trace artifact
-# Then open locally:
-npx playwright show-trace path/to/trace.zip
-
-# Or serve trace viewer:
-npx playwright show-report
-```
-
-**Key Features to Use in Trace Viewer**:
-
-1. **Timeline**: See each action (click, navigate, assertion) with timing
-2. **Snapshots**: Hover over timeline to see DOM state at that moment
-3. **Network Tab**: Inspect all API calls, headers, payloads, timing
-4. **Console Tab**: View console.log/error messages
-5. **Source Tab**: See test code with execution markers
-6. **Metadata**: Browser, OS, test duration, screenshots
-
-**Why This Works**:
-
-- `on-first-retry` avoids capturing traces for flaky passes (saves storage)
-- Screenshots + video give visual context without trace overhead
-- Interactive timeline makes timing issues obvious (race conditions, slow API)
-
----
-
-### Example 2: HAR File Recording for Network Debugging
-
-**Context**: Capture all network activity for reproducible API debugging
-
-**Implementation**:
-
-```typescript
-// tests/e2e/checkout-with-har.spec.ts
-import { test, expect } from '@playwright/test';
-import path from 'path';
-
-test.describe('Checkout Flow with HAR Recording', () => {
-  test('should complete payment with full network capture', async ({ page, context }) => {
-    // Start HAR recording BEFORE navigation
-    await context.routeFromHAR(path.join(__dirname, '../fixtures/checkout.har'), {
-      url: '**/api/**', // Only capture API calls
-      update: true, // Update HAR if file exists
-    });
-
-    await page.goto('/checkout');
-
-    // Interact with page
-    await page.getByTestId('payment-method').selectOption('credit-card');
-    await page.getByTestId('card-number').fill('4242424242424242');
-    await page.getByTestId('submit-payment').click();
-
-    // Wait for payment confirmation
-    await expect(page.getByTestId('success-message')).toBeVisible();
-
-    // HAR file saved to fixtures/checkout.har
-    // Contains all network requests/responses for replay
-  });
-});
-```
-
-**Using HAR for Deterministic Mocking**:
-
-```typescript
-// tests/e2e/checkout-replay-har.spec.ts
-import { test, expect } from '@playwright/test';
-import path from 'path';
-
-test('should replay checkout flow from HAR', async ({ page, context }) => {
-  // Replay network from HAR (no real API calls)
-  await context.routeFromHAR(path.join(__dirname, '../fixtures/checkout.har'), {
-    url: '**/api/**',
-    update: false, // Read-only mode
-  });
-
-  await page.goto('/checkout');
-
-  // Same test, but network responses come from HAR file
-  await page.getByTestId('payment-method').selectOption('credit-card');
-  await page.getByTestId('card-number').fill('4242424242424242');
-  await page.getByTestId('submit-payment').click();
-
-  await expect(page.getByTestId('success-message')).toBeVisible();
-});
-```
-
-**Key Points**:
-
-- **`update: true`** records new HAR or updates existing (for flaky API debugging)
-- **`update: false`** replays from HAR (deterministic, no real API)
-- Filter by URL pattern (`**/api/**`) to avoid capturing static assets
-- HAR files are human-readable JSON (easy to inspect/modify)
-
-**When to Use HAR**:
-
-- Debugging flaky tests caused by API timing/responses
-- Creating deterministic mocks for integration tests
-- Analyzing third-party API behavior (Stripe, Auth0)
-- Reproducing production issues locally (record HAR in staging)
-
----
-
-### Example 3: Custom Artifact Capture (Console Logs + Network on Failure)
-
-**Context**: Capture additional debugging context automatically on test failure
-
-**Implementation**:
-
-```typescript
-// playwright/support/fixtures/debug-fixture.ts
-import { test as base } from '@playwright/test';
-import fs from 'fs';
-import path from 'path';
-
-type DebugFixture = {
-  captureDebugArtifacts: () => Promise<void>;
-};
-
-export const test = base.extend<DebugFixture>({
-  captureDebugArtifacts: async ({ page }, use, testInfo) => {
-    const consoleLogs: string[] = [];
-    const networkRequests: Array<{ url: string; status: number; method: string }> = [];
-
-    // Capture console messages
-    page.on('console', (msg) => {
-      consoleLogs.push(`[${msg.type()}] ${msg.text()}`);
-    });
-
-    // Capture network requests
-    page.on('request', (request) => {
-      networkRequests.push({
-        url: request.url(),
-        method: request.method(),
-        status: 0, // Will be updated on response
-      });
-    });
-
-    page.on('response', (response) => {
-      const req = networkRequests.find((r) => r.url === response.url());
-      if (req) req.status = response.status();
-    });
-
-    await use(async () => {
-      // This function can be called manually in tests
-      // But it also runs automatically on failure via afterEach
-    });
-
-    // After test completes, save artifacts if failed
-    if (testInfo.status !== testInfo.expectedStatus) {
-      const artifactDir = path.join(testInfo.outputDir, 'debug-artifacts');
-      fs.mkdirSync(artifactDir, { recursive: true });
-
-      // Save console logs
-      fs.writeFileSync(path.join(artifactDir, 'console.log'), consoleLogs.join('\n'), 'utf-8');
-
-      // Save network summary
-      fs.writeFileSync(path.join(artifactDir, 'network.json'), JSON.stringify(networkRequests, null, 2), 'utf-8');
-
-      console.log(`Debug artifacts saved to: ${artifactDir}`);
-    }
-  },
-});
-```
-
-**Usage in Tests**:
-
-```typescript
-// tests/e2e/payment-with-debug.spec.ts
-import { test, expect } from '../support/fixtures/debug-fixture';
-
-test('payment flow captures debug artifacts on failure', async ({ page, captureDebugArtifacts }) => {
-  await page.goto('/checkout');
-
-  // Test will automatically capture console + network on failure
-  await page.getByTestId('submit-payment').click();
-  await expect(page.getByTestId('success-message')).toBeVisible({ timeout: 5000 });
-
-  // If this fails, console.log and network.json saved automatically
-});
-```
-
-**CI Integration (GitHub Actions)**:
-
-```yaml
-# .github/workflows/e2e.yml
-name: E2E Tests with Artifacts
-on: [push, pull_request]
-
-jobs:
-  test:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v4
-      - uses: actions/setup-node@v4
-        with:
-          node-version-file: '.nvmrc'
-
-      - name: Install dependencies
-        run: npm ci
-
-      - name: Run Playwright tests
-        run: npm run test:e2e
-        continue-on-error: true # Capture artifacts even on failure
-
-      - name: Upload test artifacts on failure
-        if: failure()
-        uses: actions/upload-artifact@v4
-        with:
-          name: playwright-artifacts
-          path: |
-            test-results/
-            playwright-report/
-          retention-days: 30
-```
-
-**Key Points**:
-
-- Fixtures automatically capture context without polluting test code
-- Only saves artifacts on failure (storage-efficient)
-- CI uploads artifacts for post-mortem analysis
-- `continue-on-error: true` ensures artifact upload even when tests fail
-
----
-
-### Example 4: Accessibility Debugging Integration (axe-core in Trace Viewer)
-
-**Context**: Catch accessibility regressions during visual debugging
-
-**Implementation**:
-
-```typescript
-// playwright/support/fixtures/a11y-fixture.ts
-import { test as base } from '@playwright/test';
-import AxeBuilder from '@axe-core/playwright';
-
-type A11yFixture = {
-  checkA11y: () => Promise<void>;
-};
-
-export const test = base.extend<A11yFixture>({
-  checkA11y: async ({ page }, use) => {
-    await use(async () => {
-      // Run axe accessibility scan
-      const results = await new AxeBuilder({ page }).analyze();
-
-      // Attach results to test report (visible in trace viewer)
-      if (results.violations.length > 0) {
-        console.log(`Found ${results.violations.length} accessibility violations:`);
-        results.violations.forEach((violation) => {
-          console.log(`- [${violation.impact}] ${violation.id}: ${violation.description}`);
-          console.log(`  Help: ${violation.helpUrl}`);
-        });
-
-        throw new Error(`Accessibility violations found: ${results.violations.length}`);
-      }
-    });
-  },
-});
-```
-
-**Usage with Visual Debugging**:
-
-```typescript
-// tests/e2e/checkout-a11y.spec.ts
-import { test, expect } from '../support/fixtures/a11y-fixture';
-
-test('checkout page is accessible', async ({ page, checkA11y }) => {
-  await page.goto('/checkout');
-
-  // Verify page loaded
-  await expect(page.getByRole('heading', { name: 'Checkout' })).toBeVisible();
-
-  // Run accessibility check
-  await checkA11y();
-
-  // If violations found, test fails and trace captures:
-  // - Screenshot showing the problematic element
-  // - Console log with violation details
-  // - Network tab showing any failed resource loads
-});
-```
-
-**Trace Viewer Benefits**:
-
-- **Screenshot shows visual context** of accessibility issue (contrast, missing labels)
-- **Console tab shows axe-core violations** with impact level and helpUrl
-- **DOM snapshot** allows inspecting ARIA attributes at failure point
-- **Network tab** reveals if icon fonts or images failed (common a11y issue)
-
-**Cypress Equivalent**:
-
-```javascript
-// cypress/support/commands.ts
-import 'cypress-axe';
-
-Cypress.Commands.add('checkA11y', (context = null, options = {}) => {
-  cy.injectAxe(); // Inject axe-core
-  cy.checkA11y(context, options, (violations) => {
-    if (violations.length) {
-      cy.task('log', `Found ${violations.length} accessibility violations`);
-      violations.forEach((violation) => {
-        cy.task('log', `- [${violation.impact}] ${violation.id}: ${violation.description}`);
-      });
-    }
-  });
-});
-
-// tests/e2e/checkout-a11y.cy.ts
-describe('Checkout Accessibility', () => {
-  it('should have no a11y violations', () => {
-    cy.visit('/checkout');
-    cy.injectAxe();
-    cy.checkA11y();
-    // On failure, Cypress UI shows:
-    // - Screenshot of page
-    // - Console log with violation details
-    // - Network tab with API calls
-  });
-});
-```
-
-**Key Points**:
-
-- Accessibility checks integrate seamlessly with visual debugging
-- Violations are captured in trace viewer/Cypress UI automatically
-- Provides actionable links (helpUrl) to fix issues
-- Screenshots show visual context (contrast, layout)
-
----
-
-### Example 5: Time-Travel Debugging Workflow (Playwright Inspector)
-
-**Context**: Debug tests interactively with step-through execution
-
-**Implementation**:
-
-```typescript
-// tests/e2e/checkout-debug.spec.ts
-import { test, expect } from '@playwright/test';
-
-test('debug checkout flow step-by-step', async ({ page }) => {
-  // Set breakpoint by uncommenting this:
-  // await page.pause()
-
-  await page.goto('/checkout');
-
-  // Use Playwright Inspector to:
-  // 1. Step through each action
-  // 2. Inspect DOM at each step
-  // 3. View network calls per action
-  // 4. Take screenshots manually
-
-  await page.getByTestId('payment-method').selectOption('credit-card');
-
-  // Pause here to inspect form state
-  // await page.pause()
-
-  await page.getByTestId('card-number').fill('4242424242424242');
-  await page.getByTestId('submit-payment').click();
-
-  await expect(page.getByTestId('success-message')).toBeVisible();
-});
-```
-
-**Running with Inspector**:
-
-```bash
-# Open Playwright Inspector (GUI debugger)
-npx playwright test --debug
-
-# Or use headed mode with slowMo
-npx playwright test --headed --slow-mo=1000
-
-# Debug specific test
-npx playwright test checkout-debug.spec.ts --debug
-
-# Set environment variable for persistent debugging
-PWDEBUG=1 npx playwright test
-```
-
-**Inspector Features**:
-
-1. **Step-through execution**: Click "Next" to execute one action at a time
-2. **DOM inspector**: Hover over elements to see selectors
-3. **Network panel**: See API calls with timing
-4. **Console panel**: View console.log output
-5. **Pick locator**: Click element in browser to get selector
-6. **Record mode**: Record interactions to generate test code
-
-**Common Debugging Patterns**:
-
-```typescript
-// Pattern 1: Debug selector issues
-test('debug selector', async ({ page }) => {
-  await page.goto('/dashboard');
-  await page.pause(); // Inspector opens
-
-  // In Inspector console, test selectors:
-  // page.getByTestId('user-menu') ✅
-  // page.getByRole('button', { name: 'Profile' }) ✅
-  // page.locator('.btn-primary') ❌ (fragile)
-});
-
-// Pattern 2: Debug timing issues
-test('debug network timing', async ({ page }) => {
-  await page.goto('/dashboard');
-
-  // Set up network listener BEFORE interaction
-  const responsePromise = page.waitForResponse('**/api/users');
-  await page.getByTestId('load-users').click();
-
-  await page.pause(); // Check network panel for timing
-
-  const response = await responsePromise;
-  expect(response.status()).toBe(200);
-});
-
-// Pattern 3: Debug state changes
-test('debug state mutation', async ({ page }) => {
-  await page.goto('/cart');
-
-  // Check initial state
-  await expect(page.getByTestId('cart-count')).toHaveText('0');
-
-  await page.pause(); // Inspect DOM
-
-  await page.getByTestId('add-to-cart').click();
-
-  await page.pause(); // Inspect DOM again (compare state)
-
-  await expect(page.getByTestId('cart-count')).toHaveText('1');
-});
-```
-
-**Key Points**:
-
-- `page.pause()` opens Inspector at that exact moment
-- Inspector shows DOM state, network activity, console at pause point
-- "Pick locator" feature helps find robust selectors
-- Record mode generates test code from manual interactions
-
----
-
-## Visual Debugging Checklist
-
-Before deploying tests to CI, ensure:
-
-- [ ] **Artifact configuration**: `trace: 'on-first-retry'`, `screenshot: 'only-on-failure'`, `video: 'retain-on-failure'`
-- [ ] **CI artifact upload**: GitHub Actions/GitLab CI configured to upload `test-results/` and `playwright-report/`
-- [ ] **HAR recording**: Set up for flaky API tests (record once, replay deterministically)
-- [ ] **Custom debug fixtures**: Console logs + network summary captured on failure
-- [ ] **Accessibility integration**: axe-core violations visible in trace viewer
-- [ ] **Trace viewer docs**: README explains how to open traces locally (`npx playwright show-trace`)
-- [ ] **Inspector workflow**: Document `--debug` flag for interactive debugging
-- [ ] **Storage optimization**: Artifacts deleted after 30 days (CI retention policy)
-
-## Integration Points
-
-- **Used in workflows**: `*framework` (initial setup), `*ci` (artifact upload), `*test-review` (validate artifact config)
-- **Related fragments**: `playwright-config.md` (artifact configuration), `ci-burn-in.md` (CI artifact upload), `test-quality.md` (debugging best practices)
-- **Tools**: Playwright Trace Viewer, Cypress Debug UI, axe-core, HAR files
-
-_Source: Playwright official docs, Murat testing philosophy (visual debugging manifesto), SEON production debugging patterns_

package/.bmad/bmm/testarch/tea-index.csv

@@ -1,22 +0,0 @@
-id,name,description,tags,fragment_file
-fixture-architecture,Fixture Architecture,"Composable fixture patterns (pure function → fixture → merge) and reuse rules","fixtures,architecture,playwright,cypress",knowledge/fixture-architecture.md
-network-first,Network-First Safeguards,"Intercept-before-navigate workflow, HAR capture, deterministic waits, edge mocking","network,stability,playwright,cypress",knowledge/network-first.md
-data-factories,Data Factories and API Setup,"Factories with overrides, API seeding, cleanup discipline","data,factories,setup,api",knowledge/data-factories.md
-component-tdd,Component TDD Loop,"Red→green→refactor workflow, provider isolation, accessibility assertions","component-testing,tdd,ui",knowledge/component-tdd.md
-playwright-config,Playwright Config Guardrails,"Environment switching, timeout standards, artifact outputs","playwright,config,env",knowledge/playwright-config.md
-ci-burn-in,CI and Burn-In Strategy,"Staged jobs, shard orchestration, burn-in loops, artifact policy","ci,automation,flakiness",knowledge/ci-burn-in.md
-selective-testing,Selective Test Execution,"Tag/grep usage, spec filters, diff-based runs, promotion rules","risk-based,selection,strategy",knowledge/selective-testing.md
-feature-flags,Feature Flag Governance,"Enum management, targeting helpers, cleanup, release checklists","feature-flags,governance,launchdarkly",knowledge/feature-flags.md
-contract-testing,Contract Testing Essentials,"Pact publishing, provider verification, resilience coverage","contract-testing,pact,api",knowledge/contract-testing.md
-email-auth,Email Authentication Testing,"Magic link extraction, state preservation, caching, negative flows","email-authentication,security,workflow",knowledge/email-auth.md
-error-handling,Error Handling Checks,"Scoped exception handling, retry validation, telemetry logging","resilience,error-handling,stability",knowledge/error-handling.md
-visual-debugging,Visual Debugging Toolkit,"Trace viewer usage, artifact expectations, accessibility integration","debugging,dx,tooling",knowledge/visual-debugging.md
-risk-governance,Risk Governance,"Scoring matrix, category ownership, gate decision rules","risk,governance,gates",knowledge/risk-governance.md
-probability-impact,Probability and Impact Scale,"Shared definitions for scoring matrix and gate thresholds","risk,scoring,scale",knowledge/probability-impact.md
-test-quality,Test Quality Definition of Done,"Execution limits, isolation rules, green criteria","quality,definition-of-done,tests",knowledge/test-quality.md
-nfr-criteria,NFR Review Criteria,"Security, performance, reliability, maintainability status definitions","nfr,assessment,quality",knowledge/nfr-criteria.md
-test-levels,Test Levels Framework,"Guidelines for choosing unit, integration, or end-to-end coverage","testing,levels,selection",knowledge/test-levels-framework.md
-test-priorities,Test Priorities Matrix,"P0–P3 criteria, coverage targets, execution ordering","testing,prioritization,risk",knowledge/test-priorities-matrix.md
-test-healing-patterns,Test Healing Patterns,"Common failure patterns and automated fixes","healing,debugging,patterns",knowledge/test-healing-patterns.md
-selector-resilience,Selector Resilience,"Robust selector strategies and debugging techniques","selectors,locators,debugging",knowledge/selector-resilience.md
-timing-debugging,Timing Debugging,"Race condition identification and deterministic wait fixes","timing,async,debugging",knowledge/timing-debugging.md

package/.bmad/bmm/workflows/1-analysis/brainstorm-project/instructions.md

@@ -1,112 +0,0 @@
-# Brainstorm Project - Workflow Instructions
-
-```xml
-<critical>The workflow execution engine is governed by: {project_root}/.bmad/core/tasks/workflow.xml</critical>
-<critical>You MUST have already loaded and processed: {installed_path}/workflow.yaml</critical>
-<critical>Communicate all responses in {communication_language}</critical>
-<critical>This is a meta-workflow that orchestrates the CIS brainstorming workflow with project-specific context</critical>
-<critical>⚠️ ABSOLUTELY NO TIME ESTIMATES - NEVER mention hours, days, weeks, months, or ANY time-based predictions. AI has fundamentally changed development speed - what once took teams weeks/months can now be done by one person in hours. DO NOT give ANY time estimates whatsoever.</critical>
-<critical>⚠️ CHECKPOINT PROTOCOL: After EVERY <template-output> tag, you MUST follow workflow.xml substep 2c: SAVE content to file immediately → SHOW checkpoint separator (━━━━━━━━━━━━━━━━━━━━━━━) → DISPLAY generated content → PRESENT options [a]Advanced Elicitation/[c]Continue/[p]Party-Mode/[y]YOLO → WAIT for user response. Never batch saves or skip checkpoints.</critical>
-
-<workflow>
-
-  <step n="1" goal="Validate workflow readiness" tag="workflow-status">
-    <action>Check if {output_folder}/bmm-workflow-status.yaml exists</action>
-
-    <check if="status file not found">
-      <output>No workflow status file found. Brainstorming is optional - you can continue without status tracking.</output>
-      <action>Set standalone_mode = true</action>
-    </check>
-
-    <check if="status file found">
-      <action>Load the FULL file: {output_folder}/bmm-workflow-status.yaml</action>
-      <action>Parse workflow_status section</action>
-      <action>Check status of "brainstorm-project" workflow</action>
-      <action>Get project_level from YAML metadata</action>
-      <action>Find first non-completed workflow (next expected workflow)</action>
-
-      <check if="brainstorm-project status is file path (already completed)">
-        <output>⚠️ Brainstorming session already completed: {{brainstorm-project status}}</output>
-        <ask>Re-running will create a new session. Continue? (y/n)</ask>
-        <check if="n">
-          <output>Exiting. Use workflow-status to see your next step.</output>
-          <action>Exit workflow</action>
-        </check>
-      </check>
-
-      <check if="brainstorm-project is not the next expected workflow (anything after brainstorm-project is completed already)">
-        <output>⚠️ Next expected workflow: {{next_workflow}}. Brainstorming is out of sequence.</output>
-        <ask>Continue with brainstorming anyway? (y/n)</ask>
-        <check if="n">
-          <output>Exiting. Run {{next_workflow}} instead.</output>
-          <action>Exit workflow</action>
-        </check>
-      </check>
-
-      <action>Set standalone_mode = false</action>
-    </check>
-  </step>
-
-  <step n="2" goal="Load project brainstorming context">
-    <action>Read the project context document from: {project_context}</action>
-    <action>This context provides project-specific guidance including:
-      - Focus areas for project ideation
-      - Key considerations for software/product projects
-      - Recommended techniques for project brainstorming
-      - Output structure guidance
-    </action>
-  </step>
-
-  <step n="3" goal="Invoke core brainstorming with project context">
-    <action>Execute the CIS brainstorming workflow with project context</action>
-    <invoke-workflow path="{core_brainstorming}" data="{project_context}">
-      The CIS brainstorming workflow will:
-      - Present interactive brainstorming techniques menu
-      - Guide the user through selected ideation methods
-      - Generate and capture brainstorming session results
-      - Save output to: {output_folder}/brainstorming-session-results-{{date}}.md
-    </invoke-workflow>
-  </step>
-
-  <step n="4" goal="Update status and complete" tag="workflow-status">
-    <check if="standalone_mode != true">
-      <action>Load the FULL file: {output_folder}/bmm-workflow-status.yaml</action>
-      <action>Find workflow_status key "brainstorm-project"</action>
-      <critical>ONLY write the file path as the status value - no other text, notes, or metadata</critical>
-      <action>Update workflow_status["brainstorm-project"] = "{output_folder}/bmm-brainstorming-session-{{date}}.md"</action>
-      <action>Save file, preserving ALL comments and structure including STATUS DEFINITIONS</action>
-
-      <action>Find first non-completed workflow in workflow_status (next workflow to do)</action>
-      <action>Determine next agent from path file based on next workflow</action>
-    </check>
-
-    <output>**✅ Brainstorming Session Complete, {user_name}!**
-
-**Session Results:**
-
-- Brainstorming results saved to: {output_folder}/bmm-brainstorming-session-{{date}}.md
-
-{{#if standalone_mode != true}}
-**Status Updated:**
-
-- Progress tracking updated
-
-**Next Steps:**
-
-- **Next required:** {{next_workflow}} ({{next_agent}} agent)
-- **Optional:** You can run other analysis workflows (research, product-brief) before proceeding
-
-Check status anytime with: `workflow-status`
-{{else}}
-**Next Steps:**
-
-Since no workflow is in progress:
-
-- Refer to the BMM workflow guide if unsure what to do next
-- Or run `workflow-init` to create a workflow path and get guided next steps
-{{/if}}
-    </output>
-  </step>
-
-</workflow>
-```

package/.bmad/bmm/workflows/1-analysis/brainstorm-project/project-context.md

@@ -1,25 +0,0 @@
-# Project Brainstorming Context
-
-This context guide provides project-specific considerations for brainstorming sessions focused on software and product development.
-
-## Session Focus Areas
-
-When brainstorming for projects, consider exploring:
-
-- **User Problems and Pain Points** - What challenges do users face?
-- **Feature Ideas and Capabilities** - What could the product do?
-- **Technical Approaches** - How might we build it?
-- **User Experience** - How will users interact with it?
-- **Business Model and Value** - How does it create value?
-- **Market Differentiation** - What makes it unique?
-- **Technical Risks and Challenges** - What could go wrong?
-- **Success Metrics** - How will we measure success?
-
-## Integration with Project Workflow
-
-Brainstorming sessions typically feed into:
-
-- **Product Briefs** - Initial product vision and strategy
-- **PRDs** - Detailed requirements documents
-- **Technical Specifications** - Architecture and implementation plans
-- **Research Activities** - Areas requiring further investigation