📦 deps(thirdparty): update snapshots
This commit is contained in:
@@ -0,0 +1,46 @@
|
||||
# Support Topics
|
||||
|
||||
Support topics are small, candidate-scoped investigation guardrails injected into sub-agent briefs.
|
||||
|
||||
They are not recommendations, gates, scanners, or broad documentation. A topic tells the investigator what evidence to check, what false positives to avoid, and when to abstain for one class of candidate.
|
||||
|
||||
## Add A Topic
|
||||
|
||||
Add one file: `references/support-topics/<id>.md`.
|
||||
|
||||
The filename must match the `id`. Frontmatter uses a strict subset of YAML: one `key: value` per line, arrays as JSON arrays.
|
||||
|
||||
```md
|
||||
---
|
||||
id: cdn-cache-auth-safety
|
||||
title: CDN cache auth safety
|
||||
status: active
|
||||
candidateKinds: ["uncached_route", "cache_header_gap"]
|
||||
frameworks: ["*"]
|
||||
priority: 90
|
||||
citations: ["https://vercel.com/docs/caching/cdn-cache"]
|
||||
maxBriefChars: 900
|
||||
---
|
||||
|
||||
## Investigation Brief
|
||||
...
|
||||
|
||||
## Evidence To Check
|
||||
...
|
||||
|
||||
## Do Not Recommend When
|
||||
...
|
||||
|
||||
## Verification
|
||||
...
|
||||
```
|
||||
|
||||
## Rules
|
||||
|
||||
- Every active topic must cite only URLs or skill-rule refs already present in `references/docs-library.json`.
|
||||
- Use `candidateKinds` to keep the topic narrow. Use `"*"` only for workflow/protocol topics that truly apply to every candidate.
|
||||
- Use optional `metrics` only when a topic applies to a specific candidate metric, such as `["LCP"]`, `["INP"]`, or `["CLS"]` for Core Web Vitals.
|
||||
- Use optional `routePatterns` as JavaScript regex source strings when a topic should appear only for specific candidate routes, such as `["(^|/)404$"]`.
|
||||
- Keep the body below `maxBriefChars`; the brief renderer caps selected topics before they reach the sub-agent.
|
||||
- Put URLs in frontmatter only. Topic bodies should describe checks and guardrails, not cite new sources.
|
||||
- Do not include internal repository paths, service names, pricing tables, exact savings claims, or framework APIs without version gating.
|
||||
+22
@@ -0,0 +1,22 @@
|
||||
---
|
||||
id: astro-edge-middleware-scope
|
||||
title: Astro edge middleware scope
|
||||
status: active
|
||||
candidateKinds: ["middleware_heavy"]
|
||||
frameworks: ["astro@*"]
|
||||
priority: 88
|
||||
citations: ["https://vercel.com/docs/frameworks/frontend/astro", "https://docs.astro.build/en/guides/integrations-guide/vercel/"]
|
||||
maxBriefChars: 800
|
||||
---
|
||||
|
||||
## Investigation Brief
|
||||
Astro middleware can run at the edge for broad request sets. If middleware volume is high, prove which paths actually need interception.
|
||||
|
||||
## Evidence To Check
|
||||
Use middleware invocation share and top paths. Inspect adapter middleware mode, middleware source, auth/redirect logic, and whether static assets, prerendered pages, or public pages are being intercepted.
|
||||
|
||||
## Do Not Recommend When
|
||||
Do not bypass required auth, locale, header, or routing logic. Do not move global middleware work into every page when the current scope is already minimal.
|
||||
|
||||
## Verification
|
||||
Name the middleware share, dominant paths, current middleware mode, and exact source or config line to narrow.
|
||||
+22
@@ -0,0 +1,22 @@
|
||||
---
|
||||
id: astro-output-mode-and-isr
|
||||
title: Astro output mode and ISR
|
||||
status: active
|
||||
candidateKinds: ["uncached_route", "rendering_candidate"]
|
||||
frameworks: ["astro@*"]
|
||||
priority: 90
|
||||
citations: ["https://vercel.com/docs/frameworks/frontend/astro", "https://docs.astro.build/en/guides/on-demand-rendering/", "https://docs.astro.build/en/reference/configuration-reference/"]
|
||||
maxBriefChars: 850
|
||||
---
|
||||
|
||||
## Investigation Brief
|
||||
Astro defaults to static output; `server` output makes pages render on demand unless route-level prerendering changes that. First decide whether the hot route truly needs SSR.
|
||||
|
||||
## Evidence To Check
|
||||
Inspect `astro.config`, adapter options, `output`, route-level `prerender`, dynamic params, middleware, and whether the content is shared across visitors. Compare route cache result and request volume.
|
||||
|
||||
## Do Not Recommend When
|
||||
Do not prerender or cache personalized, preview, cart, checkout, or auth-gated pages. Do not change output mode for the whole app when one route-level flag is enough.
|
||||
|
||||
## Verification
|
||||
Name the Astro output mode, route-level prerender state, observed route signal, and exact config or page line.
|
||||
+22
@@ -0,0 +1,22 @@
|
||||
---
|
||||
id: auth-preserving-parallelization
|
||||
title: Authorization-preserving parallelization
|
||||
status: active
|
||||
candidateKinds: ["slow_route"]
|
||||
frameworks: ["*"]
|
||||
priority: 90
|
||||
citations: ["vercel-react-best-practices:async-parallel", "vercel-react-best-practices:server-parallel-fetching"]
|
||||
maxBriefChars: 900
|
||||
---
|
||||
|
||||
## Investigation Brief
|
||||
Parallelizing awaits is safe only when it does not move private data access ahead of the auth, ownership, tenant, or permission check protecting that data.
|
||||
|
||||
## Evidence To Check
|
||||
List every awaited operation being reordered. If a private lookup currently runs after `getSession()`, an ownership query, a tenant check, or a redirect guard, prove the lookup itself enforces the same predicate before recommending `Promise.all`.
|
||||
|
||||
## Do Not Recommend When
|
||||
Do not parallelize a private record fetch with the ownership check that authorizes that fetch. Instead, recommend combining the guard and data lookup into one query constrained by the authenticated user, tenant, or ownership key.
|
||||
|
||||
## Verification
|
||||
The fix must preserve the sequential guard or replace it with a single authorized query. Do not promise a latency drop equal to a helper unless that helper duration was measured.
|
||||
+22
@@ -0,0 +1,22 @@
|
||||
---
|
||||
id: bot-protection-product-guardrails
|
||||
title: Bot Protection product guardrails
|
||||
status: active
|
||||
candidateKinds: ["platform_bot_protection"]
|
||||
frameworks: ["*"]
|
||||
priority: 90
|
||||
citations: ["https://vercel.com/docs/bot-management", "https://vercel.com/docs/vercel-firewall/vercel-waf/managed-rulesets", "https://vercel.com/docs/vercel-firewall/vercel-waf/custom-rules", "https://vercel.com/docs/botid"]
|
||||
maxBriefChars: 800
|
||||
---
|
||||
|
||||
## Investigation Brief
|
||||
Bot Protection recommendations must be grounded in observed automated traffic or meaningful edge-request scale.
|
||||
|
||||
## Evidence To Check
|
||||
Check bot bandwidth share, edge request volume, existing WAF managed rules, and whether BotID or Bot Protection is already enabled. Prefer a staged Log to Challenge or Deny path for rules whose false-positive risk is not proven.
|
||||
|
||||
## Do Not Recommend When
|
||||
Do not recommend disabling Vercel security products to reduce cost. Do not recommend Bot Protection for quiet projects with no bot evidence.
|
||||
|
||||
## Verification
|
||||
State the observed bot share or scale signal, current protection state, and any existing log, challenge, deny, or BotID check.
|
||||
+23
@@ -0,0 +1,23 @@
|
||||
---
|
||||
id: build-minutes-monorepo-fanout
|
||||
title: Build Minutes monorepo fanout
|
||||
status: active
|
||||
candidateKinds: ["build_minutes_fanout"]
|
||||
frameworks: ["*"]
|
||||
scannerPatterns: ["turbo-force-bypass"]
|
||||
priority: 90
|
||||
citations: ["https://vercel.com/docs/monorepos", "https://vercel.com/docs/builds", "https://turborepo.dev/docs/crafting-your-repository/caching"]
|
||||
maxBriefChars: 900
|
||||
---
|
||||
|
||||
## Investigation Brief
|
||||
Build Minutes climbs when commits rebuild unchanged work. Common causes: `TURBO_FORCE`, `cache: false`, missing outputs, or disabled build-skip settings.
|
||||
|
||||
## Evidence To Check
|
||||
Confirm Build Minutes share and scanner subtype. Inspect `package.json`, `turbo.json`, outputs, `.gitignore`, `vercel.json`, and project settings. If `build` runs migrations, split them into an uncached step before recommending Turbo build caching.
|
||||
|
||||
## Do Not Recommend When
|
||||
Skip under 5% bill share with no scanner finding. Skip single-project repos and intentional CI-only force flags. Do not recommend `ignoreCommand` from repo grep alone; dashboard-only skip-unaffected may be better.
|
||||
|
||||
## Verification
|
||||
Name the offending file and pattern. Recommend only the verified fix: cache a pure build task, add generated `outputs`, enable skip-unaffected builds, or add `ignoreCommand` only when needed.
|
||||
+22
@@ -0,0 +1,22 @@
|
||||
---
|
||||
id: cache-components-static-shell-boundaries
|
||||
title: Cache Components static shell boundaries
|
||||
status: active
|
||||
candidateKinds: ["rendering_candidate"]
|
||||
frameworks: ["next@>=16.0.0"]
|
||||
priority: 94
|
||||
citations: ["https://nextjs.org/docs/app/api-reference/config/next-config-js/cacheComponents", "https://nextjs.org/docs/app/getting-started/caching", "https://nextjs.org/docs/app/guides/migrating-to-cache-components"]
|
||||
maxBriefChars: 900
|
||||
---
|
||||
|
||||
## Investigation Brief
|
||||
On Next.js 16 with Cache Components, avoid older segment-config advice. The right question is whether the route can keep a static shell while dynamic data moves behind explicit cached or runtime boundaries.
|
||||
|
||||
## Evidence To Check
|
||||
Check `cacheComponents`, `use cache`, `cacheLife`, request-time APIs, Suspense boundaries, and scanner evidence such as `force-dynamic` or `headers-in-page`.
|
||||
|
||||
## Do Not Recommend When
|
||||
Do not suggest `dynamic`, `revalidate`, or `fetchCache` as the primary fix when Cache Components is enabled. Do not cache request-personalized content.
|
||||
|
||||
## Verification
|
||||
Name the Next.js version, Cache Components state, dynamic trigger, and the exact boundary or directive that can change.
|
||||
+23
@@ -0,0 +1,23 @@
|
||||
---
|
||||
id: cache-components-suspense-dedupe-pitfall
|
||||
title: Cache Components Suspense dedupe pitfall
|
||||
status: active
|
||||
candidateKinds: ["cache_components_suspense_dedupe"]
|
||||
frameworks: ["next@>=16.0.0"]
|
||||
scannerPatterns: ["cache-components-suspense-dedupe"]
|
||||
priority: 87
|
||||
citations: ["https://nextjs.org/docs/app/api-reference/directives/use-cache", "https://nextjs.org/docs/app/api-reference/config/next-config-js/cacheComponents", "https://nextjs.org/docs/app/guides/migrating-to-cache-components"]
|
||||
maxBriefChars: 900
|
||||
---
|
||||
|
||||
## Investigation Brief
|
||||
Default `'use cache'` does not dedupe identical calls across separate `<Suspense>` boundaries on the same render. Each boundary re-invokes the cached function, multiplying function-duration and ISR write churn.
|
||||
|
||||
## Evidence To Check
|
||||
Confirm the scanner finding's repeated fetch URL or helper name. Verify the call sites are within the same route segment and inside distinct `<Suspense>` boundaries. Cross-reference `fnDurationP95ByRoute` and `isrWritesByRoute` for the owning route.
|
||||
|
||||
## Do Not Recommend When
|
||||
Skip if the repeated call is intentional (different parameters, different intent). Skip if the duplicate is in a single component body where in-request memoization already applies.
|
||||
|
||||
## Verification
|
||||
Name the duplicated call, count, and either: (a) the page-level promise to hoist or (b) the function to move to `'use cache: remote'`.
|
||||
+22
@@ -0,0 +1,22 @@
|
||||
---
|
||||
id: cdn-cache-auth-safety
|
||||
title: CDN cache auth safety
|
||||
status: active
|
||||
candidateKinds: ["uncached_route", "cache_header_gap"]
|
||||
frameworks: ["*"]
|
||||
priority: 100
|
||||
citations: ["https://vercel.com/docs/caching/cdn-cache", "https://vercel.com/docs/caching/cache-control-headers", "https://vercel.com/docs/project-configuration"]
|
||||
maxBriefChars: 900
|
||||
---
|
||||
|
||||
## Investigation Brief
|
||||
Treat edge caching as a safety question first. The route must be a public, cacheable GET path before a shared-cache recommendation is allowed.
|
||||
|
||||
## Evidence To Check
|
||||
Use `methodDistribution`, `cacheBreakdown`, and headers. Before `s-maxage`, rule out cookies, sessions, authorization, draft state, and user-specific data.
|
||||
|
||||
## Do Not Recommend When
|
||||
Do not cache mutations, dashboards, account data, request-personalized responses, or routes whose value changes per viewer. Do not mix `private` with shared-cache directives.
|
||||
|
||||
## Verification
|
||||
Name GET share, cache mix, file line, and policy: mechanism, scope, TTL/freshness, and `Vary`. If the right policy is `no-store`, emit no-change/observation.
|
||||
+22
@@ -0,0 +1,22 @@
|
||||
---
|
||||
id: cold-start-initialization-bundle
|
||||
title: Cold-start initialization and bundle weight
|
||||
status: active
|
||||
candidateKinds: ["cold_start"]
|
||||
frameworks: ["*"]
|
||||
priority: 92
|
||||
citations: ["https://vercel.com/docs/functions/debug-slow-functions", "https://vercel.com/docs/functions/limitations", "https://vercel.com/docs/functions/runtimes"]
|
||||
maxBriefChars: 850
|
||||
---
|
||||
|
||||
## Investigation Brief
|
||||
Cold-start candidates need a code-path check, not only a project-setting check. First prove whether cold requests are paying for imports, module-scope setup, runtime choice, or dependency weight.
|
||||
|
||||
## Evidence To Check
|
||||
Use `startTypeSplit`, `coldVsWarmLatencyP95`, and `coldByDeployment`. In source, inspect module-scope SDK setup, database/client construction, top-level network calls, heavy dependencies, runtime exports, and deployment-local changes.
|
||||
|
||||
## Do Not Recommend When
|
||||
Do not blame cold starts when warm requests are similarly slow. Do not recommend keep-warm traffic or more memory before proving initialization or runtime pressure.
|
||||
|
||||
## Verification
|
||||
Name the cold-start share, cold-vs-warm gap, and exact initialization, dependency, or runtime line that explains it.
|
||||
+22
@@ -0,0 +1,22 @@
|
||||
---
|
||||
id: core-web-vitals-client-bottlenecks
|
||||
title: Core Web Vitals client bottlenecks
|
||||
status: active
|
||||
candidateKinds: ["cwv_poor"]
|
||||
frameworks: ["*"]
|
||||
priority: 90
|
||||
citations: ["https://vercel.com/docs/speed-insights", "https://web.dev/articles/vitals", "https://web.dev/articles/optimize-lcp", "https://web.dev/articles/optimize-inp", "https://web.dev/articles/optimize-cls"]
|
||||
maxBriefChars: 850
|
||||
---
|
||||
|
||||
## Investigation Brief
|
||||
Core Web Vitals candidates need metric-specific investigation. LCP, INP, and CLS usually have different causes and fixes.
|
||||
|
||||
## Evidence To Check
|
||||
Use the poor metric in the deep dive first. For LCP, inspect server response and critical media. For INP, inspect heavy client JavaScript and interaction handlers. For CLS, inspect dimensions, fonts, and injected content.
|
||||
|
||||
## Do Not Recommend When
|
||||
Do not emit a generic “improve Web Vitals” recommendation. Do not optimize a metric that is not poor for this route.
|
||||
|
||||
## Verification
|
||||
Name the poor p75 metric, its value, and the exact source mechanism behind that metric.
|
||||
+22
@@ -0,0 +1,22 @@
|
||||
---
|
||||
id: database-egress-pooling-region
|
||||
title: Database region and connection pressure
|
||||
status: active
|
||||
candidateKinds: ["slow_route"]
|
||||
frameworks: ["*"]
|
||||
priority: 60
|
||||
citations: ["https://vercel.com/docs/regions", "https://vercel.com/docs/functions", "https://vercel.com/docs/functions/functions-api-reference/vercel-functions-package", "https://vercel.com/docs/functions/limitations"]
|
||||
maxBriefChars: 800
|
||||
---
|
||||
|
||||
## Investigation Brief
|
||||
Only recommend database or region changes when source and metrics both point to downstream I/O rather than in-process compute.
|
||||
|
||||
## Evidence To Check
|
||||
Compare `cpu.p95` with `latency.p95`, then inspect database awaits, query fan-out, connection creation, pool lifecycle handling, and configured regions in project files.
|
||||
|
||||
## Do Not Recommend When
|
||||
Do not name a database provider, pooling product, or region change unless the repo and project config prove it applies.
|
||||
|
||||
## Verification
|
||||
Tie the finding to the observed wall-clock gap and the exact query, pool, or region configuration line.
|
||||
+22
@@ -0,0 +1,22 @@
|
||||
---
|
||||
id: dynamic-rendering-traps
|
||||
title: Dynamic rendering traps
|
||||
status: active
|
||||
candidateKinds: ["rendering_candidate"]
|
||||
frameworks: ["next@>=13.0.0"]
|
||||
priority: 90
|
||||
citations: ["https://nextjs.org/docs/app/api-reference/file-conventions/route-segment-config", "https://nextjs.org/docs/app/api-reference/functions/generate-static-params", "https://nextjs.org/docs/app/building-your-application/rendering/partial-prerendering"]
|
||||
maxBriefChars: 850
|
||||
---
|
||||
|
||||
## Investigation Brief
|
||||
Rendering candidates are only actionable when the dynamic behavior is accidental. First prove that the route can be static, ISR, or partially static.
|
||||
|
||||
## Evidence To Check
|
||||
Inspect `dynamic`, `revalidate`, `generateStaticParams`, route params, and dynamic APIs such as request headers or cookies. Check whether the dynamic call is in a layout, because that can affect a larger route tree.
|
||||
|
||||
## Do Not Recommend When
|
||||
Do not remove dynamic rendering for auth, personalization, draft mode, per-request redirects, or request-specific data.
|
||||
|
||||
## Verification
|
||||
The recommendation must cite the dynamic trigger and explain why the target route can tolerate static or ISR behavior.
|
||||
+22
@@ -0,0 +1,22 @@
|
||||
---
|
||||
id: external-api-critical-path-platform
|
||||
title: Cross-framework external API critical path
|
||||
status: active
|
||||
candidateKinds: ["external_api_slow"]
|
||||
frameworks: ["*"]
|
||||
priority: 86
|
||||
citations: ["https://vercel.com/docs/functions/debug-slow-functions", "https://vercel.com/docs/caching/runtime-cache", "https://vercel.com/docs/functions/functions-api-reference/vercel-functions-package"]
|
||||
maxBriefChars: 850
|
||||
---
|
||||
|
||||
## Investigation Brief
|
||||
External API candidates are actionable only when the slow hostname is on a customer route's critical path. Prove the route waits on it before suggesting a cache, payload, or post-response change.
|
||||
|
||||
## Evidence To Check
|
||||
Use hostname latency, caller routes, transfer bytes, and source awaits. Check sequential calls, overbroad payloads, repeated shared data, and side effects that can move after the response.
|
||||
|
||||
## Do Not Recommend When
|
||||
Do not cache mutations, secrets, per-user responses, or unknown freshness contracts. Do not blame Vercel runtime when the upstream owns the latency.
|
||||
|
||||
## Verification
|
||||
Name the hostname, caller route, observed p75/p95 or bytes, and exact await or fetch line that blocks the response.
|
||||
+22
@@ -0,0 +1,22 @@
|
||||
---
|
||||
id: external-api-critical-path
|
||||
title: External API critical path
|
||||
status: active
|
||||
candidateKinds: ["external_api_slow"]
|
||||
frameworks: ["next@>=13.0.0"]
|
||||
priority: 90
|
||||
citations: ["vercel-react-best-practices:async-parallel", "vercel-react-best-practices:server-parallel-fetching", "vercel-react-best-practices:server-cache-react"]
|
||||
maxBriefChars: 850
|
||||
---
|
||||
|
||||
## Investigation Brief
|
||||
For external API candidates, identify the customer route that waits on the slow hostname and whether the call is on the critical path.
|
||||
|
||||
## Evidence To Check
|
||||
Use callers-by-route evidence, transfer size, and source awaits. Check whether the upstream call can run in parallel, be cached safely, be reduced in payload size, or move after response.
|
||||
|
||||
## Do Not Recommend When
|
||||
Do not cache mutations, secrets, per-user responses, or upstream calls whose freshness requirement is unknown.
|
||||
|
||||
## Verification
|
||||
Name the hostname, caller route, p75 or p95 latency, and the exact source line that waits on the call.
|
||||
+22
@@ -0,0 +1,22 @@
|
||||
---
|
||||
id: fast-data-transfer-payloads
|
||||
title: Fast Data Transfer payloads
|
||||
status: active
|
||||
candidateKinds: ["uncached_route"]
|
||||
frameworks: ["*"]
|
||||
priority: 65
|
||||
citations: ["https://vercel.com/docs/manage-cdn-usage", "https://vercel.com/docs/caching/cdn-cache"]
|
||||
maxBriefChars: 900
|
||||
---
|
||||
|
||||
## Investigation Brief
|
||||
When uncached routes carry high bandwidth, check payload shape before recommending only cache headers. Fast Data Transfer includes the bytes transferred by requests and responses; compare compressed response sizes to the signal, not raw JSON.
|
||||
|
||||
## Evidence To Check
|
||||
Use `bandwidthByCache`, response size, and source serialization. Look for unbounded JSON, large embedded objects, static files through functions, missing pagination.
|
||||
|
||||
## Do Not Recommend When
|
||||
Do not shrink payloads without identifying fields or assets that are unnecessary for the route’s response.
|
||||
|
||||
## Verification
|
||||
Tie the finding to observed bytes, cache result mix, and the exact response line. A "large payload" claim must reflect post-compression bytes — the unit FDT meters.
|
||||
+22
@@ -0,0 +1,22 @@
|
||||
---
|
||||
id: fluid-compute-caveats
|
||||
title: Fluid compute caveats
|
||||
status: active
|
||||
candidateKinds: ["platform_fluid_compute", "cold_start"]
|
||||
frameworks: ["*"]
|
||||
priority: 80
|
||||
citations: ["https://vercel.com/docs/fluid-compute"]
|
||||
maxBriefChars: 900
|
||||
---
|
||||
|
||||
## Investigation Brief
|
||||
Fluid compute is a project-level lever. Use it when the setting is off and metrics show cold-start or warm-instance reuse pressure. Fluid can handle multiple invocations in one function instance; avoid per-request state in module scope.
|
||||
|
||||
## Evidence To Check
|
||||
Check project facts, `startTypeSplit`, cold-vs-warm latency, and routes carrying the cold-start share. When enabling Fluid, audit module-state hazards Fluid surfaces (not creates): module-scoped mutable state, lazy singletons holding per-user data, globals keyed on per-request inputs.
|
||||
|
||||
## Do Not Recommend When
|
||||
Do not recommend enabling fluid compute when project facts say it is already on. Do not frame as a file-level code fix.
|
||||
|
||||
## Verification
|
||||
State project setting, cold-start rate or fallback slow-route signal, affected route concentration. If enabling, call out module-state audit as follow-up.
|
||||
+22
@@ -0,0 +1,22 @@
|
||||
---
|
||||
id: function-duration-io-and-after
|
||||
title: Function duration, I/O, and post-response work
|
||||
status: active
|
||||
candidateKinds: ["slow_route"]
|
||||
frameworks: ["next@>=15.0.0"]
|
||||
priority: 75
|
||||
citations: ["https://nextjs.org/docs/app/api-reference/functions/after", "vercel-react-best-practices:async-parallel", "vercel-react-best-practices:server-after-nonblocking"]
|
||||
maxBriefChars: 850
|
||||
---
|
||||
|
||||
## Investigation Brief
|
||||
When wall-clock latency is much higher than CPU time, check critical-path awaits before blaming rendering or compute.
|
||||
|
||||
## Evidence To Check
|
||||
Compare `cpu.p95`, `ttfb.p95`, and `latency.p95`. In source, separate dependent awaits from independent awaits, and identify analytics, logging, or notification work that can run after the response.
|
||||
|
||||
## Do Not Recommend When
|
||||
Do not wrap dependent operations in `Promise.all`. Do not replace `Promise.allSettled` when partial failure handling is intentional.
|
||||
|
||||
## Verification
|
||||
Name the awaits that can move, the work that can run post-response, and the observed CPU-vs-wall-clock gap.
|
||||
+22
@@ -0,0 +1,22 @@
|
||||
---
|
||||
id: function-invocation-reduction
|
||||
title: Function invocation reduction
|
||||
status: active
|
||||
candidateKinds: ["slow_route"]
|
||||
frameworks: ["next@>=13.0.0"]
|
||||
priority: 70
|
||||
citations: ["https://react.dev/reference/react/cache", "vercel-react-best-practices:server-parallel-fetching", "vercel-react-best-practices:server-cache-react"]
|
||||
maxBriefChars: 850
|
||||
---
|
||||
|
||||
## Investigation Brief
|
||||
For slow routes, prove duplicated in-request work in the listed files before recommending consolidation or memoization.
|
||||
|
||||
## Evidence To Check
|
||||
Look for repeated awaits, duplicate fetches, same-app route handler calls, and helpers that run more than once per request.
|
||||
|
||||
## Do Not Recommend When
|
||||
Do not collapse endpoints called independently by different clients. Do not persistently cache user-specific data. Do not recommend `Promise.all` for CPU-bound or compile-bound work unless trace/span evidence shows wait time to overlap. High `cpu.p95` near `latency.p95` is a warning sign, not proof of a latency win.
|
||||
|
||||
## Verification
|
||||
Quote duplicated call sites with `latency.p95`, `cpu.p95`, or request-count evidence. If the fix overlaps awaits, cite measured helper/span timing or state the impact is unmeasured.
|
||||
+23
@@ -0,0 +1,23 @@
|
||||
---
|
||||
id: function-region-misconfiguration-ttfb
|
||||
title: Function region misconfiguration (TTFB)
|
||||
status: active
|
||||
candidateKinds: ["region_misconfig"]
|
||||
frameworks: ["*"]
|
||||
scannerPatterns: ["region-pin-in-config"]
|
||||
priority: 85
|
||||
citations: ["https://vercel.com/docs/functions/configuring-functions/region", "https://vercel.com/docs/regions"]
|
||||
maxBriefChars: 950
|
||||
---
|
||||
|
||||
## Investigation Brief
|
||||
A single function region is pinned. Per-region TTFB data is unavailable today (`evidence.dataGap`); treat as an audit prompt — validate the pinned region against user geo and data-source location before recommending changes.
|
||||
|
||||
## Evidence To Check
|
||||
Scanner subtype (`vercel-json-single`, `segment-preferred`) and pinned regions. Cross-check Speed Insights TTFB and country analytics for traffic geo. Locate the data source — proximity to it often wins on cache-miss paths.
|
||||
|
||||
## Do Not Recommend When
|
||||
Skip if TTFB is healthy across countries. Skip if pinned intentionally for data proximity. Skip on small projects (<20 routes). Do not propose multi-region without confirming the data layer is reachable without cross-region egress.
|
||||
|
||||
## Verification
|
||||
Name pinned region(s), traffic geo, data-source location, and a specific call: relocate, expand, or keep with a TTFB monitor.
|
||||
+22
@@ -0,0 +1,22 @@
|
||||
---
|
||||
id: image-optimization-cost-control
|
||||
title: Image optimization cost control
|
||||
status: active
|
||||
candidateKinds: ["image_optimization"]
|
||||
frameworks: ["*"]
|
||||
priority: 90
|
||||
citations: ["https://vercel.com/docs/image-optimization", "https://vercel.com/docs/image-optimization/managing-image-optimization-costs", "https://vercel.com/docs/image-optimization/limits-and-pricing"]
|
||||
maxBriefChars: 850
|
||||
---
|
||||
|
||||
## Investigation Brief
|
||||
Image recommendations should distinguish real user-facing image work from wasteful transformations.
|
||||
|
||||
## Evidence To Check
|
||||
Inspect the sampled files for raw image tags, dimensions, remote sources, repeated transforms, source image limits, icons, SVGs, GIFs, and existing framework image components.
|
||||
|
||||
## Do Not Recommend When
|
||||
Do not route tiny icons, SVG UI assets, or animated GIFs through image optimization just because they are images. Do not change remote-source policy without checking the existing config.
|
||||
|
||||
## Verification
|
||||
Name the image files or components, current rendering path, and the metric or scanner evidence that makes optimization material.
|
||||
+22
@@ -0,0 +1,22 @@
|
||||
---
|
||||
id: isr-revalidation-static-generation
|
||||
title: ISR revalidation and static generation
|
||||
status: active
|
||||
candidateKinds: ["isr_overrevalidation"]
|
||||
frameworks: ["next@>=13.4.0"]
|
||||
priority: 95
|
||||
citations: ["https://vercel.com/docs/incremental-static-regeneration", "https://nextjs.org/docs/app/api-reference/functions/revalidateTag", "https://nextjs.org/docs/app/api-reference/functions/revalidatePath"]
|
||||
maxBriefChars: 1000
|
||||
---
|
||||
|
||||
## Investigation Brief
|
||||
For ISR over-revalidation, the goal is to reduce unnecessary regeneration work without making content stale beyond the product’s tolerance.
|
||||
|
||||
## Evidence To Check
|
||||
Compare ISR writes to reads, then inspect the route’s `revalidate`, `cacheLife()`, tag invalidation, and content update path. Look for very short timer revalidation on routes where updates are event-driven. If recommending `cacheLife()` or `cacheTag()` for tagged content, prove the exact tags are invalidated by `revalidateTag()` or `updateTag()`; near-matches do not count.
|
||||
|
||||
## Do Not Recommend When
|
||||
Do not lengthen revalidation for inventory, pricing, auth, or other user-critical freshness without source evidence that stale content is acceptable. Do not claim existing CMS or webhook invalidation unless the matching invalidation call or config is in the allowed files.
|
||||
|
||||
## Verification
|
||||
Tie the fix to the observed ISR writes per read and the line that controls revalidation or on-demand invalidation.
|
||||
+22
@@ -0,0 +1,22 @@
|
||||
---
|
||||
id: middleware-proxy-edge-cost
|
||||
title: Middleware edge cost
|
||||
status: active
|
||||
candidateKinds: ["middleware_heavy"]
|
||||
frameworks: ["next@>=12.0.0"]
|
||||
priority: 90
|
||||
citations: ["https://nextjs.org/docs/app/building-your-application/routing/middleware", "https://vercel.com/docs/routing-middleware"]
|
||||
maxBriefChars: 850
|
||||
---
|
||||
|
||||
## Investigation Brief
|
||||
Middleware recommendations should reduce unnecessary interception, not remove required request handling.
|
||||
|
||||
## Evidence To Check
|
||||
Use `topMiddlewarePaths` and the matcher config. Confirm which paths need auth, rewrites, headers, or locale handling. Check whether static assets, images, or routes with no middleware need are being matched.
|
||||
|
||||
## Do Not Recommend When
|
||||
Do not narrow the matcher in a way that bypasses required auth or routing behavior. Do not move middleware work into every route if the current matcher is already scoped.
|
||||
|
||||
## Verification
|
||||
State the current middleware share, the dominant matched paths, and the exact matcher line to change.
|
||||
+22
@@ -0,0 +1,22 @@
|
||||
---
|
||||
id: next-fetch-revalidate-floor
|
||||
title: Next.js fetch revalidation floor
|
||||
status: active
|
||||
candidateKinds: ["uncached_route", "isr_overrevalidation"]
|
||||
frameworks: ["next@>=13.0.0"]
|
||||
priority: 88
|
||||
citations: ["https://nextjs.org/docs/app/api-reference/functions/fetch", "https://nextjs.org/docs/app/building-your-application/caching"]
|
||||
maxBriefChars: 850
|
||||
---
|
||||
|
||||
## Investigation Brief
|
||||
Next.js `fetch` options can set the route's effective cache floor. Low `revalidate`, `revalidate: 0`, or `cache: 'no-store'` can explain uncached traffic and excessive ISR work.
|
||||
|
||||
## Evidence To Check
|
||||
Inspect route-tree `fetch` calls. Compare route revalidation with per-fetch `cache`, `next.revalidate`, tags, dynamic APIs, and duplicated URLs with conflicting options.
|
||||
|
||||
## Do Not Recommend When
|
||||
Do not raise freshness windows for pricing, inventory, auth, draft, or user-specific data unless the source proves stale reads are acceptable.
|
||||
|
||||
## Verification
|
||||
Name the observed cache or ISR signal, the lowest cache setting that controls the route, and the exact fetch line to change.
|
||||
+23
@@ -0,0 +1,23 @@
|
||||
---
|
||||
id: next-font-cls-self-hosting
|
||||
title: Next.js font CLS guardrail
|
||||
status: active
|
||||
candidateKinds: ["cwv_poor"]
|
||||
frameworks: ["next@>=13.2.0"]
|
||||
metrics: ["CLS"]
|
||||
priority: 86
|
||||
citations: ["https://nextjs.org/docs/app/api-reference/components/font", "https://web.dev/articles/optimize-cls"]
|
||||
maxBriefChars: 800
|
||||
---
|
||||
|
||||
## Investigation Brief
|
||||
For poor CLS, check fonts only when the route actually loads external font CSS or swaps text after render.
|
||||
|
||||
## Evidence To Check
|
||||
Inspect layouts and global styles for external font links, CSS imports, custom font-face rules, late-loading font classes, and whether `next/font` is already used.
|
||||
|
||||
## Do Not Recommend When
|
||||
Do not migrate fonts when CLS is caused by images, ads, embeds, or injected UI. Do not suggest `next/font` for unsupported Next.js versions.
|
||||
|
||||
## Verification
|
||||
Name the CLS value, font-loading mechanism, and the exact layout or stylesheet line to change.
|
||||
+23
@@ -0,0 +1,23 @@
|
||||
---
|
||||
id: next-heavy-ui-lazy-load-boundaries
|
||||
title: Next.js heavy UI lazy-load boundaries
|
||||
status: active
|
||||
candidateKinds: ["cwv_poor"]
|
||||
frameworks: ["next@*"]
|
||||
metrics: ["LCP", "INP"]
|
||||
priority: 82
|
||||
citations: ["https://nextjs.org/docs/app/guides/lazy-loading", "https://web.dev/articles/optimize-inp"]
|
||||
maxBriefChars: 850
|
||||
---
|
||||
|
||||
## Investigation Brief
|
||||
Heavy above-the-fold or rarely used UI can hurt LCP and INP when it ships too much JavaScript on first load. Look for concrete route-local UI, not generic bundle advice.
|
||||
|
||||
## Evidence To Check
|
||||
Inspect client components, menus, search overlays, personalization widgets, maps, editors, and large imported libraries. Check whether they can load on interaction, viewport, or route entry with `next/dynamic` or dynamic import.
|
||||
|
||||
## Do Not Recommend When
|
||||
Do not lazy-load essential above-the-fold content needed for initial meaning or accessibility. Do not use `ssr: false` from a Server Component.
|
||||
|
||||
## Verification
|
||||
Name the poor metric, heavy UI boundary, imported library or component, and exact line to split.
|
||||
+23
@@ -0,0 +1,23 @@
|
||||
---
|
||||
id: next-image-lcp-preload-sizes
|
||||
title: Next.js image LCP preload and sizes
|
||||
status: active
|
||||
candidateKinds: ["cwv_poor"]
|
||||
frameworks: ["next@*"]
|
||||
metrics: ["LCP"]
|
||||
priority: 86
|
||||
citations: ["https://nextjs.org/docs/app/api-reference/components/image", "https://web.dev/articles/optimize-lcp"]
|
||||
maxBriefChars: 850
|
||||
---
|
||||
|
||||
## Investigation Brief
|
||||
For poor LCP, identify whether the LCP element is an image before touching unrelated JavaScript. Hero images need correct sizing, priority behavior, and source-cache hygiene.
|
||||
|
||||
## Evidence To Check
|
||||
Inspect above-the-fold media for `next/image`, `fill` without `sizes`, deprecated `priority` on Next.js 16, missing `preload` or `fetchPriority`, oversized dimensions, and remote-image TTL/source behavior.
|
||||
|
||||
## Do Not Recommend When
|
||||
Do not preload multiple possible LCP images or route tiny icons/SVG UI assets through image optimization. Do not change quality or TTL without checking source-update semantics.
|
||||
|
||||
## Verification
|
||||
Name the LCP value, image element or component, current props/config, and the exact line to change.
|
||||
+22
@@ -0,0 +1,22 @@
|
||||
---
|
||||
id: next-route-handler-get-cache-defaults
|
||||
title: Next.js Route Handler GET cache defaults
|
||||
status: active
|
||||
candidateKinds: ["uncached_route", "cache_header_gap"]
|
||||
frameworks: ["next@>=15.0.0"]
|
||||
priority: 91
|
||||
citations: ["https://nextjs.org/docs/app/api-reference/file-conventions/route", "https://vercel.com/docs/caching/cdn-cache"]
|
||||
maxBriefChars: 850
|
||||
---
|
||||
|
||||
## Investigation Brief
|
||||
On Next.js 15+, GET Route Handlers are dynamic by default. For hot public GET handlers, verify whether uncached behavior is intentional before recommending cache headers or route config.
|
||||
|
||||
## Evidence To Check
|
||||
Use method share, cache result, and source. Check `GET`, `revalidate`, `dynamic`, request headers, cookies, auth, query params, and response `Cache-Control`.
|
||||
|
||||
## Do Not Recommend When
|
||||
Do not cache POST-style handlers, webhooks, per-user APIs, streaming responses, search requests with user-specific params, or handlers that read auth/cookies.
|
||||
|
||||
## Verification
|
||||
Name the Next.js version, GET share, cache result mix, and the exact handler or header line that makes public caching safe.
|
||||
+23
@@ -0,0 +1,23 @@
|
||||
---
|
||||
id: next-script-third-party-strategy
|
||||
title: Next.js third-party script strategy
|
||||
status: active
|
||||
candidateKinds: ["cwv_poor"]
|
||||
frameworks: ["next@*"]
|
||||
metrics: ["LCP", "INP"]
|
||||
priority: 85
|
||||
citations: ["https://nextjs.org/docs/app/api-reference/components/script", "https://web.dev/articles/optimize-inp"]
|
||||
maxBriefChars: 850
|
||||
---
|
||||
|
||||
## Investigation Brief
|
||||
Third-party scripts are only actionable when they line up with the poor metric and route. For LCP or INP, prove a specific script blocks critical rendering, hydration, or interaction.
|
||||
|
||||
## Evidence To Check
|
||||
Inspect `next/script`, raw `<script>`, tag managers, chat widgets, analytics, and consent code. Check `beforeInteractive`, `afterInteractive`, `lazyOnload`, and whether the script is route-local or global.
|
||||
|
||||
## Do Not Recommend When
|
||||
Do not move required bot detection, consent, auth, or payment scripts later without product evidence. Do not recommend `worker` for App Router.
|
||||
|
||||
## Verification
|
||||
Name the poor metric, script source, current strategy, and the exact route or layout line to change.
|
||||
+22
@@ -0,0 +1,22 @@
|
||||
---
|
||||
id: nextjs-version-cache-semantics
|
||||
title: Next.js cache semantics by version
|
||||
status: active
|
||||
candidateKinds: ["uncached_route"]
|
||||
frameworks: ["next@>=15.0.0"]
|
||||
priority: 85
|
||||
citations: ["https://nextjs.org/docs/app/api-reference/directives/use-cache", "https://nextjs.org/docs/app/api-reference/functions/cacheLife", "https://nextjs.org/docs/app/building-your-application/caching"]
|
||||
maxBriefChars: 800
|
||||
---
|
||||
|
||||
## Investigation Brief
|
||||
On Next.js 15+, match the fix to the cache primitive already in use.
|
||||
|
||||
## Evidence To Check
|
||||
Check `'use cache'`, `cacheLife`, `cacheTag`, `fetch` cache options, route handlers, and dynamic APIs.
|
||||
|
||||
## Do Not Recommend When
|
||||
Do not suggest APIs outside the detected Next.js version. Do not claim `cacheLife()` emits CDN `Cache-Control` headers or that missing `cacheLife()` alone makes a `'use cache'` route run per request. Omitted `cacheLife()` calls use the default profile.
|
||||
|
||||
## Verification
|
||||
Name the detected Next.js version and exact cache primitive or route header.
|
||||
+23
@@ -0,0 +1,23 @@
|
||||
---
|
||||
id: not-found-catchall-request-waste
|
||||
title: Not-found and catch-all request waste
|
||||
status: active
|
||||
candidateKinds: ["uncached_route"]
|
||||
frameworks: ["*"]
|
||||
routePatterns: ["(^|/)404$", "not-found", "\\[\\.\\.\\."]
|
||||
priority: 92
|
||||
citations: ["https://vercel.com/docs/routing/", "https://vercel.com/docs/redirects/bulk-redirects/", "https://vercel.com/docs/vercel-firewall/vercel-waf/custom-rules", "https://vercel.com/docs/vercel-firewall/vercel-waf/managed-rulesets"]
|
||||
maxBriefChars: 850
|
||||
---
|
||||
|
||||
## Investigation Brief
|
||||
High-volume 404 or catch-all traffic is often request waste. First determine whether the traffic is legacy URLs, bots, broken links, or a real product route.
|
||||
|
||||
## Evidence To Check
|
||||
Use route volume, method share, cache result, bot share, and top request paths. Inspect redirects, rewrites, catch-all routes, sitemap/robots output, and any WAF rules already logging or blocking the pattern.
|
||||
|
||||
## Do Not Recommend When
|
||||
Do not block or redirect legitimate product routes, search crawlers, or unknown traffic without a log-mode validation path. Do not replace a useful 404 page with a blanket rewrite.
|
||||
|
||||
## Verification
|
||||
Name the dominant bad path pattern, observed request or bot volume, and the redirect, routing, or WAF rule that would stop the wasted function path.
|
||||
+22
@@ -0,0 +1,22 @@
|
||||
---
|
||||
id: nuxt-route-rules-cache-isr
|
||||
title: Nuxt routeRules cache and ISR
|
||||
status: active
|
||||
candidateKinds: ["uncached_route", "isr_overrevalidation", "rendering_candidate"]
|
||||
frameworks: ["nuxt@>=3.0.0"]
|
||||
priority: 90
|
||||
citations: ["https://vercel.com/docs/frameworks/full-stack/nuxt", "https://nuxt.com/docs/4.x/api/utils/define-route-rules", "https://nuxt.com/docs/4.x/guide/concepts/rendering"]
|
||||
maxBriefChars: 850
|
||||
---
|
||||
|
||||
## Investigation Brief
|
||||
For Nuxt on Vercel, route-level caching usually belongs in `routeRules`. Match the lever to the route: prerender for static pages, ISR for shared content, and SSR for request-specific views.
|
||||
|
||||
## Evidence To Check
|
||||
Inspect `nuxt.config`, inline route rules, server routes, pages, auth/session reads, and observed cache or ISR read/write patterns. Verify whether the route should be Vercel cache-backed ISR rather than generic SWR.
|
||||
|
||||
## Do Not Recommend When
|
||||
Do not cache authenticated, cart, checkout, preview, or per-user routes. Do not add routeRules without proving the route is public and the freshness window is acceptable.
|
||||
|
||||
## Verification
|
||||
Name the observed route signal, current routeRule or missing rule, chosen cache mode, and exact config line.
|
||||
+22
@@ -0,0 +1,22 @@
|
||||
---
|
||||
id: observability-events-cost-attribution
|
||||
title: Observability Events cost attribution
|
||||
status: active
|
||||
candidateKinds: ["observability_events_attribution"]
|
||||
frameworks: ["*"]
|
||||
priority: 92
|
||||
citations: ["https://vercel.com/docs/observability/observability-plus", "https://vercel.com/docs/alerts"]
|
||||
maxBriefChars: 900
|
||||
---
|
||||
|
||||
## Investigation Brief
|
||||
Observability Events is the metered SKU under Observability Plus. When the current bill shows a large Observability Events share, event volume is the lever. Reduce upstream: lift cache hit rate, narrow middleware matchers, and reduce unnecessary custom-span cardinality.
|
||||
|
||||
## Evidence To Check
|
||||
Verify the share from `usage.services`. Cross-reference `requestsByRouteCache`, `middlewareCount`, external API span counts, and third-party tracing (`tracesSampleRate=1`).
|
||||
|
||||
## Do Not Recommend When
|
||||
Skip below 15% share. Skip when cache hit rate is already >90% across hot routes — the lever is elsewhere. Do not propose sampling unless the specific metered signal has a documented sampling control.
|
||||
|
||||
## Verification
|
||||
Name the share, upstream drivers, and concrete remediation per driver, not generic "reduce events".
|
||||
+22
@@ -0,0 +1,22 @@
|
||||
---
|
||||
id: post-response-work-waituntil
|
||||
title: Post-response work with waitUntil
|
||||
status: active
|
||||
candidateKinds: ["slow_route", "external_api_slow"]
|
||||
frameworks: ["next@<15.0.0", "sveltekit@*", "astro@*", "nuxt@*", "unknown@*"]
|
||||
priority: 78
|
||||
citations: ["https://vercel.com/docs/functions/functions-api-reference/vercel-functions-package"]
|
||||
maxBriefChars: 800
|
||||
---
|
||||
|
||||
## Investigation Brief
|
||||
For stacks without Next.js `after()`, check whether non-critical work can run after the response instead of extending user-visible latency.
|
||||
|
||||
## Evidence To Check
|
||||
Inspect the listed route for analytics, logging, notifications, cache warming, metrics, or webhook side effects that happen after the response data is ready.
|
||||
|
||||
## Do Not Recommend When
|
||||
Do not move work that decides the response, must fail the request, changes visible state synchronously, or needs a durable retry guarantee.
|
||||
|
||||
## Verification
|
||||
Name the blocking side effect, the observed latency or upstream signal, and the exact line that can move behind `waitUntil`.
|
||||
+22
@@ -0,0 +1,22 @@
|
||||
---
|
||||
id: route-error-durable-offload
|
||||
title: Durable offload for timeout-heavy routes
|
||||
status: active
|
||||
candidateKinds: ["route_errors"]
|
||||
frameworks: ["*"]
|
||||
priority: 84
|
||||
citations: ["https://vercel.com/docs/workflow", "https://workflow-sdk.dev/docs/foundations/starting-workflows", "https://workflow-sdk.dev/docs/foundations/workflows-and-steps", "https://vercel.com/docs/queues", "https://vercel.com/docs/functions/limitations"]
|
||||
maxBriefChars: 850
|
||||
---
|
||||
|
||||
## Investigation Brief
|
||||
Timeout-heavy routes often need a job boundary, not a higher limit. Workflow fits durable multi-step work that can continue after the response; return a run ID instead of waiting on `returnValue`.
|
||||
|
||||
## Evidence To Check
|
||||
Use `errorStatusPattern`, `errorCodes`, and source flow. Look for fan-out, polling, batch work, AI jobs, uploads, sleeps, approval, multi-step side effects. If Workflow is already used, check whether the route waits or streams progress.
|
||||
|
||||
## Do Not Recommend When
|
||||
Do not offload work that must finish before responding. Do not claim savings from offload alone: Workflow Steps/Storage bill separately, and invoked functions still use compute billing.
|
||||
|
||||
## Verification
|
||||
Name the timeout/error class, long-running operation, post-enqueue response contract, and queue or workflow boundary that preserves semantics.
|
||||
+22
@@ -0,0 +1,22 @@
|
||||
---
|
||||
id: route-error-runtime-limits
|
||||
title: Route errors and runtime limits
|
||||
status: active
|
||||
candidateKinds: ["route_errors"]
|
||||
frameworks: ["*"]
|
||||
priority: 90
|
||||
citations: ["https://vercel.com/docs/functions", "https://vercel.com/docs/functions/limitations", "https://vercel.com/docs/cli/inspect"]
|
||||
maxBriefChars: 850
|
||||
---
|
||||
|
||||
## Investigation Brief
|
||||
Route error candidates are reliability findings with cost impact. Determine whether the failures are app exceptions, timeouts, payload limits, or deployment-specific regressions.
|
||||
|
||||
## Evidence To Check
|
||||
Use `errorStatusPattern`, `errorCodes`, and `errorsByDeployment`. In source, inspect the path most likely to throw, time out, or exceed a platform limit.
|
||||
|
||||
## Do Not Recommend When
|
||||
Do not frame high 5xx volume as a performance tuning issue. Do not suggest increasing limits before proving the route needs more headroom.
|
||||
|
||||
## Verification
|
||||
Name the error class, deployment concentration if present, and the file line that triggers or fails to handle it.
|
||||
+22
@@ -0,0 +1,22 @@
|
||||
---
|
||||
id: runtime-cache-reusable-data
|
||||
title: Runtime Cache for reusable server data
|
||||
status: active
|
||||
candidateKinds: ["slow_route", "external_api_slow"]
|
||||
frameworks: ["*"]
|
||||
priority: 84
|
||||
citations: ["https://vercel.com/docs/caching/runtime-cache", "https://vercel.com/docs/functions/functions-api-reference/vercel-functions-package"]
|
||||
maxBriefChars: 850
|
||||
---
|
||||
|
||||
## Investigation Brief
|
||||
Runtime Cache is only useful when the same server-side result is reused across requests. Treat it as a measured alternative when CDN response caching is unsafe or incomplete.
|
||||
|
||||
## Evidence To Check
|
||||
Use p75/p95 latency, call count, caller routes, and transfer bytes. In source, identify database queries, external API calls, or expensive computations that return the same result for many viewers.
|
||||
|
||||
## Do Not Recommend When
|
||||
Skip per-user data, mutations, secrets, one-off requests, or unknown freshness. Skip Runtime Cache when CDN caching solves the route. For Next with Cache Components, check `use cache: remote` first; use Runtime Cache only as a justified fallback.
|
||||
|
||||
## Verification
|
||||
Name the reusable data, observed route or hostname pressure, required freshness window, and the exact call site to wrap.
|
||||
+22
@@ -0,0 +1,22 @@
|
||||
---
|
||||
id: sveltekit-isr-prerender-safety
|
||||
title: SvelteKit ISR and prerender safety
|
||||
status: active
|
||||
candidateKinds: ["uncached_route", "isr_overrevalidation"]
|
||||
frameworks: ["sveltekit@*"]
|
||||
priority: 90
|
||||
citations: ["https://vercel.com/docs/frameworks/full-stack/sveltekit", "https://svelte.dev/docs/kit/adapter-vercel", "https://svelte.dev/docs/kit/page-options"]
|
||||
maxBriefChars: 850
|
||||
---
|
||||
|
||||
## Investigation Brief
|
||||
For SvelteKit, the right lever is often `prerender` or adapter ISR on public consumer pages. First prove every visitor can safely see the same response for the configured interval.
|
||||
|
||||
## Evidence To Check
|
||||
Inspect `+page`, `+page.server`, `+server`, layouts, `prerender`, `ssr`, and adapter `isr` config. Compare route cache results, ISR writes, and whether the route reads cookies, auth, or per-user locals.
|
||||
|
||||
## Do Not Recommend When
|
||||
Do not use ISR for dashboards, carts, checkout, account data, drafts, or any route whose output varies per visitor. Do not add ISR when `prerender = true` already makes it irrelevant.
|
||||
|
||||
## Verification
|
||||
Name the route, current SvelteKit page option or adapter config, observed cache or ISR signal, and the exact file line to change.
|
||||
+22
@@ -0,0 +1,22 @@
|
||||
---
|
||||
id: sveltekit-split-cold-start-tradeoff
|
||||
title: SvelteKit split function cold-start tradeoff
|
||||
status: active
|
||||
candidateKinds: ["cold_start", "slow_route"]
|
||||
frameworks: ["sveltekit@*"]
|
||||
priority: 82
|
||||
citations: ["https://vercel.com/docs/frameworks/full-stack/sveltekit", "https://svelte.dev/docs/kit/adapter-vercel"]
|
||||
maxBriefChars: 800
|
||||
---
|
||||
|
||||
## Investigation Brief
|
||||
SvelteKit bundles routes together by default to avoid excessive cold starts. Treat `split: true` as a targeted tradeoff, not a blanket optimization.
|
||||
|
||||
## Evidence To Check
|
||||
Use cold-start share, cold-vs-warm latency, deployment concentration, and source bundle pressure. Check adapter options and whether a large dependency belongs to one route or the whole app.
|
||||
|
||||
## Do Not Recommend When
|
||||
Do not split every route without evidence of function size pressure or route-local initialization cost. Do not split if cold starts are already the dominant problem.
|
||||
|
||||
## Verification
|
||||
Name the cold-start signal, route or dependency that motivates the split, and the exact adapter config line.
|
||||
+22
@@ -0,0 +1,22 @@
|
||||
---
|
||||
id: usage-spike-triage
|
||||
title: Usage spike triage
|
||||
status: active
|
||||
candidateKinds: ["usage_spike_triage"]
|
||||
frameworks: ["*"]
|
||||
priority: 95
|
||||
citations: ["https://vercel.com/docs/alerts", "https://vercel.com/docs/spend-management", "https://vercel.com/docs/bot-management"]
|
||||
maxBriefChars: 950
|
||||
---
|
||||
|
||||
## Investigation Brief
|
||||
A single-day or single-SKU spike needs cause before fix. Branches: bot or AI crawler on a cacheable route, viral moment, pricing-model migration, or code regression.
|
||||
|
||||
## Evidence To Check
|
||||
Confirm SKU and day from `usage.breakdown.data`. Cross-check firewall/bot data, traffic curve, SKU rename timing, and deploy log around the spike day. Spend Management and Alerts are monitoring tools; they do not replace finding the traffic or deploy cause.
|
||||
|
||||
## Do Not Recommend When
|
||||
Do not propose a code fix until the branch is identified. Do not rate-limit a viral moment or revert a deploy for third-party crawler traffic.
|
||||
|
||||
## Verification
|
||||
Name SKU, day, value, window mean, branch, and one supporting datum.
|
||||
+23
@@ -0,0 +1,23 @@
|
||||
---
|
||||
id: use-cache-date-stamp-isr-write-amplifier
|
||||
title: "'use cache' date-stamp ISR write amplifier"
|
||||
status: active
|
||||
candidateKinds: ["use_cache_date_stamp"]
|
||||
frameworks: ["next@>=15.0.0"]
|
||||
scannerPatterns: ["use-cache-date-stamp"]
|
||||
priority: 88
|
||||
citations: ["https://nextjs.org/docs/app/api-reference/directives/use-cache", "https://nextjs.org/docs/app/api-reference/functions/cacheLife"]
|
||||
maxBriefChars: 900
|
||||
---
|
||||
|
||||
## Investigation Brief
|
||||
`'use cache'` keys on argument identity and prerender output. A `new Date()`, `Date.now()`, or `Math.random()` baked into the cached output forces a fresh ISR write on every regeneration even when the data is unchanged.
|
||||
|
||||
## Evidence To Check
|
||||
Check the scanner finding's `subtype`: `module-scope` (module-level date) or `in-cache-fn` (inside the cached body). Cross-reference `isrWritesByRoute` — a stable write rate against low reads is the symptom.
|
||||
|
||||
## Do Not Recommend When
|
||||
Skip if the date is inside `useEffect`/`useCallback`/`useMemo`. Skip if `'use cache'` is only a comment. Skip if the date is the intended cache key.
|
||||
|
||||
## Verification
|
||||
Name the file, the specific primitive call, and the replacement: build-time constant or client-side `useEffect`.
|
||||
+22
@@ -0,0 +1,22 @@
|
||||
---
|
||||
id: use-cache-remote-shared-origin-data
|
||||
title: Remote cache for shared origin data
|
||||
status: active
|
||||
candidateKinds: ["external_api_slow", "slow_route", "uncached_route"]
|
||||
frameworks: ["next@>=16.0.0"]
|
||||
priority: 87
|
||||
citations: ["https://vercel.com/docs/caching/runtime-cache", "https://nextjs.org/docs/app/api-reference/directives/use-cache-remote"]
|
||||
maxBriefChars: 950
|
||||
---
|
||||
|
||||
## Investigation Brief
|
||||
For Next 16 candidates, check whether shared origin data or reusable route-handler work belongs in remote cache. Default `'use cache'` is not cross-request on Vercel. Use `'use cache: remote'` or `generateStaticParams`.
|
||||
|
||||
## Evidence To Check
|
||||
Hostname p75, caller routes, call count, bytes. Verify data is shared and tolerates the freshness window. Confirm `'use cache: remote'`.
|
||||
|
||||
## Do Not Recommend When
|
||||
Skip per-user, mutation, secret, or freshness-critical data. Skip when upstream is fast or rarely called. Avoid sub-ms reads (Edge Config) — overhead exceeds source latency.
|
||||
|
||||
## Verification
|
||||
Name hostname, shared data, freshness window, and exact boundary. State `'use cache: remote'`.
|
||||
+23
@@ -0,0 +1,23 @@
|
||||
---
|
||||
id: workflow-resumable-stream-routes
|
||||
title: Workflow resumable stream routes
|
||||
status: active
|
||||
candidateKinds: ["slow_route"]
|
||||
frameworks: ["*"]
|
||||
routePatterns: ["(^|/)api/.*/stream/?$", "(^|/)chat/.*/stream/?$", "\\[id\\].*/stream"]
|
||||
priority: 98
|
||||
citations: ["https://workflow-sdk.dev/docs/ai/resumable-streams", "https://workflow-sdk.dev/docs/foundations/streaming", "https://vercel.com/docs/workflow"]
|
||||
maxBriefChars: 850
|
||||
---
|
||||
|
||||
## Investigation Brief
|
||||
Stream-shaped routes may be Workflow SDK reconnection endpoints. Long wall-clock duration can be the live client connection.
|
||||
|
||||
## Evidence To Check
|
||||
Look for `WorkflowChatTransport`, `getRun`, `run.getReadable`, `startIndex`, `x-workflow-run-id`, `x-workflow-stream-tail-index`, `getWritable`, or `createUIMessageStreamResponse`. Compare CPU, TTFB, wall-clock. Check full replay, missing tail-index, unreleased locks, or unclosed streams.
|
||||
|
||||
## Do Not Recommend When
|
||||
Do not cache stream endpoints or remove resumability. Do not call high duration a bug when CPU is low, TTFB is healthy, and the route only holds a client connection.
|
||||
|
||||
## Verification
|
||||
Name whether the route starts or reconnects a run, then cite the exact waste: replay, missing tail-index, lock leak, unclosed stream, high CPU, or avoidable pre-first-byte work.
|
||||
Reference in New Issue
Block a user