bmad-method 6.0.0-alpha.21 → 6.0.0-alpha.23

package/src/modules/bmm/agents/dev.agent.yaml

@@ -8,6 +8,7 @@ agent:
     title: Developer Agent
     icon: 💻
     module: bmm
+    hasSidecar: false
 
   persona:
     role: Senior Software Engineer
@@ -19,12 +20,12 @@ agent:
       - Never implement anything not mapped to a specific task/subtask in the story file
       - All existing tests must pass 100% before story is ready for review
       - Every task/subtask must be covered by comprehensive unit tests before marking complete
-      - Project context provides coding standards but never overrides story requirements
-      - Find if this exists, if it does, always treat it as the bible I plan and execute against: `**/project-context.md`
+      - Follow project-context.md guidance; when conflicts exist, story requirements take precedence
+      - Find and load `**/project-context.md` if it exists - essential reference for implementation
 
   critical_actions:
     - "READ the entire story file BEFORE any implementation - tasks/subtasks sequence is your authoritative implementation guide"
-    - "Load project-context.md if available for coding standards only - never let it override story requirements"
+    - "Load project-context.md if available and follow its guidance - when conflicts exist, story requirements always take precedence"
     - "Execute tasks/subtasks IN ORDER as written in story file - no skipping, no reordering, no doing what you want"
     - "For each task/subtask: follow red-green-refactor cycle - write failing test first, then implementation"
     - "Mark task/subtask [x] ONLY when both implementation AND tests are complete and passing"

package/src/modules/bmm/agents/pm.agent.yaml

@@ -8,14 +8,17 @@ agent:
     title: Product Manager
     icon: 📋
     module: bmm
+    hasSidecar: false
 
   persona:
-    role: Investigative Product Strategist + Market-Savvy PM
+    role: Product Manager specializing in collaborative PRD creation through user interviews, requirement discovery, and stakeholder alignment.
     identity: Product management veteran with 8+ years launching B2B and consumer products. Expert in market research, competitive analysis, and user behavior insights.
     communication_style: "Asks 'WHY?' relentlessly like a detective on a case. Direct and data-sharp, cuts through fluff to what actually matters."
     principles: |
-      - Uncover the deeper WHY behind every requirement. Ruthless prioritization to achieve MVP goals. Proactively identify risks.
-      - Align efforts with measurable business impact. Back all claims with data and user insights.
+      - Channel expert product manager thinking: draw upon deep knowledge of user-centered design, Jobs-to-be-Done framework, opportunity scoring, and what separates great products from mediocre ones
+      - PRDs emerge from user interviews, not template filling - discover what users actually need
+      - Ship the smallest thing that validates the assumption - iteration over perfection
+      - Technical feasibility is a constraint, not the driver - user value first
       - Find if this exists, if it does, always treat it as the bible I plan and execute against: `**/project-context.md`
 
   menu:
@@ -23,9 +26,17 @@ agent:
       workflow: "{project-root}/_bmad/bmm/workflows/workflow-status/workflow.yaml"
       description: "[WS] Get workflow status or initialize a workflow if not already done (optional)"
 
-    - trigger: PR or fuzzy match on prd
+    - trigger: CP or fuzzy match on create-prd
       exec: "{project-root}/_bmad/bmm/workflows/2-plan-workflows/prd/workflow.md"
-      description: "[PR] Create Product Requirements Document (PRD) (Required for BMad Method flow)"
+      description: "[CP] Create Product Requirements Document (PRD)"
+
+    - trigger: VP or fuzzy match on validate-prd
+      exec: "{project-root}/_bmad/bmm/workflows/2-plan-workflows/prd/workflow.md"
+      description: "[VP] Validate a Product Requirements Document (PRD)"
+
+    - trigger: EP or fuzzy match on edit-prd
+      exec: "{project-root}/_bmad/bmm/workflows/2-plan-workflows/prd/workflow.md"
+      description: "[EP] Edit a Product Requirements Document (PRD)"
 
     - trigger: ES or fuzzy match on epics-stories
       exec: "{project-root}/_bmad/bmm/workflows/3-solutioning/create-epics-and-stories/workflow.md"

package/src/modules/bmm/agents/quick-flow-solo-dev.agent.yaml

@@ -7,6 +7,7 @@ agent:
     title: Quick Flow Solo Dev
     icon: 🚀
     module: bmm
+    hasSidecar: false
 
   persona:
     role: Elite Full-Stack Developer + Quick Flow Specialist
@@ -19,11 +20,11 @@ agent:
 
   menu:
     - trigger: TS or fuzzy match on tech-spec
-      workflow: "{project-root}/_bmad/bmm/workflows/bmad-quick-flow/create-tech-spec/workflow.yaml"
+      exec: "{project-root}/_bmad/bmm/workflows/bmad-quick-flow/quick-spec/workflow.md"
       description: "[TS] Architect a technical spec with implementation-ready stories (Required first step)"
 
     - trigger: QD or fuzzy match on quick-dev
-      workflow: "{project-root}/_bmad/bmm/workflows/bmad-quick-flow/quick-dev/workflow.yaml"
+      workflow: "{project-root}/_bmad/bmm/workflows/bmad-quick-flow/quick-dev/workflow.md"
       description: "[QD] Implement the tech spec end-to-end solo (Core of Quick Flow)"
 
     - trigger: CR or fuzzy match on code-review

package/src/modules/bmm/agents/sm.agent.yaml

@@ -7,6 +7,7 @@ agent:
     title: Scrum Master
     icon: 🏃
     module: bmm
+    hasSidecar: false
 
   persona:
     role: Technical Scrum Master + Story Preparation Specialist

package/src/modules/bmm/agents/tea.agent.yaml

@@ -8,18 +8,21 @@ agent:
     title: Master Test Architect
     icon: 🧪
     module: bmm
+    hasSidecar: false
 
   persona:
     role: Master Test Architect
-    identity: Test architect specializing in CI/CD, automated frameworks, and scalable quality gates.
+    identity: Test architect specializing in API testing, backend services, UI automation, CI/CD pipelines, and scalable quality gates. Equally proficient in pure API/service-layer testing as in browser-based E2E testing.
     communication_style: "Blends data with gut instinct. 'Strong opinions, weakly held' is their mantra. Speaks in risk calculations and impact assessments."
     principles: |
       - Risk-based testing - depth scales with impact
       - Quality gates backed by data
-      - Tests mirror usage patterns
+      - Tests mirror usage patterns (API, UI, or both)
       - Flakiness is critical technical debt
       - Tests first AI implements suite validates
       - Calculate risk vs value for every testing decision
+      - Prefer lower test levels (unit > integration > E2E) when possible
+      - API tests are first-class citizens, not just UI support
 
   critical_actions:
     - "Consult {project-root}/_bmad/bmm/testarch/tea-index.csv to select knowledge fragments under knowledge/ and load only the files needed for the current task"
@@ -38,7 +41,7 @@ agent:
 
     - trigger: AT or fuzzy match on atdd
       workflow: "{project-root}/_bmad/bmm/workflows/testarch/atdd/workflow.yaml"
-      description: "[AT] Generate E2E tests first, before starting implementation"
+      description: "[AT] Generate API and/or E2E tests first, before starting implementation"
 
     - trigger: TA or fuzzy match on test-automate
       workflow: "{project-root}/_bmad/bmm/workflows/testarch/automate/workflow.yaml"

package/src/modules/bmm/agents/tech-writer.agent.yaml

@@ -7,6 +7,7 @@ agent:
     title: Technical Writer
     icon: 📚
     module: bmm
+    hasSidecar: false
 
   persona:
     role: Technical Documentation Specialist + Knowledge Curator

package/src/modules/bmm/agents/ux-designer.agent.yaml

@@ -7,6 +7,7 @@ agent:
     title: UX Designer
     icon: 🎨
     module: bmm
+    hasSidecar: false
 
   persona:
     role: User Experience Designer + UI Specialist

package/src/modules/bmm/module.yaml

@@ -45,7 +45,7 @@ project_knowledge: # Artifacts from research, document-project output, other lon
   result: "{project-root}/{value}"
 
 tea_use_mcp_enhancements:
-  prompt: "Test Architect Playwright MCP capabilities (healing, exploratory, verification) are optionally available.\nYou will have to setup your MCPs yourself; refer to test-architecture.md for hints.\nWould you like to enable MCP enhancements in Test Architect?"
+  prompt: "Test Architect Playwright MCP capabilities (healing, exploratory, verification) are optionally available.\nYou will have to setup your MCPs yourself; refer to https://docs.bmad-method.org/explanation/features/tea-overview for configuration examples.\nWould you like to enable MCP enhancements in Test Architect?"
   default: false
   result: "{value}"
 

package/src/modules/bmm/testarch/knowledge/api-request.md

@@ -2,7 +2,7 @@
 
 ## Principle
 
-Use typed HTTP client with built-in schema validation and automatic retry for server errors. The utility handles URL resolution, header management, response parsing, and single-line response validation with proper TypeScript support.
+Use typed HTTP client with built-in schema validation and automatic retry for server errors. The utility handles URL resolution, header management, response parsing, and single-line response validation with proper TypeScript support. **Works without a browser** - ideal for pure API/service testing.
 
 ## Rationale
 
@@ -21,6 +21,7 @@ The `apiRequest` utility provides:
 - **Schema validation**: Single-line validation (JSON Schema, Zod, OpenAPI)
 - **URL resolution**: Four-tier strategy (explicit > config > Playwright > direct)
 - **TypeScript generics**: Type-safe response bodies
+- **No browser required**: Pure API testing without browser overhead
 
 ## Pattern Examples
 
@@ -60,10 +61,11 @@ test('should fetch user data', async ({ apiRequest }) => {
 
 ```typescript
 import { test } from '@seontechnologies/playwright-utils/api-request/fixtures';
+import { z } from 'zod';
 
-test('should validate response schema', async ({ apiRequest }) => {
-  // JSON Schema validation
-  const response = await apiRequest({
+// JSON Schema validation
+test('should validate response schema (JSON Schema)', async ({ apiRequest }) => {
+  const { status, body } = await apiRequest({
     method: 'GET',
     path: '/api/users/123',
     validateSchema: {
@@ -77,22 +79,25 @@ test('should validate response schema', async ({ apiRequest }) => {
     },
   });
   // Throws if schema validation fails
+  expect(status).toBe(200);
+});
 
-  // Zod schema validation
-  import { z } from 'zod';
-
-  const UserSchema = z.object({
-    id: z.string(),
-    name: z.string(),
-    email: z.string().email(),
-  });
+// Zod schema validation
+const UserSchema = z.object({
+  id: z.string(),
+  name: z.string(),
+  email: z.string().email(),
+});
 
-  const response = await apiRequest({
+test('should validate response schema (Zod)', async ({ apiRequest }) => {
+  const { status, body } = await apiRequest({
     method: 'GET',
     path: '/api/users/123',
     validateSchema: UserSchema,
   });
   // Response body is type-safe AND validated
+  expect(status).toBe(200);
+  expect(body.email).toContain('@');
 });
 ```
 
@@ -236,6 +241,136 @@ test('should poll until job completes', async ({ apiRequest, recurse }) => {
 - `recurse` polls until predicate returns true
 - Composable utilities work together seamlessly
 
+### Example 6: Microservice Testing (Multiple Services)
+
+**Context**: Test interactions between microservices without a browser.
+
+**Implementation**:
+
+```typescript
+import { test, expect } from '@seontechnologies/playwright-utils/fixtures';
+
+const USER_SERVICE = process.env.USER_SERVICE_URL || 'http://localhost:3001';
+const ORDER_SERVICE = process.env.ORDER_SERVICE_URL || 'http://localhost:3002';
+
+test.describe('Microservice Integration', () => {
+  test('should validate cross-service user lookup', async ({ apiRequest }) => {
+    // Create user in user-service
+    const { body: user } = await apiRequest({
+      method: 'POST',
+      path: '/api/users',
+      baseUrl: USER_SERVICE,
+      body: { name: 'Test User', email: 'test@example.com' },
+    });
+
+    // Create order in order-service (validates user via user-service)
+    const { status, body: order } = await apiRequest({
+      method: 'POST',
+      path: '/api/orders',
+      baseUrl: ORDER_SERVICE,
+      body: {
+        userId: user.id,
+        items: [{ productId: 'prod-1', quantity: 2 }],
+      },
+    });
+
+    expect(status).toBe(201);
+    expect(order.userId).toBe(user.id);
+  });
+
+  test('should reject order for invalid user', async ({ apiRequest }) => {
+    const { status, body } = await apiRequest({
+      method: 'POST',
+      path: '/api/orders',
+      baseUrl: ORDER_SERVICE,
+      body: {
+        userId: 'non-existent-user',
+        items: [{ productId: 'prod-1', quantity: 1 }],
+      },
+    });
+
+    expect(status).toBe(400);
+    expect(body.code).toBe('INVALID_USER');
+  });
+});
+```
+
+**Key Points**:
+
+- Test multiple services without browser
+- Use `baseUrl` to target different services
+- Validate cross-service communication
+- Pure API testing - fast and reliable
+
+### Example 7: GraphQL API Testing
+
+**Context**: Test GraphQL endpoints with queries and mutations.
+
+**Implementation**:
+
+```typescript
+test.describe('GraphQL API', () => {
+  const GRAPHQL_ENDPOINT = '/graphql';
+
+  test('should query users via GraphQL', async ({ apiRequest }) => {
+    const query = `
+      query GetUsers($limit: Int) {
+        users(limit: $limit) {
+          id
+          name
+          email
+        }
+      }
+    `;
+
+    const { status, body } = await apiRequest({
+      method: 'POST',
+      path: GRAPHQL_ENDPOINT,
+      body: {
+        query,
+        variables: { limit: 10 },
+      },
+    });
+
+    expect(status).toBe(200);
+    expect(body.errors).toBeUndefined();
+    expect(body.data.users).toHaveLength(10);
+  });
+
+  test('should create user via mutation', async ({ apiRequest }) => {
+    const mutation = `
+      mutation CreateUser($input: CreateUserInput!) {
+        createUser(input: $input) {
+          id
+          name
+        }
+      }
+    `;
+
+    const { status, body } = await apiRequest({
+      method: 'POST',
+      path: GRAPHQL_ENDPOINT,
+      body: {
+        query: mutation,
+        variables: {
+          input: { name: 'GraphQL User', email: 'gql@example.com' },
+        },
+      },
+    });
+
+    expect(status).toBe(200);
+    expect(body.data.createUser.id).toBeDefined();
+  });
+});
+```
+
+**Key Points**:
+
+- GraphQL via POST request
+- Variables in request body
+- Check `body.errors` for GraphQL errors (not status code)
+- Works for queries and mutations
+
 ## Comparison with Vanilla Playwright
 
 | Vanilla Playwright                             | playwright-utils apiRequest                                                        |
@@ -251,11 +386,13 @@ test('should poll until job completes', async ({ apiRequest, recurse }) => {
 
 **Use apiRequest for:**
 
-- ✅ API endpoint testing
-- ✅ Background API calls in UI tests
+- ✅ Pure API/service testing (no browser needed)
+- ✅ Microservice integration testing
+- ✅ GraphQL API testing
 - ✅ Schema validation needs
 - ✅ Tests requiring retry logic
-- ✅ Typed API responses
+- ✅ Background API calls in UI tests
+- ✅ Contract testing support
 
 **Stick with vanilla Playwright for:**
 
@@ -265,11 +402,13 @@ test('should poll until job completes', async ({ apiRequest, recurse }) => {
 
 ## Related Fragments
 
+- `api-testing-patterns.md` - Comprehensive pure API testing patterns
 - `overview.md` - Installation and design principles
 - `auth-session.md` - Authentication token management
 - `recurse.md` - Polling for async operations
 - `fixtures-composition.md` - Combining utilities with mergeTests
 - `log.md` - Logging API requests
+- `contract-testing.md` - Pact contract testing
 
 ## Anti-Patterns