shipquick 1.0.0 → 2.0.0

package/content/_bmad/tea/testarch/knowledge/overview.md

@@ -0,0 +1,286 @@
+# Playwright Utils Overview
+
+## Principle
+
+Use production-ready, fixture-based utilities from `@seontechnologies/playwright-utils` for common Playwright testing patterns. Build test helpers as pure functions first, then wrap in framework-specific fixtures for composability and reuse. **Works equally well for pure API testing (no browser) and UI testing.**
+
+## Rationale
+
+Writing Playwright utilities from scratch for every project leads to:
+
+- Duplicated code across test suites
+- Inconsistent patterns and quality
+- Maintenance burden when Playwright APIs change
+- Missing advanced features (schema validation, HAR recording, auth persistence)
+
+`@seontechnologies/playwright-utils` provides:
+
+- **Production-tested utilities**: Used at SEON Technologies in production
+- **Functional-first design**: Core logic as pure functions, fixtures for convenience
+- **Composable fixtures**: Use `mergeTests` to combine utilities
+- **TypeScript support**: Full type safety with generic types
+- **Comprehensive coverage**: API requests, auth, network, logging, file handling, burn-in
+- **Backend-first mentality**: Most utilities work without a browser - pure API/service testing is a first-class use case
+
+## Installation
+
+```bash
+npm install -D @seontechnologies/playwright-utils
+```
+
+**Peer Dependencies:**
+
+- `@playwright/test` >= 1.54.1 (required)
+- `ajv` >= 8.0.0 (optional - for JSON Schema validation)
+- `zod` >= 3.0.0 (optional - for Zod schema validation)
+
+## Available Utilities
+
+### Core Testing Utilities
+
+| Utility                    | Purpose                                            | Test Context       |
+| -------------------------- | -------------------------------------------------- | ------------------ |
+| **api-request**            | Typed HTTP client with schema validation and retry | **API/Backend**    |
+| **recurse**                | Polling for async operations, background jobs      | **API/Backend**    |
+| **auth-session**           | Token persistence, multi-user, service-to-service  | **API/Backend/UI** |
+| **log**                    | Playwright report-integrated logging               | **API/Backend/UI** |
+| **file-utils**             | CSV/XLSX/PDF/ZIP reading & validation              | **API/Backend/UI** |
+| **burn-in**                | Smart test selection with git diff                 | **CI/CD**          |
+| **network-recorder**       | HAR record/playback for offline testing            | UI only            |
+| **intercept-network-call** | Network spy/stub with auto JSON parsing            | UI only            |
+| **network-error-monitor**  | Automatic HTTP 4xx/5xx detection                   | UI only            |
+
+**Note**: 6 of 9 utilities work without a browser. Only 3 are UI-specific (network-recorder, intercept-network-call, network-error-monitor).
+
+## Design Patterns
+
+### Pattern 1: Functional Core, Fixture Shell
+
+**Context**: All utilities follow the same architectural pattern - pure function as core, fixture as wrapper.
+
+**Implementation**:
+
+```typescript
+// Direct import (pass Playwright context explicitly)
+import { apiRequest } from '@seontechnologies/playwright-utils';
+
+test('direct usage', async ({ request }) => {
+  const { status, body } = await apiRequest({
+    request, // Must pass request context
+    method: 'GET',
+    path: '/api/users',
+  });
+});
+
+// Fixture import (context injected automatically)
+import { test } from '@seontechnologies/playwright-utils/fixtures';
+
+test('fixture usage', async ({ apiRequest }) => {
+  const { status, body } = await apiRequest({
+    // No need to pass request context
+    method: 'GET',
+    path: '/api/users',
+  });
+});
+```
+
+**Key Points**:
+
+- Pure functions testable without Playwright running
+- Fixtures inject framework dependencies automatically
+- Choose direct import (more control) or fixture (convenience)
+
+### Pattern 2: Subpath Imports for Tree-Shaking
+
+**Context**: Import only what you need to keep bundle sizes small.
+
+**Implementation**:
+
+```typescript
+// Import specific utility
+import { apiRequest } from '@seontechnologies/playwright-utils/api-request';
+
+// Import specific fixture
+import { test } from '@seontechnologies/playwright-utils/api-request/fixtures';
+
+// Import everything (use sparingly)
+import { apiRequest, recurse, log } from '@seontechnologies/playwright-utils';
+```
+
+**Key Points**:
+
+- Subpath imports enable tree-shaking
+- Keep bundle sizes minimal
+- Import from specific paths for production builds
+
+### Pattern 3: Fixture Composition with mergeTests
+
+**Context**: Combine multiple playwright-utils fixtures with your own custom fixtures.
+
+**Implementation**:
+
+```typescript
+// playwright/support/merged-fixtures.ts
+import { mergeTests } from '@playwright/test';
+import { test as apiRequestFixture } from '@seontechnologies/playwright-utils/api-request/fixtures';
+import { test as authFixture } from '@seontechnologies/playwright-utils/auth-session/fixtures';
+import { test as recurseFixture } from '@seontechnologies/playwright-utils/recurse/fixtures';
+import { test as logFixture } from '@seontechnologies/playwright-utils/log/fixtures';
+
+// Merge all fixtures into one test object
+export const test = mergeTests(apiRequestFixture, authFixture, recurseFixture, logFixture);
+
+export { expect } from '@playwright/test';
+```
+
+```typescript
+// In your tests
+import { test, expect } from '../support/merged-fixtures';
+
+test('all utilities available', async ({ apiRequest, authToken, recurse, log }) => {
+  await log.step('Making authenticated API request');
+
+  const { body } = await apiRequest({
+    method: 'GET',
+    path: '/api/protected',
+    headers: { Authorization: `Bearer ${authToken}` },
+  });
+
+  await recurse(
+    () => apiRequest({ method: 'GET', path: `/status/${body.id}` }),
+    (res) => res.body.ready === true,
+  );
+});
+```
+
+**Key Points**:
+
+- `mergeTests` combines multiple fixtures without conflicts
+- Create one merged-fixtures.ts file per project
+- Import test object from your merged fixtures in all tests
+- All utilities available in single test signature
+
+## Integration with Existing Tests
+
+### Gradual Adoption Strategy
+
+**1. Start with logging** (zero breaking changes):
+
+```typescript
+import { log } from '@seontechnologies/playwright-utils';
+
+test('existing test', async ({ page }) => {
+  await log.step('Navigate to page'); // Just add logging
+  await page.goto('/dashboard');
+  // Rest of test unchanged
+});
+```
+
+**2. Add API utilities** (for API tests):
+
+```typescript
+import { test } from '@seontechnologies/playwright-utils/api-request/fixtures';
+
+test('API test', async ({ apiRequest }) => {
+  const { status, body } = await apiRequest({
+    method: 'GET',
+    path: '/api/users',
+  });
+
+  expect(status).toBe(200);
+});
+```
+
+**3. Expand to network utilities** (for UI tests):
+
+```typescript
+import { test } from '@seontechnologies/playwright-utils/fixtures';
+
+test('UI with network control', async ({ page, interceptNetworkCall }) => {
+  const usersCall = interceptNetworkCall({
+    url: '**/api/users',
+  });
+
+  await page.goto('/dashboard');
+  const { responseJson } = await usersCall;
+
+  expect(responseJson).toHaveLength(10);
+});
+```
+
+**4. Full integration** (merged fixtures):
+
+Create merged-fixtures.ts and use across all tests.
+
+## Related Fragments
+
+- `api-request.md` - HTTP client with schema validation
+- `network-recorder.md` - HAR-based offline testing
+- `auth-session.md` - Token management
+- `intercept-network-call.md` - Network interception
+- `recurse.md` - Polling patterns
+- `log.md` - Logging utility
+- `file-utils.md` - File operations
+- `fixtures-composition.md` - Advanced mergeTests patterns
+
+## Anti-Patterns
+
+**❌ Don't mix direct and fixture imports in same test:**
+
+```typescript
+import { apiRequest } from '@seontechnologies/playwright-utils';
+import { test } from '@seontechnologies/playwright-utils/auth-session/fixtures';
+
+test('bad', async ({ request, authToken }) => {
+  // Confusing - mixing direct (needs request) and fixture (has authToken)
+  await apiRequest({ request, method: 'GET', path: '/api/users' });
+});
+```
+
+**✅ Use consistent import style:**
+
+```typescript
+import { test } from '../support/merged-fixtures';
+
+test('good', async ({ apiRequest, authToken }) => {
+  // Clean - all from fixtures
+  await apiRequest({ method: 'GET', path: '/api/users' });
+});
+```
+
+**❌ Don't import everything when you need one utility:**
+
+```typescript
+import * as utils from '@seontechnologies/playwright-utils'; // Large bundle
+```
+
+**✅ Use subpath imports:**
+
+```typescript
+import { apiRequest } from '@seontechnologies/playwright-utils/api-request'; // Small bundle
+```
+
+## Reference Implementation
+
+The official `@seontechnologies/playwright-utils` repository provides working examples of all patterns described in these fragments.
+
+**Repository:** <https://github.com/seontechnologies/playwright-utils>
+
+**Key resources:**
+
+- **Test examples:** `playwright/tests` - All utilities in action
+- **Framework setup:** `playwright.config.ts`, `playwright/support/merged-fixtures.ts`
+- **CI patterns:** `.github/workflows/` - GitHub Actions with sharding, parallelization
+
+**Quick start:**
+
+```bash
+git clone https://github.com/seontechnologies/playwright-utils.git
+cd playwright-utils
+nvm use
+npm install
+npm run test:pw-ui  # Explore tests with Playwright UI
+npm run test:pw
+```
+
+All patterns in TEA fragments are production-tested in this repository.

package/content/_bmad/tea/testarch/knowledge/playwright-cli.md

@@ -0,0 +1,165 @@
+# Playwright CLI — Browser Automation for Coding Agents
+
+## Principle
+
+When an AI agent needs to look at a webpage — take a snapshot, grab selectors, capture a screenshot — it shouldn't have to load thousands of tokens of DOM trees and tool schemas into its context window just to do that. Playwright CLI gives the agent a lightweight way to talk to a browser through simple shell commands, keeping the context window free for reasoning and code generation.
+
+## Rationale
+
+Playwright MCP is powerful, but it's heavy. Every interaction loads full accessibility trees and tool definitions into the LLM context. That's fine for complex, stateful flows where you need rich introspection. But for the common case — "open this page, tell me what's on it, take a screenshot" — it's overkill.
+
+Playwright CLI solves this by returning concise **element references** (`e15`, `e21`) instead of full DOM dumps. The result: ~93% fewer tokens per interaction, which means the agent can run longer sessions, reason more deeply, and still have context left for your actual code.
+
+**The trade-off is simple:**
+
+- **CLI** = fast, lightweight, stateless — great for quick looks at pages
+- **MCP** = rich, stateful, full-featured — great for complex multi-step automation
+
+TEA uses both where each shines (see `tea_browser_automation: "auto"`).
+
+## Prerequisites
+
+```bash
+npm install -g @playwright/cli@latest    # Install globally (Node.js 18+)
+playwright-cli install --skills          # Register as an agent skill
+```
+
+This is a one-time setup, like configuring MCP servers. TEA documents it during installation but does not run it for you.
+
+## How It Works
+
+The agent interacts with the browser through shell commands. Each command is a single, focused action:
+
+```bash
+# 1. Open a page
+playwright-cli -s=tea-explore open https://app.com/login
+
+# 2. Take a snapshot — returns element references, not DOM trees
+playwright-cli -s=tea-explore snapshot
+# Output: [{ref: "e15", role: "textbox", name: "Email"},
+#          {ref: "e21", role: "textbox", name: "Password"},
+#          {ref: "e33", role: "button", name: "Sign In"}]
+
+# 3. Interact using those references
+playwright-cli -s=tea-explore fill e15 "user@example.com"
+playwright-cli -s=tea-explore fill e21 "password123"
+playwright-cli -s=tea-explore click e33
+
+# 4. Capture evidence
+playwright-cli -s=tea-explore screenshot --filename=login-flow.png
+
+# 5. Clean up
+playwright-cli -s=tea-explore close
+```
+
+The `-s=tea-explore` flag scopes everything to a named session, preventing state leakage between workflows.
+
+## What TEA Uses It For
+
+**Selector verification** — Before generating test code, TEA can snapshot a page to see the actual labels, roles, and names of elements. Instead of guessing that a button says "Login", it knows it says "Sign In":
+
+```
+snapshot ref {role: "button", name: "Sign In"}
+  → generates: page.getByRole('button', { name: 'Sign In' })
+```
+
+**Page discovery** — During `test-design` exploratory mode, TEA snapshots pages to understand what's actually there, rather than relying only on documentation.
+
+**Evidence collection** — During `test-review`, TEA can capture screenshots, traces, and network logs as evidence without the overhead of a full MCP session.
+
+## How CLI Relates to Playwright Utils and API Testing
+
+CLI and playwright-utils are **complementary tools that work at different layers**:
+
+|              | Playwright CLI                               | Playwright Utils                                 |
+| ------------ | -------------------------------------------- | ------------------------------------------------ |
+| **When**     | During test _generation_ (the agent uses it) | During test _execution_ (your test code uses it) |
+| **What**     | Shell commands to observe your app           | Fixtures and helpers imported in test files      |
+| **Examples** | `snapshot`, `screenshot`, `network`          | `apiRequest`, `auth-session`, `network-recorder` |
+
+They work together naturally. The agent uses CLI to _understand_ your app, then generates test code that _imports_ playwright-utils:
+
+```bash
+# Agent uses CLI to observe network traffic on the dashboard page
+playwright-cli -s=tea-discover open https://app.com/dashboard
+playwright-cli -s=tea-discover network
+# Output: GET /api/users → 200, POST /api/audit → 201, GET /api/settings → 200
+playwright-cli -s=tea-discover close
+```
+
+```typescript
+// Agent generates API tests using what it discovered, with playwright-utils
+import { test } from '@seontechnologies/playwright-utils/api-request/fixtures';
+
+test('GET /api/users returns user list', async ({ apiRequest }) => {
+  const { status, body } = await apiRequest<User[]>({
+    method: 'GET',
+    path: '/api/users',
+  });
+  expect(status).toBe(200);
+  expect(body.length).toBeGreaterThan(0);
+});
+```
+
+**For pure API testing** (no UI involved), CLI doesn't add much — there's no page to snapshot. The agent generates API tests directly from documentation, specs, or code analysis using `apiRequest` and `recurse` from playwright-utils.
+
+**For E2E testing**, CLI shines — it snapshots the page to get accurate selectors, observes network calls to understand the API contract, and captures auth flows via `state-save` that inform how tests use `auth-session`.
+
+**Bottom line:** CLI helps the agent _write better tests_. Playwright-utils helps those tests _run reliably_.
+
+## Session Isolation
+
+Every CLI command targets a named session. This prevents workflows from interfering with each other:
+
+```bash
+# Workflow A uses one session
+playwright-cli -s=tea-explore open https://app.com
+
+# Workflow B uses a different session (can run in parallel)
+playwright-cli -s=tea-verify open https://app.com/admin
+```
+
+For parallel safety (multiple agents on the same machine), append a unique suffix:
+
+```bash
+playwright-cli -s=tea-explore-<timestamp> open https://app.com
+```
+
+## Command Quick Reference
+
+| What you want to do       | Command                                          |
+| ------------------------- | ------------------------------------------------ |
+| Open a page               | `open <url>`                                     |
+| See what's on the page    | `snapshot`                                       |
+| Take a screenshot         | `screenshot [--filename=path]`                   |
+| Click something           | `click <ref>`                                    |
+| Type into a field         | `fill <ref> <text>`                              |
+| Navigate                  | `goto <url>`, `go-back`, `reload`                |
+| Mock a network request    | `route <pattern> --status=200 --body='...'`      |
+| Start recording a trace   | `tracing-start`                                  |
+| Stop and save the trace   | `tracing-stop`                                   |
+| Save auth state for reuse | `state-save auth.json`                           |
+| Load saved auth state     | `state-load auth.json`                           |
+| See network requests      | `network`                                        |
+| Manage tabs               | `tab-list`, `tab-new`, `tab-close`, `tab-select` |
+| Close the session         | `close`                                          |
+
+## When CLI vs MCP (Auto Mode Decision)
+
+| Situation                             | Tool | Why                                |
+| ------------------------------------- | ---- | ---------------------------------- |
+| "What's on this page?"                | CLI  | One-shot snapshot, no state needed |
+| "Verify this selector exists"         | CLI  | Single check, minimal tokens       |
+| "Capture a screenshot for evidence"   | CLI  | Stateless capture                  |
+| "Walk through a multi-step wizard"    | MCP  | State carries across steps         |
+| "Debug why this test fails" (healing) | MCP  | Needs rich DOM introspection       |
+| "Record a drag-and-drop flow"         | MCP  | Complex interaction semantics      |
+
+## Related Fragments
+
+- `overview.md` — Playwright Utils installation and fixture patterns (the test code layer that CLI complements)
+- `api-request.md` — Typed HTTP client for API tests (CLI discovers endpoints, apiRequest tests them)
+- `api-testing-patterns.md` — Pure API test patterns (when CLI isn't needed)
+- `auth-session.md` — Token management (CLI `state-save` informs auth-session usage)
+- `selector-resilience.md` — Robust selector strategies (CLI verifies them against real DOM)
+- `visual-debugging.md` — Trace viewer usage (CLI captures traces)