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

patch_cc-0.4.0/.github/workflows/release-watch.yml

@@ -0,0 +1,164 @@
+name: Release watch
+
+# Fires the "patch-cc release watch" cloud routine the moment Anthropic ships a
+# new Claude Code build, instead of leaving it to the routine's own daily cron.
+#
+# The routine already knows how to decide whether anything moved -- it compares
+# the upstream version and the checkout HEAD against the ledger in issue #1 and
+# exits silently when neither did. Its schedule was never the interesting part;
+# it was just a poll, once a day, which meant a release that broke a patch could
+# sit unnoticed for up to 24 hours. This workflow moves the poll here, where a
+# tick is one curl instead of a cloud session, and only wakes the routine when
+# the version actually changes.
+#
+# The routine keeps its daily schedule as a backstop: if this workflow breaks or
+# GitHub skips the schedule, the watch degrades to its old once-a-day behaviour
+# rather than going silent. That is why a failed poll below is a warning and not
+# a red run -- a flaky fetch must not page anyone.
+#
+# SETUP (one time, by hand -- there is no API for token creation):
+#   claude.ai/code/routines -> "patch-cc release watch" -> pencil icon
+#   -> Add another trigger -> API -> Generate token (shown once)
+#   -> store it as the repo secret ROUTINE_FIRE_TOKEN.
+
+on:
+  schedule:
+    # Every 10 minutes. GitHub delays scheduled runs under load, so read this as
+    # "within ~10-25 min of a release", not as a guarantee.
+    - cron: "*/10 * * * *"
+  workflow_dispatch:
+
+concurrency:
+  group: release-watch
+  cancel-in-progress: false
+
+permissions:
+  contents: read
+  issues: read
+
+env:
+  # The channel file the Claude Code installer itself reads -- the same source
+  # the routine treats as authoritative, so the two never disagree about what
+  # "the current release" means.
+  CHANNEL_URL: https://storage.googleapis.com/claude-code-dist-86c565f3-f756-42ad-8dfa-d59b1c096819/claude-code-releases/latest
+  # Not a secret: firing needs the bearer token, and that is one.
+  ROUTINE_ID: trig_01WrgxdCZahJEHD3NNYcetqS
+  LEDGER_ISSUE: "1"
+
+jobs:
+  watch:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Read the release channel
+        id: upstream
+        run: |
+          set -uo pipefail
+          if ! v=$(curl -fsSL --max-time 30 --retry 3 --retry-delay 5 "$CHANNEL_URL"); then
+            echo "::warning::could not reach the release channel; skipping this tick"
+            echo "skip=1" >> "$GITHUB_OUTPUT"
+            exit 0
+          fi
+          v=$(printf '%s' "$v" | tr -d '[:space:]')
+          case "$v" in
+            [0-9]*.[0-9]*.[0-9]*) ;;
+            *)
+              echo "::warning::channel returned something that is not a version: '$v'"
+              echo "skip=1" >> "$GITHUB_OUTPUT"
+              exit 0
+              ;;
+          esac
+          echo "version=$v" >> "$GITHUB_OUTPUT"
+          echo "upstream: $v"
+
+      # First guard: did an earlier tick already fire for this version? The
+      # routine takes several minutes to run (it downloads a ~275 MB bundle), so
+      # without this every tick during that window would fire it again.
+      - name: Already fired for this version?
+        id: marker
+        if: steps.upstream.outputs.skip != '1'
+        uses: actions/cache/restore@v4
+        with:
+          path: .fired
+          key: fired-${{ steps.upstream.outputs.version }}
+          lookup-only: true
+
+      # Second guard, and the authoritative one: the ledger records the version
+      # the routine has actually finished processing. This is what catches the
+      # case where the cache entry was evicted but the work is long done.
+      - name: Read the ledger's last-version
+        id: ledger
+        if: steps.upstream.outputs.skip != '1' && steps.marker.outputs.cache-hit != 'true'
+        env:
+          GH_TOKEN: ${{ github.token }}
+        run: |
+          set -uo pipefail
+          if ! body=$(gh issue view "$LEDGER_ISSUE" --repo "$GITHUB_REPOSITORY" --json body -q .body); then
+            echo "::warning::could not read the ledger; skipping this tick rather than guessing"
+            echo "skip=1" >> "$GITHUB_OUTPUT"
+            exit 0
+          fi
+          last=$(printf '%s\n' "$body" | sed -n 's/^last-version:[[:space:]]*//p' | head -1 | tr -d '[:space:]')
+          echo "last=$last" >> "$GITHUB_OUTPUT"
+          echo "ledger: $last"
+
+      - name: Fire the routine
+        id: fire
+        if: >-
+          steps.upstream.outputs.skip != '1' &&
+          steps.marker.outputs.cache-hit != 'true' &&
+          steps.ledger.outputs.skip != '1' &&
+          steps.ledger.outputs.last != steps.upstream.outputs.version
+        env:
+          TOKEN: ${{ secrets.ROUTINE_FIRE_TOKEN }}
+          VERSION: ${{ steps.upstream.outputs.version }}
+          LAST: ${{ steps.ledger.outputs.last }}
+        run: |
+          set -uo pipefail
+          if [ -z "${TOKEN:-}" ]; then
+            echo "::error::ROUTINE_FIRE_TOKEN is not set -- see the setup note at the top of this file"
+            exit 1
+          fi
+          body=$(printf 'Claude Code %s is on the release channel; the ledger last recorded %s. This line is a hint for the run log only -- re-derive the version yourself from the channel, per your step 2.' "$VERSION" "${LAST:-(none)}")
+          payload=$(jq -nc --arg t "$body" '{text: $t}')
+          out=$(mktemp)
+          code=$(curl -sS -o "$out" -w '%{http_code}' -X POST \
+            "https://api.anthropic.com/v1/claude_code/routines/$ROUTINE_ID/fire" \
+            -H "Authorization: Bearer $TOKEN" \
+            -H "anthropic-version: 2023-06-01" \
+            -H "anthropic-beta: experimental-cc-routine-2026-04-01" \
+            -H "Content-Type: application/json" \
+            -d "$payload") || code=000
+          echo "HTTP $code"
+          cat "$out"
+          echo
+          if [ "$code" != "200" ]; then
+            # Deliberately not marking the version as fired, so the next tick
+            # retries. A 429 here just means the daily run cap was reached.
+            echo "::error::fire failed with HTTP $code"
+            exit 1
+          fi
+          echo "url=$(jq -r '.claude_code_session_url // empty' "$out")" >> "$GITHUB_OUTPUT"
+          : > .fired
+
+      # Only reached on a 200, so the marker never claims a fire that failed.
+      - name: Mark this version as fired
+        if: steps.fire.outcome == 'success'
+        uses: actions/cache/save@v4
+        with:
+          path: .fired
+          key: fired-${{ steps.upstream.outputs.version }}
+
+      - name: Summary
+        if: always()
+        run: |
+          {
+            echo "### Release watch"
+            echo
+            echo "- upstream: \`${{ steps.upstream.outputs.version || 'unreadable' }}\`"
+            echo "- ledger last-version: \`${{ steps.ledger.outputs.last || 'not read' }}\`"
+            if [ -n "${{ steps.fire.outputs.url }}" ]; then
+              echo "- **fired the routine** -> ${{ steps.fire.outputs.url }}"
+            else
+              echo "- no fire (nothing moved, or already fired for this version)"
+            fi
+          } >> "$GITHUB_STEP_SUMMARY"

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

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: patch-cc
-Version: 0.3.2
+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.2 → 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.2 → 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.2 → 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
@@ -455,7 +507,11 @@ Each sub-step records its own `candidates`/`applied`:
   reducer whose setter threading applied while every arm had drifted once
   reported hits and streamed nothing.
 - **`final-summary`**, optional: redacted thinking in the closing summary is a
-  refinement, not the feature.
+  refinement, not the feature. Its guard is whichever enclosing `if` *tests the
+  block* — 2.1.236 nested an experiment gate between the test and the summary
+  it guards, and "the nearest `if`" read a shape that had merely moved as one
+  that was gone. The climb is bounded by the function that declares the block,
+  because a receiver's name is only a spelling until its scope is said.
 
 An *optional* sub-step that finds nothing is reported as absent, not broken —
 it is just a shape this build doesn't have. A sub-step that finds a shape but
@@ -489,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.
 
@@ -788,6 +848,28 @@ 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.
 
   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
@@ -830,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`
@@ -1245,10 +1333,10 @@ enumerated with their hashes in [corpus.md](corpus.md). Each removed matcher hit
 can still be running; each was carried as "kept for older builds", which is a
 claim the corpus disproves. The verbatim matchers were re-run from `HEAD` over
 the whole corpus after the move, and they are still zero everywhere. The
-measurements this section quotes were taken during the move across a wider span
-(2.1.210 → 2.1.233; 2.1.230 was never published), some of whose early builds
-predate the current backup set — `corpus.md` is the reproducible subset on disk
-now, and re-running `doctor` over it is one command (below).
+measurements this section quotes were taken during the move across
+2.1.210 → 2.1.233 (2.1.230 was never published) — a span the corpus has since
+grown to hold in full, so they are re-checkable rather than historical, and
+re-running `doctor` over it is one command (below).
 
 - **`live-thinking` / `reducer-legacy`** — the pre-2.1.138 reducer with
   positional parameters. Its removal collapsed the `reducer` variant *group*