@decocms/start 6.1.0 → 6.2.1

package/.agents/skills/deco-migrate-script/SKILL.md

@@ -293,9 +293,10 @@ Generates `MIGRATION_REPORT.md` with:
 ### Phase 7: Bootstrap
 
 Runs automatically after all phases (skipped in `--dry-run`):
-1. `npm install` (or `bun install`)
-2. `npx tsx node_modules/@decocms/start/scripts/generate-blocks.ts`
-3. `npx tsr generate`
+1. `bun install`
+2. `bunx tsx node_modules/@decocms/start/scripts/generate-blocks.ts`
+3. `bunx tsx node_modules/@decocms/start/scripts/generate-invoke.ts` — emits `src/server/invoke.gen.ts` (top-level `createServerFn` declarations for every VTEX action, plus the `forwardResponseCookies()` Set-Cookie bridge). Without this step the site falls back to the `/deco/invoke/...` proxy and the cart breaks at `/checkout` after addItemToCart. See `.cursor/skills/deco-server-functions-invoke/troubleshooting.md` ("Cart 'forgets' items between requests") for the failure mode.
+4. `bunx tsr generate`
 
 ### Phase 8: Compile
 

package/.cursor/skills/deco-apps-vtex-porting/cookie-auth-patterns.md

@@ -31,6 +31,19 @@ export async function vtexFetchWithCookies<T>(
 
 Use in: `checkout.ts`, `auth.ts`, `session.ts` (create/edit).
 
+### Pitfall: never copy with `Headers.entries()` or `forEach`
+
+When a caller pushes the captured cookies onto the request scope's response headers (e.g. `RequestContext.responseHeaders.append("set-cookie", c)`), the eventual HTTP-response bridge must read them back with `Headers.getSetCookie()`. **Do not** iterate `headers.entries()` (or `forEach`) and re-append, because both collapse multiple `Set-Cookie` values into a single comma-joined string, which browsers silently discard. The result: the cart appears empty after addItemToCart even though the action returned an OrderForm with items.
+
+Two bridges where this rule applies in a TanStack Start site:
+
+- `src/server/invoke.gen.ts` — the auto-generated `forwardResponseCookies()` already uses `getSetCookie()`. Re-run `bunx tsx node_modules/@decocms/start/scripts/generate-invoke.ts` if the file is missing or stale.
+- `@decocms/start/src/admin/invoke.ts` — `forwardCtxHeadersTo()` does the same for the `/deco/invoke/...` HTTP path. Versions ≥ 5.0.0 ship the fix.
+
+### Client-side `setOrderFormIdCookie` is defense-in-depth, not the fix
+
+Some migrated `useCart` hooks (e.g. miess-01-tanstack) manually call `document.cookie = "checkout.vtex.com__orderFormId=..."` after each cart action. That only patches one cookie — `segment`, `sc`, `vtex_session` etc. are still dropped. Keep the workaround if you like (cheap, idempotent), but the real fix is the two server-side bridges above. Once both are in place, the manual cookie write can be removed without regressing the cart.
+
 ## buildAuthCookieHeader
 
 VTEX IO GraphQL at `{account}.myvtex.com` requires both cookie names:

package/.cursor/skills/deco-apps-vtex-review/SKILL.md

@@ -63,6 +63,21 @@ const result = await vtexFetchWithCookies<OrderForm>(url, opts);
 
 **Where NOT needed**: Read-only loaders, GraphQL queries.
 
+**Server→browser bridge** — the cookies that `vtexFetchWithCookies` captures must be forwarded onto the outgoing HTTP response, or the browser never sees them and the cart appears empty on the next request. There are two bridge points in a TanStack Start site, and both must be wired:
+
+1. **`src/server/invoke.gen.ts`** (TanStack RPC path). Generated by `bunx tsx node_modules/@decocms/start/scripts/generate-invoke.ts`. Audit:
+   - File exists?
+   - Contains `function forwardResponseCookies()`?
+   - Every action handler calls `forwardResponseCookies()` after the `await`?
+
+   If any answer is "no", regenerate with the script above. Then make sure `useCart`, `useUser`, `useWishlist` import `invoke` from `~/server/invoke.gen` (or a barrel that re-exports it), not from the proxy `~/runtime.ts`.
+
+2. **`@decocms/start/src/admin/invoke.ts`** (`/deco/invoke/...` HTTP path). The framework's single + batch invoke handlers must use `Headers.getSetCookie()` (not `entries()`!) when copying `RequestContext.responseHeaders` onto the response. Pin to a version ≥ 5.0.0 that ships `forwardCtxHeadersTo`.
+
+The historical failure mode: a `for…of headers.entries()` loop collapsed N `Set-Cookie` values into one comma-joined string, which browsers silently discard. Every VTEX cart action returns 3–5 cookies (`checkout.vtex.com__orderFormId`, `segment`, `sc`, `vtex_session`…), so even one collapse breaks the entire cart flow.
+
+**Quick diagnosis**: Add an item, watch DevTools → Network → the cart-action response should have **multiple** `Set-Cookie:` rows, not one comma-joined line.
+
 ### 2. Auth Cookie Headers
 
 All authenticated VTEX IO GraphQL calls need both cookie variants:

package/.cursor/skills/deco-server-functions-invoke/troubleshooting.md

@@ -1,5 +1,27 @@
 # Troubleshooting
 
+## Cart "forgets" items between requests / /checkout opens empty after addItemToCart
+
+**Symptom**: `invoke.vtex.actions.addItemsToCart(...)` succeeds (returns an `OrderForm` with items), but the next page load — or clicking the cart icon — shows an empty cart, and `/checkout` lands on a fresh empty order. Sometimes the orderFormId is different from the one just returned.
+
+**Root cause**: The VTEX cart cookies (`checkout.vtex.com__orderFormId`, `segment`, `sc`, `vtex_session`) never reach the browser because somewhere in the chain, multiple `Set-Cookie` headers got collapsed into a single comma-joined string. Browsers silently discard malformed `Set-Cookie` values, so every subsequent request hits VTEX without authentication and gets a new empty orderForm.
+
+**Two places this can break**:
+
+1. **`src/server/invoke.gen.ts` missing or stale**. This is the TanStack RPC path. Each action must call `forwardResponseCookies()` after awaiting the underlying VTEX call. The helper uses `Headers.getSetCookie()` (not `entries()`!) to read the un-collapsed list and writes each value to TanStack's response via `setResponseHeader("set-cookie", [...])`. If the file doesn't exist, the site falls back to the `/deco/invoke/...` proxy.
+
+2. **`/deco/invoke/...` HTTP proxy** (`~/runtime.ts` pattern). The framework's admin handler (`@decocms/start/src/admin/invoke.ts`) used to iterate `RequestContext.responseHeaders.entries()` which collapses Set-Cookie. Fixed in @decocms/start ≥ 5.0.0 by switching to `getSetCookie()` + a `forwardCtxHeadersTo()` helper applied on both single and batch paths.
+
+**Diagnosis**: Open DevTools → Network → response to the cart action. You should see **multiple distinct** `Set-Cookie:` rows. If you see a single `Set-Cookie: foo=1, bar=2; Path=/, baz=3` line, that's the collapse bug.
+
+**Fix**:
+1. Upgrade `@decocms/start` to the version with `forwardCtxHeadersTo` in `src/admin/invoke.ts` (search the file — both single and batch handlers should call it).
+2. Run `bunx tsx node_modules/@decocms/start/scripts/generate-invoke.ts` to regenerate `src/server/invoke.gen.ts`. Verify it has `function forwardResponseCookies()` and that every emitted handler calls it.
+3. Make sure `useCart` (and other VTEX hooks) imports `invoke` from `~/server/invoke.gen` (or a barrel re-export of it), not from `~/runtime`.
+4. The migration script (`scripts/migrate.ts` bootstrap) runs `generate-invoke.ts` automatically on freshly-migrated sites — if a site was migrated before that, run the generator manually.
+
+**Client-side workaround** (defense-in-depth, removable): some sites manually `document.cookie = "checkout.vtex.com__orderFormId=..."` inside `useCart`. That only patches one cookie of many. With the server-side fix in place, the workaround is harmless but no longer load-bearing — see `~/conductor/workspaces/miess-01-tanstack/newport-beach/src/hooks/useCart.ts` for an example.
+
 ## CORS Error on Add to Cart / Checkout
 
 **Symptom**: Browser console shows CORS error when calling VTEX API directly.

package/docs/rum-plan.md

@@ -0,0 +1,209 @@
+# RUM (Real-User Monitoring) — Plan
+
+> Sibling deliverable to [`observability_refinement_plan_4fa41548.plan.md`](../../../.cursor/plans/observability_refinement_plan_4fa41548.plan.md).
+> The refinement plan covers server-side observability end-to-end. This
+> plan covers what runs **in the browser** — Core Web Vitals, JS errors,
+> long tasks, resource timing, custom user-journey events.
+
+## Why this is a separate plan
+
+Server-side telemetry tells us what our Workers did. RUM tells us what
+the **user actually experienced** — including everything outside our
+edge (DNS, TLS handshake, third-party scripts, the user's CPU, their
+flaky LTE link, their ad-blocker). The two answer different questions:
+
+| Question | Answered by |
+|---|---|
+| "Did we serve the request?" | server outcomes (Phase 2 of refinement plan) |
+| "Was the user able to read the page?" | RUM (this plan) |
+| "Did our deploy regress LCP on iOS Safari?" | RUM (this plan) |
+| "Why did checkout abandon at 73%?" | RUM + server outcomes joined |
+
+Today the answer to every RUM question is "we don't know." The plan
+puts a floor on that.
+
+## Scope tiers — the decision you're making
+
+The size of this plan changes by an order of magnitude depending on
+scope. Three defensible tiers below; the work is **strictly additive**
+between them so we can commit to Tier 1, run it for a quarter, and
+upgrade to Tier 2 or 3 only if the data we collect surfaces a need.
+
+### Tier 1 — Core Web Vitals + JS errors (recommended for v1)
+
+**What's collected:**
+- LCP (Largest Contentful Paint), CLS (Cumulative Layout Shift),
+  INP (Interaction to Next Paint), FCP, TTFB — via the standard
+  [`web-vitals`](https://github.com/GoogleChrome/web-vitals) library.
+- `window.onerror` + `window.onunhandledrejection` — uncaught JS errors
+  with stack, source URL, line/col, user agent, route pattern, deploy
+  id, `request.id` (same one the server stamped in Phase 1, joinable to
+  `otel_logs` and `otel_traces`).
+- Page-context attributes: `route_pattern`, `service.version`,
+  `service.name`, `deployment.environment`, viewport, connection type
+  (`navigator.connection.effectiveType`), `cf-ray`.
+
+**What's NOT collected:**
+- Session replay.
+- Custom user-journey events (add-to-cart, scroll-to-fold, etc.).
+- Resource timing for every asset.
+- User interaction heatmaps.
+
+**Implementation footprint:** ~3 dev-weeks.
+- `@decocms/start/sdk/rum.ts` — single browser-side module bundled into
+  the site entry. Reads `web-vitals` (peer dep, ~3KB gzipped), batches
+  events, sends to `/__deco/rum` on the same origin (no CORS / no
+  third-party script).
+- `cmsRoute.ts` already serves a worker; add a `/__deco/rum` handler
+  that validates the payload, redacts referrer/URL via the shared PII
+  library (Phase 1), and forwards to the OTLP HTTP endpoint as
+  `otel_logs` with `SeverityText="INFO"` and `LogAttributes.rum.*`.
+- ClickHouse rows land in the existing `otel_logs` table — no new
+  schema, no new pipeline. The Tier 1 query "p75 LCP per route per
+  site, last 7 days" is a single SQL join on the existing tables.
+- One Grafana dashboard template added to
+  `stats-lake/observability/dashboards/templates/site-rum.json`. Auto-
+  provisioned via the existing Phase 5 script — `--with-rum` flag
+  mirrors `--with-alerts`.
+
+**Cost:** marginal. One row per pageview per metric (~5 rows / pageview)
+adds < 5% to existing log volume. Within the cost guardrail dashboard
+(Phase 6) headroom.
+
+**Risks:**
+- INP requires the modern API; falls back to FID on older browsers.
+  Reported separately so the metric isn't muddied.
+- `web-vitals` runs ~50ms of JS on first input; teams that obsess over
+  shaving milliseconds will want a build flag to disable it. Ship one
+  off the bat.
+
+### Tier 2 — Tier 1 + custom user-journey events + resource timing
+
+**What's added:**
+- A typed `rum.track(name, attributes)` API exposed from
+  `@decocms/start/sdk/rum.ts`. Sites call
+  `rum.track('add_to_cart', { sku, price, currency })` and the event
+  flows through the same `/__deco/rum` endpoint into `otel_logs` with a
+  reserved attribute namespace (`rum.event.*`).
+- Resource Timing API rollup: for each pageview, total resource bytes,
+  count by content-type, slowest 5 URLs (with paths redacted). Helps
+  diagnose when a third-party tag has gone bad.
+- A `rum.identify(userIdHash)` call that lets sites cohort by logged-in
+  user without sending PII (the site hashes the user id before passing
+  it in; we never see plaintext).
+
+**Implementation footprint:** ~6 additional dev-weeks on top of Tier 1.
+- The framework-side API + types: ~2 weeks.
+- Resource Timing payload shape + redaction: ~1 week.
+- Documentation, codemod fixtures, and an audit rule that enforces
+  the redaction helpers stay in use: ~3 weeks.
+- A second Grafana dashboard (`site-rum-events.json`) that pivots on
+  `rum.event.*`.
+
+**Risks:**
+- Cardinality explosion: a site that emits `track('view_product', { id })`
+  with the product id as a label creates one time-series per SKU. The
+  attribute system has to **enforce** id-as-attribute / id-not-as-label
+  via the type system + a runtime check in the framework. Doable but
+  it's the new piece that has to be designed right.
+- Custom events drift across sites unless we standardize a vocabulary.
+  Recommend shipping a small reserved-name list (`add_to_cart`,
+  `begin_checkout`, `purchase`, `view_product`) so fleet-wide dashboards
+  can roll up "conversion funnel" without per-site cooperation.
+
+### Tier 3 — Tier 2 + session replay + interaction heatmaps
+
+**What's added:**
+- Session replay: capture every DOM mutation + every user input as a
+  delta-encoded stream, replay it as a video in HyperDX / a custom
+  viewer. The canonical OSS implementation is
+  [`rrweb`](https://github.com/rrweb-io/rrweb).
+- Interaction heatmaps: aggregate click positions over a page within a
+  given time window.
+
+**Implementation footprint:** months.
+- ~30KB gzipped of `rrweb` on every pageview — measurable LCP impact.
+  Mitigation: lazy-load after first interaction; some events miss the
+  first paint.
+- The replay payload is enormous (~100KB/min/session compressed).
+  Multiplied by realistic session counts this is a 10-100× ingest
+  blowup vs Tier 1. Replay storage is the new bottleneck, not the
+  schema; we'd need an R2-backed cold tier separate from ClickHouse.
+- A privacy review needs to ship before the first byte of replay
+  flows. PII redaction has to happen client-side before the network —
+  rrweb's "mask all inputs" mode is the floor; password fields, credit
+  card numbers, and authenticated user-data attributes need explicit
+  privacy classes.
+
+**Risks:**
+- Privacy: replay is a high-magnification footgun. One regression in
+  the mask config and we've recorded a user's credit card. The whole
+  payment-flow page must be force-masked at the framework level, not
+  opt-in per site.
+- Cost: 10-100× the ingest of Tier 1 even with aggressive sampling.
+  The Phase 6 cost-guardrail dashboard will trip; needs a new tier of
+  retention policies (replay rows expire at 30d, not 90d like logs).
+
+## Out of scope (regardless of tier)
+
+- **Synthetic monitoring.** Lighthouse runs against canonical journeys
+  on a cron. Covers a different need — "would a clean browser have
+  hit our SLO?" rather than "what did real users see?". A separate
+  initiative if we want it.
+- **Heatmaps for individual users.** Aggregate heatmaps only; never
+  identifiable.
+- **A/B-test attribution.** Sites that want it can pass an experiment
+  cohort id through `rum.identify` — we don't ship the experiment
+  framework itself.
+
+## Recommended sequencing
+
+Ship Tier 1 in one PR. Live with the data for a quarter. If during
+that quarter the question "but what did the user actually click before
+they bounced?" comes up more than twice, plan and ship Tier 2. If
+during *that* quarter we hit a category of bug that can only be
+diagnosed by replay (so far: 0), plan Tier 3.
+
+**Anti-recommendation:** do not commit to Tier 3 up front. Replay is
+the highest-cost, highest-privacy-risk piece of the whole observability
+surface, and the bug categories that genuinely need it are rare.
+
+## Decision points
+
+These mirror the main plan's structure — answer once, then this
+document gets a follow-up PR turning answers into TODOs.
+
+1. **Tier selection.** Tier 1 only / Tier 1 + Tier 2 / Full Tier 3.
+2. **Identify hashing.** If we're shipping Tier 2, do sites pass in a
+   client-side hash, or do we accept plaintext IDs and hash at the
+   ingest worker? (Recommend client-side hash — keeps plaintext out of
+   our pipeline entirely.)
+3. **Sampling.** RUM events are cheap per-row but high-volume. Default
+   sample rate: 100% (Tier 1), 100% (Tier 2 events), 10% (Tier 3
+   replay). Confirm or revise per tier.
+
+## Files this plan would touch (Tier 1)
+
+```
+deco-start/
+├── src/sdk/rum.ts                  # NEW — browser-side instrumentation
+├── src/sdk/rum.server.ts           # NEW — /__deco/rum handler
+├── src/admin/setup.ts              # ROUTE — mount /__deco/rum
+├── src/sdk/observability.ts        # EXPORT — re-export rum API
+├── package.json                    # DEP — add `web-vitals` peer dep
+└── docs/rum.md                     # NEW — site-side usage docs
+
+stats-lake/observability/
+└── dashboards/templates/site-rum.json   # NEW
+```
+
+## Why this is a plan and not an implementation
+
+The user explicitly asked for RUM to be in a separate plan document
+rather than rolled into the refinement plan. The scope-tier decision
+above is the single highest-leverage choice; everything downstream
+follows from it, and "Tier 3 because Tier 3 is biggest" is the wrong
+default. A 30-minute conversation on the tier choice saves weeks of
+work in the wrong direction.
+
+Open the matching Linear / GitHub issue once a tier is selected.

package/docs/runbooks/README.md

@@ -0,0 +1,40 @@
+# Runbooks
+
+Tested response procedures for the alerts auto-provisioned by
+[`stats-lake/observability/`](https://github.com/decocms/stats-lake/blob/main/observability/README.md).
+
+Every alert generated by `provision-dashboards.ts` carries a
+`runbook_url` annotation that points to a Markdown file in this
+directory. Each runbook follows the same structure so on-call can read
+top-to-bottom under stress:
+
+1. **What this alert means.** One paragraph, no jargon.
+2. **First check (60 seconds).** The single most likely cause and how to
+   confirm it.
+3. **Diagnostic queries.** ClickHouse SQL the responder can paste into
+   Grafana / ClickStack to dig deeper.
+4. **Common causes & fixes.** Ranked by frequency. Each with a "did
+   that fix it?" verification step.
+5. **Escalation.** When to page a domain owner, and who.
+6. **Post-mortem hook.** What to capture so the post-mortem isn't
+   reconstructed from memory.
+
+## Runbook catalogue
+
+| Alert ID                  | Runbook                                                |
+|---------------------------|--------------------------------------------------------|
+| `http-error-spike`        | [`http-error-spike.md`](./http-error-spike.md)         |
+| `http-latency-spike`      | [`http-latency-spike.md`](./http-latency-spike.md)     |
+| `cache-hit-drop`          | [`cache-hit-drop.md`](./cache-hit-drop.md)             |
+| `commerce-upstream-slow`  | [`commerce-upstream-slow.md`](./commerce-upstream-slow.md) |
+| `tail-exception-spike`    | [`tail-exception-spike.md`](./tail-exception-spike.md) |
+
+## Authoring a new runbook
+
+When you add a new alert template, add a runbook with the same ID. The
+provisioning script doesn't enforce the link today — that gate lands in
+Phase 6 (Governance), but treat it as required: an alert without a
+runbook is a half-shipped alert.
+
+Keep runbooks short. If a section grows past 20 lines, split it out
+into a dedicated incident-pattern doc and link to it from the runbook.

package/docs/runbooks/cache-hit-drop.md

@@ -0,0 +1,83 @@
+# Runbook: `cache-hit-drop`
+
+> A site's edge cache hit rate fell below its own 24h rolling baseline by 3σ for ≥ 10 minutes.
+
+## What this alert means
+
+The edge cache is missing more than usual. On the user side this
+manifests as slower page loads. On the cost side it means more origin
+requests (more billing for Workers + commerce API calls). On the
+upstream side it can become a thundering herd if many users hit a
+freshly-evicted entry simultaneously.
+
+## First check (60 seconds)
+
+Was there a deploy or a cache purge in the last 10 minutes? Cold caches
+recover quickly (5–10m) so if the alert is fresh and a deploy is
+recent, this often self-heals.
+
+```sql
+-- Recent deploys (any change to service.version visible in metrics)
+SELECT ResourceAttributes['service.version'] AS version, min(TimeUnix) AS first_seen
+FROM otel_metrics_sum
+WHERE ServiceName = '{site}'
+  AND TimeUnix > now() - INTERVAL 1 HOUR
+GROUP BY version
+ORDER BY first_seen DESC;
+```
+
+If neither deploy nor purge fired in the window, the cache miss share
+indicates a real regression — proceed below.
+
+## Diagnostic queries
+
+```sql
+-- Hit / miss share by route_pattern, last 30 minutes
+SELECT
+  Attributes['route_pattern'] AS route,
+  countIf(MetricName = 'cache_hit_total') AS hits,
+  countIf(MetricName = 'cache_miss_total') AS misses,
+  hits / nullIf(hits + misses, 0) AS hit_rate
+FROM otel_metrics_sum
+WHERE MetricName IN ('cache_hit_total', 'cache_miss_total')
+  AND ServiceName = '{site}'
+  AND TimeUnix > now() - INTERVAL 30 MINUTE
+GROUP BY route
+ORDER BY misses DESC
+LIMIT 20;
+```
+
+```sql
+-- Cache decision distribution by cache_profile
+SELECT
+  Attributes['profile'] AS profile,
+  Attributes['decision'] AS decision,
+  sum(toFloat64(Value)) AS n
+FROM otel_metrics_sum
+WHERE MetricName = 'cache_hit_total'
+  AND ServiceName = '{site}'
+  AND TimeUnix > now() - INTERVAL 30 MINUTE
+GROUP BY profile, decision
+ORDER BY n DESC;
+```
+
+## Common causes & fixes
+
+| Rank | Cause                                                       | How to confirm                                                | Fix                                                                                                       |
+|------|-------------------------------------------------------------|----------------------------------------------------------------|------------------------------------------------------------------------------------------------------------|
+| 1    | Deploy purged the version cache (`X-Cache-Version` flipped) | Recent `service.version` in the deploy query                  | Wait 10m for cache to warm. If sustained, check that the new build hash is propagating consistently.       |
+| 2    | A new query parameter is hashing into the cache key         | One route's MISS share is far higher than the rest             | Check `cacheHeaders` / `ignoreSearchParams` config for that route; add the new param to the ignore list.   |
+| 3    | Set-Cookie present on a previously cacheable response       | `X-Cache: BYPASS` with `X-Cache-Reason: private-set-cookie` on the affected route | Inspect the section that started emitting cookies; move the cookie write to a non-cacheable POST handler. |
+| 4    | A real burst of unique URLs (e.g. crawler scanning long-tail) | `Attributes['route_pattern']` doesn't change but distinct paths multiply | If a known bot, add a WAF rule. If a real catalog query, consider broader cache profile.                  |
+
+## Escalation
+
+- Sustained > 1 hour despite no deploy → page the site team owner.
+- Suspected bot/abuse → loop in security / WAF on-call.
+
+## Post-mortem hook
+
+- The "before" hit rate and the "after" hit rate.
+- The top route that lost the hit rate.
+- A representative response header snippet showing `X-Cache`,
+  `X-Cache-Profile`, `X-Cache-Reason`.

package/docs/runbooks/commerce-upstream-slow.md

@@ -0,0 +1,88 @@
+# Runbook: `commerce-upstream-slow`
+
+> A site's `commerce_request_duration_ms` p95 exceeded its own 24h rolling baseline by 3σ for ≥ 10 minutes.
+
+## What this alert means
+
+Calls out to a commerce provider (VTEX, Shopify, or similar) are
+taking abnormally long for *this* site. Because SSR is synchronous on
+upstream commerce calls, a slow upstream cascades into the user-facing
+`http-latency-spike` alert almost immediately. If both fired together,
+this is the root cause — fix here first.
+
+## First check (60 seconds)
+
+Which provider/operation is slow? The same dashboard's "Commerce p95
+by provider/operation" panel breaks it out. Note the
+`provider.operation` string — e.g. `vtex.intelligent-search.product_search`.
+
+If a single operation is responsible, jump to "Common causes" #1.
+If multiple operations from the same provider are slow simultaneously,
+that's a provider-wide regression — jump to "Common causes" #2.
+
+## Diagnostic queries
+
+```sql
+-- p95 commerce latency by provider + operation, last hour
+SELECT
+  toStartOfInterval(TimeUnix, INTERVAL 5 MINUTE) AS t,
+  Attributes['provider'] AS provider,
+  Attributes['operation'] AS op,
+  quantileBFloat16(0.95)(toFloat64(Sum / nullIf(Count, 0))) AS p95
+FROM otel_metrics_histogram
+WHERE MetricName = 'commerce_request_duration_ms'
+  AND ServiceName = '{site}'
+  AND TimeUnix > now() - INTERVAL 1 HOUR
+GROUP BY t, provider, op
+ORDER BY t, p95 DESC;
+```
+
+```sql
+-- Commerce call status distribution — are we getting 5xx from upstream?
+SELECT
+  Attributes['provider'] AS provider,
+  Attributes['operation'] AS op,
+  Attributes['status_class'] AS status_class,
+  count() AS n
+FROM otel_metrics_histogram
+WHERE MetricName = 'commerce_request_duration_ms'
+  AND ServiceName = '{site}'
+  AND TimeUnix > now() - INTERVAL 30 MINUTE
+GROUP BY provider, op, status_class
+ORDER BY n DESC;
+```
+
+```sql
+-- VTEX SWR cache effectiveness on the slow operation
+SELECT
+  Attributes['cached'] AS cached,
+  count() AS n,
+  avg(toFloat64(Sum / nullIf(Count, 0))) AS avg_ms
+FROM otel_metrics_histogram
+WHERE MetricName = 'commerce_request_duration_ms'
+  AND ServiceName = '{site}'
+  AND Attributes['operation'] = '<paste operation here>'
+  AND TimeUnix > now() - INTERVAL 30 MINUTE
+GROUP BY cached;
+```
+
+## Common causes & fixes
+
+| Rank | Cause                                                | How to confirm                                                                                  | Fix                                                                                                                |
+|------|------------------------------------------------------|--------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------|
+| 1    | One specific upstream operation is slow              | Single `provider.operation` row dominates the p95 query                                          | Check provider status page (status.vtex.com, www.shopifystatus.com). If clean, see if we recently changed payload size or filter on that operation. |
+| 2    | Provider-wide regression                             | Multiple operations from the same `provider` regressed simultaneously                            | Public provider status page is usually the source of truth. Open a ticket with the provider citing our timing window.    |
+| 3    | VTEX SWR / cachedLoader hit rate dropped             | Query 3 shows `cached=false` share rose                                                          | Inspect recent loader changes for the affected section. May have invalidated the cache key by changing the loader signature. |
+| 4    | Region-specific (CF colo → upstream latency)         | `region` label on the metric isolates one CF colo                                                | Usually transient; CF will rebalance. If sustained, file a CF support ticket.                                       |
+
+## Escalation
+
+- Provider-wide regression confirmed → notify the affected customer-facing teams; this is communication-shaped, not engineering-shaped.
+- One operation slow, no provider status incident → page the site team owner for that route.
+
+## Post-mortem hook
+
+- The `provider.operation` string and its p95 timeline.
+- The cache (`cached=true/false`) split on that operation.
+- A representative trace from `otel_traces` showing the slow span
+  (`SpanName LIKE 'vtex.%'` or `'shopify.%'`).

package/docs/runbooks/http-error-spike.md

@@ -0,0 +1,98 @@
+# Runbook: `http-error-spike`
+
+> A site's 5xx error rate exceeded its own 24h rolling baseline by 3σ for ≥ 10 minutes.
+
+## What this alert means
+
+Real users are getting 5xx responses at a rate that's statistically
+abnormal for this specific site. The alert uses a per-site anomaly band
+(not a fleet-wide threshold) so a site that normally runs at 0.3% 5xx
+fires for spikes other sites wouldn't notice — and a site that normally
+runs at 4% (a known-noisy legacy storefront) doesn't false-positive at
+4.1%.
+
+## First check (60 seconds)
+
+Look at the **commerce upstream p95** panel on the same dashboard. If
+that spiked at the same moment, the root cause is almost always an
+upstream commerce API regressing. Stop here, jump to
+[`commerce-upstream-slow.md`](./commerce-upstream-slow.md).
+
+If commerce p95 is flat, the 5xx is internal — proceed below.
+
+## Diagnostic queries
+
+Paste into ClickStack or a Grafana Explore panel pointed at the
+ClickHouse datasource.
+
+```sql
+-- Top error routes for this site, last 30 minutes
+SELECT
+  Attributes['route_pattern'] AS route,
+  countIf(Attributes['status_class'] = '5xx') AS errors,
+  count()                                     AS total,
+  errors / total                              AS rate
+FROM otel_metrics_sum
+WHERE MetricName = 'http_requests_total'
+  AND ServiceName = '{site}'
+  AND TimeUnix > now() - INTERVAL 30 MINUTE
+GROUP BY route
+HAVING errors > 0
+ORDER BY rate DESC
+LIMIT 20;
+```
+
+```sql
+-- Recent exceptions captured by the tail worker
+SELECT Timestamp, Body, LogAttributes['url.path'] AS path, LogAttributes['http.response.status_code'] AS status
+FROM otel_logs
+WHERE ServiceName = '{site}'
+  AND SeverityText = 'ERROR'
+  AND LogAttributes['_source'] = 'tail-worker'
+  AND LogAttributes['_outcome'] = 'exception'
+  AND Timestamp > now() - INTERVAL 30 MINUTE
+ORDER BY Timestamp DESC
+LIMIT 100;
+```
+
+```sql
+-- Did a deploy correlate? List versions seen in the last hour
+SELECT
+  ResourceAttributes['service.version'] AS version,
+  min(Timestamp) AS first_seen,
+  max(Timestamp) AS last_seen,
+  count() AS log_count
+FROM otel_logs
+WHERE ServiceName = '{site}'
+  AND Timestamp > now() - INTERVAL 1 HOUR
+GROUP BY version
+ORDER BY first_seen DESC;
+```
+
+## Common causes & fixes
+
+| Rank | Cause                                              | How to confirm                                              | Fix                                                                 |
+|------|----------------------------------------------------|-------------------------------------------------------------|---------------------------------------------------------------------|
+| 1    | A recent deploy regressed                          | Top query above shows a `service.version` that flipped just before the spike | Roll back via Cloudflare dashboard `Deployments → Rollback`. Confirm via a fresh `service.version` line in the next 5m. |
+| 2    | A specific route is broken (one bad section)       | Top error routes query shows one `route_pattern` at 100% error rate | Check the recent commits to that section. Roll back or `Lazy` wrap it for graceful degradation. |
+| 3    | Upstream cache layer evicted; cold-cache thundering herd | `cache_miss_total` for the same window spikes proportionally to errors | Wait it out — usually self-heals in 5m. If sustained, check that `staleTime` is set correctly on cmsRouteConfig. |
+| 4    | Origin (commerce API) returning 5xx                | `commerce_request_duration_ms` spike OR commerce logs       | See [`commerce-upstream-slow.md`](./commerce-upstream-slow.md).      |
+
+## Escalation
+
+- **Site team owner** if a fix isn't obvious in 15 minutes (slack
+  `#deco-platform`).
+- **Cloudflare support** if all sites in a region are affected
+  simultaneously (look at the `region` label on the metrics) — this
+  has happened during CF colo incidents.
+
+## Post-mortem hook
+
+Capture before the alert clears:
+- `request.id` of one failing request (from the response header
+  `X-Request-Id` of a manually-reproduced 5xx).
+- A representative tail-worker log row with stack trace.
+- The deploy `service.version` window during the spike.
+
+Stash them in the incident ticket so the post-mortem has the
+correlation IDs it needs.