patch-cc 0.3.3__tar.gz → 0.4.0__tar.gz

{patch_cc-0.3.3 → patch_cc-0.4.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: patch-cc
-Version: 0.3.3
+Version: 0.4.0
 Summary: Interactive patcher for the Claude Code native binary
 Project-URL: Homepage, https://github.com/anfreire/patch-cc
 Project-URL: Repository, https://github.com/anfreire/patch-cc
@@ -198,14 +198,16 @@ startup name / `--version` marker are visible tells too.
 ## Why native-only, and why it stays small
 
 Claude Code now ships only as a Bun single-file executable; the npm package is a
-wrapper that downloads it. patch-cc edits the JavaScript bundle embedded in the
-binary's `.bun` section in place. It also drops the entry module's stale
-precompiled bytecode — editing the source invalidates it anyway, and it is more
-than half the download — so on Linux, where the ELF section is rewritten in
-place, a patched binary is *smaller* than the original, not larger. (On macOS
-the freed bytes are not yet reclaimed, so the file keeps its size; it still runs
-correctly.) [docs/INTERNALS.md](docs/INTERNALS.md#the-bytecode-and-why-we-drop-it)
-has the measurements; `patch-cc status` has yours.
+wrapper that downloads it. patch-cc edits the JavaScript modules embedded in the
+binary's `.bun` section in place — since 2.1.242 the app is code-split across
+~1,300 of them, and patch-cc treats every one as a single surface. It also drops
+the stale precompiled bytecode of the modules it edits — editing a module's
+source invalidates its bytecode anyway — so on Linux, where the ELF section is
+rewritten in place, a patched binary is *smaller* than the original, not larger
+(83 MB smaller on 2.1.243). (On macOS the freed bytes are not yet reclaimed, so
+the file keeps its size; it still runs correctly.)
+[docs/INTERNALS.md](docs/INTERNALS.md#the-bytecode-and-why-we-drop-it) has the
+measurements; `patch-cc status` has yours.
 
 See [docs/INTERNALS.md](docs/INTERNALS.md) for the container format and
 [docs/PLAYBOOK.md](docs/PLAYBOOK.md) for repairing a patch after an update.

{patch_cc-0.3.3 → patch_cc-0.4.0}/README.md

@@ -167,14 +167,16 @@ startup name / `--version` marker are visible tells too.
 ## Why native-only, and why it stays small
 
 Claude Code now ships only as a Bun single-file executable; the npm package is a
-wrapper that downloads it. patch-cc edits the JavaScript bundle embedded in the
-binary's `.bun` section in place. It also drops the entry module's stale
-precompiled bytecode — editing the source invalidates it anyway, and it is more
-than half the download — so on Linux, where the ELF section is rewritten in
-place, a patched binary is *smaller* than the original, not larger. (On macOS
-the freed bytes are not yet reclaimed, so the file keeps its size; it still runs
-correctly.) [docs/INTERNALS.md](docs/INTERNALS.md#the-bytecode-and-why-we-drop-it)
-has the measurements; `patch-cc status` has yours.
+wrapper that downloads it. patch-cc edits the JavaScript modules embedded in the
+binary's `.bun` section in place — since 2.1.242 the app is code-split across
+~1,300 of them, and patch-cc treats every one as a single surface. It also drops
+the stale precompiled bytecode of the modules it edits — editing a module's
+source invalidates its bytecode anyway — so on Linux, where the ELF section is
+rewritten in place, a patched binary is *smaller* than the original, not larger
+(83 MB smaller on 2.1.243). (On macOS the freed bytes are not yet reclaimed, so
+the file keeps its size; it still runs correctly.)
+[docs/INTERNALS.md](docs/INTERNALS.md#the-bytecode-and-why-we-drop-it) has the
+measurements; `patch-cc status` has yours.
 
 See [docs/INTERNALS.md](docs/INTERNALS.md) for the container format and
 [docs/PLAYBOOK.md](docs/PLAYBOOK.md) for repairing a patch after an update.

{patch_cc-0.3.3 → patch_cc-0.4.0}/docs/INTERNALS.md

@@ -13,7 +13,11 @@ binary:
 - **Windows**: a PE `.bun` section (not supported here)
 
 Inside that section is a *Bun module graph*: a flat arena of payloads, a module
-table describing them, and a trailer.
+table describing them, and a trailer. Before 2.1.242 the graph was the app in one
+module plus a few asset modules; since then the app is **code-split** across
+~1,300 `chunk-*.js` modules that the entry lazily imports (see
+[the split](#the-21242-split-and-the-patchable-surface)). Either way patch-cc
+treats every module the container declares to be JavaScript as one surface.
 
 ```
 .bun section
@@ -35,52 +39,85 @@ A module record (new 52-byte format) is six such pairs — `name`, `contents`,
 `sourcemap`, `bytecode`, `moduleInfo`, `bytecodeOriginPath` — followed by four
 `u8` flags (`encoding`, `loader`, `moduleFormat`, `side`).
 
-The module we patch is the entrypoint, which the offsets struct names by index
-(`entry_point_id`) — the same index Bun itself resolves it by. Its `contents` is
-the JS we edit. Its *name* is upstream's to change and we never read it:
-2.1.229 renamed it `/$bunfs/root/src/entrypoints/cli.js` → `/$bunfs/root/cli`.
-
 Code: `src/patch_cc/bun/blob.py`.
 
-## The bytecode, and why we drop it
-
-The entry module also carries precompiled Bun **bytecode** — more than half the
-binary. Every other module has none.
+## The 2.1.242 split, and the patchable surface
 
-Any edit to `contents` invalidates that bytecode; Bun detects the mismatch and
-recompiles from source at launch. So keeping it buys nothing:
+Through 2.1.241 the entrypoint module *was* the app: one ~28 MB `contents`
+carrying every line patch-cc anchors on. 2.1.242 turned on Bun code-splitting
+with lazy loading, and the shape changed under the tool:
 
-| binary | size | startup |
+| build | modules | entrypoint `contents` |
 |---|---|---|
-| original (valid bytecode) | 323 MB | ~100 ms |
-| patched, bytecode kept | 323 MB | ~650 ms |
-| patched, bytecode dropped | **125 MB** | ~650 ms |
-
-Patching pays the recompile cost either way, so patch-cc drops the entry
-module's bytecode (`rebuild(..., drop_bytecode=True)`). The result runs source,
-guaranteeing our edits are authoritative, and — on Linux — is smaller by
-exactly the bytecode.
-
-The size figures are the **ELF** path: the `.bun` section is rewritten in place,
-so the dropped bytecode is genuinely reclaimed (`container.verify` refuses a
-Linux write that did not shrink). On **macOS** the file keeps its original size:
-`macho.py` grows a segment but never shrinks one, so the freed bytes stay as
-dead space. The binary still runs correctly (the bytecode is gone), it is just
-not smaller — reclaiming it means shrinking the Mach-O segment and re-laying
-`__LINKEDIT`, which is not done yet.
-
-Those are **2.1.232's** Linux numbers, and they are a measurement rather than a
-promise: the same table read 267 / 113 MB against 2.1.216, because the bytecode
-grew from 154 MB to 198 MB in the fifteen builds between them (2.1.230 was
-never published). Read the current pair off any
-binary with `patch-cc status` rather than off this table.
-
-Every write asserts the binary it produced carries `bytecode == 0`
-(`container.verify`, beside the round-trip check), and `patch-cc status` reports
-the field for an installed one. `doctor` cannot: a dry run is handed a *clean*
-bundle, which still has its bytecode by definition. If a future Bun build makes
-bytecode authoritative over source, that assert is the tripwire — every patch
-would silently no-op otherwise.
+| 2.1.241 | 11 | 28,249,679 bytes (the whole app) |
+| 2.1.243 | 1,385 | 19,952 bytes (an argv shim) |
+
+The entrypoint is now a ~20 KB shim that parses argv and lazily
+`import()`s the app across ~1,300 `/$bunfs/root/chunk-*.js` modules; ~46 MB of
+JS, the largest chunk 7.3 MB. The code did not disappear — every anchor is still
+in the binary — but it left the one module patch-cc used to read, and it does not
+concentrate in a single chunk (`branding` spans a dozen modules, `org-label` ten,
+`spinner-tips` six).
+
+So the patchable surface is **every module the container declares to be
+JavaScript**, discovered the way the entrypoint itself is discovered — off the
+artifact, never hardcoded. A module's *loader* (the second trailing flag) is how
+Bun decides whether to compile it as source or hand it over as opaque bytes, and
+the entrypoint is by definition the JS Bun runs, so its loader *is* the JS loader
+(`Blob.js_modules`). The asset modules (the native addons, the bundled
+`mermaid`/`hljs`, the HTML template) carry other loaders and are left alone. A
+pre-split build is the one-module case of this — `js_modules()` returns just the
+monolith — so [`js.Source`](PLAYBOOK.md#the-many-module-surface) spans one module
+or a thousand through the same code.
+
+The entrypoint still matters for one thing: it is where the manifest lives and
+what `status` reads, named by the offsets struct's `entry_point_id` — the same
+index Bun resolves it by. Its *name* is upstream's to change and we never read
+it: 2.1.229 renamed it `/$bunfs/root/src/entrypoints/cli.js` → `/$bunfs/root/cli`.
+
+## The bytecode, and why we drop it
+
+Modules carry precompiled Bun **bytecode** — most of the binary. Before the
+split only the entry module had any (~half of it); the code-split builds carry it
+on nearly every chunk (232 MB of 377 on 2.1.243, across ~1,375 modules).
+
+Any edit to a module's `contents` invalidates *that module's* bytecode; Bun
+detects the mismatch and recompiles that module from source at launch. So keeping
+a stale copy buys nothing — the recompile is paid either way — and dropping it
+reclaims the space and guarantees our edits are what runs. patch-cc drops the
+bytecode of exactly the modules it edited (`rebuild` over `changed_modules`) and
+leaves every untouched module its bytecode and its fast start. On Linux, where
+the ELF section is rewritten in place, the binary is smaller by exactly the
+edited modules' bytecode.
+
+Measured on 2.1.243, the full patch set:
+
+| binary | size | bytecode | startup |
+|---|---|---|---|
+| pristine | 378 MB | 232 MB (every module) | ~13 ms `--version` |
+| patched (edited modules' bytecode dropped) | **295 MB** | 150 MB (untouched modules) | ~15 ms |
+
+The 83 MB reclaimed is the ~45 edited modules' bytecode; the rest stays, which is
+why a split-build patched binary is smaller but not the *half* a patched monolith
+was. The recompile is now per lazily-imported edited module rather than the whole
+app at once, so startup barely moves. Read the current figures off any binary
+with `patch-cc status` rather than off this table — the bytecode total grows every
+few builds.
+
+The size story is the **ELF** path: the `.bun` section is rewritten in place, so
+the dropped bytecode is genuinely reclaimed (`container.verify` refuses a Linux
+write that did not shrink by about that much). On **macOS** the file keeps its
+original size: `macho.py` grows a segment but never shrinks one, so the freed
+bytes stay as dead space. The binary still runs correctly (the bytecode is gone),
+it is just not smaller — reclaiming it means shrinking the Mach-O segment and
+re-laying `__LINKEDIT`, which is not done yet.
+
+Every write asserts each **edited** module carries `bytecode == 0` in the binary
+it produced (`container.verify`, beside the round-trip check), and `patch-cc
+status` reports the total for an installed one. `doctor` cannot: a dry run is
+handed a *clean* bundle, which still has all its bytecode by definition. If a
+future Bun build makes bytecode authoritative over source, that assert is the
+tripwire — every edit would silently no-op otherwise.
 
 ## Writing it back without ballooning
 
@@ -108,8 +145,10 @@ edit is followed by an ad-hoc `codesign` (mandatory on Apple Silicon).
 
 ## The manifest
 
-Every patched bundle ends with a single comment line — the one description of
-its shape; [PLAYBOOK.md](PLAYBOOK.md) covers what it means for matcher health:
+Every patched bundle carries a single comment line — appended to the **entry
+module**, the one module always present and always re-extracted, and the one
+`status` reads — describing its shape; [PLAYBOOK.md](PLAYBOOK.md) covers what it
+means for matcher health:
 
 ```
 //patch-cc {"v":1,"tool":"<version>","patches":[...],"brand":...,"suffix":...,
@@ -157,7 +196,8 @@ rather than from a store of their own.
   and dropped rather than aborting the run. See
   [PLAYBOOK.md](PLAYBOOK.md#the-syntax-gate).
 - Every write is verified: patch-cc re-extracts the JS from the binary it just
-  wrote and asserts it equals what it meant to write.
+  wrote and asserts every module equals what it meant to write, and that each
+  module it edited carries no leftover bytecode to run instead of the edit.
 - Patching a binary that is already marked, when no pristine backup exists, is
   refused outright — there is nothing clean to start from, and our edits change
   lengths, so a second pass would corrupt rather than update. `restore` or a

{patch_cc-0.3.3 → patch_cc-0.4.0}/docs/PLAYBOOK.md

@@ -152,6 +152,56 @@ gone green, and every one buys a branch against a single build. The counting
 below is the net for drift; the rule above is the only thing standing between a
 repair and the next repair.
 
+## The many-module surface
+
+Through 2.1.241 the bundle was one module — the entrypoint carried the whole app
+— and every matcher searched that one buffer. 2.1.242 code-split it: the
+entrypoint became a ~20 KB argv shim that lazily imports the app across ~1,300
+`chunk-*.js` modules ([INTERNALS](INTERNALS.md#the-21242-split-and-the-patchable-surface)).
+The anchors did not move — they scattered. So `js.Source` **spans every
+JavaScript module the container declares** (`Blob.js_modules`, discovered off the
+entrypoint's own loader), and the one-module world is exactly the many-module
+world with one module: `find`/`literals`/`count` sweep every module, `apply`
+routes each edit to the module its node came from, and a patch says
+`source.find(name)` / `source.apply(edits)` unchanged. This is representation
+change of the crudest kind — the same code in more files — so it *moved* no
+invariant and abolished none; the surface widened, the rules held. Three things
+the move made explicit, each a rule the single-module world could leave unsaid
+because the module was the bundle:
+
+- **A node carries its module; an offset does not.** An `Edit` is built from a
+  node, and the node's program root (`node.id`, distinct across parses) names the
+  module the edit belongs to, so a batch spanning a dozen chunks routes each
+  splice home and reparses only the modules it touched. It is why dedup keys are
+  the node's `id`, never its `start_byte`: a minified offset repeats in a
+  thousand modules, and two different sites at the same local offset are two
+  sites, not one to skip.
+
+- **A minified local is scoped to its module.** Resolving one — a hoisted
+  `agentType:uu` constant read through its value — searches *its own* module
+  (`Source.find_local`), never the bundle, where `uu` binds a string in a dozen
+  unrelated chunks and `js.only` would rightly refuse to choose. Before the split
+  the module *was* the bundle, so a bundle-wide `find` was a module-wide one; the
+  two only came apart when the app was dealt across files. The same lesson the
+  playbook already states for identifiers within a build — "a name is a spelling
+  until its scope is said" — now reaches the module boundary too. A scope search
+  that climbs outward (`live-thinking`'s state and memo resolution) reads the
+  module wrapper by what it *is* — the pre-split monolith's whole-body IIFE is a
+  module of one top-level statement; a split module's `program` is dozens, and
+  its top-level components are real scopes to search — never by a fixed position,
+  which read every split component as the un-searchable wrapper and found nothing.
+
+- **The gate reads code, not linkage.** tree-sitter's JavaScript grammar does not
+  model a reserved word as an import/export alias (`export{x as if}`,
+  `import{if as a}` — legal ES2015, which the split minifier emits when its
+  two-letter alias generator lands on `if`/`in`/`do`), so it plants a localized
+  `ERROR` inside the clause. patch-cc never locates in or edits module linkage —
+  every anchor is executable code — so `Source.defect` reads *past* an error
+  confined to an import/export statement and returns the first one that is not,
+  while a splice that broke real code still lands outside linkage and is still
+  caught. It is the gate's scope stated precisely, not a tolerance bolted on: the
+  eight such modules on 2.1.243 parse clean for every purpose the tool has.
+
 ## Discovery instead of hardcoding
 
 Anything the binary can enumerate for us, it does:
@@ -313,7 +363,9 @@ re-deriving it.
 
 Both numbers above are counts, and a count cannot tell a rewrite that landed
 from a rewrite that landed *one prop-name to the left*. So the bundle is parsed,
-and any `ERROR` or `MISSING` node aborts (`src/patch_cc/js.py`).
+and any `ERROR` or `MISSING` node **outside module linkage** aborts
+(`src/patch_cc/js.py`; the linkage read-past is
+[above](#the-many-module-surface)).
 
 The parse is not a separate pass any more: locating already needs it, and an
 edit costs one incremental reparse — ~75 ms on a 25 MB bundle against ~3 s for a
@@ -493,6 +545,10 @@ that broke a patch along with every note.
    patch-cc extract ~/.local/share/claude/versions/<ver> > clean.js
    ```
 
+   Since 2.1.242 that is every JavaScript module concatenated, each behind a
+   `// ==== patch-cc module <n> ====` header, so `rg` still works over one file
+   and the header says which chunk a hit lives in.
+
 2. Run `patch-cc doctor`. Note which patch dropped to `candidates == 0`, or —
    for `live-thinking` — which sub-step.
 
@@ -856,11 +912,17 @@ for you. Each entry: what it changes, the stable anchor, and where it lives.
   than carried over from whichever renderer the first step happened to see
   last: a second component with the same four props donated its local to the
   first one's memo, spliced an identifier that component cannot see, and
-  reported both steps green. The memo itself is found by what it computes (a
-  `useMemo` over a `flatMap` that wraps each streaming block as a message),
-  which is what a claim about the *text* around the block (`.contentBlock]}`)
-  only approximated: one sibling property beside `content` read as the whole
-  computation being gone.
+  reported both steps green. The memo itself is found by what it computes — an
+  arrow whose whole body is a `flatMap` that wraps each streaming block as a
+  message, and the call that takes that arrow — never by the memo hook's name.
+  The hook is one more minified spelling: the monolith reaches it as
+  `<React>.useMemo(...)` (the property name survives a member read), but a
+  code-split module imports it under a local (`import{useMemo as te}` → `te(...)`),
+  so keying on `useMemo` read a build that memoizes exactly the same way as one
+  with no memo at all, and the rewrite reuses the memo's *own* callee rather than
+  re-spelling `.useMemo`. What a claim about the *text* around the block
+  (`.contentBlock]}`) only approximated is the computation itself: one sibling
+  property beside `content` read as the whole thing being gone.
 
   **`display-mode`** defaults the request's thinking display to `"summarized"`;
   without it the API only streams summary text when the `showThinkingSummaries`

{patch_cc-0.3.3 → patch_cc-0.4.0}/docs/corpus.md

@@ -21,11 +21,13 @@ matches means the file changed under you, not that a number moved.
 
 ## On disk now
 
-The whole published span `2.1.210` → `2.1.236` — 2.1.230 was never published —
-one pristine binary per version, 26 in all. Two pairs share a byte count
-(`2.1.225`/`2.1.226`, `2.1.229`/`2.1.231`) and are still distinct binaries,
-which is why the identity column is the hash (of the whole file,
-`sha256sum <version>.orig`) and never the size:
+The whole published span `2.1.210` → `2.1.243` — 2.1.230 was never published —
+one pristine binary per version, 33 in all. It straddles the **2.1.242 code
+split** (INTERNALS.md): `2.1.242`/`2.1.243` are the first many-module builds, and
+they jump ~35 MB over `2.1.241` for it. Several pairs share a byte count
+(`2.1.225`/`2.1.226`, `2.1.229`/`2.1.231`, `2.1.239`–`2.1.241`, `2.1.242`/`2.1.243`)
+and are still distinct binaries, which is why the identity column is the hash (of
+the whole file, `sha256sum <version>.orig`) and never the size:
 
 | version | size | sha256 |
 |---|---|---|
@@ -55,10 +57,17 @@ which is why the identity column is the hash (of the whole file,
 | `2.1.234` | 328 MB | `3473601ea695d5bf769c5b202844d4cb4fbf723ae995450fcb6973204775c84a` |
 | `2.1.235` | 331 MB | `bfcf0ae2dbf94b2b6a106074aabf3938b9a10889c3b678e4cb5a00c03274d5d5` |
 | `2.1.236` | 335 MB | `6c8818fa22187aa555c242be4abbacc44d6b71a32ac9631ee7b2b5d12f51f752` |
+| `2.1.237` | 335 MB | `73975167f0108693cf6fd6614994781657ebb8456ebef5d247458734abfb3916` |
+| `2.1.238` | 339 MB | `0933b286cf94e1b2504b35ac165ab76b8f822735d53371c56393988c23040d58` |
+| `2.1.239` | 343 MB | `7de1b1576e2e0be73ce91c2b4dedf16a41058ea633b957a36fdc6044ddfc0f3c` |
+| `2.1.240` | 343 MB | `1386169da77de19a655f07a86ab80f5775983a50eb0c9c27a7daf16e7320322d` |
+| `2.1.241` | 343 MB | `0771bd866cff82b76581fc0499f6529e1a36845078f144f8c81dccb3bc7037b8` |
+| `2.1.242` | 378 MB | `528ef039aa7d64d7b3fbc06925132755a516b4dcaad784cf0b51fe03167360d4` |
+| `2.1.243` | 378 MB | `4b0dafeedd0b469c41988e200036fd773e7553ba960349c9f02a82c6d1f2ba27` |
 
 This set covers the span the playbook's tree-move measurements were taken over
-(`2.1.210` → `2.1.233`), so those numbers are re-checkable here rather than
-historical.
+(`2.1.210` → `2.1.233`) and the 2.1.242 split, so both are re-checkable here
+rather than historical.
 
 ## Rebuild or extend it
 

{patch_cc-0.3.3 → patch_cc-0.4.0}/src/patch_cc/__init__.py

@@ -1,3 +1,3 @@
 """patch-cc: an interactive patcher for the Claude Code native binary."""
 
-__version__ = "0.3.3"
+__version__ = "0.4.0"

{patch_cc-0.3.3 → patch_cc-0.4.0}/src/patch_cc/bun/blob.py

@@ -24,6 +24,11 @@ from .errors import BunError
 TRAILER = b"\n---- Bun! ----\n"
 OFFSETS_SIZE = 32
 
+#: Index of the ``loader`` byte in a module record's four trailing flags
+#: (``encoding, loader, module_format, side``). It is how Bun decides whether a
+#: module is JavaScript it compiles or an asset it hands over as bytes.
+LOADER = 1
+
 #: Module record field order. Old Bun (<1.3.7) stops after ``bytecode``.
 FIELDS_NEW = (
     "name",
@@ -86,18 +91,40 @@ class Blob:
         """
         return self.modules[self.entry_point_id]
 
-    def entry_source(self) -> bytes:
-        return self.payload(self.entry_module().ranges["contents"])
+    def js_modules(self) -> list[Module]:
+        """Every module Bun loads the way it loads the entrypoint: the JS the
+        app is made of.
+
+        Since 2.1.242 the entrypoint is a ~20 KB argv shim that lazily imports
+        the app across ~1,300 ``chunk-*.js`` modules; before it, the entrypoint
+        *was* the whole app. Both are one question -- which modules carry the
+        JavaScript we patch -- and the loader byte answers it: a module's
+        ``loader`` (the second trailing flag) says how Bun reads it, and the
+        entry is by definition the JS Bun runs, so its loader *is* the JS loader.
+        Read off the artifact, exactly as :meth:`entry_module` reads the
+        entrypoint -- never hardcoded to a value, and never by name -- so a build
+        that renumbers the loader still answers correctly. The assets (native
+        addons, the bundled ``mermaid``/``hljs`` minified files, the HTML
+        template) carry other loaders and are excluded: they are opaque bytes to
+        Bun and would not parse as our JavaScript.
+
+        Pre-split, this is the one-element list ``[entry_module()]`` -- the
+        monolith -- so the single-module world is exactly the many-module world
+        with one module, and every layer above flows through the same code.
+        """
+        loader = self.entry_module().trailing[LOADER]
+        return [m for m in self.modules if m.trailing[LOADER] == loader]
 
     def bytecode_size(self) -> int:
-        """Bytes of precompiled bytecode on the entrypoint, for either layout.
+        """Total precompiled Bun bytecode across every module, for either layout.
 
         ``bytecode`` is the fourth pair, so *both* record formats carry it --
-        ``FIELDS_OLD`` is the first four of ``FIELDS_NEW``. Reporting zero for the
-        36-byte layout said "already stripped" about a module that had 154 MB of
-        it, which is the one thing ``status`` reads this for.
+        ``FIELDS_OLD`` is the first four of ``FIELDS_NEW``. Before 2.1.242 only
+        the entrypoint carried any; the code-split builds carry it on every
+        chunk, so the figure ``status`` reports and the write reclaims is the sum,
+        not one module's.
         """
-        return self.entry_module().ranges["bytecode"][1]
+        return sum(m.ranges["bytecode"][1] for m in self.modules)
 
 
 def _detect_struct_size(modules_len: int) -> int:
@@ -192,20 +219,29 @@ def parse(data: bytes) -> Blob:
     )
 
 
-def rebuild(blob: Blob, source: bytes, *, drop_bytecode: bool = True) -> bytes:
-    """Return a new blob with the entrypoint's source replaced.
-
-    Payloads are re-emitted in their original file order so the result stays as
-    close to the input layout as possible.
-
-    ``drop_bytecode`` removes the entrypoint's precompiled Bun bytecode. Editing
-    the source invalidates that bytecode anyway -- Bun recompiles from source --
-    so keeping it costs more than half the binary for no benefit. What that is in
-    megabytes is a fact about the build, and :meth:`Blob.bytecode_size` reads it;
-    docs/INTERNALS.md has the measurements.
+def rebuild(
+    blob: Blob, sources: dict[int, bytes], *, drop_bytecode: bool = True
+) -> bytes:
+    """Return a new blob with the given modules' source replaced.
+
+    ``sources`` maps a module index to its new ``contents``; every other
+    module's bytes are re-emitted unchanged. Payloads keep their original file
+    order so the result stays as close to the input layout as possible. One
+    edited module or a thousand is the same code -- the pre-split monolith is
+    just ``{entry_index: new_bytes}``.
+
+    ``drop_bytecode`` removes the precompiled Bun bytecode of exactly the
+    modules whose source changed. Editing a module's source invalidates its
+    bytecode -- Bun recompiles that module from source -- so keeping it would
+    run the recompile cost *and* the megabytes; dropping it reclaims the space
+    and, more importantly, guarantees our edits are what runs
+    (docs/INTERNALS.md). A module we did not touch keeps its bytecode and its
+    fast start. The set actually changed is returned by :func:`changed_modules`;
+    here we drop for every module handed new bytes, since a caller only passes
+    bytes it means to replace.
     """
-    entry = blob.entry_module()
     fields = blob.fields
+    changed = set(sources)
 
     # Every payload, in the order it appears in the source arena.
     placed: list[
@@ -222,15 +258,15 @@ def rebuild(blob: Blob, source: bytes, *, drop_bytecode: bool = True) -> bytes:
     new_ranges: dict[tuple[int, str], tuple[int, int]] = {}
     prev_end = 0
     for off, length, mod_index, field in placed:
-        is_entry = mod_index == entry.index
-        if is_entry and field == "bytecode" and drop_bytecode:
+        edited = mod_index in changed
+        if edited and field == "bytecode" and drop_bytecode:
             new_ranges[(mod_index, field)] = (0, 0)
             prev_end = off + length
             continue
 
         payload = (
-            source
-            if (is_entry and field == "contents")
+            sources[mod_index]
+            if (edited and field == "contents")
             else blob.data[off : off + length]
         )
         # Preserve the 1-byte separators Bun emits between payloads.
@@ -268,16 +304,33 @@ def rebuild(blob: Blob, source: bytes, *, drop_bytecode: bool = True) -> bytes:
     struct.pack_into("<I", out, offsets_at + 28, blob.flags)
 
     if drop_bytecode:
-        # The entry now carries no bytecode -- whether we dropped a real payload
-        # or it had none to begin with. Reading the outcome with a ``(0, 0)``
-        # default is what lets the had-none case flow through the same check
-        # instead of raising ``KeyError`` past both CLI handlers: a field the
-        # ``placed`` loop never saw a length for is absent from ``new_ranges``,
-        # and absent *is* stripped.
-        assert new_ranges.get((entry.index, "bytecode"), (0, 0)) == (0, 0)
+        # Each edited module now carries no bytecode -- whether we dropped a real
+        # payload or it had none to begin with. Reading the outcome with a
+        # ``(0, 0)`` default is what lets the had-none case flow through the same
+        # check instead of raising ``KeyError``: a field the ``placed`` loop never
+        # saw a length for is absent from ``new_ranges``, and absent *is*
+        # stripped.
+        for index in changed:
+            assert new_ranges.get((index, "bytecode"), (0, 0)) == (0, 0)
     return bytes(out)
 
 
+def changed_modules(blob: Blob, sources: dict[int, bytes]) -> dict[int, bytes]:
+    """The subset of ``sources`` whose bytes actually differ from the blob.
+
+    A module the patches parsed but left byte-identical must not have its
+    bytecode dropped: that would trade a working fast-start module for a slow
+    recompile of code that never changed. So the write reclaims bytecode for the
+    modules that moved and no others, and the size tripwire measures against that
+    same set.
+    """
+    return {
+        index: data
+        for index, data in sources.items()
+        if data != blob.payload(blob.modules[index].ranges["contents"])
+    }
+
+
 def unwrap_section(section: bytes) -> tuple[bytes, int]:
     """Strip the length prefix a container section puts in front of the blob.