@brunosps00/dev-workflow 0.11.0 → 0.15.0

package/scaffold/skills/dw-testing-discipline/references/flaky-discipline.md

@@ -0,0 +1,163 @@
+# Flaky discipline — taxonomy, quarantine, SLOs
+
+A flaky test is one that produces different verdicts (pass/fail) on the same code across runs. They corrode trust in the suite faster than any other category of test debt.
+
+## The four root causes (in order of frequency)
+
+### Cause 1: Race conditions (concurrency)
+
+**Tells:**
+- Test passes locally, fails in CI (or vice versa).
+- Failure rate correlates with CI machine load.
+- Adding `await page.waitForTimeout(100)` "fixes" it.
+
+**Common scenarios:**
+- Async operation completes after test moves on (missing `await`).
+- Two requests sent simultaneously, response order matters.
+- DOM update happens after assertion runs.
+- Database write not yet committed when read fires.
+
+**Fix:**
+- Replace wall-clock waits with condition-based waits (`waitFor`, `toBeVisible`, `expect.poll`).
+- Add proper `await` on every async operation.
+- Use transaction boundaries explicitly when test reads its own write.
+
+### Cause 2: Test order dependency
+
+**Tells:**
+- Test passes when suite runs in order, fails with `--shuffle`.
+- Test fails when run with `.only` in isolation.
+- Failures cluster on first run after CI restart but not afterwards.
+
+**Common scenarios:**
+- `beforeAll` populates shared state; second test mutates it; third test fails.
+- Test A creates a global mock; Test B inherits it unexpectedly.
+- Database row persists across tests because cleanup is in `afterEach` but a test threw mid-execution.
+
+**Fix:**
+- Move state creation from `beforeAll` to `beforeEach`.
+- Reset shared state in `beforeEach` (clean slate every test).
+- Avoid global mocks; scope mocks to the test that needs them.
+- Run with `--shuffle` in CI to catch new order dependencies.
+
+### Cause 3: Non-deterministic inputs
+
+**Tells:**
+- Test fails at month boundary, year boundary, DST change.
+- Test fails based on hostname, locale, timezone.
+- Test fails when a flaky RNG produces edge values.
+
+**Common scenarios:**
+- `new Date()` in production code, tested without clock fake.
+- `Math.random()` for IDs, tested without seed.
+- `Intl.DateTimeFormat` rendering based on system locale.
+- File paths with timestamps, hash IDs based on time.
+
+**Fix:**
+- Mock the clock (`vi.useFakeTimers`, `freezegun`).
+- Seed RNG explicitly in tests (`Math.random = () => 0.5` or via DI).
+- Pin locale and timezone in CI environment AND in test setup.
+
+### Cause 4: External dependencies
+
+**Tells:**
+- Test fails when a third-party service has an outage.
+- Test fails when CI runs against a real API and hits rate limits.
+- Test fails differently for different geographic CI runners.
+
+**Common scenarios:**
+- Direct call to external API in unit tests.
+- DNS lookup baked into test execution path.
+- CDN-hosted resources in E2E tests.
+
+**Fix:**
+- Mock external services at unit/integration layers.
+- Use contract tests instead of live calls.
+- For E2E, use a sandbox account / dedicated test environment.
+
+## Quarantine workflow
+
+When a test flakes:
+
+### Within 1 hour of detection
+
+1. **Quarantine the test.** Add `.skip` or equivalent. Add a comment:
+
+   ```javascript
+   test.skip('FLAKY-2026-05-12: race condition in checkout flow — owner: bruno, fix-by: 2026-05-19', () => {
+     // ...
+   });
+   ```
+
+2. **File a tracking issue.** Title: `FLAKY: <test name>`. Body includes:
+   - Test name and file
+   - Failure mode observed (race? order-dependency? non-determinism?)
+   - First detection: CI run URL, timestamp
+   - Hypothesis (if any)
+   - Owner and fix-by date
+
+3. **Note in CI.** The next CI run shows "1 quarantined" — make this visible on the dashboard.
+
+### Within 24 hours
+
+1. **Named owner assigned.** Not "team X" — a person.
+2. **Fix-by date set.** Default 5 business days. Major flake (production-path test): 2 days.
+
+### When fix-by passes without fix
+
+Escalate:
+- Pair the owner with someone for a debug session.
+- If still unfixed after 2× the fix-by window, the test is removed (not skipped). A failing un-skipped test is better than a perpetually skipped test.
+
+## SLOs
+
+### `flaky_rate` (first-class metric)
+
+- Definition: `(tests that pass on retry but fail on first run) / (total test runs)`.
+- Target: < 1–2% per week.
+- Alert at: > 5% on any given day.
+
+### `time-to-fix-flaky`
+
+- Definition: hours from quarantine to fix-merged.
+- Target: median < 24 hours; p95 < 7 days.
+
+### `quarantine inventory`
+
+- Definition: count of currently-skipped tests with `FLAKY-*` markers.
+- Target: < 10 at any time.
+- Alert at: > 25 (the quarantine has become a cemetery — emergency cleanup).
+
+## What NOT to do
+
+- **Auto-retry as fix.** `retries: 3` in CI config is hiding flakes, not fixing them. The 4th run that finally passes still validated nothing.
+- **Increase timeouts indefinitely.** A timeout that grows from 5s to 30s "to make CI pass" means the test isn't waiting on the right condition.
+- **Remove the test without investigation.** "It's been flaky forever, delete it" — sometimes correct, but make sure the underlying invariant is captured elsewhere.
+- **Mark skip without owner.** A skip is a debt. An unowned debt is a perpetual liability.
+
+## When a test should be permanently removed
+
+A flaky test should be DELETED (not just skipped) when:
+
+1. The invariant it tests is covered elsewhere (duplicate per A23).
+2. The invariant it tests is no longer a real requirement.
+3. The test was always probabilistic by design and never had value.
+
+Deletion is acceptable; abandonment-by-skip is not.
+
+## Real-systems-at-final-gate principle
+
+Many flakes come from mocks drifting from reality. The defense:
+
+- **Unit:** mock the world; fast feedback; flake budget tiny here.
+- **Integration:** real DB (testcontainers); mock external services with contract validation.
+- **Contract:** Pact / schemathesis verifying producer-consumer agreement.
+- **E2E:** real services in a preview environment; near-zero mocks.
+
+When CI is wired this way, a flake at unit usually = race or order-dependency (fixable). A flake at E2E usually = real environment issue (fix the environment, not the test).
+
+## Integration with dev-workflow
+
+- `/dw-fix-qa` uses this taxonomy when retest cycles produce inconsistent results: classify the flake, apply the right fix, document.
+- `/dw-code-review` flags tests being modified that have a `FLAKY-*` marker — review must verify the flake is now actually fixed, not just made less likely.
+- `/dw-run-qa` weekly summary includes the `flaky_rate` metric.

package/scaffold/skills/dw-testing-discipline/references/patterns.md

@@ -0,0 +1,241 @@
+# Twelve positive patterns — pseudo-code that survives refactors
+
+Each pattern survives across testing frameworks (Jest, Vitest, Playwright, Cypress, pytest, JUnit). Pseudo-code in JavaScript-flavored examples; translate to your stack.
+
+## 1. Query by behavior and accessible role, not CSS selectors
+
+**Pattern:**
+
+```javascript
+// GOOD — describes what the user does
+const submitBtn = await page.getByRole('button', { name: 'Submit order' });
+await submitBtn.click();
+expect(await page.getByText(/order #\d+ confirmed/i)).toBeVisible();
+```
+
+**Anti-pattern:**
+
+```javascript
+// BAD — describes implementation
+await page.click('.btn-primary.submit-btn');
+expect(page.querySelector('.confirmation-toast')).toBeTruthy();
+```
+
+The good version survives a CSS refactor, a className rename, a Tailwind migration. The bad version breaks on each.
+
+## 2. Selector hierarchy
+
+When the role isn't enough, climb DOWN this ladder. Stop at the highest rung that disambiguates:
+
+1. **Role + name** — `getByRole('button', { name: 'Submit' })`
+2. **Label / form association** — `getByLabel('Email')`
+3. **Text content** — `getByText('Welcome back')`
+4. **Test-id** — `getByTestId('user-menu')` (escape hatch; do not start here)
+5. **Structural / CSS** — `querySelector('article:nth-child(3)')` (last resort; flags)
+
+Test-id is fine. Test-id as your default is a sign you're not designing accessible UI.
+
+## 3. Wait on observable conditions, never wall-clock
+
+**Pattern:**
+
+```javascript
+// GOOD — waits for the actual condition
+await expect(page.getByText('Order confirmed')).toBeVisible({ timeout: 5000 });
+```
+
+**Anti-pattern:**
+
+```javascript
+// BAD — wall-clock hopes
+await page.waitForTimeout(3000);
+expect(page.getByText('Order confirmed')).toBeVisible();
+```
+
+`waitForTimeout` is the #1 source of flakiness. It races with the network, with rendering, with the event loop. Always wait on what you actually need to see.
+
+## 4. Each test independent and order-free
+
+Every test runs cleanly when invoked in isolation (with `.only`) or in a randomized order.
+
+**Pattern:**
+
+```javascript
+beforeEach(async () => {
+  // Set up state THIS test needs
+  await db.users.create({ id: 'test-1', email: 'a@b.c' });
+});
+
+afterEach(async () => {
+  // Clean up — but if tests are independent, you may not need this
+  await db.users.deleteAll();
+});
+```
+
+**Anti-pattern:** Shared state in `beforeAll`. Tests passing only when run in suite order. Brittle CI runs.
+
+**Healthier:** prefer setup in `beforeEach` over teardown in `afterEach`. A test that sets up its own state from a clean baseline never wonders "did the previous test corrupt me?"
+
+## 5. One behavior per test, as many assertions as that behavior needs
+
+**Pattern:**
+
+```javascript
+test('successful login redirects to dashboard and shows user name', async () => {
+  await login('user@example.com', 'password');
+
+  expect(await page.url()).toContain('/dashboard');
+  expect(await page.getByRole('heading', { name: /welcome/i })).toBeVisible();
+  expect(await page.getByText('user@example.com')).toBeVisible();
+});
+```
+
+ONE behavior ("successful login leads to dashboard with user info"). THREE assertions because that behavior has three observable parts.
+
+**Anti-pattern:** Two unrelated behaviors crammed into one test ("login + then-also-test-search-works"). When it fails, you don't know which broke.
+
+## 6. Names read as specifications
+
+**Pattern:**
+
+```
+should reject invalid email when registering given no prior account
+should approve refund within SLA given amount under threshold
+should sync calendar events when user reconnects given offline edits
+```
+
+Form: `should <expected outcome> when <triggering condition> [given <starting state>]`
+
+**Anti-pattern:**
+
+```
+test_login
+test_email_1
+testHappy
+```
+
+These tell you nothing on failure. A spec-style name doubles as documentation when failure messages get noisy.
+
+## 7. Table-driven / parameterized when inputs vary
+
+**Pattern:**
+
+```javascript
+describe.each([
+  { input: '',           expected: 'required' },
+  { input: 'a',          expected: 'too short' },
+  { input: 'a'.repeat(100), expected: 'too long' },
+  { input: 'a@b.c',      expected: 'valid' },
+])('validateEmail($input)', ({ input, expected }) => {
+  test(`returns ${expected}`, () => {
+    expect(validateEmail(input)).toBe(expected);
+  });
+});
+```
+
+Easy to add cases; impossible to forget one input class.
+
+**Anti-pattern:** Five copy-pasted tests with one variable changed. Drift between them; one gets updated, others don't.
+
+## 8. Build test data via factories
+
+**Pattern:**
+
+```javascript
+const buildUser = (overrides = {}) => ({
+  id: 'u-' + Math.random().toString(36).slice(2),
+  email: 'test@example.com',
+  role: 'member',
+  createdAt: new Date(),
+  ...overrides,
+});
+
+test('admin can delete users', () => {
+  const admin = buildUser({ role: 'admin' });
+  const target = buildUser();
+  expect(canDelete(admin, target)).toBe(true);
+});
+```
+
+Tests focus on the FIELDS that matter to the behavior. Default everything else.
+
+**Anti-pattern:** Literal 50-field JSON blobs copy-pasted across tests. When the schema changes, you update them all — or worse, miss some.
+
+## 9. Mock at boundaries you don't control
+
+**Pattern:**
+
+| Boundary | Test treatment |
+|----------|---------------|
+| Your own modules | Real (don't mock) |
+| Your own DB (with testcontainers) | Real |
+| Third-party HTTP API | Mock at fetch/axios level |
+| Cloud SDK (AWS, GCP, Stripe) | Mock at SDK level OR sandbox account |
+| System clock | Mock when test depends on time |
+| RNG | Mock when test depends on randomness |
+| File system (when external) | Mock; in tests of fs logic, real temp dir |
+
+**Anti-pattern:** Mocking your own modules so the test is fast. You're now testing the mock setup, not the code.
+
+## 10. Real systems gate final merge
+
+**Pattern:**
+
+```
+unit (mocks ok)        → every commit, run locally and in CI
+integration (real DB)  → every PR, run in CI
+contract (boundary)    → every PR
+E2E (real services)    → before merge to main, run in CI on preview env
+```
+
+No merge to main without a real-system path going green. Mocks are speed, real is truth.
+
+**Anti-pattern:** 100% mocked test suite. "It all passes locally" → first user request fails because the mock didn't match the real API shape.
+
+## 11. Mutation score over coverage percentage
+
+**Pattern:**
+
+Set up mutation testing (Stryker for JS/TS, mutmut for Python, etc.) ONCE per project. Run weekly on critical modules.
+
+```bash
+npx stryker run
+# Output: 87 mutants, 78 killed, 9 survived → mutation score 89.6%
+```
+
+A surviving mutant means: this code path runs in tests, but the tests don't actually assert anything that breaks when the code changes. Investigate each.
+
+**Anti-pattern:** 95% line coverage with assertions like `expect(result).toBeTruthy()` — every line ran, but mutations all survive. The suite is decorative.
+
+## 12. Page Object Model is a tool, not a religion
+
+For small E2E suites (<20 tests, <5 pages), POM is over-engineering — direct queries are clearer.
+
+For large suites (>50 tests, many pages, multi-step flows), POM pays off:
+
+```javascript
+class CheckoutPage {
+  constructor(page) { this.page = page; }
+
+  async fillShipping(addr) { /* ... */ }
+  async selectPayment(method) { /* ... */ }
+  async place() { /* ... */ }
+  async waitForConfirmation() { return this.page.getByText(/confirmed/i); }
+}
+
+test('checkout end-to-end', async ({ page }) => {
+  const checkout = new CheckoutPage(page);
+  await checkout.fillShipping(defaultAddress);
+  await checkout.selectPayment('card');
+  await checkout.place();
+  await expect(checkout.waitForConfirmation()).toBeVisible();
+});
+```
+
+The page object hides the selector mess; tests read like specs. But for a 5-test suite, that wrapper is just noise.
+
+**Rule of thumb:** apply POM when you have ≥3 tests sharing the same page interactions. Otherwise inline.
+
+## Applying these patterns
+
+When `/dw-run-task` generates a new test, it must comply with these 12. `/dw-code-review` checks each diff hunk under test paths against these patterns and the anti-patterns in the sibling reference. Violations become findings.

package/scaffold/skills/dw-testing-discipline/references/playwright-recipes.md

@@ -0,0 +1,282 @@
+# Playwright recipes — concrete tactical patterns
+
+Practical Playwright code for the common scenarios. Use this when `/dw-run-qa` runs in UI mode or when `/dw-functional-doc` needs E2E coverage.
+
+> These recipes ASSUME the doctrine in this skill (core rules, positive patterns) has already been applied. Recipes are the HOW once the WHY is settled.
+
+## Basic Navigation
+
+```javascript
+import { test, expect } from '@playwright/test';
+
+test('homepage loads and shows hero', async ({ page }) => {
+  await page.goto('http://localhost:3000');
+  await expect(page).toHaveTitle(/Welcome/);
+  await expect(page.getByRole('heading', { level: 1 })).toBeVisible();
+});
+```
+
+Key practices:
+- Use `expect(page).toHaveTitle(/pattern/)` instead of `await page.title()` + manual assertion (waits for title to settle).
+- Use `getByRole`, not selectors (Positive Pattern #1).
+
+## Form interaction
+
+```javascript
+test('login redirects to dashboard with user info', async ({ page }) => {
+  await page.goto('/login');
+
+  // Use labels, not selectors
+  await page.getByLabel('Email').fill('user@example.com');
+  await page.getByLabel('Password').fill('secret123');
+  await page.getByRole('button', { name: 'Sign in' }).click();
+
+  // Wait on observable outcome, not wall-clock
+  await expect(page).toHaveURL(/\/dashboard/);
+  await expect(page.getByText('user@example.com')).toBeVisible();
+});
+```
+
+## Screenshot capture (debugging + visual evidence)
+
+```javascript
+// For debugging
+test('checkout flow', async ({ page }) => {
+  try {
+    await page.goto('/checkout');
+    // ... interaction
+  } catch (err) {
+    await page.screenshot({ path: `failure-${Date.now()}.png`, fullPage: true });
+    throw err;
+  }
+});
+
+// For visual regression (only on stable surfaces)
+test('header looks correct', async ({ page }) => {
+  await page.goto('/');
+  await expect(page.getByRole('banner')).toHaveScreenshot('header.png');
+});
+```
+
+Warning: visual regression tests need a baseline. Apply the snapshot classification gate from `ai-agent-gates.md` (Gate 5).
+
+## Browser console logs (capture for debug)
+
+```javascript
+test('no console errors during checkout', async ({ page }) => {
+  const errors = [];
+  page.on('console', msg => {
+    if (msg.type() === 'error') errors.push(msg.text());
+  });
+  page.on('pageerror', err => errors.push(err.message));
+
+  await page.goto('/checkout');
+  await page.getByRole('button', { name: 'Complete order' }).click();
+  await expect(page.getByText('Order placed')).toBeVisible();
+
+  expect(errors).toEqual([]);
+});
+```
+
+## Network interception (mock or inspect)
+
+```javascript
+test('handles API failure gracefully', async ({ page }) => {
+  // Intercept the orders API and return 500
+  await page.route('**/api/orders', route =>
+    route.fulfill({ status: 500, body: 'Server error' })
+  );
+
+  await page.goto('/orders');
+
+  // The UI should show a recoverable error state, not crash
+  await expect(page.getByText('Could not load orders')).toBeVisible();
+  await expect(page.getByRole('button', { name: 'Retry' })).toBeVisible();
+});
+```
+
+```javascript
+test('order list calls API with correct params', async ({ page }) => {
+  let capturedUrl;
+  page.on('request', req => {
+    if (req.url().includes('/api/orders')) capturedUrl = req.url();
+  });
+
+  await page.goto('/orders?filter=overdue');
+
+  await expect.poll(() => capturedUrl).toContain('filter=overdue');
+});
+```
+
+## Wait for conditions (NOT wall-clock)
+
+```javascript
+// GOOD — wait on observable condition
+await expect(page.getByText(/order #\d+ confirmed/i)).toBeVisible({ timeout: 10000 });
+
+// GOOD — wait on URL change
+await page.waitForURL(/\/dashboard/);
+
+// GOOD — wait on network response
+const responsePromise = page.waitForResponse(resp => resp.url().includes('/api/orders') && resp.status() === 200);
+await page.getByRole('button', { name: 'Load orders' }).click();
+await responsePromise;
+
+// GOOD — poll a custom condition
+await expect.poll(async () => {
+  const count = await page.getByRole('listitem').count();
+  return count;
+}, { timeout: 5000 }).toBeGreaterThan(0);
+
+// BAD — wall-clock
+await page.waitForTimeout(3000);  // ← Anti-pattern A7
+```
+
+## Mobile viewport testing
+
+```javascript
+test('mobile menu works', async ({ browser }) => {
+  const context = await browser.newContext({
+    viewport: { width: 375, height: 812 },  // iPhone X
+    userAgent: 'Mozilla/5.0 (iPhone; ...)',
+  });
+  const page = await context.newPage();
+
+  await page.goto('/');
+  await page.getByRole('button', { name: /menu/i }).click();
+  await expect(page.getByRole('navigation')).toBeVisible();
+});
+```
+
+For dev-workflow's redesign-ui flow, capture screenshots at TWO viewports: 375px (mobile) and 1440px (desktop). This is documented in `/dw-redesign-ui` step 7.
+
+## Multi-step user journey (Page Object Model)
+
+For >3 tests sharing the same flow, POM pays off:
+
+```javascript
+// checkout-page.ts
+export class CheckoutPage {
+  constructor(private page) {}
+
+  async goto() {
+    await this.page.goto('/checkout');
+  }
+
+  async fillShipping(addr) {
+    await this.page.getByLabel('Address').fill(addr.street);
+    await this.page.getByLabel('City').fill(addr.city);
+    await this.page.getByLabel('ZIP').fill(addr.zip);
+  }
+
+  async selectPayment(method) {
+    await this.page.getByLabel(method).check();
+  }
+
+  async place() {
+    await this.page.getByRole('button', { name: 'Place order' }).click();
+  }
+
+  async expectConfirmed() {
+    await expect(this.page.getByText(/order #\d+ confirmed/i)).toBeVisible();
+  }
+}
+
+// checkout.spec.ts
+test('checkout end-to-end', async ({ page }) => {
+  const checkout = new CheckoutPage(page);
+  await checkout.goto();
+  await checkout.fillShipping(defaultAddress);
+  await checkout.selectPayment('Card ending in 4242');
+  await checkout.place();
+  await checkout.expectConfirmed();
+});
+```
+
+## Helper utilities
+
+For small projects, a couple of helpers reduce boilerplate. Drop these in `test-helpers.ts`:
+
+```typescript
+import type { Page } from '@playwright/test';
+
+/**
+ * Capture browser console logs as the page runs.
+ * Pass the returned array to assert on logs at the end of the test.
+ */
+export function captureConsoleLogs(page: Page) {
+  const logs: Array<{ type: string; text: string; ts: string }> = [];
+  page.on('console', msg => {
+    logs.push({ type: msg.type(), text: msg.text(), ts: new Date().toISOString() });
+  });
+  return logs;
+}
+
+/**
+ * Take a timestamped screenshot for debugging or evidence collection.
+ */
+export async function captureScreenshot(page: Page, name: string) {
+  const stamp = new Date().toISOString().replace(/[:.]/g, '-');
+  const filename = `${name}-${stamp}.png`;
+  await page.screenshot({ path: filename, fullPage: true });
+  return filename;
+}
+```
+
+## Persistent session (auth state)
+
+When tests need to start logged in, save auth state ONCE in setup:
+
+```typescript
+// global-setup.ts
+import { chromium } from '@playwright/test';
+
+export default async () => {
+  const browser = await chromium.launch();
+  const page = await browser.newPage();
+
+  await page.goto('http://localhost:3000/login');
+  await page.getByLabel('Email').fill('e2e-user@example.com');
+  await page.getByLabel('Password').fill(process.env.E2E_PASSWORD);
+  await page.getByRole('button', { name: 'Sign in' }).click();
+  await page.waitForURL(/\/dashboard/);
+
+  await page.context().storageState({ path: '.auth/user.json' });
+  await browser.close();
+};
+
+// playwright.config.ts
+export default defineConfig({
+  globalSetup: require.resolve('./global-setup'),
+  use: {
+    storageState: '.auth/user.json',
+  },
+});
+```
+
+Tests now start authenticated. No login loop in every test.
+
+## Common pitfalls (cross-reference to anti-patterns)
+
+| Pitfall | Anti-pattern | Fix |
+|---------|--------------|-----|
+| `await page.click('.btn-primary')` | A1 (implementation selectors) | `getByRole('button', { name: ... })` |
+| `await page.waitForTimeout(3000)` | A7 (static sleeps) | Wait on observable condition |
+| `expect(button).toBeTruthy()` | A5 (vague existence) | Assert what you actually want |
+| Tests pass solo, fail in suite | A8 (order dependency) | Setup in beforeEach, not beforeAll |
+| `await page.goto('https://www.google.com')` | A20 (third-party site) | Mock or skip |
+
+## Limitations
+
+- Playwright cannot test native mobile apps (use React Native Testing Library or Detox).
+- Some authentication flows (Google Sign-In, MFA hardware keys) cannot be automated; use test-mode bypasses with a dedicated test account.
+- Visual regression tests are sensitive to font rendering across OSes; pin to a CI runner OS.
+
+## Cross-skill integration
+
+When running these recipes, the doctrine in this skill applies:
+- Apply core rules (especially Rule 2: lowest layer first — many E2E tests should be integration tests instead).
+- Run the 7 AI Agent Gates if a coding agent is producing this test.
+- Check for Anti-Patterns 1, 5, 7, 20 in the diff.
+- For browser security scenarios (auth bypass, XSS, CSRF), see `security-boundary.md`.
+- For picking which workflow (UI / network / perf) applies, see `three-workflow-patterns.md`.

package/scaffold/skills/{webapp-testing → dw-testing-discipline}/references/security-boundary.md

@@ -1,6 +1,6 @@
 # Security boundary — every browser is hostile
 
-> Adapted from [`addyosmani/agent-skills/browser-devtools`](https://github.com/addyosmani/agent-skills/tree/main/browser-devtools) (MIT). Adopts the security-boundary principle to inform how webapp-testing scenarios should validate trust boundaries.
+> Adapted from [`addyosmani/agent-skills/browser-devtools`](https://github.com/addyosmani/agent-skills/tree/main/browser-devtools) (MIT). Adopts the security-boundary principle to inform how browser-based testing scenarios validate trust boundaries.
 
 The browser is not a secure environment. Anything that runs there — JS, CSS, HTML, devtools — is under the user's control. When you write a webapp test, you're not just verifying functionality; you're often verifying that this assumption holds.