{
  "sourceCommit": "6f6730f478e20235b3266d56253d097d02dcdf46",
  "originalOutcome": "five callback failed on attempt 2 at D4 before incrementing reviewCount3",
  "reportCoverage": "Earlier complete acknowledged report through15:17:13; D4 ledger row also appears unchanged in final native terminal diff context line135. Final complete report was not retained. This fixture proves the lexical classifier boundary only, not full paid success.",
  "call": {
    "sessionId": "c0a001a7-fafa-4203-ad16-4e9a3c39ed58",
    "toolUseId": "toolu_011hzWgHQPupfxa9UnKiue7f",
    "questions": [
      {
        "question": "D4 — What automated test coverage ships with the new handler?\nProject/branch/task: gstack-plan-count-Z2wGKp on main, HOLD SCOPE CEO review (ledger row D4).\nELI10: The plan ships a new payment handler with zero automated tests and trusts the existing integration suite plus a manual staging replay. The existing suite cannot cover a class that does not exist yet unless it already drives the dispatcher with a real fixture event and the new flag on, and the plan offers no evidence it does. The three changes we just approved (dispatcher registration, bound lookup, named-error rescue) each fail in a way only a test catches: a guard skipped, an injection, or a wrong exception class turning the rescue into a catch-all or a no-op.\nStakes if we pick wrong: The first time the new handler's error paths run is in production with real money; the manual checklist only walks the happy path.\nRecommendation: A because with AI-assisted implementation the full suite costs ~30 minutes and each approved change gets a failing test before it gets a bug.\nCompleteness: A=10/10, B=7/10, C=1/10\nNet: full coverage including flag routing and dedup (A) vs. handler-only coverage that leaves the rollback path unproven (B) vs. production as the test environment (C).",
        "header": "D4 tests",
        "multiSelect": false,
        "options": [
          {
            "label": "A) Unit tests for every path + dispatcher replay integration test (recommended)",
            "description": "✅ Covers happy path, zero orders, missing email, unknown user, adversarial IDs, MailTimeout/delivery error, unknown exception propagation, DB error propagation\n✅ Proves flag on/off routes to new/prior handler and same event id twice runs the handler once, which is the whole rollback story (human: ~1 day / CC: ~30 min)\n❌ Needs a mail-client test double and a recorded fixture event; a dispatcher harness may have to be added if none exists"
          },
          {
            "label": "B) Unit tests only",
            "description": "✅ Fully covers the bound lookup (D2) and the named-error rescue (D3)\n✅ Smaller footprint, no dispatcher harness needed (human: ~half day / CC: ~15 min)\n❌ Dispatcher registration, flag routing and dedup interaction stay untested; staging replay remains the only proof the class is reached"
          },
          {
            "label": "C) No new tests (plan as written)",
            "description": "✅ Zero test-writing effort; matches the plan text literally\n❌ Error paths first execute in production; the manual checklist covers only the happy path; contradicts the stated preference that well-tested code is non-negotiable"
          }
        ]
      }
    ],
    "answered": true,
    "failed": false,
    "answers": {
      "D4 — What automated test coverage ships with the new handler?\nProject/branch/task: gstack-plan-count-Z2wGKp on main, HOLD SCOPE CEO review (ledger row D4).\nELI10: The plan ships a new payment handler with zero automated tests and trusts the existing integration suite plus a manual staging replay. The existing suite cannot cover a class that does not exist yet unless it already drives the dispatcher with a real fixture event and the new flag on, and the plan offers no evidence it does. The three changes we just approved (dispatcher registration, bound lookup, named-error rescue) each fail in a way only a test catches: a guard skipped, an injection, or a wrong exception class turning the rescue into a catch-all or a no-op.\nStakes if we pick wrong: The first time the new handler's error paths run is in production with real money; the manual checklist only walks the happy path.\nRecommendation: A because with AI-assisted implementation the full suite costs ~30 minutes and each approved change gets a failing test before it gets a bug.\nCompleteness: A=10/10, B=7/10, C=1/10\nNet: full coverage including flag routing and dedup (A) vs. handler-only coverage that leaves the rollback path unproven (B) vs. production as the test environment (C).": "A) Unit tests for every path + dispatcher replay integration test (recommended)"
    },
    "unansweredQuestionIndices": [],
    "answeredAt": "2026-09-15T15:19:43.362Z"
  },
  "savedPlan": "# Plan: Payment Processing Integration (CEO review working plan)\n\nSource: `PLAN.md` on `main` (fe7f2fa). Review mode: HOLD SCOPE (user-selected).\nReviewer: /plan-ceo-review, session 144618-1789485179-b77975c6, 2026-09-15.\n\n## Context\n\nMove payment orchestration for `payment_intent.succeeded` out of the prior\nlibrary-adapter handler into application-owned code, keeping the existing\npayment and receipt product behavior byte-for-byte. The ingress (signature\nverification, event-type filter, ownership guard, event-ID dedup, per-user\nlock), the DB/mail clients (tracing, idempotency key, durable failure record,\ndeadlines), the runbooks, dashboards, feature flag and rollback path are all\nretained unchanged. The plan under review adds the handler that runs inside\nthose guards. The repo contains only `PLAN.md` and `CLAUDE.md`; there is no\ncode to inspect, so every finding is traced against the retained contracts\nstated in the plan.\n\n## Original plan (as submitted, unchanged)\n\n### Existing contracts retained\nSee `PLAN.md` lines 7–103. Key contracts this review leans on:\n- Ingress verifies signature on raw body; forwards only `payment_intent.succeeded`.\n- `request.params.userId` = `event.data.object.metadata.user_id`, forwarded\n  unchanged, no cast/escape; opaque TEXT incl. punctuation and Unicode.\n  \"A valid signature does not make it safe for SQL.\"\n- Ownership guard: PaymentIntent ID ↔ stored user-ID binding, identity compare only.\n- Event-ID dedup + per-user lock held through handler and completion\n  bookkeeping; completion recorded only after the DB transaction commits.\n- User update is an idempotent assignment (`payment_status=paid`, PI id).\n- Unknown/deleted user → HTTP 200, log, stop.\n- Nil/empty email → `skipped_missing_address`, processing continues.\n- Mail client: 1s deadline, `MailTimeout`, no inline retries, durable\n  notification-attempt record before rethrow, provider idempotency key from PI\n  id, failure-rate + backlog dashboards/alerts, runbook retries notification only.\n- DB exceptions → ingress logs, HTTP 500, Stripe retries.\n- DB+ingress budget 2s inside 10s webhook deadline.\n- Handler feature flag, tested rollback, manual staging replay checklist.\n- One receipt per PaymentIntent with order summary; zero orders → one receipt.\n- Class name, if a class exists: `Webhooks::StripePaymentWebhookHandler` (settled).\n  Separate implementation vs. reuse `WebhookDispatcher`: open.\n\n### Architecture\nNew `StripePaymentWebhookHandler` class bypassing `WebhookDispatcher` for\n\"clean namespace separation\".\n\n### Database access\n`request.params.userId` read directly into a raw SQL fragment for the lookup.\n\n### Webhook fan-out\nUpdate user record AND send notification email, both inline; no error\nhandling on the email leg.\n\n### Tests\nNone planned; rely on existing integration suite.\n\n### Performance\nUser lookup, then one query per order in a loop.\n\n## Step 0 — Nuclear Scope Challenge\n\n### 0A. Premise Challenge\n1. **Right problem?** Yes, narrowly. Owning the orchestration code is a\n   legitimate goal: the library adapter is a dependency boundary the team\n   cannot patch. The framing error is \"clean namespace separation\" as the\n   reason to bypass `WebhookDispatcher`. Namespace ownership is about where\n   the class lives (already settled: `Webhooks::`); it says nothing about\n   whether the class should be dispatched through the shared module. Those\n   are two decisions presented as one.\n2. **Outcome?** Same paid-status update and same receipt, with code the team\n   owns and can test. The plan reaches the ownership outcome directly but\n   regresses two retained invariants on the way: it interpolates an\n   unsanitized external string into SQL (the plan itself says the signature\n   does not make it SQL-safe), and it lets a mail failure surface as a\n   payment failure (HTTP 500 after the payment committed).\n3. **Do nothing?** Payments keep working on the prior adapter handler. The\n   pain (cannot modify orchestration) is real but not urgent; there is no\n   outage driving this. That argues for slowing down on the irreversible\n   parts (data-model or contract changes) and moving fast on the rest.\n   Nothing here is a one-way door except shipping a SQL injection.\n\n### 0B. Existing Code Leverage\n| Sub-problem | Existing code (per retained contracts) | Plan's use |\n|---|---|---|\n| Signature, event filter, ownership, dedup, lock | Ingress middleware + event guard | Reused (runs inside) |\n| Event routing to handler | `WebhookDispatcher` | **Bypassed** — open decision |\n| User lookup | Shared DB client with tracing | Used, but via raw SQL fragment |\n| User update | Existing idempotent assignment | Reused |\n| Recipient policy (nil/empty email) | Retained helper | Reused |\n| Email send, idempotency key, durable failure record | Shared mail client | Reused; exception left unhandled |\n| Order summary loading | Unspecified; plan loops per order | Rebuilt as N+1 |\n| Observability | Ingress logs, DB/mail traces, dashboards, runbooks | Reused |\n| Rollout | Feature flag + rollback + staging checklist | Reused |\n\nRebuilding: the bypass rebuilds event routing that `WebhookDispatcher`\nalready does. The plan gives no reason rebuilding beats registering.\n\n### 0C. Dream State Mapping\n```\n  CURRENT STATE                    THIS PLAN                        12-MONTH IDEAL\n  Library-adapter handler   --->   App-owned handler class   --->   All Stripe event handlers are\n  owns orchestration;              for payment_intent.succeeded;    app-owned classes registered\n  team cannot patch it;            second entry point beside        through ONE dispatcher; each\n  guards live in ingress.          WebhookDispatcher; raw SQL;      has unit + replay tests; every\n                                   unhandled mail leg; no tests.    outcome is a named, traced result.\n```\nThe plan moves toward the ideal on ownership and away from it on entry-point\ncount, test coverage, and SQL hygiene. Each of those is fixable inside the\nstated scope.\n\n### Landscape check\nAside unavailable; WebSearch used. Layer 1 (tried and true): verify signature\non raw body, dedup on `event.id` with a UNIQUE constraint, return 2xx fast,\nreplay real events in tests. Layer 2 (search, 2026): same consensus; none of\nthe results mention SQL parameterization because it is assumed. Layer 3\n(first principles): a webhook response code is a message to Stripe about\nwhether to retry. Once the payment row is committed, a 500 for a failed\nreceipt email asks Stripe to redo work that is already done; the retained\nnotification-retry procedure is the correct retry channel for that leg.\n\n### Retrospective check\nSingle commit (`fe7f2fa Seed review plan`); no prior review cycles, refactors\nor reverts on this branch. No TODOS.md, no FIXME/TODO markers, no stash.\n\n### Frontend/UI scope\nNone. No UI surface is touched; Section 11 will be skipped as not applicable.\n\n## Decision ledger\n\n| ID and owner | Contract and evidence | Current | Proposed | Status | Exact approval and scope |\n|---|---|---|---|---|---|\n| D1 (arch owner) — dispatch path for the new handler | PLAN.md L10–11, L100–103: dispatcher remains available; separate impl vs reuse is open. Class name settled. | Prior adapter handler dispatched via `WebhookDispatcher` | A) register `Webhooks::StripePaymentWebhookHandler` through `WebhookDispatcher`; B) bypass with a second entry point (plan as written); C) no new class, implement inside dispatcher | approved | User answer D1 = A (this session). Scope: Architecture section only; new class registered via `WebhookDispatcher`, one entry point, no bypass. Class name unchanged. |\n| D2 (data owner) — user lookup query construction | PLAN.md L21–26: string forwarded unchanged, no cast/escape, \"not safe for SQL\", opaque TEXT incl. punctuation/Unicode. | Prior handler lookup method unknown (not in plan) | Plan: raw SQL fragment interpolation. Alternatives: bound parameter via shared DB client; existing finder by TEXT id | unresolved | — |\n| D3 (payments owner) — mail exception handling on the inline email leg | PLAN.md L52–53, L60–63, L85–97: client rethrows, records durable attempt first, idempotency key, runbook retries notification only, 500 → Stripe retry. | Prior handler behavior unknown (not in plan) | Plan: no handling → propagates to ingress → HTTP 500. Alternatives: rescue named mail errors after commit, record outcome, 200 | unresolved | — |\n| D4 (eng owner) — automated tests for the new handler | PLAN.md L76–80: staging replay is manual; \"no new automated tests are planned\"; existing integration suite may not cover the new class. | No automated coverage of new handler | Add unit tests for every path + replayed-event integration test behind the flag | unresolved | — |\n| D5 (perf owner) — order summary loading | PLAN.md L81–84, L92–95: order loop is data loading; DB+ingress budget 2s. | Unknown | Plan: one query per order (N+1). Alternative: one batched query per PaymentIntent | unresolved | — |\n\nStatus legend: unresolved, approved, reopened, deferred, declined.\n\n## 0D. Alternatives\n\n### D1 — Dispatch path for the new handler\n\nCommitment grid:\n```text\nCommitment                              | Source/approval or pending | Current            | A: register via dispatcher | B: bypass (plan)         | C: implement inside dispatcher\nClass `Webhooks::StripePaymentWebhookHandler` | settled (PLAN L100–103) | n/a               | yes                        | yes                      | no (violates settled name)\nRuns inside ingress guards               | retained (PLAN L38–39)    | yes                | yes                        | yes, if wired by hand    | yes\nNumber of Stripe entry points            | pending                   | 1                  | 1                          | 2                        | 1\nEvent-type routing owner                 | pending                   | WebhookDispatcher  | WebhookDispatcher          | new class duplicates it  | WebhookDispatcher\nFeature flag / rollback path             | retained (PLAN L74–75)    | dispatcher-level   | flag selects handler in one place | flag must gate two routes | flag selects code path\nHandler identity in traces               | retained (PLAN L98–99)    | yes                | yes                        | yes                      | yes\n```\n\n**A) Register through WebhookDispatcher (recommended).** New app-owned class,\nsame dispatcher. Effort S. Risk low. Pros: one entry point, guards and flag\nwiring stay where they are, rollback flips one registration. Cons: the class\ndepends on the dispatcher's handler interface; \"namespace separation\" is only\nat the class level, which is what the settled name already gives. Reuse:\nfull. Verification: unit test the class; one dispatcher registration test.\n\n**B) Bypass with a second entry point (plan as written).** Effort M. Risk\nmedium-high. Pros: no coupling to dispatcher interface; can evolve the route\nindependently. Cons: two routes to keep in sync with the ingress guards; flag\nmust gate both; a future guard fix lands in one place and not the other;\nduplicates routing. Reuse: partial. Verification: must test that the bypass\nstill sits inside every guard, which is exactly the thing hardest to test.\n\n**C) No new class; implement inside WebhookDispatcher.** Effort S. Risk\nmedium. Pros: least code. Cons: conflicts with the settled class name and the\nstated motivation (application-owned handler); grows the dispatcher into a\ngod module. Reuse: full. Verification: dispatcher tests.\n\nNote: options differ in kind, not coverage — no completeness score.\n\n**Decision D1: A approved.** Amended Architecture: `Webhooks::StripePaymentWebhookHandler`\nis registered with `WebhookDispatcher` for `payment_intent.succeeded`; the\nfeature flag selects prior vs new handler at that single registration. No\nbypass, no second entry point.\n\n### D2 — User lookup query construction\n\nThe plan's own contract (PLAN L21–26) says the user_id string is forwarded\nunchanged, uncast, unescaped, may contain punctuation and Unicode, and \"a\nvalid signature does not make it safe for SQL\". Interpolating it into a raw\nSQL fragment is therefore a SQL injection in the payment path. HOLD SCOPE\nkeeps stated invariants and repairs needed to meet them are in scope; the\nquestion is which repair.\n\nFailure trace of the plan as written: Stripe metadata `user_id` is set by\nwhichever code created the PaymentIntent. A value like `x' OR '1'='1` passes\nsignature verification (Stripe signs whatever was sent) and passes the\nownership guard if the PaymentIntent was created with that same string. The\nlookup then returns an arbitrary row; the handler marks the wrong user paid\nand emails them a receipt. Unicode/punctuation in legitimate IDs also breaks\nthe query (quote characters), turning a valid payment into a DB error → 500 →\nStripe retry loop → on-call alert.\n\nCommitment grid:\n```text\nCommitment                         | Source/approval or pending | Current | A: bound parameter via shared DB client | B: existing finder by TEXT id | C: raw fragment (plan)\nInjection-safe for any TEXT value  | retained invariant (L21–26) | unknown | yes                                    | yes (finder binds)            | no\nOpaque TEXT preserved, no cast     | retained (L24–26)           | yes     | yes                                    | yes, if finder takes TEXT     | yes\nTracing via shared DB client       | retained (L60–63)           | yes     | yes                                    | yes                           | yes, if fragment goes through client\nNew SQL text in handler            | pending                     | n/a     | yes (one parameterized statement)      | no                            | yes\n```\n\n**A) Bound parameter through the shared DB client (recommended if no finder\nexists).** `WHERE id = $1` with the string passed as a bind value. Effort S.\nRisk low. Pros: safe for every byte sequence; keeps tracing; one line.\nCons: SQL text lives in the handler. Verification: unit test with quote,\nsemicolon, comment-marker, and Unicode IDs.\n\n**B) Existing finder by TEXT id (recommended if one exists).** Reuse the\nlookup the prior handler or the account code already calls. Effort S. Risk\nlow. Pros: zero new SQL, DRY with the rest of the app. Cons: only works if\nthat finder takes an opaque TEXT id with no cast; must confirm. Verification:\nsame adversarial-ID tests.\n\n**C) Raw SQL fragment (plan as written).** Effort S. Risk high. Pros: none\nthat survive the plan's own contract. Cons: injection; breaks on legitimate\npunctuation. Not viable against the retained invariant.\n\nA and B are the same commitment (bound lookup) with different reuse; the\nchoice between them is a rung on the reuse ladder, not a behavior change.\nCompleteness: A=10/10, B=10/10 (if finder exists), C=3/10.\n",
  "reportSha256": "217ce4cb888f0f2d99bf9df901e9a1203ac0f7ba54d491dbaaa8609359c46758",
  "seed": "Please review this plan thoroughly in HOLD SCOPE mode. As you go, write your plan-mode plan to /tmp/gstack-owned-display-np1l2aqb/gstack-paid-shard-MmyToP/tmp/gstack-e2e-plan-ceo-njEsdf/gstack-test-plan-ceo.md (use Edit/Write to that exact path).\nProceed directly to the requested CEO review; skip the optional /office-hours prerequisite.\nFinish after this CEO review; I will handle subsequent reviews manually.\n\n# Plan: Payment Processing Integration\n\n## Existing contracts retained\nThe approved motivation is to move payment orchestration out of the prior\nlibrary-adapter handler into application-owned code while retaining the\nexisting payment and receipt product behavior. The shared dispatcher remains\navailable; the proposed bypass below is still an architectural choice to review.\nThe existing ingress middleware verifies the Stripe signature against the\nraw request body and rejects invalid signatures before invoking handlers.\nThe existing ingress forwards only `payment_intent.succeeded` events to\nthis handler; other Stripe event types are acknowledged without invoking it.\nThe existing payload adapter exposes `event.data.object.metadata.user_id`\nas `request.params.userId`. This params object is the parsed body-data map,\nnot URL query/path parameters; all users share one webhook URL.\nThe adapter acknowledges missing, nil, or empty user_id metadata with\nHTTP 200 and an event-correlated warning before invoking this handler.\nFor every nonempty external string it performs no SQL-format validation.\nThe adapter forwards that external string unchanged. It does not cast,\nescape, or SQL-sanitize it; a valid signature does not make it safe for SQL.\nUser IDs are opaque TEXT values, including punctuation and Unicode. The\nlookup has no integer/UUID cast or ID-format restriction; every nonempty\nstring is a valid identifier representation.\nAn existing ingress ownership guard checks the PaymentIntent ID against\nits stored opaque user-ID binding before invoking the handler. A mismatch\nis acknowledged with HTTP 200 and an event-correlated warning. This is an\nidentity comparison, not SQL-format validation; the adapter still forwards\nthe original string unchanged.\nThe existing webhook event guard deduplicates deliveries by Stripe event ID,\nand an existing per-user lock serializes payment updates.\nThe event guard acquires the existing per-user lock before checking the\ncommitted completion marker, and rechecks after any lock wait. It holds\nthat lock through the handler and completion bookkeeping; an overlapping\ncompleted duplicate does not invoke the handler.\nThe new handler runs inside those unchanged guards; this plan does not\nreplace signature verification, event deduplication, or update locking.\nThe existing user update assigns payment_status=paid and the payment intent\nID; it does not increment a balance or counter. Repeating the same payment\nintent assigns the same values, independently of the event-ID guard.\nThe existing lookup-result guard acknowledges unknown/deleted users with\nHTTP 200, logs the event, and stops before user updates or email fan-out.\nThe retained recipient-policy helper treats a nil or empty email address as\nskipped_missing_address: payment processing continues normally, and no mail\nclient call is attempted. It persists an event/user/PaymentIntent-correlated\nskip record, emits a structured warning, and increments the existing counter.\nThe existing notification runbook already covers that skip result: correct\nthe account address, then retry only its recorded notification using the\nsame PaymentIntent idempotency key. It never replays the payment for this case.\nThat recipient policy does not catch failures from sends to nonempty addresses;\nthe shared mail client still rethrows those exceptions to this handler.\nAccount deletion uses the same per-user lock. The handler holds it from\nlookup through update and inline email, so deletion either precedes lookup\n(the existing unknown/deleted-user path) or follows the handler; it cannot\nremove the user between lookup and update.\nThe ingress wrapper already logs event IDs, outcomes, and durations, with\nalerts for failed webhook processing. Those controls remain in place.\nThe existing DB and mail clients attach the adapter user ID and event ID\nto outcome traces, including update success and email delivery success or\nfailure. These shared clients rethrow exceptions unchanged; tracing does\nnot rescue email errors or change the inline email call below.\nThe shared mail client also publishes its delivery failure rate to the\nexisting dashboard and tested on-call alert, including caught exceptions.\nThe existing incident runbook uses the correlated DB and mail outcomes to\ndistinguish committed payments from failed notifications. It directs on-call\nto check provider status and retry only the failed notification through the\nexisting notification retry procedure, never replay the payment blindly.\nDB lookup/update exceptions propagate to that ingress wrapper, which logs\nthe failure and returns HTTP 500 so Stripe retries the event. The existing\nevent-ID dedup guard records completion only after the database transaction\ncommits; failed or rolled-back database attempts remain retryable.\nThe deployment already has a handler feature flag and a documented, tested\nrollback to the prior handler; this change uses that existing rollout path.\nThat documented manual rollout checklist already requires a staging\npayment-event replay for this handler and verification of the user update,\nemail delivery, and correlated outcome trace before enabling it broadly.\nThis is manual deployment verification, not automated handler regression\ncoverage; no new automated tests are planned in the Tests section below.\nThe existing notification contract sends one payment receipt per PaymentIntent,\nincluding a summary of the user orders. With zero orders it still sends one\nreceipt with an empty order summary; the order loop is data loading, never\none email or payment update per order. These product semantics are retained.\nThe shared mail client already derives a provider idempotency key from that\nPaymentIntent ID. The provider durably suppresses duplicate successful sends\nfor the same key across process crashes, webhook retries, and manual retries.\nBefore rethrowing a failed or timed-out send, that client durably records the\nnotification attempt for the existing retry procedure. The dashboard and\non-call alert already monitor failed-notification age and backlog after an\noutage clears, as well as failure rate; the runbook retries those records.\nThe existing mail-client deadline is one second, enforced by cancellation\nof the provider request with no inline retries. It raises MailTimeout on\nexpiry. The retained DB/ingress deadlines bound their combined work to two\nseconds, leaving headroom inside the existing ten-second webhook deadline.\nNeither deadlines nor retry records catch the mail exception for this handler;\nthe shared client still rethrows it to the inline caller described below.\nEvery existing event-correlated outcome trace includes the active handler\nidentity (prior or new), so rollout attribution is already available.\nIf a separate handler class is retained, its already-approved name is\n`Webhooks::StripePaymentWebhookHandler` in the application-owned namespace,\nnever the Stripe library namespace. This naming choice is settled; whether\nto add a separate implementation or reuse WebhookDispatcher remains open.\n\n## Architecture\nWe're adding a new `StripePaymentWebhookHandler` class that will handle Stripe webhooks.\nThis bypasses the existing `WebhookDispatcher` module — we want a clean\nnamespace separation.\n\n## Database access\nThe new endpoint reads `request.params.userId` directly into a raw SQL\nfragment for the lookup query.\n\n## Webhook fan-out\nOn payment success we update the user record AND fire a notification email.\nBoth happen inline; no error handling on the email leg.\n\n## Tests\nNone planned. We'll rely on the existing integration suite catching regressions.\n\n## Performance\nEach webhook lookup hits the database for the user, then fetches each\norder in a loop."
}