Diagnose SSR private-state leaks and hydration mismatch

Understand the likely causes

• Likely causes include module-global user stores, shared nested references, incomplete event.locals verification, unsafe load projection, request-dependent prerendering, time/locale differences or browser-only code evaluated too early. A component reused by Kit can also keep an initial snapshot even when the server returned correct new data. Diagnose each boundary separately rather than calling every wrong view a cache bug.

Trace the same object through two safe principals

Use synthetic allowed and denied principals with the same requested object ID. Record safe route, request correlation, principal scope and source revision, not credentials or full private payloads. Confirm that the session verifier established current authority in this event’s locals and that the domain helper applied tenant/object rules. If the source is already wrong, changing hydration or UI state cannot repair access policy. Check direct load, action and endpoint entry points because a protected layout can be bypassed by another server path. Do not probe real accounts or dump configured session state during editorial investigation.

Inspect module and nested-reference ownership

A server module instance can outlive one request, so a mutable exported user store can mix callers. A new wrapper does not deep-copy a shared principal or Map inside it. Allocate request/component-owned mutable state deliberately and share only values whose immutability and audience permit it. Context and runes do not automatically create request isolation. The JSON checklist is a synthetic design record, not an observed production trace. It asks whether the returned load model and any client cache preserve the same current principal scope when identity changes or pending old requests finish.

{"compare":"same-object-two-synthetic-principals","check":["verified-event-locals","tenant-aware-source","no-global-private-state","nested-reference-owner","public-load-projection","pending-old-result","initial-render-inputs"],"execution":"review-only"}

Compare source HTML and the first client output

Once source eligibility is correct, compare the exact initial data and markup under the same build. Check time, locale, random IDs, invalid HTML nesting and browser-only branches. Effects run only in the browser and cannot supply essential SSR data, while reused layouts can expose stale copied values during navigation. Page options must match the audience: private session output should not become public prerendered data. Do not disable SSR or suppress every mismatch before locating the differing input. A successful later screen does not prove initial privacy or hydration correctness.

Repair the earliest failing boundary and verify lifecycle

Move private server state to event-owned data or a scoped component/context factory, and project only eligible load fields. Use current reactive access for reused page data and reject incompatible old-principal results. Make initial output deterministic under an explicit timezone/format contract. Then test direct load, navigation, identity switching and overlapping callers in an authorized isolated build/browser environment. This guide parses its checklist only; it does not authenticate, issue requests, render HTML or hydrate a component. Keep that limitation visible and verify actual privacy and interaction rather than treating warning absence as a complete repair.

Keep it from recurring

• Keep private state request-owned, context lifetimes explicit and source policy shared across server entries. Retain SSR/navigation and cross-principal fixtures with page options and exact versions. Treat server-only import protection, authorized data access and public projection as complementary controls.