Code Memory — Diagnose & Fix Memory Leaks — refactor-chain · DEBUG lane

Bundle: refactor-chain (self-diagnosing, self-healing fix-it pipeline). Phase: do-the-work (debug) · Prerequisite: diagnose (harness classified the case as debug/code-memory) · Next: review gate → docs → ship. Adaptivity / conditional: works for browser (DevTools heap snapshots) and Node.js (v8.writeHeapSnapshot / --inspect). Prefers a browser/DevTools heap tool when connected; otherwise drives Node's built-in heap-snapshot APIs. Repo-agnostic beyond that JS/TS runtime split.

Purpose

Find and fix a real memory leak — memory that grows across repeated identical actions and is never reclaimed — rather than guessing at "probably a listener somewhere." The method is snapshot diffing: take a heap snapshot, do the suspect action N times, take another, and compare. The objects that accumulated (and shouldn't have) are the leak; following their retained size and retaining path back to the GC root reveals the exact reference that pins them. Fix that reference; prove the growth is gone.

When to use

• Memory climbs the longer the app runs or the more you repeat an action. Triggers: "memory keeps growing", "gets slower over time", "heap keeps climbing".
• It eventually crashes or is killed. Triggers: "OOMs after a while", "process RSS never comes back", "out of memory".
• A known leak smell. Triggers: "detached DOM nodes", "listeners not cleaned up", "cache never evicts".
• Not for: a one-off crash/bug (use refactor-whats-wrong) or slow page load / jank (use refactor-web-performance).