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

{patch_cc-0.4.0 → patch_cc-0.5.0}/AGENTS.md

@@ -17,9 +17,15 @@ point it at the pristine copies in `~/.local/share/patch-cc/backups/` to sweep
 older builds). There is no test suite by design — doctor against real bundles
 is the check.
 
-Be exact about what that covers: doctor runs the **matchers** and parses the
-bundle they produce. It never runs the gateway, the translator, the OAuth flow
-or the menu, so a change under `src/patch_cc/codex/` (the bridge — all of it
-runtime, none of it a patch; the Codex *patch* is `patches/codex.py`, which the
-sweep does cover) or in `menu.py` is checked by exercising it — a real `codex
-serve` against a real turn — and a green sweep says nothing about it.
+Be exact about what that covers: doctor runs the **matchers**, parses the
+bundle they produce, then **bakes it into a temp binary and executes
+`--version`** — so the sweep also proves every build writes and boots (the
+container layer included; 2.1.246 is why). It still never runs the gateway,
+the translator, the OAuth flow or the menu, so a change under
+`src/patch_cc/codex/` (the bridge — all of it runtime, none of it a patch; the
+Codex *patch* is `patches/codex.py`, which the sweep does cover) or in
+`menu.py` is checked by exercising it — a real `codex serve` against a real
+turn — and a green sweep says nothing about it. Nor does `--version` exercise
+a patch's *feature* at runtime: it proves the patched code loads and runs, not
+that a streamed turn renders — behaviour changes still want a real turn
+watched.

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

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: patch-cc
-Version: 0.4.0
+Version: 0.5.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
@@ -94,7 +94,7 @@ patch-cc                       # then just run it
 | Chrome & branding | Disable spinner tips | No rotating tips on the spinner |
 | | Mark `--version` | Appends `(patched)` — or any marker you choose |
 | | Custom startup name | Defaults to `<your username>'s Code` |
-| | Startup org/email label | Replace the org/email on the welcome screen — or hide it (demo mode keeps the stock line) |
+| | Startup org/email label | Replace the org/email on the welcome screen — or hide it (demo mode keeps the stock line). Upstream stopped drawing the segment in 2.1.246, so newer builds offer this dimmed as *not on this build* |
 
 ## Usage
 
@@ -113,8 +113,8 @@ uvx patch-cc apply --org-label "Ada's Lab"    # ...or show this instead
 uvx patch-cc apply --codex gpt-5.6-sol        # + a Codex model (see below)
 uvx patch-cc apply --from-cache               # replay your last remembered selection
 uvx patch-cc status                           # exactly what is applied
-uvx patch-cc doctor                           # do all patches match this build?
-uvx patch-cc doctor path/to/claude            # ...or match some other binary
+uvx patch-cc doctor                           # do all patches match this build, and does it bake + boot?
+uvx patch-cc doctor path/to/claude            # ...same, for some other binary
 uvx patch-cc list                             # every patch, described
 uvx patch-cc restore                          # put the original back
 ```

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

@@ -63,7 +63,7 @@ patch-cc                       # then just run it
 | Chrome & branding | Disable spinner tips | No rotating tips on the spinner |
 | | Mark `--version` | Appends `(patched)` — or any marker you choose |
 | | Custom startup name | Defaults to `<your username>'s Code` |
-| | Startup org/email label | Replace the org/email on the welcome screen — or hide it (demo mode keeps the stock line) |
+| | Startup org/email label | Replace the org/email on the welcome screen — or hide it (demo mode keeps the stock line). Upstream stopped drawing the segment in 2.1.246, so newer builds offer this dimmed as *not on this build* |
 
 ## Usage
 
@@ -82,8 +82,8 @@ uvx patch-cc apply --org-label "Ada's Lab"    # ...or show this instead
 uvx patch-cc apply --codex gpt-5.6-sol        # + a Codex model (see below)
 uvx patch-cc apply --from-cache               # replay your last remembered selection
 uvx patch-cc status                           # exactly what is applied
-uvx patch-cc doctor                           # do all patches match this build?
-uvx patch-cc doctor path/to/claude            # ...or match some other binary
+uvx patch-cc doctor                           # do all patches match this build, and does it bake + boot?
+uvx patch-cc doctor path/to/claude            # ...same, for some other binary
 uvx patch-cc list                             # every patch, described
 uvx patch-cc restore                          # put the original back
 ```

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

@@ -23,17 +23,33 @@ treats every module the container declares to be JavaScript as one surface.
 .bun section
 └── [u64 size prefix]           (u32 on Bun < 1.3.4)
     └── Bun blob
-        ├── payload arena       name / contents / sourcemap / bytecode / ... bytes
+        ├── payload arena       name / contents / sourcemap / bytecode / ... bytes,
+        │                       plus the record chain's own payloads (Bun >= 1.4.1)
         ├── module table        N records × 52 bytes (36 on old Bun)
+        ├── record chain        flag-gated records (Bun >= 1.4.1), see below
         ├── compileExecArgv
         ├── offsets struct       32 bytes: byteCount, modulesPtr, entryId, argvPtr, flags
         └── "\n---- Bun! ----\n"  15-byte trailer
 ```
 
 Every pointer is a `(u32 offset, u32 length)` pair relative to the blob start,
-and pointers live in only two places: the module table and the offsets struct.
-That is what makes rewriting tractable — move a payload, fix the handful of
-pointers that describe it.
+and pointers live in exactly three places: the module table, the offsets
+struct, and the record chain. That is what makes rewriting tractable — move a
+payload, fix the handful of pointers that describe it.
+
+Two invariants ride on payload *positions* rather than pointers, and `rebuild`
+preserves both by keeping every payload's inter-payload gap and its offset
+phase modulo 128 — so a rebuild with no edits reproduces the blob byte for
+byte, and one with edits moves payloads only in whole alignment steps:
+
+- Bytecode payloads (module bytecode, and the record chain's bytecode blobs)
+  sit at blob `offset % 128 == 120`, which is 128-byte alignment once the
+  section's 8-byte size prefix is in front. Bun ≥ 1.4.1 deserializes bytecode
+  in place and calls misalignment "a runtime assertion error or segfault"
+  (`append_bytecode_aligned`); older Bun quietly tolerated the phase drift the
+  rewriter used to introduce.
+- `count_z` payloads (names, contents) carry a NUL terminator in the gap
+  after them.
 
 A module record (new 52-byte format) is six such pairs — `name`, `contents`,
 `sourcemap`, `bytecode`, `moduleInfo`, `bytecodeOriginPath` — followed by four
@@ -41,6 +57,42 @@ A module record (new 52-byte format) is six such pairs — `name`, `contents`,
 
 Code: `src/patch_cc/bun/blob.py`.
 
+## The record chain (Bun ≥ 1.4.1)
+
+2.1.246 moved to Bun 1.4.1, whose `StandaloneModuleGraph.rs` chains optional
+records directly after the module table, each announced by a new `flags` bit
+and read back in flag order:
+
+| bit | record |
+|---|---|
+| 5 | `[u32; modules]` — each module's WTF hash of its source text (0 = none) |
+| 6 | `u32 count`, then `count` × `{u32 id, ptr}` — internal-module bytecode |
+| 7 | one pointer: the **shared bytecode string table** |
+| 8 | `u32` — how many leading modules load before the first `import()` |
+| 9 | one pointer: the string table `moduleInfo` bodies index |
+
+The pointers point back into the arena: the shared string table (~9.9 MB on
+2.1.246) is the string data **every chunk's bytecode references by ordinal**,
+so it is load-bearing for every module we did *not* touch. The hash is JSC's
+SourceCodeKey hash, how a launch that runs from bytecode avoids paging in
+source text just to hash it.
+
+patch-cc parses the chain record for record (`_parse_records` — a build with
+none of the bits, which is every Bun before 1.4.1, walks zero records through
+the same code), carries the pointed-at payloads through `rebuild` like any
+module payload, copies the whole tail between table and offsets struct
+verbatim, and re-points the pointers in place. Two details matter:
+
+- An **edited** module's hash word is zeroed — upstream's own "none, compute
+  it" value — because the pristine text's hash must not key our bytes in JSC's
+  source cache.
+- **Unknown** record bits are refused at parse: a record of unknown size
+  cannot be walked past nor re-pointed, and rewriting around it is exactly how
+  a graph gets corrupted. 2.1.246 against patch-cc ≤ 0.4.0 is the lesson: the
+  chain-blind rewriter dropped the records and zero-filled the string table
+  while every *module* round-tripped byte-perfect — matcher-green, dead at
+  launch, `SIGSEGV` from inside Bun's graph loader.
+
 ## The 2.1.242 split, and the patchable surface
 
 Through 2.1.241 the entrypoint module *was* the app: one ~28 MB `contents`
@@ -86,9 +138,11 @@ detects the mismatch and recompiles that module from source at launch. So keepin
 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.
+leaves every untouched module its bytecode and its fast start — which is why
+the shared bytecode string table those modules' bytecode indexes
+([the record chain](#the-record-chain-bun--141)) is never droppable. 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:
 
@@ -114,10 +168,12 @@ 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.
+status` reports the total for an installed one. `doctor`'s dry run cannot — a
+clean bundle still has all its bytecode by definition — but its smoke bake
+writes a temp binary through the same `container.write` and then *executes* it,
+so the sweep exercises the assert, and the loader itself, on every corpus
+build. 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
 
@@ -196,8 +252,14 @@ 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 every module equals what it meant to write, and that each
-  module it edited carries no leftover bytecode to run instead of the edit.
+  wrote and asserts every module equals what it meant to write, that each
+  module it edited carries no leftover bytecode to run instead of the edit, and
+  that the graph around the modules survived — the record chain kept its
+  length and flags, its arena payloads (the shared bytecode string table above
+  all) round-trip byte-identical, and every source-hash word is the pristine
+  one, except an edited module's, which must be zero. The chain checks exist
+  because 2.1.246 failed *only* there: every module compared equal while the
+  written binary was dead.
 - 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.4.0 → patch_cc-0.5.0}/docs/PLAYBOOK.md

@@ -309,6 +309,20 @@ isolation was cheaper and could not see the one ordering this project calls
 load-bearing — `codex-models` registering the ids `subagent-models` then pins —
 nor anything at all about the bundle the run produced, which it discarded.
 
+The composed result is then **baked and executed**: doctor writes it into a
+temp binary through the same `container.write` as a real apply — staging,
+round-trip verification, the container checks — and runs `<binary> --version`,
+expecting the version-marker suffix in the output (our own edit's print, so the
+check proves patched code *executes*, not merely that the binary boots around
+it). Matching and running are different truths with different failure owners:
+matchers break in the patches, the run breaks in the container layer, and
+2.1.246 is the build where they split — every matcher green, every module
+round-tripping byte-perfect, and the written binary `SIGSEGV`ing in Bun's graph
+loader because what the rewrite had destroyed (the Bun 1.4.1 record chain and
+the shared bytecode string table, docs/INTERNALS.md) lives in bytes no module
+owns. The temp binary is always removed; the backup under test is never
+written to.
+
 Three readings of the two numbers, kept distinct:
 
 | symptom | meaning |
@@ -608,6 +622,12 @@ that broke a patch along with every note.
    enumerated with its hashes in [corpus.md](corpus.md) — so both sides are
    recomputed from the binaries themselves.
 
+   Each build's report ends with its baked binary's own `--version` output (the
+   smoke run above), so the sweep also proves every corpus build still *bakes
+   and boots* — the half matcher counts cannot see, and the half 2.1.246 broke
+   while every count held. A moved runtime line is as much a finding as a moved
+   count.
+
 ## Patch reference
 
 Grouped by source module. The menu's three groups (Output & display, Models &
@@ -848,28 +868,37 @@ for you. Each entry: what it changes, the stable anchor, and where it lives.
     *initialised* to is deliberately not asked: `useState(null)` is every
     build's spelling and `useState(void 0)` would be the same state, while the
     setter is the identity that matters.
-  - **The state has two homes, and the handed setter names both.** Through
-    2.1.235 the scope that hands `onStreamingThinking` declared the state
-    itself, and the state is the array pattern binding the handed setter —
-    `useState`'s pair. 2.1.236 moved it into an external stream store
-    (`subscribe`/`getSnapshot`/`_publish` — the `useSyncExternalStore` shape)
-    and hands `<store>.setStreamingThinking` instead; the same scope reads the
-    store back by destructuring the hook call it hands the store to
-    (`{streamingToolUses:…}=useX(<store>)`), so the state is that pattern's own
-    `streamingThinking` binding — upstream's the day it takes one, the goal
-    achieved, and until then ours, inserted at the front of the pattern. The
-    pattern is proven the snapshot read by the store expression itself: the
-    call's *only* argument is the very expression the setter was read off, one
-    answer or none (`js.only`). Sole argument is deliberate — a second is a
-    selector whose result is no longer the snapshot, and extending a pattern of
-    unknowable provenance binds `undefined` with every count green. The
-    insertion also pays for a witness the way `thinking-summaries` does: the
-    field it binds must still be named by the bundle's own objects (the store's
-    snapshot initialiser, its publish call), so a store that renames the field
-    reads as the step reporting the store rather than threading `undefined`.
-    Two things come free with the store: its setter takes functional updaters —
-    React's own contract, which the reducer splices already speak — and it
-    hides a finished block itself after 30 s, upstream's own linger.
+  - **The state has two homes, and each is proven by the only name it has.**
+    Through 2.1.235 the scope that hands `onStreamingThinking` declared the
+    state itself, and the state is the array pattern binding the handed setter
+    — `useState`'s pair, which nothing else names. 2.1.236 moved it into an
+    external stream store (`subscribe`/`getSnapshot`/`_publish` — the
+    `useSyncExternalStore` shape) that a component reads back by destructuring
+    a hook call (`{streamingToolUses:…}=useX(<store>)`), so the state is that
+    pattern's own `streamingThinking` binding — upstream's the day it takes
+    one, the goal achieved, and until then ours, inserted at the front of the
+    pattern. The pattern names *itself*: it binds the store's own
+    `streamingToolUses` field — the name the store publishes and the
+    transcript signature already rests on — and that membership is its whole
+    identity, provided its value is a call taking exactly one argument, one
+    answer or none (`js.only`). It was once proven by the handing instead —
+    "the call's only argument is the very expression the setter was read off"
+    — and 2.1.246 moved the handing into the engine
+    (`this.stream.setStreamingThinking`), out of every component, without
+    moving the state: four renders that plainly draw the conversation read as
+    having none in scope, with `onStreamingThinking:` still twice in the
+    bundle. The handed setter was `agentDefinitions` again — a neighbour
+    standing in for the thing itself, one more fact upstream had to keep.
+    Sole argument stays deliberate — a second is a selector whose result is
+    no longer the snapshot, and extending a pattern of unknowable provenance
+    binds `undefined` with every count green. The insertion also pays for a
+    witness the way `thinking-summaries` does: the field it binds must still
+    be named by the bundle's own objects (the store's snapshot initialiser,
+    its publish call), so a store that renames the field reads as the step
+    reporting the store rather than threading `undefined`. Two things come
+    free with the store: its setter takes functional updaters — React's own
+    contract, which the reducer splices already speak — and it hides a
+    finished block itself after 30 s, upstream's own linger.
 
   A render was once selected by *position* — the observation that the real sites
   fall after the state's `useState` declaration. That is worth recording as a
@@ -922,7 +951,19 @@ for you. Each entry: what it changes, the stable anchor, and where it lives.
   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.
+  property beside `content` read as the whole thing being gone. The wrapped
+  block is asked by membership among the element's *possible values*
+  (`js.values` — the same value routing the codex resolvers read), never asked
+  to be the read: 2.1.246 minted stable ids for streamed blocks
+  (`ce?{...S.contentBlock,id:V}:S.contentBlock`), and the exact-node question
+  read the same wrap one choice deeper as no wrap at all — nine required steps
+  to zero, every anchor count standing. The rewrite reuses upstream's callback
+  and dependencies verbatim — the callback invoked per entry with the same
+  three arguments `flatMap` hands it, each dependency spread rather than
+  transcribed — because a rebuilt copy is a copy free to shed whatever
+  upstream adds next: the re-spell this replaced would have silently dropped
+  the 2.1.246 minting, and with it went the uuid-stamp identity that re-spell
+  had to prove and the reuse no longer asks.
 
   **`display-mode`** defaults the request's thinking display to `"summarized"`;
   without it the API only streams summary text when the `showThinkingSummaries`
@@ -1313,6 +1354,24 @@ for you. Each entry: what it changes, the stable anchor, and where it lives.
   touched: the `/status` Organization/Email rows, the login screen, and the
   org's startup message (`"Message from <org>:"`) still show the real account.
 
+  **2.1.246 retired the surface.** Upstream deleted the welcome-banner variant
+  that composed the segment; the surviving banner draws `model · billing` with
+  no org anywhere — the hidden state an empty `--org-label` asks for, now
+  upstream's own default. That is a semantic change, not a matcher to repair
+  (the `help-title` precedent), and it is *absence*, reported apart from broken
+  (CONDUCT): the patch declares its surface (`Patch.absence`, answered by the
+  same `_org_segments` its candidates count off, so the two cannot disagree),
+  and every surface derives its answer from the bundle in hand — the menu shows
+  the row dimmed (`not on this build`, unselectable), an explicit `--org-label`
+  is refused at the front door with the same sentence, a cached replay skips it
+  with a note, and `doctor` prints a `-` row apart from ✓/✗ and stays green.
+  Nothing is keyed on a version, so a build that composes the segment again
+  un-dims the row with no code change. What absence cannot tell apart is a
+  composition respelled out of the locator's sight — that build would read as
+  absent, visibly dimmed on a screen that still draws the segment — and the
+  sweep over the corpus, where thirty-four builds carry the surface, is what
+  keeps the locator honest.
+
 ## Removed patches
 
 Kept here so nobody reintroduces them without knowing why they left:

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

@@ -21,10 +21,11 @@ matches means the file changed under you, not that a number moved.
 
 ## On disk now
 
-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
+The whole published span `2.1.210` → `2.1.246` — 2.1.230 and 2.1.244 were never
+published — one pristine binary per version, 35 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:
@@ -64,10 +65,12 @@ the whole file, `sha256sum <version>.orig`) and never the size:
 | `2.1.241` | 343 MB | `0771bd866cff82b76581fc0499f6529e1a36845078f144f8c81dccb3bc7037b8` |
 | `2.1.242` | 378 MB | `528ef039aa7d64d7b3fbc06925132755a516b4dcaad784cf0b51fe03167360d4` |
 | `2.1.243` | 378 MB | `4b0dafeedd0b469c41988e200036fd773e7553ba960349c9f02a82c6d1f2ba27` |
+| `2.1.245` | 392 MB | `16ad2b94deaf7b29abed966d981c9991a47af0420f5be8ed4a3f83bea9f678bc` |
+| `2.1.246` | 248 MB | `1a0a662dc1bb938eaec38545abce9a4a69113d7d7f7c5e1a553ea276617b906a` |
 
 This set covers the span the playbook's tree-move measurements were taken over
-(`2.1.210` → `2.1.233`) and the 2.1.242 split, so both are re-checkable here
-rather than historical.
+(`2.1.210` → `2.1.233`), the 2.1.242 split, and the 2.1.246 stream-store
+migration, so each is re-checkable here rather than historical.
 
 ## Rebuild or extend it
 
@@ -93,5 +96,11 @@ done; }
 sweep
 ```
 
-`doctor` is read-only — it runs the matchers and parses their output, and never
-writes a binary — so the sweep is safe to run against every backup at any time.
+`doctor` never writes to the backup it reads — it runs the matchers, parses
+their output, then bakes the composed result into a *temp* binary and executes
+`<binary> --version` (the smoke run, [PLAYBOOK.md](PLAYBOOK.md#how-resilience-is-detected)),
+removing the temp afterwards — so the sweep is safe to run against every backup
+at any time, and proves each build bakes and boots, not just that it matches.
+Each bake transiently writes a binary-sized temp file (a few hundred MB) to the
+system temp dir — RAM, where that is tmpfs — one at a time; `TMPDIR` steers it
+elsewhere.

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

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