froid-plane-test-architecture-enterprise 1.23.4

package/src/workflows/testarch/froid-testarch-test-review/resources/knowledge/webhook-waiting-querying.md

@@ -0,0 +1,167 @@
+# Webhook Waiting and Querying Patterns
+
+## Principle
+
+`waitFor` and `waitForCount` poll until matching webhooks arrive; `getReceived` queries without waiting. Always drain preceding events before asserting on subsequent ones. Scope templates by entity ID to prevent parallel worker cross-contamination.
+
+## Pattern Examples
+
+### Example 1: waitFor — single webhook
+
+Poll until the first webhook matching the template arrives. Returns the typed `ReceivedWebhook<T>`.
+
+```typescript
+const webhook = await webhookRegistry.waitFor(movieCreated(movieId));
+
+expect(webhook.body).toMatchObject({
+  event: 'movie.created',
+  timestamp: expect.any(String),
+  data: {
+    id: movieId,
+    name: movie.name,
+    year: movie.year,
+    rating: movie.rating,
+  },
+});
+```
+
+### Example 2: The drain pattern — sequential events
+
+When testing a downstream event (e.g. deletion), always `waitFor` the preceding event first. Without the drain, the create webhook may remain in the journal and interfere with cleanup or subsequent polling.
+
+```typescript
+test('movie deletion triggers a webhook with correct payload', async ({ authToken, addMovie, deleteMovie, webhookRegistry }) => {
+  const movie = generateMovieWithoutId();
+  const { body: createResponse } = await addMovie(authToken, movie);
+  const movieId = createResponse.data.id;
+
+  await log.step('Drain the create webhook before testing the delete path');
+  await webhookRegistry.waitFor(movieCreated(movieId)); // drain — consume the create event
+
+  await deleteMovie(authToken, movieId);
+
+  await log.step('Wait for the delete webhook');
+  const webhook = await webhookRegistry.waitFor(movieDeleted(movieId));
+
+  expect(webhook.body).toMatchObject({
+    event: 'movie.deleted',
+    data: { id: movieId, name: movie.name },
+  });
+});
+```
+
+**Why drain?** If you skip the drain and go directly to `waitFor(movieDeleted)`, the create webhook is already in the journal. The delete webhook may arrive and be cleaned up by another test before your poll reaches it. Draining makes the event order explicit and removes the ambiguity.
+
+### Example 3: waitForCount — collect N webhooks concurrently
+
+Collect exactly N matching webhooks. Use `matchPredicate` with all IDs to prevent cross-worker contamination when running `fullyParallel: true`:
+
+```typescript
+await log.step('Create two movies concurrently');
+const [{ body: res1 }, { body: res2 }] = await Promise.all([
+  addMovie(authToken, generateMovieWithoutId()),
+  addMovie(authToken, generateMovieWithoutId()),
+]);
+
+const [id1, id2] = [res1.data.id, res2.data.id];
+
+const batchTemplate = webhookTemplate<{
+  event: string;
+  data: { id: number };
+}>('movie.created.batch')
+  .matchField('event', 'movie.created')
+  .matchPredicate(`data.id is ${id1} or ${id2}`, (p) => p.data.id === id1 || p.data.id === id2)
+  .withTimeout(15_000)
+  .withInterval(500)
+  .build();
+
+const webhooks = await webhookRegistry.waitForCount(batchTemplate, 2);
+
+expect(webhooks).toHaveLength(2);
+const receivedIds = webhooks.map((w) => w.body.data.id);
+expect(receivedIds).toContain(id1);
+expect(receivedIds).toContain(id2);
+expect(new Set(receivedIds).size).toBe(2); // guard against the same ID delivered twice
+```
+
+### Example 4: getReceived — query without waiting
+
+Query the journal without polling. Useful for asserting presence of webhooks after a `waitFor`, or for method/URL filtering.
+
+```typescript
+await webhookRegistry.waitFor(movieCreated(movieId)); // wait first
+
+const all = await webhookRegistry.getReceived();
+expect(all.length).toBeGreaterThanOrEqual(1);
+
+// Method filter — all sample-app webhooks are delivered via POST
+const postOnly = await webhookRegistry.getReceived({ method: 'POST' });
+expect(postOnly.every((w) => w.method === 'POST')).toBe(true);
+
+// URL pattern filter — match the webhooks endpoint path
+const byUrl = await webhookRegistry.getReceived({ urlPattern: '/webhooks' });
+expect(byUrl.every((w) => w.url.includes('/webhooks'))).toBe(true);
+```
+
+`getReceived` accepts `WebhookQueryFilter`:
+
+```typescript
+type WebhookQueryFilter = {
+  urlPattern?: string; // glob or regex string
+  method?: string; // HTTP method filter
+  since?: Date; // only return webhooks after this timestamp
+};
+```
+
+Note: `getReceived` is a direct passthrough to the provider — it does **not** automatically apply the `startedAt` filter. Only `waitFor` and `waitForCount` apply the since-filter internally during polling. If you need to scope a manual `getReceived` call to this test's time window, record your own timestamp before the action under test and pass `{ since: myTimestamp }` explicitly.
+
+## Parallel Worker Safety
+
+Always scope template factories to the entity's ID:
+
+```typescript
+// ✅ Scoped — only matches webhooks for this specific movie
+const movieCreated = (movieId: number) =>
+  webhookTemplate('movie.created')
+    .matchField('event', 'movie.created')
+    .matchField('data.id', movieId) // scoped by ID
+    .build();
+
+// ❌ Unscoped — will match any movie.created from any parallel worker
+const movieCreatedUnscoped = webhookTemplate('movie.created').matchField('event', 'movie.created').build();
+```
+
+## Method Summary
+
+| Method                      | Returns                         | Description                                                                                       |
+| --------------------------- | ------------------------------- | ------------------------------------------------------------------------------------------------- |
+| `waitFor(template)`         | `Promise<ReceivedWebhook<T>>`   | Poll until first match; throws `WebhookTimeoutError` on timeout                                   |
+| `waitForCount(template, n)` | `Promise<ReceivedWebhook<T>[]>` | Poll until N matches; throws `WebhookTimeoutError` on timeout                                     |
+| `getReceived(filter?)`      | `Promise<ReceivedWebhook[]>`    | Direct passthrough to provider — no automatic since-filter; pass `{ since }` explicitly if needed |
+| `resetJournal()`            | `Promise<void>`                 | Wipe the entire journal and clear matchedIds                                                      |
+| `cleanup()`                 | `Promise<void>`                 | Delete matched webhooks (`matched-only`) or reset journal (`full-reset`)                          |
+
+## Anti-Patterns
+
+**DON'T skip the drain for sequential events:**
+
+```typescript
+// Bad: direct jump to delete webhook — create webhook pollutes the journal
+await addMovie(authToken, movie);
+const webhook = await webhookRegistry.waitFor(movieDeleted(movieId));
+```
+
+**DO drain preceding events:**
+
+```typescript
+// Good: drain create first, then wait for delete
+await webhookRegistry.waitFor(movieCreated(movieId)); // drain
+await deleteMovie(authToken, movieId);
+const webhook = await webhookRegistry.waitFor(movieDeleted(movieId));
+```
+
+## Related Fragments
+
+- `webhook-template-matchers.md` — How to build templates
+- `webhook-timeout-error.md` — What to do when waitFor times out
+- `recurse.md` — The polling primitive used internally by the registry

package/src/workflows/testarch/froid-testarch-test-review/resources/tea-index.csv

@@ -0,0 +1,60 @@
+id,name,description,tags,tier,fragment_file
+library-integration-mandate,Library Integration Mandate,"General contract for every TEA integration library flag: the two gates (flag true plus package installed), REQUIRED vs RECOMMENDED levels, deviation protocol, scope discipline, the flag-to-mandate registry, and the ten places a new library must be wired","standards,governance,generation,review,integration,mandate",core,knowledge/library-integration-mandate.md
+fixture-architecture,Fixture Architecture,"Composable fixture patterns (pure function → fixture → merge) and reuse rules","fixtures,architecture,playwright,cypress",core,knowledge/fixture-architecture.md
+network-first,Network-First Safeguards,"Intercept-before-navigate workflow, HAR capture, deterministic waits, edge mocking","network,stability,playwright,cypress,ui",core,knowledge/network-first.md
+data-factories,Data Factories and API Setup,"Factories with overrides, API seeding, cleanup discipline, and naming the domain literals a test hardcodes on purpose","data,factories,setup,api,backend,seeding,magic-value,literals,naming,constants",core,knowledge/data-factories.md
+component-tdd,Component TDD Loop,"Red→green→refactor workflow, provider isolation, accessibility assertions, and user-level interaction over raw event dispatch","component-testing,tdd,ui,user-event,fire-event,interaction",extended,knowledge/component-tdd.md
+playwright-config,Playwright Config Guardrails,"Environment switching, timeout standards, artifact outputs","playwright,config,env",extended,knowledge/playwright-config.md
+ci-burn-in,CI and Burn-In Strategy,"Staged jobs, shard orchestration, burn-in loops, artifact policy","ci,automation,flakiness",extended,knowledge/ci-burn-in.md
+selective-testing,Selective Test Execution,"Tag/grep usage, spec filters, diff-based runs, promotion rules","risk-based,selection,strategy",extended,knowledge/selective-testing.md
+feature-flags,Feature Flag Governance,"Enum management, targeting helpers, cleanup, release checklists","feature-flags,governance,launchdarkly",specialized,knowledge/feature-flags.md
+contract-testing,Contract Testing Essentials,"Pact publishing, provider verification, resilience coverage, PactV4 four-rule determinism & FFI safety block (fileParallelism + pool:forks + singleFork + determinism gate)","contract-testing,pact,api,backend,microservices,service-contract,vitest,ffi,determinism,pactv4",specialized,knowledge/contract-testing.md
+email-auth,Email Authentication Testing,"Magic link extraction, state preservation, caching, negative flows","email-authentication,security,workflow",specialized,knowledge/email-auth.md
+error-handling,Error Handling Checks,"Scoped exception handling, retry validation, telemetry logging","resilience,error-handling,stability,api,backend",extended,knowledge/error-handling.md
+visual-debugging,Visual Debugging Toolkit,"Trace viewer usage, artifact expectations, accessibility integration","debugging,dx,tooling,ui",specialized,knowledge/visual-debugging.md
+risk-governance,Risk Governance,"Scoring matrix, category ownership, gate decision rules","risk,governance,gates",core,knowledge/risk-governance.md
+probability-impact,Probability and Impact Scale,"Shared definitions for scoring matrix and gate thresholds","risk,scoring,scale",core,knowledge/probability-impact.md
+test-quality,Test Quality Definition of Done,"Execution limits, isolation rules, green criteria, committed skips and focus, assertions that cannot fail, and suite structure and naming","quality,definition-of-done,tests,skip,only,focused,disabled,tautological,assertions,mocks,unreachable,concerns,grouping,nesting,naming,assertion-style",core,knowledge/test-quality.md
+nfr-criteria,NFR Review Criteria,"Security, performance, reliability, maintainability status definitions","nfr,assessment,quality",extended,knowledge/nfr-criteria.md
+test-levels,Test Levels Framework,"Guidelines for choosing unit, integration, or end-to-end coverage","testing,levels,selection,api,backend,ui",core,knowledge/test-levels-framework.md
+test-priorities,Test Priorities Matrix,"P0–P3 criteria, coverage targets, execution ordering","testing,prioritization,risk",core,knowledge/test-priorities-matrix.md
+test-healing-patterns,Test Healing Patterns,"Common failure patterns and automated fixes","healing,debugging,patterns",core,knowledge/test-healing-patterns.md
+selector-resilience,Selector Resilience,"Robust selector strategies and debugging techniques","selectors,locators,debugging,ui",core,knowledge/selector-resilience.md
+timing-debugging,Timing Debugging,"Race condition identification, deterministic wait fixes, wall-clock fixtures and fake timers, and unawaited promises in test bodies","timing,async,debugging,clock,fake-timers,expiry,ttl,unawaited,await,floating-promise",extended,knowledge/timing-debugging.md
+overview,Playwright Utils Overview,"Installation, design principles, fixture patterns for API and UI testing","playwright-utils,fixtures,api,backend,ui",core,knowledge/overview.md
+playwright-utils-mandate,Playwright Utils Mandate,"Binding rule when tea_use_playwright_utils is true: substitution table (page.route to interceptNetworkCall, raw request to apiRequest, waitForTimeout to recurse), REQUIRED vs RECOMMENDED levels, banned patterns, pre-emit self-check, deviation protocol","playwright-utils,standards,generation,review,governance,mandate",core,knowledge/playwright-utils-mandate.md
+api-request,API Request,"Typed HTTP client, schema validation, retry logic, operation-based overload for API and service testing","api,backend,service-testing,api-testing,playwright-utils,openapi,codegen,operation",core,knowledge/api-request.md
+network-recorder,Network Recorder,"HAR record/playback, CRUD detection for offline UI testing","network,playwright-utils,ui,har",extended,knowledge/network-recorder.md
+auth-session,Auth Session,"Token persistence, multi-user, API and browser authentication","auth,playwright-utils,api,backend,jwt,token",core,knowledge/auth-session.md
+intercept-network-call,Intercept Network Call,"Network spy/stub, JSON parsing for UI tests","network,playwright-utils,ui",extended,knowledge/intercept-network-call.md
+recurse,Recurse Polling,"Async polling for API responses, background jobs, eventual consistency","polling,playwright-utils,api,backend,async,eventual-consistency",extended,knowledge/recurse.md
+log,Log Utility,"Report logging, structured output for API and UI tests","logging,playwright-utils,api,ui",extended,knowledge/log.md
+file-utils,File Utilities,"CSV/XLSX/PDF/ZIP validation for API exports and UI downloads","files,playwright-utils,api,backend,ui",extended,knowledge/file-utils.md
+burn-in,Burn-in Runner,"Smart test selection, git diff for CI optimization","ci,playwright-utils",extended,knowledge/burn-in.md
+network-error-monitor,Network Error Monitor,"HTTP 4xx/5xx detection for UI tests","monitoring,playwright-utils,ui",extended,knowledge/network-error-monitor.md
+fixtures-composition,Fixtures Composition,"mergeTests composition patterns for combining utilities","fixtures,playwright-utils",extended,knowledge/fixtures-composition.md
+api-testing-patterns,API Testing Patterns,"Pure API test patterns without browser: service testing, microservices, GraphQL","api,backend,service-testing,api-testing,microservices,graphql,no-browser",specialized,knowledge/api-testing-patterns.md
+pactjs-utils-overview,Pact.js Utils Overview,"Installation, contract testing flows, utility table (createProviderState, toJsonMap, setJsonContent, setJsonBody)","pactjs-utils,contract-testing,pact,api,backend,microservices",specialized,knowledge/pactjs-utils-overview.md
+pactjs-utils-mandate,Pact.js Utils Mandate,"Binding rule when tea_use_pactjs_utils is true: substitution table (hand-cast given to createProviderState, literal VerifierOptions to buildVerifierOptions, bespoke auth middleware to createRequestFilter), relevance gate before scaffolding, banned patterns, pre-emit self-check, broker degradation","pactjs-utils,contract-testing,pact,standards,generation,review,governance,mandate",core,knowledge/pactjs-utils-mandate.md
+pactjs-utils-zod-to-pact,Pact.js Utils Zod to Pact,"zodToPactMatchers for consumer-curated schemas, example precedence, Pact V3 matcher mapping, and anti-patterns","pactjs-utils,zod,contract-testing,pact,consumer,schema,matchers,api",specialized,knowledge/pactjs-utils-zod-to-pact.md
+pactjs-utils-consumer-helpers,Pact.js Utils Consumer Helpers,"createProviderState, toJsonMap, setJsonContent, setJsonBody; PactV4 one-interaction-per-it() determinism rule","pactjs-utils,consumer,contract-testing,pact,api,determinism,pactv4",specialized,knowledge/pactjs-utils-consumer-helpers.md
+pactjs-utils-provider-verifier,Pact.js Utils Provider Verifier,"buildVerifierOptions, buildMessageVerifierOptions; vitest pool:forks + singleFork for FFI safety (same rule applies to consumer and provider)","pactjs-utils,provider,consumer,contract-testing,pact,api,backend,ci,vitest,ffi",specialized,knowledge/pactjs-utils-provider-verifier.md
+pactjs-utils-request-filter,Pact.js Utils Request Filter,"createRequestFilter, noOpRequestFilter for auth injection","pactjs-utils,auth,contract-testing,pact",specialized,knowledge/pactjs-utils-request-filter.md
+pact-mcp,Pact MCP Server,"SmartBear MCP for PactFlow: generate tests, review, can-i-deploy, provider states","pact,mcp,pactflow,contract-testing,broker",specialized,knowledge/pact-mcp.md
+pact-consumer-framework-setup,Pact Consumer CDC Framework Setup,"Directory structure, vitest config with fileParallelism:false + pool:forks + singleFork:true (FFI safety), one-file-per-consumer+provider-pair rule (FFI handle collision prevention), jq-normalized publishing, 1:1 local/CI parity, PactV4 patterns","pactjs-utils,consumer,contract-testing,pact,ci,framework,setup,vitest,shell-scripts,jq,pactv4,ffi,file-organization,one-file-per-pair",specialized,knowledge/pact-consumer-framework-setup.md
+pact-broker-webhooks,Pact Broker Webhooks,"PactFlow → GitHub repository_dispatch auth via dedicated machine user + classic PAT (repo scope, no expiration) + PactFlow secret; staleness monitoring and PAT rotation runbook","pact,pactflow,broker,webhooks,github,auth,pat,ci,operations,security",specialized,knowledge/pact-broker-webhooks.md
+adr-quality-readiness-checklist,ADR Quality Readiness Checklist,"8-category 29-criteria framework for ADR testability and NFR evidence audit","nfr,testability,adr,quality,assessment,checklist",extended,knowledge/adr-quality-readiness-checklist.md
+playwright-cli,Playwright CLI,"Token-efficient CLI for AI coding agents: element refs, sessions, snapshots, trace analysis, debug=cli autonomous investigation","cli,browser,agent,automation,snapshot,trace,debug",core,knowledge/playwright-cli.md
+pact-consumer-di,Pact Consumer DI Pattern,"Dependency injection pattern for Pact consumer tests — call actual source code instead of raw fetch by injecting mock server URL via optional baseUrl in context type","contract-testing,pact,consumer,dependency-injection,api,backend,architecture",extended,knowledge/pact-consumer-di.md
+webhook-fundamentals,Webhook Testing Fundamentals,"Why webhook delivery is hard: async, parallel pollution, opaque timeouts, cleanup drift. playwright-utils approach with polling, typed matchers, rich errors, startedAt isolation","webhook,async,playwright-utils,event-driven,eventually-consistent",core,knowledge/webhook-testing-fundamentals.md
+webhook-setup,Webhook Module Setup,"Fixture wiring for WireMock/MockServer/Mockoon providers, matched-only vs full-reset cleanup strategy, fullyParallel race condition fix","webhook,fixtures,playwright-utils,wiremock,mockserver,mockoon,setup",core,knowledge/webhook-module-setup.md
+webhook-matchers,Webhook Template Matchers,"matchField (dot-path exact), matchPartial (deep subset), matchPredicate (arbitrary fn), AND semantics, template factories, clone, withTimeout, withInterval","webhook,matchers,playwright-utils,templates,patterns",core,knowledge/webhook-template-matchers.md
+webhook-waiting,Webhook Waiting and Querying,"waitFor, waitForCount, getReceived, drain pattern for sequential events, parallel worker safety via ID-scoped templates","webhook,async,playwright-utils,polling,patterns,eventually-consistent",core,knowledge/webhook-waiting-querying.md
+webhook-timeout-error,WebhookTimeoutError Debugging,"templateName, timeoutMs, totalReceived, receivedWebhooks, matcherDetails, toJSON — inspect what arrived vs what was expected","webhook,debugging,errors,playwright-utils",extended,knowledge/webhook-timeout-error.md
+webhook-providers,Webhook Provider Patterns,"WireMock (deleteById supported), MockServer (deleteById no-op), Mockoon (deleteById no-op, 100-entry limit), custom WebhookProvider interface","webhook,providers,playwright-utils,wiremock,mockserver,mockoon",extended,knowledge/webhook-providers.md
+webhook-risk,Webhook Testing Risk Guidance,"When webhook tests are required, P2×I3 default risk score, complete test checklist, failure patterns and mitigations, TA assessment checklist","webhook,risk,assessment,event-driven,async,playwright-utils,governance",core,knowledge/webhook-risk-guidance.md
+confidence-gate,Confidence Gate,"1-10 confidence scoring with stop-and-ask rule below threshold for selectors, endpoints, risk classification, fixtures, schemas, and data factories — prevents agent fabrication","reliability,agent-safety,generation,quality,governance",core,knowledge/confidence-gate.md
+maestro-flows,Maestro Flow Patterns,"Declarative mobile flow structure, selector hierarchy (id > text > scoped text), clearState isolation, synchronization without sleeps, subflow composition, text selectors as whole-element regex, taps that report COMPLETED without being handled, visible meaning inside the viewport, asserting the transition rather than a state that may already hold, anti-patterns","mobile,maestro,ios,android,flows,selectors,ui",specialized,knowledge/maestro-flows.md
+mobile-test-strategy,Mobile Test Strategy,"Mobile test level framework (unit/component/contract/device flow), what belongs in a device flow, mobile risk categories (permissions, lifecycle, connectivity, fragmentation, upgrade), device matrix with a gate profile matching local, CI shape, no live third-party flag evaluation in the run path","mobile,maestro,strategy,risk,levels,ci,ios,android",specialized,knowledge/mobile-test-strategy.md
+evidence-integrity,Evidence Integrity,"Falsifiability of checks (hollow green, optional assertions, continue-on-error, partial manifests, assertions already true before the action), three-state diagnostics (pass/fail/could-not-measure), probes that issue the client's own request, verifying the outcome rather than the act, verifying framework properties before use, proving claims from the side that can observe them, environment asymmetry including screen geometry and accumulated credentials, ranking hypotheses by the cost of the measurement that kills them, recording what a change did rather than what it was for","quality,evidence,diagnostics,review,ci,gates,falsifiability",core,knowledge/evidence-integrity.md
+mobile-ci-device-lab,Mobile CI Device Lab,"Build artifact selection (release build vs development shell vs debug-variant development build), native modules that degrade silently in a shell, deep links reachable through the shell routed URL form, development-server manifest signing in non-interactive CI, one device profile across local and CI, Android emulator snapshot caching and config.ini pitfalls, repairing locally created AVDs, per-device identity for sharded runs, runner version pinning, artifact layout and failure diagnosis, sharding measured on wall clock","mobile,maestro,ci,android,ios,expo,emulator,artifacts",specialized,knowledge/mobile-ci-device-lab.md

package/src/workflows/testarch/froid-testarch-test-review/resources/test-review.example.md

@@ -0,0 +1,297 @@
+---
+stepsCompleted: ['step-01-load-context', 'step-02-discover-tests', 'step-03f-aggregate-scores', 'step-04-generate-report']
+lastStep: 'step-04-generate-report'
+lastSaved: '2026-08-17'
+workflowType: 'testarch-test-review'
+inputDocuments:
+  - 'tests/e2e/profile-notifications.spec.ts'
+  - 'docs/stories/5-2-notification-preferences.md'
+  - 'test-artifacts/test-design-epic-5.md'
+  - 'playwright.config.ts'
+  - 'src/workflows/testarch/froid-testarch-test-review/steps-c/criteria-registry.md'
+---
+
+# Test Quality Review: profile-notifications.spec.ts
+
+**Quality Score**: 97/100 (A)
+**Review Date**: 2026-08-17
+**Review Scope**: single
+**Reviewer**: TEA Agent
+
+---
+
+Note: This review audits existing tests. It does not generate tests or score requirement coverage. Use `trace` for coverage decisions.
+
+## Executive Summary
+
+**Overall Assessment**: Needs Improvement
+
+**Recommendation**: Request Changes
+
+**Context Basis**: pr_diff
+
+**Context Waivers Applied**: 0
+
+The score remains high because the file is small, readable, and mostly deterministic. One HIGH finding still forces `Request Changes`: a fixed timer can pass or fail according to runner speed. The recommendation is computed from the deduplicated registry findings and is unchanged by the strong numeric score.
+
+### Key Strengths
+
+- Behavior-focused Given-When-Then naming across all three tests
+- Tenant and user setup is isolated through project fixtures
+- Stable test IDs and explicit assertions make failures diagnosable
+
+### Key Weaknesses
+
+- One fixed `waitForTimeout` introduces timing-dependent behavior
+- One network observer is registered after navigation
+- One test omits the repository's established priority marker
+
+## Quality Criteria Assessment
+
+| Criterion                            | Status        | Violations | Basis                                                                   | Notes                                                    |
+| ------------------------------------ | ------------- | ---------: | ----------------------------------------------------------------------- | -------------------------------------------------------- |
+| BDD Format (Given-When-Then)         | ✅ PASS       |          0 | Convention: bddNaming (18 of 24 sampled)                                | All names state user-visible behavior                    |
+| Test IDs                             | ✅ PASS       |          0 | Convention: testIds (20 of 24 sampled)                                  | All DOM lookups use stable test IDs                      |
+| Priority Markers (P0/P1/P2/P3)       | ⚠️ WARN       |          1 | Convention: priorityMarkers (22 of 24 sampled)                          | Test at line 81 has no marker                            |
+| Disabled or Focused Tests            | ✅ PASS       |          0 | Absolute                                                                | No skip, fixme, only, or focus marker                    |
+| Hard Waits (sleep, waitForTimeout)   | ❌ FAIL       |          1 | Absolute                                                                | Fixed 2-second timer at line 37                          |
+| Determinism (no conditionals)        | ✅ PASS       |          0 | Absolute                                                                | No branching, catches, or wall-clock fixtures            |
+| Isolation (cleanup, no shared state) | ✅ PASS       |          0 | Absolute                                                                | Fixtures create and remove each preference record        |
+| Fixture Patterns                     | ✅ PASS       |          0 | Applicability: the file needs authenticated setup                       | Existing merged fixtures are reused                      |
+| Data Factories                       | ✅ PASS (n/a) |          0 | Applicability: the file does not construct domain payloads              | No payload shape to extract                              |
+| Network-First Pattern                | ❌ FAIL       |          1 | Applicability: the file navigates and then reads data-dependent content | Observer at line 58 is declared after navigation         |
+| Playwright Utils Adoption            | ✅ PASS       |          0 | Convention: playwrightUtils (16 of 24 sampled)                          | Imports merged fixtures and uses utility interception    |
+| Pact.js Utils Adoption               | ✅ PASS (n/a) |          0 | Applicability: the reviewed file is not a Pact artifact                 | Gate closed                                              |
+| Explicit Assertions                  | ✅ PASS       |          0 | Absolute                                                                | Every test has a falsifiable assertion                   |
+| Test Length (≤1000 lines)            | ✅ PASS       |          0 | Absolute                                                                | File is 146 lines                                        |
+| Test Duration (≤1.5 min)             | ⚠️ WARN       |          1 | Absolute                                                                | Measured at 18 seconds, but H1 still makes timing unsafe |
+| Flakiness Patterns                   | ❌ FAIL       |          1 | Absolute                                                                | Same H1 timer, counted once in the ledger                |
+
+**Total Violations**: 0 Critical, 1 High, 1 Medium, 1 Low
+
+**Convention Baseline**: 24 test files sampled outside the review set
+
+## Quality Score Breakdown
+
+```
+Starting Score:          100
+Critical Violations:     -0 × 10 = -0
+High Violations:         -1 × 5 = -5
+Medium Violations:       -1 × 2 = -2
+Low Violations:          -1 × 1 = -1
+
+Bonus Points:
+  Excellent BDD:         +5
+  Comprehensive Fixtures: +0
+  Data Factories:        +0
+  Network-First:         +0
+  Perfect Isolation:     +0
+  All Test IDs:          +0
+                         --------
+Total Bonus:             +5
+
+Final Score:             97/100
+Grade:                   A
+```
+
+The hard-wait finding appears in three assessment rows because H1 affects timing, duration, and flakiness. The ledger deduplicates the same row, file, and line into one HIGH violation.
+
+## Critical Issues (Must Fix)
+
+No critical issues detected.
+
+## Recommendations (Should Fix)
+
+### 1. Replace the Fixed Notification Delay
+
+**Severity**: P1 (High)
+**Location**: `tests/e2e/profile-notifications.spec.ts:37`
+**Row**: H1
+**Criterion**: Hard Waits
+**Knowledge Base**: [test-quality.md](./knowledge/test-quality.md)
+
+**Issue Description:** The test sleeps for two seconds after saving notification preferences. It can pass before persistence finishes on a fast response and fail after two seconds on a slow runner.
+
+**Current Code:**
+
+```typescript
+await saveButton.click();
+await page.waitForTimeout(2000);
+await expect(savedBanner).toBeVisible();
+```
+
+**Recommended Improvement:**
+
+```typescript
+const savePreference = interceptNetworkCall({
+  url: '/api/profile/notification-preferences',
+  method: 'PUT',
+});
+
+await saveButton.click();
+await savePreference;
+await expect(savedBanner).toBeVisible();
+```
+
+**Why This Matters:** The response is the state transition the assertion depends on. Waiting for that response is deterministic across runner speeds.
+
+### 2. Register the Preference Load Observer Before Navigation
+
+**Severity**: P2 (Medium)
+**Location**: `tests/e2e/profile-notifications.spec.ts:58`
+**Row**: M1
+**Criterion**: Network-First Pattern
+**Knowledge Base**: [network-first.md](./knowledge/network-first.md)
+
+**Issue Description:** The test opens `/profile/notifications` before creating the observer for the initial preference request. A fast response can finish before the observer exists.
+
+**Current Code:**
+
+```typescript
+await page.goto('/profile/notifications');
+const preferencesLoaded = interceptNetworkCall({ url: '/api/profile/notification-preferences' });
+await preferencesLoaded;
+```
+
+**Recommended Improvement:**
+
+```typescript
+const preferencesLoaded = interceptNetworkCall({ url: '/api/profile/notification-preferences' });
+await page.goto('/profile/notifications');
+await preferencesLoaded;
+```
+
+**Benefits:** The test observes the request regardless of response speed and keeps the existing playwright-utils convention.
+
+### 3. Add the Missing Priority Marker
+
+**Severity**: P3 (Low)
+**Location**: `tests/e2e/profile-notifications.spec.ts:81`
+**Row**: L2
+**Criterion**: Priority Markers
+**Knowledge Base**: [test-priorities-matrix.md](./knowledge/test-priorities-matrix.md)
+
+**Issue Description:** The repository uses priority markers in 22 of 24 sampled files. This test has none, so selective execution cannot classify it.
+
+**Recommended Improvement:** Prefix the behavioral name with `[P2]` after confirming the priority through the decision tree. Do not infer the marker from a risk score.
+
+## Best Practices Found
+
+### 1. Composed Authentication Fixture
+
+**Location**: `tests/e2e/profile-notifications.spec.ts:6`
+**Pattern**: Merged fixture entry point
+**Knowledge Base**: [fixture-architecture.md](./knowledge/fixture-architecture.md)
+
+The file imports `test` from `tests/support/merged-fixtures` and receives `authToken` and `profilePreference` from isolated fixtures. It does not repeat login through the UI.
+
+### 2. Stable State Assertions
+
+**Location**: `tests/e2e/profile-notifications.spec.ts:25`
+**Pattern**: Test-ID selectors with explicit assertions
+**Knowledge Base**: [test-quality.md](./knowledge/test-quality.md)
+
+The assertions target the saved banner, digest checkbox, and frequency value directly. They can fail when the user-visible state is wrong.
+
+## Test File Analysis
+
+### File Metadata
+
+- **File Path**: `tests/e2e/profile-notifications.spec.ts`
+- **File Size**: 146 lines, 5.8 KB
+- **Test Framework**: Playwright
+- **Language**: TypeScript
+
+### Test Structure
+
+- **Describe Blocks**: 1
+- **Test Cases**: 3
+- **Average Test Length**: 31 lines
+- **Fixtures Used**: 3 (`authToken`, `profilePreference`, `interceptNetworkCall`)
+- **Data Factories Used**: 0
+
+### Test Scope
+
+- **Test IDs**: `5.2-E2E-001`, `5.2-E2E-002`, `5.2-E2E-003`
+- **Priority Distribution**:
+  - P0: 0
+  - P1: 1
+  - P2: 1
+  - P3: 0
+  - Unknown: 1
+
+### Assertions Analysis
+
+- **Total Assertions**: 5
+- **Assertions per Test**: 1.7 average
+- **Assertion Types**: visibility, checked state, input value
+
+## Context and Integration
+
+### What the Context Said
+
+Story 5.2 requires saving email and push preferences, preserving the saved state across a reload, and rejecting an unsupported digest frequency. The reviewed tests cover those behaviors. The PR diff also changes the preference API from a synchronous response to a queued write, which raises the impact of the hard wait and late observer; context does not waive either registry row.
+
+### Related Artifacts
+
+- **Story File**: `docs/stories/5-2-notification-preferences.md`
+- **Test Design**: `test-artifacts/test-design-epic-5.md`
+- **Risk Assessment**: Medium
+- **Priority Framework**: P0 through P3 applied independently from risk score
+
+## Knowledge Base References
+
+- [test-quality.md](./knowledge/test-quality.md)
+- [fixture-architecture.md](./knowledge/fixture-architecture.md)
+- [network-first.md](./knowledge/network-first.md)
+- [data-factories.md](./knowledge/data-factories.md)
+- [test-levels-framework.md](./knowledge/test-levels-framework.md)
+- [selective-testing.md](./knowledge/selective-testing.md)
+- [ci-burn-in.md](./knowledge/ci-burn-in.md)
+- [test-priorities-matrix.md](./knowledge/test-priorities-matrix.md)
+
+## Next Steps
+
+### Immediate Actions Before Merge
+
+1. Replace the hard wait with the response-bound observer. Owner: PR author.
+2. Move the initial preference observer before navigation. Owner: PR author.
+3. Add the reviewed P2 priority marker. Owner: PR author.
+
+### Follow-up Actions
+
+1. Add this file to the changed-test burn-in set after the fixes land.
+
+### Re-Review Needed?
+
+Re-review after the HIGH finding is fixed. The computed recommendation remains `Request Changes` until H1 is absent.
+
+## Decision
+
+**Recommendation**: Request Changes
+
+**Rationale:** One HIGH hard-wait violation requires changes even though the deterministic score is 97. The two remaining findings are cheaper to fix in the same change and protect the queued-write transition introduced by this pull request.
+
+## Appendix
+
+### Violation Summary by Location
+
+| Line | Severity | Criterion             | Row | Issue                                | Fix                                 |
+| ---: | -------- | --------------------- | --- | ------------------------------------ | ----------------------------------- |
+|   37 | P1       | Hard Waits            | H1  | Fixed two-second timer               | Await the application response      |
+|   58 | P2       | Network-First Pattern | M1  | Observer registered after navigation | Register before `page.goto`         |
+|   81 | P3       | Priority Markers      | L2  | Established marker missing           | Add decision-tree-derived P2 marker |
+
+### Quality Trends
+
+No earlier review exists for this file.
+
+## Reviewed Files
+
+- tests/e2e/profile-notifications.spec.ts
+
+## Review Context
+
+- docs/stories/5-2-notification-preferences.md
+- test-artifacts/test-design-epic-5.md
+- src/profile/notification-preferences.ts