Check web rendering

Operation

Inspect the selected SSR, hydration or server-action boundary without product edits. Read web rendering boundaries, then follow the repository's actual framework and rendering mode. Do not apply one framework's server/client rules to another.

Required input

The selected route/action, framework/runtime version, rendering mode, affected user state, trusted session/data owner and expected initial and post-interaction behavior. Recover available facts from the repository and supplied reproduction.

Goal and scope

Find concrete failures between server-rendered data, serialized payload, first browser render, client effects and subsequent mutations. Include the route's directly shared layout, cache and authorization owner. Keep general design, unrelated client state and backend redesign outside the selected boundary.

Inspect

• Framework/runtime versions, route handlers, server/client component boundaries, loaders, layouts, streaming or deferred segments, error/loading states and deployment configuration.
• Server render inputs, serialization/escaping, locale/timezone/theme sources, random IDs, time-dependent values, browser-only APIs and client initialization.
• Request identity, personalized fetches, cache keys/tags/lifetimes, CDN/framework caches and invalidation after mutations.
• Server actions or equivalent mutation endpoints, trusted sessions, object authorization, input validation, CSRF/origin handling and redirect destinations.
• Browser console/recoverable errors, rendered HTML, route tests, real browser tests and relevant production traces.

Audit method

1. Trace a concrete route from request and identity through server HTML/data to the first client render. Separate a server-only failure, hydration mismatch and later client-state bug.
2. Compare initial values on both sides. Reproduce the relevant saved preference, timezone, locale, signed-in state or query parameter; do not treat a harmless post-hydration update as a mismatch.
3. Follow serialized data and shared caches across two identities when personalization exists. Identify which layer owns cache variation and which mutation invalidates it.
4. Call the mutation boundary directly with the same object under permitted, forged and signed-out contexts. Hidden buttons and browser-supplied identity do not enforce server authorization.
5. Verify the browser symptom and its source owner. A unit test of a page function cannot establish successful hydration or navigation.

Issue classes and priority

Prioritize cross-user data exposure, unauthorized server actions and durable corruption; then failed first render, broken navigation/mutation, stale personalized output and inaccessible error recovery. Lower-priority findings still require a visible consumer effect. Examine duplicate effects during retries, lost validation errors, unsafe serialized data, unbounded redirect targets and mismatched server/browser environment assumptions only where reachable.

Evidence requirements

Provide route, affected state/identity, path:line and symbol, reproduction, expected and observed output, one correction direction and a meaningful regression. Do not suppress hydration warnings as a proposed repair or report every use of browser APIs as defective. Bound negative conclusions to the routes and states inspected, and distinguish local rendering evidence from deployment/CDN behavior.

Hand the repair step the first divergent value or decision in the request → HTML/payload → first render → interaction path, with the same fixture needed to reproduce it. For stale or exposed data, name the cache that actually served it and a second identity or post-write read that distinguishes the defect from a normal cache hit. Missing browser or HTTP evidence stays an open verification item.