Catch the Date.now()-in-cache trap before Cache Components ships it to production

You are auditing Next.js code for caching correctness under the Cache Components model, where a component or function is dynamic — it re-runs on every request — by default, unless it explicitly opts into caching with a 'use cache' directive at the top of the file or the function. Treat that inversion as the baseline for this audit; do not assume the older static-unless-opted-out model still applies anywhere in this codebase.

CACHING MODE AND VERSION
Next.js 16.1, cacheComponents: true in next.config.ts

CODE TO AUDIT
app/account/page.tsx plus lib/get-account-summary.ts, which is wrapped in 'use cache' and calls new Date() to build a 'balance as of' string.

FRESHNESS REQUIREMENTS
Account balance must always be current; the 'member since' date can be cached indefinitely; notification counts can be up to 2 minutes stale.

KNOWN CACHE-RELATED INCIDENTS
A support ticket reported two different users seeing the same account balance figure for about six minutes after a manual cache warm-up script ran.

THE TRAP TO CHECK FOR
Inside every function or component marked 'use cache', search for a call to a dynamic API: Date.now(), new Date(), Math.random(), cookies(), headers(), or a searchParams value read directly inside the cached scope. Flag every instance as a bug, not a style note. Once a function is cached, whatever value one of these calls happened to return on the request that populated that specific cache entry is frozen into every response served from that entry until its cacheLife profile expires or a matching cacheTag triggers revalidation — a "last updated" timestamp, a per-user greeting, or a randomized A/B assignment computed inside a 'use cache' scope will show the same frozen value to every visitor who hits that cache entry, not just the first one who happened to populate it. For every instance found, state exactly what value gets frozen, for how long given any cacheLife profile that's actually set (or the platform default if none is), and the fix: either move the dynamic read outside the 'use cache' boundary and pass it in as an argument from the uncached caller, or confirm explicitly that the staleness is genuinely intended and the cacheLife profile is scoped tightly enough to match that intent.

OTHER CHECKS
Confirm every 'use cache' function has an explicit cacheLife() profile rather than silently relying on the platform default — call this out either way, since an unnamed default is itself a decision nobody actually made on purpose. Check that cacheTag() calls are specific enough to invalidate correctly given the freshness requirements above — a single global tag covering an entire collection means any one item's update invalidates everything cached under that tag, which technically works but defeats the purpose of caching at the granularity the underlying data actually changes at. Flag anything cached that reads request-specific data — a user ID, a session token, a role, a tenant identifier — without that value being part of what determines the cache key, since that is a cross-user cache leak: one user's cached response getting served back to a completely different user who happens to hit the same cache entry next.

OUTPUT FORMAT
A findings table: File or function | Issue | Severity — bug, needs-profile, or leak-risk | Fix. Follow the table with one paragraph stating plainly whether the current caching setup, taken as a whole, actually matches the stated freshness requirements, and naming the single highest-risk finding first if more than one bug was found.