How it works

Pipeline

1. Find the React fiber root using the adapter's rootCandidates (framework-specific mount points — not always document.body).
2. Read __reactFiber$* from those nodes and walk the fiber tree (same family of internals React DevTools uses).
3. Collect user client components: function/class/forwardRef/memo (including simple memo) fibers, with display names, excluding a framework-specific set of internal components (each adapter maintains its own list).
4. Map each client component to its outermost host DOM nodes (stopping at nested user boundaries).
5. Collect explicit server regions: elements with data-rsc-boundary-server (e.g. via RscServerBoundaryMarker).
6. Derive rsc-debug regions (development builds only): read _debugInfoon client component fibers, keep entries that look like server-owned component metadata, bucket by object identity, and anchor each region at the lowest common ancestor of the related DOM nodes. Framework internal names in the adapter's internals set are skipped.
7. Compute heuristic regions for anything not already covered: walk descendants of resolveScanContainer() (or document.body); nodes outside every client subtree and outside explicit / rsc-debug region roots become candidates; skip non-visual tags (script, style, etc.); drop wrappers that strictly contain a client root; keep minimal region roots (nested islands, not only top-level siblings).
8. Merge results in order: explicit, then rsc-debug, then heuristic (later passes only fill gaps).
9. Draw blue outlines for server regions and orange for client boundaries; floating labels use Server (explicit), Server (rsc), or Server (~)to match the panel's provenance (marker · debug · heuristic).
10. Attach a debounced MutationObserver on document.body to re-scan after navigations and dynamic updates.

What you see

• Client: dashed orange border and a label with the component name when available.
• Server: dashed blue border. Explicit regions use your marker label (or a host fallback if the attribute is empty). Rsc-debug regions use the Server Component name from _debugInfo when React provides it. Heuristic regions use host tags / ids / disambiguating indices because there is no fiber name for that slice of DOM.

Explicit markers

Wrap any server subtree with RscServerBoundaryMarker or set data-rsc-boundary-server on your own element. Optional attribute value becomes the panel label. Heuristic scanning skips DOM inside those subtrees (and inside rsc-debug region roots) so regions are not double-counted.

Development vs production builds

RscBoundaryProvider mounts devtools only when NODE_ENV is development. Production bundles ship no scanning UI (the provider renders only children). In production React, _debugInfo is not available either. This documentation site uses static outlined previews on the Examples page so you can see the color language without running fiber detection on a public build.

Limitations

• Depends on React internals (__reactFiber$*, _debugInfo). Acceptable for devtools; not a public React API.
• Framework-specific internal filtering is name-based in each adapter (@rsc-boundary/next, @rsc-boundary/start) and may need updates as those frameworks evolve.
• Heuristic server regions are inferred from DOM vs client roots; server output rendered inside a client subtree (slots) is still classified as client-owned for highlighting. Use explicit markers where that distinction matters.
• Portals and non-standard roots can still produce surprising groupings.