Decide exactly where the client/server boundary belongs in your component tree

You are auditing a Next.js App Router component tree to decide, component by component, whether each one should stay a Server Component (the default, no directive) or become a Client Component ('use client'). The goal is to push every client boundary down to the smallest leaf that genuinely needs it, never up to a shared ancestor for convenience.

COMPONENT TREE
app/checkout/page.tsx renders <OrderSummary>, <PromoCodeForm>, <ShippingAddressPicker>, and <PaymentButton>, all currently imported into one page component marked 'use client' at the top.

WHAT ACTUALLY NEEDS TO RUN IN THE BROWSER
PromoCodeForm needs an input and an apply button with pending state; ShippingAddressPicker needs a client-side address autocomplete widget; PaymentButton opens a third-party payment SDK modal on click.

CURRENT BOUNDARY PLACEMENT
The entire page.tsx has 'use client' at the top, so OrderSummary re-fetches and re-renders on the client via useEffect instead of being server-rendered with the order data it already had at request time.

REACT VERSION
19

DECISION RULES
Mark a component 'use client' only if it directly does at least one of the following: calls a stateful hook such as useState, useReducer, or a hook that reads a browser API; attaches a real event handler like onClick, onChange, or a client-side onSubmit; reads window, document, localStorage, navigator, or any other browser-only global; imports a third-party library that itself requires the client runtime, such as most charting libraries, rich-text editors, and drag-and-drop libraries; or consumes a React Context created with createContext for a value that changes at runtime. Every other component defaults to a Server Component, including anything that only fetches data, reads environment variables or secrets, or renders markup with no runtime behavior of its own, regardless of how deep it sits in the tree.

When a single component needs both server-fetched data and client interactivity, do not resolve the tension by making the whole thing a Client Component and fetching data with useEffect instead. Split it: keep the data fetch in a Server Component parent or grandparent, and pass the fetched data down as props or children into a small Client Component that owns only the interactive slice. Never move the 'use client' boundary higher in the tree than the smallest node that actually needs it, because everything imported beneath a client boundary in the module graph ships to the browser as JavaScript, including modules that look server-safe on their own — a chart library imported by a client-marked parent bundles into the client even if the specific component rendering the chart does nothing browser-specific itself.

If a component that is already marked 'use client' today does not actually meet any trigger in the rules above, treat that as a real finding, not a stylistic nitpick. Name what it currently costs — a heavier client bundle, a subtree that could have streamed server-rendered HTML but instead ships as an empty shell waiting for hydration — and recommend converting it back to a Server Component rather than leaving it as a safe-looking default.

OUTPUT FORMAT
A table: Component | Current marking | Recommended marking | Trigger from the rules that justifies Client (or "none — revert to Server") | One-line reason. Then, for every component you would restructure by splitting a mixed component into a server parent plus a client leaf, show the before/after boundary as a short tree diagram, not full code. Close with one paragraph describing what actually changes in the client JavaScript bundle if every recommendation here is applied, naming which specific dependency stops shipping to the browser.