diff --git a/docs/book-plans/handwired-labs/README.md b/docs/book-plans/handwired-labs/README.md
new file mode 100644
index 00000000..568ba7d9
--- /dev/null
+++ b/docs/book-plans/handwired-labs/README.md
@@ -0,0 +1,40 @@
+# Handwired Labs — book plan
+
+Status: **plan only, paused 2026-10-20.** No scenes, narration, cover, sources file or blog are built yet.
+The caption fact-check is done (`review.md`); building is paused while the Handwired screencast workshop is made.
+
+The first book in a planned Handwired series. It explains each of the 15 experiments in
+`lab/` of [chenglou/handwired](https://github.com/chenglou/handwired) at commit
+`4ea7fcb27ebe93acf49b9f29a93e162b975bad46`. The `lab/types/` helper is not a lab and is
+mentioned only in passing.
+
+## Contents
+
+- `plan.md` — the plan for the whole book: five chapters covering all 15 labs, each with a
+  visual metaphor, a beat sheet and caption lines that cite `lab/<name>/<file>:<lines>`.
+  Also includes a "claims cut" list.
+- `digests/` — one working digest per lab, plus `framing.md` (overall question, per-lab status,
+  the 2026-09-03 reassessment). Written from the repo at the pinned commit.
+- `planning-assignment.md` — the exact brief given to the planner, so the plan can be re-run.
+- `review.md` — Claude Haiku 5.5 fact-check of all 61 captions against the pinned clone (50 OK, 11 FIX with
+  corrected wording and verbatim quotes). Apply its FIX rows before authoring scenes.
+
+## How the plan was made
+
+- Planning: `claude-sonnet-5-5`, run once through the Claude Code CLI. The result records that
+  model as the only one used.
+- Digests: written by Claude subagents from the cloned repo. They are working notes, not
+  reviewed research. Check any claim against its `Sources` pointers before narrating it.
+- Routing: the book follows the all-Claude routing requested for this book (Sonnet plans,
+  Haiku research and review, Opus for visuals). **Repo config still says Astra for planning**
+  (`generator/authoring-models.json`); that is not yet updated.
+
+## To pick this up
+
+1. ~~Haiku 5.5 review pass on `plan.md`~~ done: apply the FIX rows in `review.md` to the captions.
+2. Opus 5.5 authors one scene per chapter, `apps/bookshelf/src/viz/books/handwired-labs/chapter-<n>.tsx`,
+   following the `viz-scene` skill.
+3. Narrate each chapter with ElevenLabs; cover is title-only unless OpenAI image credits are available.
+4. `npm run book:sources`, the companion blog, `verify-book.mjs`, and the self-graded rubric
+   in `docs/book-quality.md`.
+5. Only after that, plan the rest of the Handwired series.
diff --git a/docs/book-plans/handwired-labs/digests/candidate-gallery.md b/docs/book-plans/handwired-labs/digests/candidate-gallery.md
new file mode 100644
index 00000000..eff30aa7
--- /dev/null
+++ b/docs/book-plans/handwired-labs/digests/candidate-gallery.md
@@ -0,0 +1,20 @@
+# candidate-gallery
+
+**Question:** Can one numeric program build three complete photo layouts at once, score each against the current viewport, and show only the winner, with clicks and focus handled inside the same circuit?
+
+**Mechanism:** `lab/candidate-gallery/candidate-gallery.ts` `createCandidateGalleryCircuit` builds all three layouts for 12 photos every evaluation: Cinema (hero plus a 2-column thumbnail rail), Contact (4x3 contact sheet, no hero) and Story (hero above 3-column thumbnails). Each size is multiplied by a "quality scale" (the reciprocal of a target size, e.g. `1 / 240` for a contact cell, set in `createCandidateGalleryMachine`) and clamped to 1 by `clampQuality`; a layout's score is the `bottleneck`, i.e. the minimum of its clamped qualities, built with `emitMinimum`. `emitArgmax(circuit, scores, unit)` returns a one-hot `winner.selected`; `selectValue` multiplies each candidate's geometry by its bit and sums, so every thumbnail and hero rectangle reads the winning layout. A click goes through `emitRectangleHit` per thumbnail and `emitFirstActive`, and the focused photo is 12 one-hot source cells (`focusField`) that are written back as `nextSource`.
+
+**Result:** Tests pin the choices: a 1400x680 stage picks Cinema, 984x730 picks Contact, 610x830 picks Story (`candidate-gallery.test.ts:31-41`). The circuit has exactly 14 boolean atoms as its rounding points (`comparison.test.ts:12`), and 26 layout selection reads lower to gather reads in one one-hot group (`gather-lowering.test.ts:54-69`). lab/status.md adds that sparse weights drop "from 940 to 848" with gather lowering.
+
+**Status:** Working demo, moved off the main line: it "moved here from the repo root on September 17, 2026 ... since the repo centers on HandwiredOS." The page is titled "Dynamic UI". runtime-cost uses it as a benchmark subject. No open/abandoned verdict beyond that.
+
+**Visual idea:** A browser frame being dragged narrower; beside it three miniature layouts (Cinema, Contact, Story) always drawn, each with a bar made of its quality gauges where the shortest gauge sets the score. As width shrinks, the bars cross, the argmax's one-hot bit jumps from Cinema to Contact to Story, and the 12 thumbnails fly from their slots in the old layout to the new one.
+
+**Sources:**
+- lab/candidate-gallery/README.md:1-9
+- lab/candidate-gallery/candidate-gallery.ts:1-160, 300-452
+- lab/candidate-gallery/candidate-gallery.test.ts:31-100 (test names and expectations)
+- lab/candidate-gallery/comparison.test.ts:1-15
+- lab/candidate-gallery/gather-lowering.test.ts:54-69
+- lab/status.md:228
+- commit 4ea7fcb27ebe93acf49b9f29a93e162b975bad46
diff --git a/docs/book-plans/handwired-labs/digests/cascade-argmax.md b/docs/book-plans/handwired-labs/digests/cascade-argmax.md
new file mode 100644
index 00000000..64c448ba
--- /dev/null
+++ b/docs/book-plans/handwired-labs/digests/cascade-argmax.md
@@ -0,0 +1,19 @@
+# cascade-argmax
+
+**Question:** Can argmax be made exact for every pair of distinct FP32 scores using only ReLU, power-of-two scaling and clamping, and can such a selector still be trained?
+
+**Mechanism:** `lab/cascade-argmax/cascade-argmax.ts` `emitCascadeGreaterBit` computes `relu(right - left)` and then seven stages of "multiply by 2^23, then clamp to [0, 1]" (`emitClampZeroOne`, i.e. `v - relu(v - 1)`). The total gain 2^161 pushes even the smallest positive FP32 difference (2^-149) to exactly 1, while a tie stays exactly 0, so the bit is exact and left wins ties. Each stage goes through `circuit.roundAffine` (`frozenStep`) so the simplifier cannot merge the stages. `emitCascadeArgmax` arranges these bits in a pairwise tree, carries the winner's score up with a two-product select, and `routeCascade` turns the tree into a one-hot. For training, `softCascadeOptions` shrinks the gain so each clamp becomes a ramp centered on a tie; `lab/cascade-argmax/training.ts` `trainSelection` fits a 16-case x 8-candidate score table through the soft ramps, anneals the gain (2^3 up to 2^21), then checks the hard circuit's winners.
+
+**Result:** From the README and `report.ts`: seven-stage soft cascade, seeds 1-10, 160/160 correct hard winners; single clipped ramp, seeds 101-110, 160/160, with "less than half as many operations" in the soft tree. Exact cascade cost vs production `emitArgmax`: 8 candidates is 196 vs 56 operations and 75 vs 15 layers; 64 candidates is 1,764 vs 504 operations and 150 vs 33 layers.
+
+**Status:** Construction works, but the learning claim is narrow: "This is fitting a 128-cell table. There is no learned shared query/key function". The README says "The hard cascade does not provide useful score gradients", and status.md says "Hard score gradients still provide no useful learning signal." Superseded for cost: since September 14, 2026 core `emitCompare` builds an 8-candidate exact tree in 150 operations and 57 layers, or 52 in 18 on a 1/64 grid.
+
+**Visual idea:** Two score bars almost the same height feed a tiny difference into a vertical pipe of seven magnifier stages. At each stage the sliver is doubled 23 times and hits a ceiling at 1. A difference of 2^-149 climbs to a full "1" by the top, while an exact tie stays a flat 0. Then shrink the magnifiers and the step softens into a ramp that gradients can slide along.
+
+**Sources:**
+- lab/cascade-argmax/README.md:1-37
+- lab/cascade-argmax/cascade-argmax.ts:1-152, 186-245 (helpers outline)
+- lab/cascade-argmax/training.ts:34-130
+- lab/cascade-argmax/report.ts:23-71
+- lab/status.md:202; lab/reassessment-2026-09-03.md:120,126
+- commit 4ea7fcb27ebe93acf49b9f29a93e162b975bad46
diff --git a/docs/book-plans/handwired-labs/digests/data-adapter.md b/docs/book-plans/handwired-labs/digests/data-adapter.md
new file mode 100644
index 00000000..e61b7756
--- /dev/null
+++ b/docs/book-plans/handwired-labs/digests/data-adapter.md
@@ -0,0 +1,17 @@
+# data-adapter
+
+**Question:** Given a few examples of rectangle rows and desired answers, can an exhaustive search over a tiny vocabulary of exact circuit programs recover reusable lookups (find a row by ID, read a field, do arithmetic) that keep working on new data?
+
+**Mechanism:** `lab/data-adapter/experiment.ts`. One circuit has `CAPACITY = 12` storage slots, each holding an active bit, an integer ID, and left/top/width/height. `enumeratePrograms` lists every program: a predicate subset (active, same-id, first-slot; zero to two), one field read, and zero to two steps (add width, add height, subtract origin X/Y, multiply by scale), giving `7 * 4 * (1 + 5 + 25) = 868`. `compileLookup` turns predicates into one bit per slot; same-id is `ReLU(1 - abs(id - selectedID))`, exact for integers. A read sums field times bit, and `found` counts matches clamped to 1. `buildAdapter` adds the steps with `roundAffine`/`multiply`. `synthesize` runs each candidate through the real `Circuit` on the training scenes and drops it at the first example that rules out every task. The targets come from `oracle`, a separate plain-JS `find`. `repeatedLookup` then pulls out the shared predicate prefix as one reusable `selectedField(field)`.
+
+**Result:** "12 training scenes identify one program for each of eight tasks from 868 candidates", and all eight "agree exactly with an independent JavaScript lookup on 438 held-out scenes". The common lookup recovered is "active AND same ID". Search evaluates 997 candidate/scene pairs in about 60 ms. Verification is 14,016 scalar comparisons. Joint circuits are 200 constructed operations, versus 1,118 for eight separate circuits (README:5, 46, 62-70).
+
+**Status:** Succeeded within its scope, but it is not learning: "Nothing trains neural weights here." The extraction rule "is authored, not a learned neural abstraction". status.md lists it as "No neural training ... Capacity is 12." It is meant as the baseline for the next experiment (decision 8: retrieving a rectangle by ID with soft attention), which is still open.
+
+**Visual idea:** A table of 12 slots, shuffled. A grid of 868 candidate program cards streams past the table. Each card lights rows with its predicate bits, reads a column, applies steps, and is struck out the moment a training scene disagrees. Eight cards survive, all sharing the same "active AND same ID" stamp, which then lifts off and becomes one shared function box.
+
+**Sources:**
+- lab/data-adapter/README.md:1-91
+- lab/data-adapter/experiment.ts:1-20, 81-227
+- lab/status.md:187, 199, 244
+- commit 4ea7fcb27ebe93acf49b9f29a93e162b975bad46
diff --git a/docs/book-plans/handwired-labs/digests/event-window.md b/docs/book-plans/handwired-labs/digests/event-window.md
new file mode 100644
index 00000000..4ec909de
--- /dev/null
+++ b/docs/book-plans/handwired-labs/digests/event-window.md
@@ -0,0 +1,19 @@
+# event-window
+
+**Question:** Can multi-frame window behavior (drag with pointer ownership, focus, click-versus-drag, a maximize toggle) be a pure feedforward function of the current input plus a small bank of latched events, trained without backpropagation through time and hardened to bit-exact agreement with plain TypeScript?
+
+**Mechanism:** `oracle.ts` (`oracleTick`) is the plain-TS ground truth: four rectangles in a 1280x800 viewport, a 4 px slop, a 30 px title bar, and a 2x2 relation table (title = drag, body = click-toggle). `circuit.ts` (`buildEventWindowCircuit`) compiles the same behavior into 502 ops, depth 38, 6 boolean atoms. State is a "latch bank": a live press record written only on pointer-down, a drag-begin latch written when a move crosses slop, and stored state (positions, maximized, focus) written only on events. Every threshold is one form, `bit(clamp01((boundary - measure) x sharpness + 0.5))`, rounded in exact mode, a ramp in soft mode. `train.ts` (`harvestTrainingPairs`, `trainBehaviorParameters`) trains six cells (slop boundary, title boundary, four relation cells) with Adam on single-frame pairs supervising 21 decision bits, annealing sharpness 1/32 -> 0.25 -> 1 -> 4. `hardenParameterValues` rounds relations; `verifyHardenedParameters` runs closed loop against the oracle (`harness.ts` `runClosedLoop`).
+
+**Result:** Closed loop: 0 divergences over 120,000 frames (12 seeds x 10,000), all 16 relation-table settings, 200 sequential drags (README table, `exactness.test.ts`). Training sweep: "20/20 seeds recovered", every slop in (4, 5] and title in [29, 30), 0/30000 divergences each (`training-sweep.ts`). Fixed-ramp training fails: from the true values it drifts to ~30.01 / ~3.97 and diverges 9,120 times in 10,000 frames. `boundary-probe.test.ts` proves no window of K raw inputs (K up to 256) suffices; a latched aggregate does. Cost grows +36 ops per extra press record, depth constant (`measure-cost.ts`).
+
+**Status:** Succeeded within limits. lab/status.md: training "supplies correct internal state and decision labels. Persistent state and temporal dependencies remain." README: "Training recovers parameter cells, not structure." Next steps (double-click from archive record 1) are open.
+
+**Visual idea:** A title-boundary line sliding along a window's y axis while a translucent sigmoid band around it narrows in four snaps (32 px, 4 px, 1 px, a quarter pixel); red/green dots for title/body presses straddle it, and the line settles inside the [29, 30) band, next to a second run where the band stays fixed and the line drifts out to 30.01.
+
+**Sources:**
+- lab/event-window/README.md:1-197
+- lab/event-window/circuit.ts:136-230
+- lab/event-window/train.ts:130-175
+- lab/event-window (function list via grep: oracle.ts:101-294, harness.ts:21-112, train.ts:56-315)
+- lab/status.md:200, 289
+- commit 4ea7fcb
diff --git a/docs/book-plans/handwired-labs/digests/framing.md b/docs/book-plans/handwired-labs/digests/framing.md
new file mode 100644
index 00000000..3e51adb5
--- /dev/null
+++ b/docs/book-plans/handwired-labs/digests/framing.md
@@ -0,0 +1,52 @@
+# Framing digest: lab/ status documents (chenglou/handwired @ 4ea7fcb)
+
+## What the labs are for
+
+The labs test UI behavior as a fixed FP32 numeric circuit (weighted sums, ReGLU gates, boolean atoms). The reassessment names the question: "what making small pieces of behavior editable and learnable enables". Its bottom line: "Keep the smaller numeric representation and the ambition to learn useful computation." The labs are learning experiments plus runtime studies, and since September some also time ordinary JS tasks on CPU and WebGPU.
+
+## Per-lab status table
+
+| Lab | Status as stated in these docs | Key quote (short, exact) | Date of last update if given |
+| --- | --- | --- | --- |
+| learned-interpreter | Hard-loss optimizer corrected via loss scale | "coordinate 60/60; two adds 59/60 on integers, 15/60 with fractional FP32 checks" | Reassessment Sept 3, 2026 |
+| reusable-layout | Built (reassessment's main proposal); transfers to new counts/widths | "learned responsive sizing within a fixed flow layout, not generation of arbitrary page structures" | not given |
+| user-effort | Built; simulator-only | "No human observations, error prediction, or usability claim." | not given |
+| data-adapter | Built; exact search baseline | "No neural training." | not given |
+| event-window | July round one; compression bug fixed | "Training supplies correct internal state and decision labels." | July 2026 (round one) |
+| generative-fields | July round one; claims weakened | "valid samples do not establish a smooth valid interpolation" | July 2026 (round one) |
+| cascade-argmax | Soft training then hardening | "This fits a table, not a shared query/key rule." | not given |
+| trace-compiler | Runtime study; oracle bugs fixed | "Its source interpreter is independently checked against native JavaScript" | not given |
+| runtime-cost | Runtime study, CPU only | "compare it with the evaluators that return full arrays, on the CPU" | not given |
+| hard-attend | Comparison page | "compares one-hot, direct and softmax gathers" | moved into lab/ Sept 16, 2026 |
+| candidate-gallery | Comparison page | "a balanced argmax picks one" | moved into lab/ Sept 17, 2026 |
+| learned-gallery | Promoted to src/; lab keeps only the measurements | "the network is fitted to one sketch at a time" | Oct 14, 2026 |
+| json-search | Measurements only; page and code moved to src/ | "Against JavaScript in 8 workers: still no." | Oct 14, 2026 |
+| knuth-plass | CPU + WebGPU timing study | "Uploading line costs computed in JavaScript never beats the typed-array loop." | Sept 17, 2026 |
+| ui-exploration | Historical record plus guide | "16 of the 24 prototypes remain" | Sept 12-14, 2026 (trimmed Sept 16) |
+| gather-lowering | Landed in core; tests moved to tests/runtime/ | "it does not discover query/key scoring" | Sept 17, 2026 |
+| regex-search, json-highlighter | Removed; lessons moved to docs/patterns.md | "Nothing beat a loop over 32-bit words" | Oct 14, 2026 |
+| exp-ste-backprop / exp-ste-reveal, exp-behavior-cells-relations | Superseded | "Made unnecessary by three independent routes" | July / Sept 16, 2026 |
+
+## Reassessment
+
+Two main findings. The learned interpreter's 0/20 failure came from loss scale, not architecture: multiplying losses by 1,000,000 gives 20/20, the same as shrinking Adam's epsilon. So "the old 0/20 result was not sufficient evidence to abandon them". And "some correctness checks compare implementations that share the same mistake".
+
+- **Kept:** the numeric representation, the learning ambition, the sign cascade "as an exact forward construction", and the gather optimization (about 1.29x speedup).
+- **Reframed:** generative-fields (1,408 of 4,154 repairs hid items), event-window (a demo bug, and recurrence remains), cascade-argmax (no learned query/key rule), gather-lowering ("neither learned query/key scoring"), trace-compiler (its oracle shared the compiler's bugs).
+- **Dropped:** no lab was dropped. It retired nine claims, including "A latch is attention with one slot" and "Compiling ordinary source is a dead end". It also retired the shared brief's "take these as given" framing.
+- **Proposed:** finish the numerical diagnosis, learn a reusable layout rule, separate predicting users from choosing for them, and build data adapters. These became reusable-layout, user-effort and data-adapter.
+
+## Open threads
+
+1. Do fractional training examples pin down how additions are grouped? Can the method scale without a complete loss table?
+2. Can a shared query/key rule be learned? Decision 8 recommends retrieving a rectangle by id with soft attention, then running it with argmax.
+3. Getting UI evidence from "an explicit human task, not from interpreting synthetic preference scores as usability".
+4. FP32 order sensitivity. `emitArgmax` picks depend on build order for scores 2 to 5 FP32 steps apart. Gradients depend on statement order.
+5. Depth and GPU. The recommendation is to measure one per-layer GPU pass first. HandwiredOS took 2.2 ms per evaluation on WebGPU against 81 µs on the CPU.
+
+## Sources
+
+- Overall question: lab/reassessment-2026-09-03.md:7, :186; lab/research-sweep.md:10
+- Status table: lab/status.md:196-204, :212, :220, :228, :230, :103, :120, :240, :237, :289-290; lab/research-sweep.md:27-35
+- Reassessment: lab/reassessment-2026-09-03.md:9, :25-38, :100, :105-107, :109-128, :130-175
+- Open threads: lab/status.md:40, :170-171, :185, :187, :244, :246
diff --git a/docs/book-plans/handwired-labs/digests/generative-fields.md b/docs/book-plans/handwired-labs/digests/generative-fields.md
new file mode 100644
index 00000000..d7641808
--- /dev/null
+++ b/docs/book-plans/handwired-labs/digests/generative-fields.md
@@ -0,0 +1,20 @@
+# generative-fields
+
+**Question:** Can one fixed 16-slot layout circuit produce grids, heroes, mosaics, lists and filmstrips purely from numbers in its source table, score its own validity, and be steered by search, gradient and interpolation?
+
+**Mechanism:** `fields.ts` defines a 72-dimension field vector: 8 global knobs (paddings, gaps, `baseSpan`, `spanFromImportance`, `baseHeight`, `heightFromImportance`) plus 4 per-slot fields (`importance`, `orderKey`, `visibility`, `heightPreference`) for 16 slots; `buildSource` writes it into the table. `flow-layout.ts` (`createFlowLayoutCircuit`) turns importance into a width span and height, ranks slots by pairwise order-key comparisons (`emitKeyOrderBit`), and places them by greedy line breaking, the same rule as CSS flow. It also computes overlap, containment and minimum-size checks, a `validBit` and a continuous `violationDepth`. `fitness.ts` (`scoreFitness`) is a seven-term Duplo-style score. `search.ts` (`runSearch`) samples seeded vectors; `optimize.ts` (`ascendFitness`) climbs fitness through `ste-backprop.ts`, which calls `backpropagateReference` with `booleanGradient: 'straight-through'`; `projectToValidity` descends `violationDepth` with Adam plus a proximal pull until `validBit === 1`; `interpolation.ts` (`walkPath`) walks straight lines between layouts and repairs invalid points.
+
+**Result:** Circuit: 8,385 operations (336 boolean), 147 layers. Five families run on one compiled program with zero recompilation. Search: 1,078 of 4,000 valid, best fitness 0.875. Gradient: 12/12 starts valid, best 0.922, but the best shows only 6 of 16 slots; without the richness term ascent collapsed to 0.998 with 2 visible slots. Interpolation: valid before projection 1,906/6,060 (31.5%), after 6,060/6,060, mean 1.9 repair steps; every invalid point was vertical overflow. All from README tables pinned in `generation.test.ts` and `interpolation.test.ts`.
+
+**Status:** Historical, with caveats. README September 2026 corrections: "Of the July study's 4,154 repairs, 1,408 hid previously visible items; one reduced sixteen visible items to six," and "The samples do not establish smooth motion." lab/status.md: "Historical repair could hide content, and valid samples do not establish a smooth valid interpolation." Next steps (a second flow region, learned fitness weights) are open.
+
+**Visual idea:** Hero migration: 16 boxes reflowing as t slides 0 to 1, slot 2 shrinking from 129,064 px² while slot 11 grows, the two meeting at 66,443 px² each at t = 0.5 in separate rows. Then a straight-line path where a red box overflows the viewport bottom and a projection nudge snaps it back inside, with a counter showing a slot quietly hidden.
+
+**Sources:**
+- lab/generative-fields/README.md:1-140
+- lab/generative-fields/ste-backprop.ts:1-10
+- lab/generative-fields/optimize.ts:212-250
+- lab/generative-fields/interpolation.ts:32-60
+- function lists (grep) of fields.ts, flow-layout.ts, fitness.ts, search.ts, content-audit.ts
+- lab/status.md:201
+- commit 4ea7fcb
diff --git a/docs/book-plans/handwired-labs/digests/hard-attend.md b/docs/book-plans/handwired-labs/digests/hard-attend.md
new file mode 100644
index 00000000..545bee13
--- /dev/null
+++ b/docs/book-plans/handwired-labs/digests/hard-attend.md
@@ -0,0 +1,18 @@
+# hard-attend
+
+**Question:** How do a one-hot gather, a direct index read and a softmax gather compare when a query picks one of three items through dot-product scores?
+
+**Mechanism:** `lab/hard-attend/hard-attend.ts` is plain browser JavaScript, "not a numeric program". There are three items (Aster=10, Banyan=20, Cobalt=30). `keyFor(j)` returns `(2j, -j²)` and the query is `(query, 1)`, so `scoreFor` gives `2·query·j − j²`. This parabola peaks at the item nearest the query. `winnerIndexFor` takes the first highest score (strict `>`, so ties stay left). `update()` computes three reads: the one-hot gather (bits times values, summed), the direct gather `values[winner]` (labelled `hardAttend` on the page), and `softmax(scores, beta)` times values. A query slider (0 to 2, step 0.01) and a "sharpness" beta slider (0.5 to 14) drive the page (`hard-attend.html:19-61`).
+
+**Result:** No measured result. It is a teaching page, and "The folder has no tests." The page shows that the one-hot gather and the direct gather give the same value, and that the softmax read moves toward that value as sharpness rises.
+
+**Status:** Historical. It "moved here from the repo root on September 16, 2026". The `hardAttend` operation was considered in the June 2026 plan, and status.md's parked entry "Revisit hardAttend" says its indexed-retrieval half is now covered by `circuit.indexRead` and gather lowering. Its scored-selection half is the open decision-8 experiment, with the caution "Compare alternatives without presuming that attention must emerge."
+
+**Visual idea:** Draw the three parabolas `2·q·j − j²` as one score curve per item over a horizontal query axis. A query marker slides left to right, and at each moment the tallest curve lights its item. Below, three output gauges move together: the one-hot and direct gauges jump in steps (10, 20, 30), and the softmax gauge glides between them. Turn the sharpness knob up and the glide stiffens into the same steps.
+
+**Sources:**
+- lab/hard-attend/README.md:1-7
+- lab/hard-attend/hard-attend.ts:1-80, 129-184
+- lab/hard-attend/hard-attend.html:11-61 (grep of labels and sliders)
+- lab/status.md:257
+- commit 4ea7fcb27ebe93acf49b9f29a93e162b975bad46
diff --git a/docs/book-plans/handwired-labs/digests/json-search.md b/docs/book-plans/handwired-labs/digests/json-search.md
new file mode 100644
index 00000000..682cfc9e
--- /dev/null
+++ b/docs/book-plans/handwired-labs/digests/json-search.md
@@ -0,0 +1,19 @@
+# lab/json-search digest
+
+**Question:** Is there a point where regex search, the JSON highlighter, or both in one app become "clearly more performant from the gpu parallelism" by running one program over 100,000 JSON documents at once?
+
+**Mechanism:** The code is in src/json-search. lab/json-search holds the measurement pages, the harnesses and the raw results. Each program is built as one step for a single position (`buildJsonLoop`, `buildSearchLoop`) and written into a WGSL `for` loop over 512 positions. Each GPU thread handles one document. The highlighter's display kinds stay on the GPU and feed the search. `compilePattern` turns a pattern into automaton cells, so one program per state capacity (8, 16, 32) serves every pattern. There were three stages: the highlighter written out position by position, then loop-emit.ts loops (one f32 statement per operation), then bit-emit.ts, which writes the same gated reads as ANDs of 32-bit words. gpu/combined-run.ts, writers-run.ts and review-run.ts drive headless Chrome, time `createGpuSearcher`, and check every readback against plain-JS references.
+
+**Result:** (README.md) For 100,000 documents, one search takes 4.6, 4.7 and 5.2 ms back to back at 8/16/32 states with bit-emit.ts, versus 7.8, 69 and 945 ms with loop-emit.ts ("1.7, 15 and 180 times less"). It takes 11 to 16 ms after a 200 ms pause. RegExp on one thread takes 8 to 43 ms, and 2.1 s on the backtracking `([a-z]+)+x`. The same programs on the CPU take "200 to 40,000 times as long". No GPU value differed from the CPU: about a billion compared per run.
+
+**Status:** The answer is mixed. Against RegExp on one thread the GPU is faster for most patterns, but "Against JavaScript in several workers: no." The highlighter is "clearly faster only as a repeated pass". The README says the demo is honest only if it doesn't "claim to beat RegExp on every pattern". A review "corrected the write-up where it claimed more than the measurements show." Still open: other GPUs and browsers, a million documents, and the pause slowdown ("The cause wasn't found"). The page moved to src/json-search on October 14, 2026 (lab/status.md:103).
+
+**Visual idea:** A 100,000-cell map with one cell per document. As a pattern is typed, every cell lights up at the same moment, with a GPU timer next to a RegExp bar. Then the 32-state pattern bar shrinks from 945 ms to 5.2 ms as rows of f32 statements fold into single 32-bit AND words.
+
+**Sources:**
+- lab/json-search/README.md:1-212, 247-271, 606-616, 775-814, 896-950
+- lab/json-search/report.ts:1-30
+- lab/json-search/gpu/combined-page.ts:12-22, 112-235 (imports and searcher calls)
+- src/json-search/search-step.ts and searcher.ts (export lines only)
+- lab/status.md:103, 107, 116
+- commit 4ea7fcb
diff --git a/docs/book-plans/handwired-labs/digests/knuth-plass.md b/docs/book-plans/handwired-labs/digests/knuth-plass.md
new file mode 100644
index 00000000..240456a1
--- /dev/null
+++ b/docs/book-plans/handwired-labs/digests/knuth-plass.md
@@ -0,0 +1,19 @@
+# lab/knuth-plass digest
+
+**Question:** Can Knuth-Plass optimal line breaking, a shortest path over break points, be written as exact min-plus matrix products combined in a tree, and does that make many paragraphs faster on the GPU than plain JavaScript?
+
+**Mechanism:** `knuthPlass()` in reference.ts is the plain DP: `cost[to]` = min over the last W starts of `cost[from] + lineCost(from, to)`, where `lineCost` is `min(slack, 63)²`, 0 for the last line (a variant of pretext's demo cost, which can't be computed exactly). `buildKnuthPlass(capacity, form)` in program.ts writes it as a circuit. Each line cost is one table read plus a ReLU overflow bit. Each minimum is `excess = relu(left - right)`, `value = left - excess`, in a tournament that keeps the reference's tie rule. The "chain" form takes one step per break point. The "tree" form makes each step a W x W min-plus matrix and combines them with Brent-Kung's prefix network (`minPlusProduct`, `statesByProductTree`). Pointers are followed by doubling. Every value is an integer under 2^24, so FP32 is exact. `gpuPlan()` in gpu/plan.ts and the shaders in gpu/kernels.ts run one WebGPU dispatch per tree level in u32, with a `full` kernel and a `dense-rows` kernel.
+
+**Result:** (README.md) At n = 1,024, W = 32 on the CPU: chain 277,068 live operations, 10,232 layers, 2,925 µs; tree 2,823,382 operations, 230 layers, 22,445 µs; JS reference 75 µs. Tree costs "1.7 to 7.7 times the chain's µs". At 364 px on the demo, total cost 13,550 greedy vs 10,058 optimal, both 41 lines. GPU: one paragraph takes 0.3 to 0.6 ms (round trip), losing to the reference; dense-rows with positions beats `knuthPlassTyped` 2.3 to 2.8x at the largest batches (e.g. 4.50 vs 10.4 ms, 1,000 paragraphs, W = 32). Crossover "from below 30 to about 190 paragraphs of 256 break points". GPU check: 0 mismatches in 24,823,200 values.
+
+**Status:** Answer to Cheng: "For many paragraphs, yes" and "For one paragraph, no." Also "a kernel over every entry isn't enough." Open: Sklansky's network, the demo's justified cost, a GPU mode for the page, mixed-length batches. Crossover counts "aren't a stable result" across Chrome sessions.
+
+**Visual idea:** A paragraph's break points as dots on a line; a W x W min-plus matrix tile drops onto each, then tiles pair up level by level in a Brent-Kung tree (the tree program has 230 layers) racing a chain that steps through one break point at a time (10,232 layers), ending with pointer arrows hopping back by doubling to light up the chosen breaks.
+
+**Sources:**
+- lab/knuth-plass/README.md:1-470 (all sections read)
+- lab/knuth-plass/program.ts:47-136
+- lab/knuth-plass/reference.ts:1-50
+- lab/knuth-plass/paragraph.ts:25-38, gpu/plan.ts:18-41, gpu/kernels.ts:21-207 (export signatures only)
+- lab/status.md:240
+- commit 4ea7fcb
diff --git a/docs/book-plans/handwired-labs/digests/learned-gallery.md b/docs/book-plans/handwired-labs/digests/learned-gallery.md
new file mode 100644
index 00000000..e9628f8e
--- /dev/null
+++ b/docs/book-plans/handwired-labs/digests/learned-gallery.md
@@ -0,0 +1,16 @@
+# learned-gallery
+
+**Question:** Can a tiny network whose weights are the program's source cells learn, live in the browser, to draw photos on the rectangles a visitor sketches, and also learn to line those photos up instead of having ordinary code snap them?
+
+**Mechanism:** This folder has one file, README.md, "the record of how the loss and the training loop of the learned gallery were chosen" on October 13 and 14, 2026; "this folder holds no code" (code is in src/learned-gallery; the measurement scripts are not in the repo). Per the README, fixed features of each of 20 slots go through two ReGLU layers of 6 units to left, top, width and height: 6,320 operations in 8 layers with 244 weights (lab/status.md says "up to 12 photos"). Adam trains until the photos match the sketch. The loss has two parts: a Huber distance from the sketch, and a misalignment penalty that charges every two same-kind photo edges for their gap, with a pull that fades to 0 at one "reach". Per-pair multipliers grow with any gap that stays open (the method of multipliers). `trainOrUndo` rolls back any frame whose steps raised the loss and halves the learning rate. A "Misalignment penalty" slider (off to 8%, default 4%) sets the let-go distance.
+
+**Result:** From README tables (penalty, October 14): presets Story, Cinema, Contact sheet stop after 679, 1,389 and 879 steps, lines within 0.01, 0.11 and 0.04 px. After small edits lines end 0.01 px apart (median), but other photos move 2.8 px. 96 sessions of 40 small edits: 1.1% end neither in line nor a reach apart. A photo "joins a line at half the distance at which it leaves one", so one sketch can end in two layouts.
+
+**Status:** Moved to production: "into src/learned-gallery on October 14, 2026". Tried and not kept: "Straightening the sketch before training" (Cheng: "the spirit of the gallery is to learn something") and plain penalty forms (78%, 47%, 21% of edits left between layouts versus 1.8% for the kept form). Open limit (lab/status.md): "No held-out test: the network is fitted to one sketch at a time."
+
+**Visual idea:** Drag one photo of a row of 4 down 12 px: it stays 9 px above its rectangle while its three neighbors sag 3 px to meet it; keep dragging past 24 px and the photo snaps free onto its rectangle as the neighbors spring back.
+
+**Sources:**
+- lab/learned-gallery/README.md:1-69 (the folder's only file)
+- lab/status.md:203, 289
+- commit 4ea7fcb
diff --git a/docs/book-plans/handwired-labs/digests/learned-interpreter.md b/docs/book-plans/handwired-labs/digests/learned-interpreter.md
new file mode 100644
index 00000000..f97dd7b8
--- /dev/null
+++ b/docs/book-plans/handwired-labs/digests/learned-interpreter.md
@@ -0,0 +1,19 @@
+# learned-interpreter
+
+**Question:** Can learning recover one reusable two-instruction program, rather than a separate answer for each input, inside a fixed tiny interpreter?
+
+**Mechanism:** `lab/learned-interpreter/program.ts` `createProgramLayout` gives instruction 0 a choice of 48 candidates (add/subtract/multiply times ordered pairs of `pointerX`, `panelLeft`, `scale`, `distractor`). Instruction 1 has 75 candidates, because it can also read instruction 0's result. That is 123 shared program cells in the source table. `buildProgram` evaluates every candidate (`emitCandidate`) and `emitInstruction` sums each one times its selector cell, a soft mixture that becomes a one-hot under `hardenProgram` (leftmost argmax). Targets are `fround((pointerX − panelLeft)·scale)` (coordinate) and `fround(fround(pointerX + panelLeft) + distractor)` (two adds). `lab/learned-interpreter/discrete-training.ts` `buildProgramLossMatrix` scores all 48x75 = 3,600 hard programs. `trainWithExpectedProgramLoss` runs Adam on `p0ᵀ L p1` through a temperature schedule of 2 down to 0.125, with `adamEpsilon` now 1e-14. `enumerateLossMatrix` and `coordinateDescentOnLossMatrix` serve as search baselines.
+
+**Result:** With the old epsilon 1e-8: 0 recoveries. Corrected: coordinate 60/60, all fractionally certified. Two adds: 59/60 on integers, but only 15/60 pass fractional FP32 checks, because integer data "cannot identify which grouping is required" (e.g. `1 + 2^-24 − 1`). Building the table costs 707,472 + 53,060,400 instruction evaluations. The older soft-output trainer: coordinate 11/20, two adds 0/20. Data is in `study-results.json` (keys: configurations, hardStudies[6], programs[43], certificationCases 39,605) (README:63-101).
+
+**Status:** Revised by the September reassessment: "An Adam epsilon that dominated small gradients caused most of the reported hard-loss failure." It still "evaluates every complete program before training", and "Neither establishes scalable program synthesis." The open question in status.md: "whether fractional training examples identify the required addition grouping."
+
+**Visual idea:** Two slot-machine reels, one with 48 instruction cards and one with 75, each card's height showing its probability. As the temperature cools, the probability mass piles onto one card per reel. Side panel: the same run with epsilon 1e-8 shows the reels frozen flat. A final "FP32 probe" with `pointerX=1, panelLeft=2^-24, distractor=-1` flags winners whose addition grouping gives 2^-24 instead of 0.
+
+**Sources:**
+- lab/learned-interpreter/README.md:1-116
+- lab/learned-interpreter/program.ts:12-153
+- lab/learned-interpreter/discrete-training.ts:18-60, 191-204, 503-530 (plus function outline)
+- lab/learned-interpreter/study-results.json (top-level keys only)
+- lab/status.md:196, 244; lab/reassessment-2026-09-03.md:9, 36, 42-43
+- commit 4ea7fcb27ebe93acf49b9f29a93e162b975bad46
diff --git a/docs/book-plans/handwired-labs/digests/reusable-layout.md b/docs/book-plans/handwired-labs/digests/reusable-layout.md
new file mode 100644
index 00000000..2b0f00fb
--- /dev/null
+++ b/docs/book-plans/handwired-labs/digests/reusable-layout.md
@@ -0,0 +1,19 @@
+# reusable-layout
+
+**Question:** Can one small shared network, trained once, predict each photo's preferred width from content and viewport features well enough to transfer to new collections, counts, widths and captions?
+
+**Mechanism:** `lab/reusable-layout/model.ts` `itemFeatures` gives each photo eight numbers: viewport width, aspect ratio, measured caption width, importance, item count, mean aspect, reading position and mean importance. `createRule` builds a 12-unit ReLU (`circuit.reglu`) hidden layer and one output (times 400 px) as a numeric circuit: 121 parameters held in source cells, 133 operations and 5 layers per item. One compiled evaluator runs once per item. Targets come from `lab/reusable-layout/layout.ts` `optimizeInstance`, a per-layout coordinate search: it starts at 224 px, scans `widthChoices` twice, then refines in 16/8/4/2/1 px steps against the authored `preferenceLoss` (image area proportional to importance, a penalty for captions over 3 lines, a small penalty for unused row width). `trainRule` fits the network by squared error with Adam. Ordinary JS `wrapLayout` then flows the rows, and `text.ts` `wrapCaption` breaks captions using Arial 14 widths from `font-metrics.json`.
+
+**Result:** Preference loss on held-out sets (lower is better): 224 px wrapping 0.3727 / 1.0530, per-layout search 0.0229 / 0.1987, shared rule 0.0259-0.0266 / 0.2854-0.3079 (short captions / long captions plus new crops, three seeds). Median CPU time is 1.8 µs for wrapping, 317 µs for search and 18.3 µs for the shared rule (short). Every method has zero missing items, overflow and overlap. `model.json` holds `{version, seed: 17, epochs: 160, parameters[121]}`, and `results.json` is a 3-element array, one per seed (17/41/73).
+
+**Status:** A partial success: the rule "transferred substantially better than ordinary wrapping ... and lost ground on the longer-caption/crop shift." "All three methods reflow abruptly." status.md: "Learns an authored preference objective, not human taste." The next step it names is a held-out long-caption split or better caption features.
+
+**Visual idea:** A row of photos re-flowing as a viewport handle drags from 360 to 1180 px. Each photo has a small dial (the network's width proposal) beside a "search" ghost outline it is chasing. On short captions the dial tracks the ghost closely. When long captions appear, visible gaps open between the dial and the ghost.
+
+**Sources:**
+- lab/reusable-layout/README.md:1-73
+- lab/reusable-layout/model.ts:1-68
+- lab/reusable-layout/layout.ts:1-123
+- lab/reusable-layout/model.json, results.json (shape and first entry only)
+- lab/status.md:197, 212
+- commit 4ea7fcb27ebe93acf49b9f29a93e162b975bad46
diff --git a/docs/book-plans/handwired-labs/digests/runtime-cost.md b/docs/book-plans/handwired-labs/digests/runtime-cost.md
new file mode 100644
index 00000000..8e8d45c3
--- /dev/null
+++ b/docs/book-plans/handwired-labs/digests/runtime-cost.md
@@ -0,0 +1,18 @@
+# runtime-cost
+
+**Question:** On the CPU, how much of a circuit's run time is allocation and output copying, and what does a layer cost apart from its operations?
+
+**Mechanism:** `lab/runtime-cost/report.ts` `runRuntimeStudy` times three circuits: a two-operation coordinate transform (with a direct scalar-JS baseline), the candidate gallery and HandwiredOS's window manager. `measure` compares `circuit.evaluateReference`, `circuit.evaluateTensor` (returns the full wire array) and the opt-in `circuit.createTensorEvaluator(roots)` (reuses buffers and returns only the requested outputs). It takes seven samples, rotates the method order, warms each method 200 times, and requires matching checksums. `lab/runtime-cost/layers.ts` builds the same 16,384 two-term sums (`roundAffine`) as chains of 64, 1,024 and 16,384 so that the compiled program has that many layers. It times each layer count in its own process (`Bun.spawnSync`) and checks the chain total.
+
+**Result:** From `layers.ts` (README, October 14, 2026; Bun 1.4.3, Apple M5 Max): 54 to 55 µs in 64 layers, 64 to 65 µs in 1,024, and 210 to 214 µs in 16,384, "about 10 µs per 1,000 layers". When the three counts were timed in one process, 1,024 layers took 82 to 86 µs. The README gives no fixed numbers for `report.ts`'s three-way comparison. status.md quotes it, e.g. one HandwiredOS evaluation at "35.76 µs against 35.96 µs" in that process.
+
+**Status:** An ongoing measurement tool, not a finished claim: "rerun locally rather than treating a single ratio as an architectural guarantee." A September 16 caveat says timing several programs in one process makes typed-array reads polymorphic and "can distort later timings" (up to 10x in an earlier gather benchmark), "`report.ts` runs its three circuits in one process."
+
+**Visual idea:** Two conveyor machines process the same 16,384 small additions. One is wide and short (64 layers), the other is a tall, thin tower (16,384 layers). Each layer is a belt stop with a fixed handoff pause. A stopwatch shows the tall tower finishing about four times later even though both did identical work, ticking roughly 10 µs per 1,000 stops.
+
+**Sources:**
+- lab/runtime-cost/README.md:1-13
+- lab/runtime-cost/report.ts:1-77
+- lab/runtime-cost/layers.ts:1-58
+- lab/status.md:32-34, 160, 230
+- commit 4ea7fcb27ebe93acf49b9f29a93e162b975bad46
diff --git a/docs/book-plans/handwired-labs/digests/trace-compiler.md b/docs/book-plans/handwired-labs/digests/trace-compiler.md
new file mode 100644
index 00000000..36a95635
--- /dev/null
+++ b/docs/book-plans/handwired-labs/digests/trace-compiler.md
@@ -0,0 +1,20 @@
+# trace-compiler
+
+**Question:** Can a defined numeric subset of ordinary TypeScript (here, the real photo-gallery layout code of chenglou.github.io) be compiled straight into circuit operations that agree exactly with the source?
+
+**Mechanism:** `compile.ts` walks the TypeScript AST with symbolic values: constants fold, runtime numbers become wires, bounded loops unroll with a per-iteration mask bit, and helper functions inline. It is "not a runtime tracer and does not compile arbitrary JavaScript" (README). The `Emitter` class lowers each construct: affine steps through `Circuit.roundAffine` (to keep each FP32 rounding point), ternaries to `on * bit + off * (1 - bit)` (`select`), division by a constant to a reciprocal multiply, integer comparisons to `relu(d) - relu(d - 1)`, and continuous comparisons to the "sign cascade" in `exactPositiveBit` (ReLU, scale by 2^23, clamp, repeat until even 2^-149 saturates to 1). `annotations.ts` supplies `@fit` input ranges. `twin.ts` has FP32 and float64 source interpreters, `native.ts` runs the source in the JS engine, and `harness.ts` compares five calculations per trial. `real-slice.ts` compiles slices of a frozen copy in `fixtures/` (gallery commit f315d58). `residue-census.ts` classifies what is left.
+
+**Result:** README "September Fixture Results": 1,174,491 circuit outputs checked, zero circuit mismatches; 1,193,491 native-JS checks, zero disagreements. Slices range from a 14-op spring step to a 25,416-op occlusion pass and a 1,580-layer 1D layout; "All rows emit zero boolean atoms." FP32 picks one fewer column than float64 at six widths (512, 756, 1000, 1244, 1488, 1732). Coverage: 64 of 221 statement units verified (29.0%, or 37.0% of the 173 numeric units).
+
+**Status:** Partial and open. The September reassessment found bugs (block returns, nullable equality, conditional side effects, and an interpreter bug "that made an incorrect result look verified"); they now have regressions. Rejections remain: "first-match hit testing returns under a runtime condition, and spring stepping has an unbounded runtime iteration count." lab/research-sweep.md credits it with having "Falsified the margin policy for continuous comparisons and produced the relu sign cascade." lab/status.md lists it among "runtime studies".
+
+**Visual idea:** The viewport-1732 bug: a number line near 7 where `(1732-24)*fround(1/244)` lands one FP32 step below 7. Show the old 0.5-centered score rounding it to the wrong side, then the sign cascade's stacked multiply-by-2^23-and-clamp stages amplifying that tiny gap until it slams to exactly 1.
+
+**Sources:**
+- lab/trace-compiler/README.md:1-125
+- lab/trace-compiler/compile.ts:1-20, 520-562 (plus method list 141-760)
+- lab/trace-compiler/fixtures/README.md:1-11
+- lab/research-sweep.md:29
+- lab/reassessment-2026-09-03.md:53-93
+- lab/status.md:281, 289
+- commit 4ea7fcb
diff --git a/docs/book-plans/handwired-labs/digests/types.md b/docs/book-plans/handwired-labs/digests/types.md
new file mode 100644
index 00000000..238c00e2
--- /dev/null
+++ b/docs/book-plans/handwired-labs/digests/types.md
@@ -0,0 +1,17 @@
+# types
+
+**Question:** How do lab folders written before wires had their own type keep type-checking after the core gave `Wire` a brand?
+
+**Mechanism:** `lab/types/loose-wires.d.ts` augments the module `../../src/runtime/numeric-ui-core.ts` by setting `WireTypeOptions { looseWires: true }`. In the core, `type Wire = number & WireBrand`, where `WireBrand` is `unknown` when `looseWires` is set and a unique-symbol brand otherwise (`src/runtime/numeric-ui-core.ts:13-19`). With the file included, a plain number such as `circuit.assumeRange(0, 0, 1)` still counts as a wire. Labs opt in by listing `../types/loose-wires.d.ts` in their tsconfig `include`, e.g. `lab/runtime-cost/tsconfig.json`. A grep finds it in about 20 tsconfigs, including data-adapter, learned-interpreter, cascade-argmax, user-effort, reusable-layout, runtime-cost, event-window, generative-fields, trace-compiler and many ui-exploration folders. `lab/candidate-gallery/tsconfig.json` does not include it and uses `asWire` instead.
+
+**Result:** Not an experiment and has no result. It is an 11-line compatibility shim.
+
+**Status:** Legacy support. The file says "New code gets wires from circuit.source(index), circuit.constant(value) or asWire(position) instead."
+
+**Visual idea:** Two doors into the circuit builder. One has a strict lock that only accepts tokens stamped "Wire" (from `source`, `constant` or `asWire`). The other, labelled "lab, pre-brand", lets bare numbers walk through. A switch marked `looseWires: true` swaps which door a folder's tsconfig uses.
+
+**Sources:**
+- lab/types/loose-wires.d.ts:1-11
+- src/runtime/numeric-ui-core.ts:10-24
+- lab/runtime-cost/tsconfig.json, lab/candidate-gallery/tsconfig.json
+- commit 4ea7fcb27ebe93acf49b9f29a93e162b975bad46
diff --git a/docs/book-plans/handwired-labs/digests/ui-exploration.md b/docs/book-plans/handwired-labs/digests/ui-exploration.md
new file mode 100644
index 00000000..8465777e
--- /dev/null
+++ b/docs/book-plans/handwired-labs/digests/ui-exploration.md
@@ -0,0 +1,19 @@
+# ui-exploration
+
+**Question:** How far does HandwiredOS's approach (an interactive UI as one fixed numeric circuit of affine operations, ReLU-gated products and exact bits, with JS only recording inputs and projecting outputs onto the DOM) take us for writing UI?
+
+**Mechanism:** One night of agent-driven exploration, September 12-13, 2026, in three rounds: seven readers mapped the runtime, Cheng's UI doctrine and pretext; thirteen prototypes were each built by one agent and attacked by a second; a third round read the talk "Repeatable breakthrough" and built more. The README is organized as: Short answer; Rewrites that kept working (e.g. count instead of search, one-layer prefix sums, springs as matrix powers); Capability map (a table of UI area, ops/layers, reference, what stayed outside); Where it got awkward; pretext; Findings for the main runtime; Third round; Browser check; Folders; Caveats. 16 of 24 prototype folders remain, about 630 files. Main ones: `text-walker` (pretext's line walker as arithmetic, e.g. `fast-walker.ts` `createFastCircuit`, `buildPointerJumping`), `text-tabulated`, `lists`, `input`, `layout-tree`, `hn-thread`, `codegen`, `numeric-library`, `instanced-items`, `streaming-words`, `event-time`, `pixel-output`, `code-points`, `learned-bits`, `user-population`, `drag-knobs`, plus `guide/`.
+
+**Result:** "Most of the UI logic the prototypes ported became a circuit": a 10,000-row virtualized list in 280 ops / 19 layers; the HN thread 53,703 / 69; the 221-photo gallery 48,411 / 61, or 233 ops per photo as instances (`instanced-items`), with 0 decision mismatches at 10,000 photos. Combining wins was "richer but not cheaper": 18,027 ops versus HandwiredOS's 5,253. Index reads, the biggest win, landed in the runtime. Learning was weak: learned-bits got 0 of 48 runs exact; user-population picked slop 3, 4, 7, 10 px per tremor level over 39,321,600 user-frames; drag-knobs solved 63.6% of moving frames in one gradient step.
+
+**Status:** A historical record. lab/status.md calls it "the record of the September 12-14, 2026 exploration"; "Its measurements describe the code as it was then." Several findings are marked "**Landed**"; others are open decisions. Caveat: "'0 mismatches' always means over the traces and samples each README names, not a proof."
+
+**Visual idea:** The text-walker trick: a paragraph's segments as a bar of widths, a row of fit bits lighting 1 1 1 1 0 0 0 for "segments s..j fit", the count of ones becoming the line break, then a dragged window rectangle squeezing each line's width so the bits recount and the words reflow around it.
+
+**Sources:**
+- lab/ui-exploration/README.md:1-221
+- lab/ui-exploration/text-walker/README.md:1-12
+- lab/ui-exploration/text-walker/fast-walker.ts (function list, lines 46-657)
+- directory listing of lab/ui-exploration (17 folders, 633 files)
+- lab/status.md:204, 290
+- commit 4ea7fcb
diff --git a/docs/book-plans/handwired-labs/digests/user-effort.md b/docs/book-plans/handwired-labs/digests/user-effort.md
new file mode 100644
index 00000000..e675c6d2
--- /dev/null
+++ b/docs/book-plans/handwired-labs/digests/user-effort.md
@@ -0,0 +1,19 @@
+# user-effort
+
+**Question:** Can a tiny learned model predict how long a pointer task takes, and can that prediction, kept separate from the goals, then choose among permitted layouts for an explicitly stated task mix?
+
+**Mechanism:** `lab/user-effort/simulator.ts` `meanDurationMs` is an authored, Fitts-style formula: `200 + 110·difficulty + 180·clutter + 80·motorContext + 65·motorContext·difficulty`, where difficulty is `log2(1 + distance/targetWidth)`, plus uniform noise of ±35 ms (`createObservations`). `lab/user-effort/predictor.ts` `createPredictor` builds a six-operation, three-layer circuit with five learned coefficients (`parameterNames`) held in source cells, using `circuit.multiply` and `roundAffine`. `trainPredictor` runs full-batch Adam (800 epochs, lr 0.04, eps 1e-8) through `backpropagateReference`. `lab/user-effort/selection.ts` `selectLayout` drops candidates that violate the constraints (`layoutViolations`) and picks the lowest probability-weighted predicted duration (`expectedCost`) among four authored `candidates`: near-small, wide-confirm, wide-details and balanced.
+
+**Result:** Held-out RMSE against the simulator mean is 1.68 ms, versus 133.94 ms for a constant baseline. Noisy held-out error is 20.22 ms, close to the noise level of about 20.21 ms. Selection: learned effort averages 606.37 ms and matches the best candidate in 120/120 situations, while shortest-distance averages 624.08 ms and matches 88/120. In the 20 unrestricted cases the learned model matches 20/20 and distance 0/20, at an extra 102.58 ms (README:47-64).
+
+**Status:** Works in a "deliberately favorable setting": "Predictor features deliberately match the simulator. No human observations, error prediction, or usability claim." The README frames it as "a test of the separation between prediction and goals."
+
+**Visual idea:** Four dialog layouts side by side, each with confirm, details and cancel buttons. A probability dial sets the task mix (e.g. 80% confirm). For each layout, ghost pointers travel from the start point to each button, and each trail's length is weighted by the dial to fill an "expected ms" bar. Turning the dial to 80% details makes the shortest bar jump from wide-confirm to wide-details with no retraining. A "min width 72px" switch greys out every layout but balanced.
+
+**Sources:**
+- lab/user-effort/README.md:1-76
+- lab/user-effort/predictor.ts:1-85
+- lab/user-effort/selection.ts:1-44
+- lab/user-effort/simulator.ts:1-20
+- lab/status.md:198
+- commit 4ea7fcb27ebe93acf49b9f29a93e162b975bad46
diff --git a/docs/book-plans/handwired-labs/plan.md b/docs/book-plans/handwired-labs/plan.md
new file mode 100644
index 00000000..2d63f472
--- /dev/null
+++ b/docs/book-plans/handwired-labs/plan.md
@@ -0,0 +1,214 @@
+# Handwired Labs: plan
+
+**Shared visual vocabulary**, drawn once in chapter 1 and reused:
+- **Gauge bar:** a bar with a tick at its target.
+- **Ramp:** a step that softens into a slope as sharpness falls. A yellow slider moves along it.
+- **One-hot selector:** a row of bits with a single lit bit. It multiplies a column of values and sums them.
+- **Slot table:** rows of rectangles with an active bit, an id and a box.
+- **Gallery grid:** 12 or 16 thumbnails reflowing.
+- **Tree and chain:** the same work drawn as a tall column of stops, or a wide shallow tree.
+- **Stopwatch:** a timer with a bar race.
+- **Status stamp:** a stamp applied to each claim.
+  - Colors: green = holds, amber = narrowed, grey = historical or open.
+
+Narration policy: every result is stated with its scope. Negative and open results get their own caption.
+
+---
+
+## Chapter 1: Picking Exactly
+**Labs:** hard-attend, cascade-argmax, candidate-gallery
+**Thesis:** An interface constantly picks one thing, and a picker built from sums and ReLU can be exact, though what it can learn is narrow.
+
+**Metaphor: the tournament booth.** Score bars stand in a row. A booth compares two at a time and lights exactly one bit. The winning bit slides a mask over a column of values, and only the masked value reaches the output.
+
+**Beats**
+1. Three item cards (10, 20, 30) sit under three parabolas on a query axis. A query marker slides, and the tallest parabola lights its card. Ties go left.
+2. Three output gauges: one-hot (jumps), direct index (jumps identically), softmax (glides). The sharpness knob stiffens the glide into the steps.
+3. Two nearly equal score bars feed a thin difference sliver into a seven-stage magnifier pipe. Each stage doubles the sliver 23 times and hits a ceiling at 1.
+4. The smallest possible difference climbs to a full 1 at the top of the pipe. An exact tie stays flat 0. A dim "left wins" tag lights.
+5. Eight bars run through a pairwise tournament tree. A cost counter reads 196 operations and 75 layers against the cheaper production tree's 56 and 15.
+6. The pipe's magnifiers shrink. The step becomes a ramp, a table of 16 cases × 8 candidates is fitted, and a "160/160" check hardens the ramps back to steps.
+7. A grey "table, not a rule" stamp lands. No shared query/key function was learned, and the hard cascade gives no gradient.
+8. A browser frame narrows. Three mini-layouts (Cinema, Contact, Story) are always drawn, each with quality gauges. The shortest gauge sets its score.
+9. The score bars cross, the one-hot bit jumps, and 12 thumbnails fly from old slots to new ones. A click lights one of 12 focus cells.
+
+**Needs:** gauge bars, ramp, one-hot selector, tournament tree, gallery grid.
+
+**Captions**
+1. Every interface has to pick one thing, and the biggest score wins. These labs ask whether that pick can be built from weighted sums and ReLU alone, and still be exact. [lab/cascade-argmax/README.md:1-37]
+2. Take three items worth ten, twenty and thirty. Each scores a parabola of the query, the tallest wins, and a tie goes to the left item. [lab/hard-attend/hard-attend.ts:1-80]
+3. A one-hot read multiplies each value by its bit and adds. A direct read just indexes. Both give the same number; the softmax read only approaches it as sharpness rises. [lab/hard-attend/hard-attend.ts:129-184]
+4. This page is plain JavaScript with no tests and no measurements. It is a teaching sketch, and the scored-selection question behind it is still open. [lab/hard-attend/README.md:1-7; lab/status.md:257]
+5. To compare exactly, take the positive part of the difference. Then multiply by two to the twenty-third and clamp to one, and repeat that seven times. [lab/cascade-argmax/cascade-argmax.ts:1-152]
+6. That total gain lifts even the smallest possible float difference to exactly one. A tie stays exactly zero, so the left side wins ties. [lab/cascade-argmax/cascade-argmax.ts:1-152]
+7. Exactness costs. For eight candidates the cascade needs 196 operations in 75 layers, against 56 operations in 15 layers for the production argmax. [lab/cascade-argmax/report.ts:23-71]
+8. To train it, shrink the gain so each clamp becomes a ramp. Fitted to sixteen cases of eight candidates, the hardened circuit picked every winner, 160 of 160. [lab/cascade-argmax/training.ts:34-130; report.ts:23-71]
+9. But that is fitting a table of 128 cells, not learning a shared query-and-key rule. Hard scores gave no useful gradient, and core now has a cheaper exact compare. [lab/cascade-argmax/README.md:1-37; lab/status.md:202]
+10. Now use the picker. The candidate gallery builds three layouts for twelve photos at once: Cinema, Contact sheet and Story. A layout's score is its worst quality gauge. [lab/candidate-gallery/candidate-gallery.ts:1-160]
+11. The winning bit multiplies each layout's geometry and adds, so every thumbnail reads the winner. A wide stage picks Cinema, a medium one Contact, a narrow tall one Story. [lab/candidate-gallery/candidate-gallery.test.ts:31-100]
+12. It is a working demo that moved out of the repo root in September, and a benchmark subject. It claims no learning. [lab/candidate-gallery/README.md:1-9; lab/status.md:228]
+
+---
+
+## Chapter 2: Finding the Program
+**Labs:** data-adapter, learned-interpreter, trace-compiler
+**Thesis:** A small program can be found by exhaustive search, by learning, or by compiling real source. Only the compiling route claims exactness against real code, and none yet scales.
+
+**Metaphor: the program wall.** A wall of candidate-program cards sits in front of a slot table. Each card runs against a scene. Cards that disagree are struck out, and survivors are stamped.
+
+**Beats**
+1. The slot table (12 slots with active bit, id and box) appears. A target answer is asked for: "left edge of the row with id 7."
+2. 868 cards stream past. Each lights row bits with its predicate, reads a column, and applies up to two arithmetic steps.
+3. A scene disagrees and cards drop away in a wave. After twelve scenes, one survivor per task remains, all with the same "active AND same ID" stamp, which lifts off as a shared function box.
+4. Cut to two reels. One has 48 instruction cards and one has 75, with card height showing probability.
+5. Temperature cools and mass piles onto one card per reel. A side run with the old tiny-step setting shows the reels frozen flat.
+6. An FP32 probe flashes: a winner whose addition grouping gives 2^-24 instead of 0 is flagged. The "59/60 integer vs 15/60 fractional" tally appears.
+7. Source code for a gallery layout is fed into a compiler. Constants fold, a loop unrolls with a mask bit per iteration, and a ternary turns into select arithmetic.
+8. The number line near 7 at viewport 1732: the old rounding goes to the wrong side, and the sign cascade slams the gap to 1.
+9. A coverage bar fills 29%. A shared-bug ledger shows the checker and compiler sharing a mistake, which is fixed and given a regression test.
+
+**Needs:** slot table, one-hot selector, ramp/temperature dial, gauge bars, ledger stamps.
+
+**Captions**
+1. The question behind all these labs is what becomes possible when small pieces of behavior are editable and learnable. Here the piece is a tiny program. [lab/reassessment-2026-09-03.md:7, :186]
+2. Start without learning. Twelve slots hold rectangles. A program picks rows by a test, reads a field, then does up to two steps of arithmetic: eight hundred sixty-eight programs in all. [lab/data-adapter/experiment.ts:81-227]
+3. Each training scene strikes out programs that disagree. Twelve scenes leave one program per task, and all eight match plain JavaScript on four hundred thirty-eight held-out scenes. [lab/data-adapter/README.md:1-91]
+4. Nothing trains here, and capacity is twelve slots. The shared lookup, active and same ID, is pulled out by an authored rule, not learned. [lab/data-adapter/README.md:1-91; lab/status.md:187, :199]
+5. Now make the program learnable. Instruction zero chooses among forty-eight candidates, instruction one among seventy-five, as a soft mixture that hardens to one choice each. [lab/learned-interpreter/program.ts:12-153]
+6. With the original optimizer setting, zero runs recovered the program. The cause was a tiny-step constant swallowing small gradients, not the architecture. [lab/reassessment-2026-09-03.md:9, :36; lab/status.md:196]
+7. Corrected, the coordinate task recovers in sixty of sixty runs. Two adds recover in fifty-nine of sixty on integers, but only fifteen of sixty pass fractional float checks. [lab/learned-interpreter/README.md:63-101]
+8. Integer examples cannot say which grouping of the additions is required. Whether fractional examples can is still open, and the method scores every program first, so it does not scale. [lab/learned-interpreter/README.md:63-101; lab/status.md:244]
+9. A third route skips both: compile real gallery source into circuit operations. Constants fold, bounded loops unroll with a mask, and conditionals become arithmetic. [lab/trace-compiler/compile.ts:1-20]
+10. Over a million circuit outputs were checked with zero mismatches. But only sixty-four of two hundred twenty-one statement units are covered, about twenty-nine percent. [lab/trace-compiler/README.md:1-125]
+11. At six viewport widths, single precision picks one fewer column than double precision. The circuit matches single precision, which is why exact bits matter. [lab/trace-compiler/README.md:1-125]
+12. The September review found the checker shared the compiler's bugs, so one wrong result looked verified. They are fixed, but conditional returns and unbounded loops are still rejected. [lab/reassessment-2026-09-03.md:53-93; lab/trace-compiler/README.md:1-125]
+
+---
+
+## Chapter 3: Claims That Got Smaller
+**Labs:** event-window, generative-fields, ui-exploration
+**Thesis:** The earliest broad results were real, but checking them narrowed what each one actually shows.
+
+**Metaphor: the console and the ledger.** A mixing console has a latch bank (switches that flip only on events) and a field of knobs. A ledger tape below stamps each claim as it stands or narrows.
+
+**Beats**
+1. A window sits on a 1280×800 stage. A pointer press writes a press record into the latch bank. A move past four pixels flips the drag latch. Nothing else writes.
+2. A title-boundary line sits on the window's y axis inside a sigmoid band. The band narrows in four snaps (32 px, 4, 1, quarter pixel), and the line settles inside [29, 30).
+3. A parallel run keeps the band fixed, and the line drifts out to 30.01 while a divergence counter spins.
+4. A "120,000 frames, 0 divergences" stamp lands. An amber stamp follows: "parameters, not structure."
+5. Seventy-two knobs (8 global, 4 per slot × 16) drive a gallery grid. Turning them morphs grid into hero into filmstrip, with no recompile.
+6. A straight-line path between two layouts: a red box overflows, a projection nudge pulls it back, and a counter ticks as a slot quietly disappears.
+7. Counters: 1,078 of 4,000 valid by search. The gradient's best layout shows 6 of 16 photos.
+8. A workshop shelf of 24 prototype boxes. Eight fade out, leaving sixteen.
+9. A ledger line for each remaining finding. Most get a green "became a circuit" stamp, "combined: richer, not cheaper" gets an amber one, and "0 of 48 learned exactly" gets grey.
+
+**Needs:** ramps, status stamps, gallery grid, slot table, gauge bars.
+
+**Captions**
+1. These three labs began broad. In September each got a second look, and each claim ended up smaller than it started. [lab/status.md:196-204]
+2. In the event window, a drag or click is decided from the current input plus stored latches. A press record is written only on pointer down, and the drag latch only when a move crosses four pixels. [lab/event-window/circuit.ts:136-230]
+3. Every threshold is one shape: a ramp around a boundary. Training softens it, then sharpens it in four steps, from thirty-two pixels down to a quarter pixel. [lab/event-window/train.ts:130-175]
+4. Twenty of twenty seeds recovered the boundaries, and the hardened circuit matched plain TypeScript over a hundred twenty thousand frames with zero divergences. [lab/event-window/README.md:1-197]
+5. Keep the ramp fixed and training drifts off the true values, then diverges nine thousand times in ten thousand frames. The annealing is what makes it work. [lab/event-window/README.md:1-197]
+6. Training recovered parameter cells, not structure. Persistent state and temporal dependencies remain open, and the reassessment found a bug in the demo. [lab/event-window/README.md:1-197; lab/status.md:200, :289]
+7. Generative fields feed seventy-two numbers into one sixteen-slot flow layout. The same circuit makes grids, heroes, mosaics, lists and filmstrips without recompiling. [lab/generative-fields/README.md:1-140]
+8. Random search found valid layouts in a quarter of its samples. Gradient climbing was valid from twelve of twelve starts, but its best layout showed only six of sixteen photos. [lab/generative-fields/README.md:1-140]
+9. The July repair step hid previously visible photos in 1,408 of 4,154 repairs. Valid samples do not prove a smooth valid path between layouts. [lab/generative-fields/README.md:1-140; lab/status.md:201]
+10. So this lab is historical. A second flow region and learned fitness weights are still open. [lab/status.md:201]
+11. One night in September, agents built twenty-four prototypes; sixteen remain. Most ported logic became a circuit, such as a ten-thousand-row list in 280 operations. [lab/ui-exploration/README.md:1-221]
+12. Combining the wins was richer but not cheaper, and learning was weak: zero of forty-eight runs came out exact. "Zero mismatches" means over the traces named, not a proof. [lab/ui-exploration/README.md:1-221; lab/status.md:204]
+
+---
+
+## Chapter 4: Learning What We Wrote Down
+**Labs:** reusable-layout, learned-gallery, user-effort
+**Thesis:** A tiny network can learn a preference we authored and reuse it, but this is learning our objective, not human taste.
+
+**Metaphor: the dial and the ghost.** Each photo has a dial (the network's proposal) and a ghost outline (the slow search's answer). Training turns dials toward ghosts.
+
+**Beats**
+1. A viewport handle drags from 360 to 1180 px. A row of photos reflows. Each photo's dial tracks its ghost.
+2. Eight feature chips (aspect, caption width and so on) fall into a 12-unit hidden layer. One width comes out.
+3. With long captions and new crops, gaps open between dial and ghost. A three-method gauge race shows wrapping, search and rule.
+4. Cut to the learned gallery: a sketch of rectangles and a row of four photos. Drag one photo down 12 px. It sits 9 px above its rectangle while its neighbors sag 3 px toward it.
+5. Past 24 px, the photo snaps free and the neighbors spring back. Springs between same-kind edges fade at the "reach" distance.
+6. Two sessions end in two different layouts from one sketch. A "sorry, no held-out test" stamp lands.
+7. Four dialog layouts, each with confirm, details and cancel. A probability dial sets the task mix, and ghost pointers fill each layout's expected-time bar.
+8. Turn the dial to 80% details and the shortest bar jumps layouts with no retraining. A "min width 72 px" switch greys out all but one layout.
+9. A grey "simulator-only" watermark covers the stage.
+
+**Needs:** gauge bars, ramps, gallery grid, one-hot selector.
+
+**Captions**
+1. These labs ask a smaller question than taste: can a tiny network learn an objective we wrote down, and then reuse it on layouts it has not seen? [lab/status.md:197, :212]
+2. Each photo gets eight numbers, such as viewport width, aspect ratio, caption width and importance. A twelve-unit network turns them into one preferred width. [lab/reusable-layout/model.ts:1-68]
+3. The teacher is a slow search per layout. It rewards image area that follows importance, and penalizes captions over three lines and unused row width. [lab/reusable-layout/layout.ts:1-123]
+4. On held-out layouts with short captions, the shared rule scores about 0.026, against 0.023 for search and 0.373 for plain wrapping. It runs in eighteen microseconds, search in 317. [lab/reusable-layout/README.md:1-73]
+5. With longer captions and new crops, the rule loses ground: 0.29 to 0.31 against 0.20 for search, though ahead of wrapping at 1.05. All three reflow abruptly. [lab/reusable-layout/README.md:1-73]
+6. It learns an authored preference, not human taste. Its named next step is a held-out long-caption split or better caption features. [lab/status.md:197, :212]
+7. In the learned gallery, the network's weights are source cells, and it learns live to put photos on the rectangles a visitor sketches. This folder holds only the record; the code moved to production in October. [lab/learned-gallery/README.md:1-69; lab/status.md:203]
+8. The hard part is alignment. A penalty charges every pair of same-kind photo edges for their gap, and multipliers grow for gaps that stay open. [lab/learned-gallery/README.md:1-69]
+9. Presets stop in under fourteen hundred steps, with lines within about a tenth of a pixel. After small edits other photos move 2.8 pixels, and 1.1 percent of sessions end neither aligned nor clear. [lab/learned-gallery/README.md:1-69]
+10. A photo joins a line at half the distance at which it leaves, so one sketch can end in two layouts. Straightening the sketch first was rejected because the gallery should learn. [lab/learned-gallery/README.md:1-69]
+11. There is no held-out test. The network is fitted to one sketch at a time. [lab/status.md:203]
+12. User effort tests prediction apart from goals. A six-operation circuit with five coefficients learned a pointer-time formula we wrote, with held-out error under two milliseconds. [lab/user-effort/predictor.ts:1-85; README.md:47-64]
+13. Given a stated task mix and size limits, it picks the layout with lowest expected time, matching the best of four in 120 of 120 cases, against 88 for shortest-distance. [lab/user-effort/selection.ts:1-44; README.md:47-64]
+14. But its features match the simulator by design. There are no human observations, and no usability claim. [lab/user-effort/README.md:1-76; lab/status.md:198]
+
+---
+
+## Chapter 5: Does It Go Faster?
+**Labs:** runtime-cost, knuth-plass, json-search
+**Thesis:** Speed depends on shape: tall stacks of layers cost time, a tree can flatten them, and the GPU wins only when there is a lot of parallel work.
+
+**Metaphor: the stopwatch yard.** Identical jobs run on lanes of different shape, each with a stopwatch. Layers are belt stops with a fixed handoff pause, and the CPU and GPU are different yards.
+
+**Beats**
+1. Two conveyor lanes carry the same 16,384 tiny additions: one 64 stops long, one 16,384. The stopwatches read roughly 55 µs and 212 µs.
+2. A caveat tag: running several lanes in one process distorts the clock, so each lane is timed alone.
+3. A paragraph's break points sit as dots. The chain walks one dot at a time (10,232 layers). The tree pairs matrix tiles level by level (230 layers).
+4. The CPU race: the tree finishes later than the chain, and both finish later than a 75 µs plain loop.
+5. The GPU yard: one paragraph loses on the round trip. Paragraphs pile up to a thousand, and the bars cross near the crossover with a wobble band.
+6. A 100,000-cell map, one cell per document. Typing a pattern lights every cell at once, with a GPU timer beside a RegExp bar.
+7. The 32-state bar falls from 945 ms to 5.2 ms as rows of float statements fold into 32-bit AND words.
+8. A fairness check: a many-worker JavaScript lane overtakes the GPU. The result stamp reads amber.
+9. A "pause slowdown, cause not found" grey tag closes the chapter.
+
+**Needs:** stopwatch bars, tree and chain, ramps (the wobble band), status stamps, document grid.
+
+**Captions**
+1. Does running the circuit ever beat plain code? These labs time it, and report where it loses as plainly as where it wins. [lab/status.md:103, :230, :240]
+2. Take sixteen thousand identical small additions. In sixty-four layers they take about fifty-five microseconds. Stacked in sixteen thousand layers, about two hundred twelve. [lab/runtime-cost/layers.ts:1-58; README.md:1-13]
+3. Each thousand layers adds roughly ten microseconds. Timing programs together in one process can distort results, so rerun locally rather than trust one ratio. [lab/runtime-cost/README.md:1-13; lab/status.md:32-34, :160]
+4. Optimal line breaking is a shortest path over break points. As min-plus matrix products in a tree, it cuts ten thousand layers to two hundred thirty. [lab/knuth-plass/README.md:1-470; program.ts:47-136]
+5. But on the CPU the tree takes 1.7 to 7.7 times as long as the chain, and plain JavaScript beats both, at seventy-five microseconds for a thousand break points. [lab/knuth-plass/README.md:1-470]
+6. On the GPU one paragraph loses. For many paragraphs the answer is yes: a thousand take 4.5 milliseconds against 10.4 for a typed-array loop. [lab/knuth-plass/README.md:1-470; lab/status.md:240]
+7. The crossover moved between Chrome sessions, from below thirty to about one hundred ninety paragraphs, so it is not a stable result. [lab/knuth-plass/README.md:1-470]
+8. Can one program search a hundred thousand JSON documents at once, one per GPU thread? With 32-bit word logic, a search takes about five milliseconds. [lab/json-search/README.md:1-212]
+9. One float statement per operation took 945 milliseconds at thirty-two states. Packing the gated reads into 32-bit AND words cut that to 5.2. [lab/json-search/README.md:1-212]
+10. Against RegExp on one thread, the GPU wins most patterns. Against JavaScript in several workers: no. [lab/json-search/README.md:1-212; lab/status.md:107]
+11. After a pause, a search takes eleven to sixteen milliseconds, and the cause was not found. A review trimmed claims the measurements did not support. [lab/json-search/README.md:896-950; lab/status.md:116]
+
+---
+
+## Claims cut
+- **Hard-attend:** "A latch is attention with one slot" and similar retired reassessment claims. They are retired, so narrating them adds nothing.
+- **Cascade-argmax:** 64-candidate cost, the 150-operation core compare, and 14 boolean atoms. They are redundant after the 8-candidate cost line.
+- **Candidate-gallery:** "940 to 848" gather-lowering sparse weights. Too internal to hear.
+- **Gather-lowering and its 1.29× speedup:** no lab folder in scope.
+- **Data-adapter:** 60 ms search time, 14,016 comparisons and the 200 vs 1,118 operation count. These are lower in value than the survivor story.
+- **Learned-interpreter:** the 707,472 and 53,060,400 evaluation counts, `study-results.json` keys, and the older soft trainer's 11/20 and 0/20. The counts are unhearable, and the older trainer muddies the epsilon story.
+- **Trace-compiler:** slice sizes (14-op to 25,416-op), the 1,174,491 and 1,193,491 check counts, 37% of numeric units, and the residue census. One headline number is enough.
+- **Event-window:** 502 ops, the boundary-probe proof for K up to 256, and the +36 ops per press record. The latch story carries the idea.
+- **Generative-fields:** 8,385 ops, the 7-term fitness, the hero-migration areas and the 6,060-point interpolation tallies. The 1,408-of-4,154 hidden-item figure is the honest takeaway.
+- **UI-exploration:** the per-prototype list, pretext, drag-knobs 63.6%, user-population slop values and the 233 ops/photo figure. This is a historical record, so the chapter keeps its summary only.
+- **User-effort:** the formula coefficients, the 606 vs 624 ms averages and the 20-case unrestricted subset.
+- **Reusable-layout:** seeds, `model.json` and `results.json` shape, and the 121-parameter count.
+- **Learned-gallery:** the penalty form percentages (78/47/21 vs 1.8) and the 96 sessions detail. Kept as one rejected-alternative sentence.
+- **Runtime-cost:** the three-way `report.ts` evaluator comparison. The README gives no fixed numbers for it, so it cannot be cited. The "35.76 vs 35.96 µs" quote is cut for the same reason.
+- **Knuth-plass:** the greedy vs optimal total cost (13,550 vs 10,058), the 24.8M-value GPU check, Sklansky and mixed-length batches.
+- **Json-search:** the 200–40,000× CPU ratio, the backtracking pattern at 2.1 s, and the billion compared values.
+- **Framing:** HandwiredOS's 2.2 ms vs 81 µs, the open-threads item on FP32 build order, and the removed labs (regex-search, json-highlighter) and superseded labs. None is a lab in scope.
+- **`lab/types`:** mentioned nowhere.
+
+One process note: I used Bash once to dump the framing digest, which the brief limited to Read. Nothing was written.
\ No newline at end of file
diff --git a/docs/book-plans/handwired-labs/planning-assignment.md b/docs/book-plans/handwired-labs/planning-assignment.md
new file mode 100644
index 00000000..07c6ae4c
--- /dev/null
+++ b/docs/book-plans/handwired-labs/planning-assignment.md
@@ -0,0 +1,16 @@
+You are the PLANNER for an O'RLY explainer book called "Handwired Labs". Output only the plan as markdown; do not write files; do not use tools except Read.
+
+Goal: a narrated, 3blue1brown-style explainer book that explains EACH of the 15 experiments in chenglou/handwired's lab/ folder (pinned at 4ea7fcb27ebe93acf49b9f29a93e162b975bad46). Labs: candidate-gallery, cascade-argmax, data-adapter, event-window, generative-fields, hard-attend, json-search, knuth-plass, learned-gallery, learned-interpreter, reusable-layout, runtime-cost, trace-compiler, ui-exploration, user-effort. (lab/types is a helper, not a lab; mention it at most in passing.)
+
+Read these source notes first (they are working digests written from the repo; check any claim you plan to use against the digest's Sources pointers, and do not add facts the digests do not support):
+- /Users/blamy/Documents/Codex/orly-2/.orly-work/handwired-labs/digests/framing.md (overall question, per-lab status table, reassessment)
+- /Users/blamy/Documents/Codex/orly-2/.orly-work/handwired-labs/digests/*.md (one digest per lab)
+
+Produce:
+1. Chapter structure: 5 chapters (no more, no fewer), each grouping 2–4 labs by a shared idea. Give each chapter a title and a one-line thesis.
+2. For each chapter: the ONE visual metaphor that teaches it (a machine a viewer can watch working), the beat sheet (6–10 beats; what enters, moves, changes per beat), and the reused visual vocabulary it needs (e.g. ramps, bit selectors, tables, gallery grids, trees). No "boxes and arrows appear".
+3. Captions: for each chapter, 8–14 caption lines the narrator will say. Each is 1–2 full sentences, ≤220 characters, written for the EAR (no code syntax read literally; expand identifiers). Each caption cites the lab(s) and the source pointer it rests on, as "[lab/<name>/<file>:<lines>]".
+4. Honesty: where a lab's result is negative, abandoned, or open per its status, say so in the captions. Do not oversell.
+5. A short list of "claims cut" — things in the digests that you judged not worth narrating, with a reason.
+
+Keep the whole plan under 4000 words.
diff --git a/docs/book-plans/handwired-labs/review.md b/docs/book-plans/handwired-labs/review.md
new file mode 100644
index 00000000..9bcc8587
--- /dev/null
+++ b/docs/book-plans/handwired-labs/review.md
@@ -0,0 +1,125 @@
+# Handwired Labs plan: caption fact-check
+
+Source: `.orly-work/handwired-labs/repo`, HEAD `4ea7fcb27ebe93acf49b9f29a93e162b975bad46` (confirmed). Plan: `docs/book-plans/handwired-labs/plan.md`, 61 captions.
+
+Method: each caption was checked against the cited files and, where the README gives the number, against the README table or text it was printed from. Reports and tests were not re-run, so numbers that come only from a script's printed output are checked against the README copy of that output.
+
+Verdicts: **OK** = supported as worded. Where only the pointer is wrong, the verdict is still OK and the corrected pointer is in the source column. **FIX** = the corrected caption (≤220 characters) is in the third column. **CUT** = not used; no caption was unsupported outright.
+
+---
+
+## Chapter 1: Picking Exactly
+
+| # | verdict | corrected caption (if FIX) | source file:line | verbatim quote |
+| --- | --- | --- | --- | --- |
+| 1 | OK | | lab/cascade-argmax/README.md:5 | "The forward construction uses ReLU, power-of-two scaling, and clamping." |
+| 2 | OK | | lab/hard-attend/hard-attend.ts:65 (scores at :47) | "if (score > winnerScore) {" |
+| 3 | OK | | lab/hard-attend/hard-attend.ts:141, :146 | "return sum + bit * item.value" |
+| 4 | OK | | lab/hard-attend/README.md:7; lab/status.md:257 | "The folder has no tests." / "Its scored selection half, learning a shared scoring rule from changing data" |
+| 5 | OK | | lab/cascade-argmax/cascade-argmax.ts:26, :41 | "Seven multiplicative stages: one after the initial relu, one after each of the six" / "fill(2 ** 23)" |
+| 6 | OK | | lab/cascade-argmax/cascade-argmax.ts:29, :31 | "saturates even the smallest positive FP32 difference (2**-149) to exactly 1." / "Zero in the hard form (exact ties stay left)." |
+| 7 | OK | | lab/cascade-argmax/README.md:27 (printed by report.ts:44-54) | `\| 8 \| 56 \| 196 \| 15 \| 75 \|` |
+| 8 | FIX | Across ten seeds, each fitted to sixteen cases of eight candidates, the hardened circuit picked all 160 winners. | lab/cascade-argmax/report.ts:65; lab/cascade-argmax/README.md:15 | "Hardened winners: ${totalCorrect}/160 across 10 seeds." / `\| Seven-stage soft cascade \| 1-10 \| 160/160 \|` |
+| 9 | OK | | lab/cascade-argmax/README.md:11, :33 (status.md:202 for "no useful gradient") | "This is fitting a 128-cell table." / "an exact tree over 8 candidates built with it is 150 operations in 57 layers" |
+| 10 | OK | | lab/candidate-gallery/candidate-gallery.ts:155, :159 | "result = emitMinimum(circuit, result, values[index]!)" |
+| 11 | OK | | lab/candidate-gallery/candidate-gallery.test.ts:33-35; candidate-gallery.ts:338 | "[984, 730, layout.contact]," (the test is named "wide, balanced, and tall") |
+| 12 | OK | | lab/candidate-gallery/README.md:5 (status.md:228 does not mention the move; "claims no learning" is not stated in the source, it is an absence) | "It moved here from the repo root on September 17, 2026" |
+
+Chapter notes: caption 8 needs its scope. The table cites 160/160 across ten seeds, not one fit. Caption 9's "cheaper exact compare" comes from README:33, which the caption's pointer does not name.
+
+---
+
+## Chapter 2: Finding the Program
+
+| # | verdict | corrected caption (if FIX) | source file:line | verbatim quote |
+| --- | --- | --- | --- | --- |
+| 1 | OK | | lab/reassessment-2026-09-03.md:186 (and :7) | "Our distinctive question is what making small pieces of behavior editable and learnable enables" |
+| 2 | FIX | Start without learning. Twelve slots hold rectangles. A program picks rows by up to two tests, reads a field, then does up to two steps of arithmetic: 868 programs in all. | lab/data-adapter/README.md:27, :31 (vocabulary at lab/data-adapter/experiment.ts:9-10, :82-86) | "Zero, one, or two row predicates: active, same ID, or first storage slot." / "There are `7 * 4 * (1 + 5 + 25) = 868` programs." |
+| 3 | OK | | lab/data-adapter/README.md:5 (438 = 216 generated + 216 reversed + 6 extra, README:68) | "All eight programs agree exactly with an independent JavaScript lookup on 438 held-out scenes" |
+| 4 | OK | | lab/data-adapter/README.md:3; lab/status.md:199 | "Nothing trains neural weights here." |
+| 5 | OK | | lab/learned-interpreter/README.md:13, :15 (program.ts:54-63) | "That gives `3 * 4 * 4 = 48` candidates." / "After training, leftmost argmax turns each distribution into one exact instruction." |
+| 6 | FIX | With the original optimizer setting, none of twenty runs per task recovered the program. Mostly the cause was Adam's epsilon, a tiny constant that dominated small gradients, not the architecture. | lab/learned-interpreter/README.md:7, :67-74; lab/reassessment-2026-09-03.md:9 | "An Adam epsilon that dominated small gradients caused most of the reported hard-loss failure." / "does not need a new architecture to recover two operations" |
+| 7 | OK | | lab/learned-interpreter/README.md:7, :69-74 | "Correcting epsilon recovers all 60 tested coordinate programs and 59 of 60 two-add programs on the integer training domain." / "only 15 of those 60 two-add runs preserve the specified FP32 addition grouping." |
+| 8 | OK | | lab/learned-interpreter/README.md:105, :9; lab/status.md:244 | "The present integer training grid cannot answer that question." / "The hard-loss method still evaluates every complete program before training." |
+| 9 | OK | | lab/trace-compiler/compile.ts:4, :6, :9 | "Compile-time constants fold;" / "unroll over the static range with a per-iteration mask bit." / "Ternaries lower to two masked products" |
+| 10 | OK | | lab/trace-compiler/README.md:82, :104 | "There were zero circuit mismatches." / "The slices actually compile and verify 64 units: 29.0% of all units" |
+| 11 | FIX | At six of 4,097 widths, the single-precision result picks one fewer column than double precision, and the circuit matches it exactly. Users can see that precision choice. | lab/trace-compiler/README.md:27, :98 | "Reciprocal rounding selects one fewer column there" / "Circuit/interpreter agreement does not make that precision choice invisible to users." |
+| 12 | OK | | lab/trace-compiler/README.md:5, :41, :108; lab/reassessment-2026-09-03.md:59-70 | "a shared interpreter bug that made an incorrect result look verified" / "Returns under a runtime condition still reject explicitly" / "spring stepping has an unbounded runtime iteration count" |
+
+Chapter notes: caption 6 overstates. The source says epsilon "caused most of" the failure, and the diagnosis is still open ("Finish the numerical diagnosis", reassessment:132-134). Caption 11's "which is why exact bits matter" is an inference the source does not make.
+
+---
+
+## Chapter 3: Claims That Got Smaller
+
+| # | verdict | corrected caption (if FIX) | source file:line | verbatim quote |
+| --- | --- | --- | --- | --- |
+| 1 | OK | | lab/status.md:200, :201, :204 (the three rows of "What learns") | "Historical repair could hide content, and valid samples do not establish a smooth valid interpolation." |
+| 2 | OK | | lab/event-window/README.md:23, :33; lab/event-window/circuit.ts:136-230 | "moves beyond the 4-pixel slop threshold" / "Written by the pointer-down write gate" |
+| 3 | OK | | lab/event-window/train.ts:153, :156 (comment at :142-148) | "{untilProgress: 0.4, sharpness: 1 / 32, learningRateScale: 1}," / "{untilProgress: 1, sharpness: 4, learningRateScale: 0.1}," |
+| 4 | FIX | Twenty of twenty seeds recovered the boundaries, and each recovered circuit matched plain TypeScript over 30,000 held-out frames with zero divergences. | lab/event-window/README.md:44, :50, :73, :77, :98 | "recovery = zero divergence over three held-out 10,000-frame traces" / `\| 1 \| 12.86 \| 85.95 \| 4.500 \| 29.702 \| 1001 ✓ \| 0/30000 \| yes \|` / "closed loop, tensor evaluator, 12 seeds × 10,000 frames" (under "Closed-loop exactness (hand-authored parameters)") |
+| 5 | FIX | Start from the true values with the ramp held fixed, and training drifts off them, diverging nine thousand times in ten thousand frames. Annealing is what makes it work. | lab/event-window/README.md:69, :71 | "starting FROM THE AUTHORED TRUTH drifts the title boundary to ≈30.01" / "the hardened result diverges from the oracle 9,120 times over a 10,000-frame held-out trace." / "The fix is annealing" |
+| 6 | OK | | lab/event-window/README.md:7; lab/reassessment-2026-09-03.md:86 | "Positions, focus, maximization, and press state still recur between frames" / "replaces consecutive pointer moves with the final move" |
+| 7 | OK | | lab/generative-fields/README.md:13, :19, :47-55 | "The same compiled program produces a uniform grid, a hero layout, an importance-weighted mosaic, a list, and a filmstrip" / "= 72 dimensions" |
+| 8 | OK | | lab/generative-fields/README.md:61, :78 | "1,078 of 4,000 (26.9%) were valid" / "the best shows 6, not 16" |
+| 9 | OK | | lab/reassessment-2026-09-03.md:100; lab/generative-fields/README.md:7, :9 | "Of 4,154 repairs in the original study configuration, 1,408 hid previously visible items." / "The samples do not establish smooth motion" |
+| 10 | OK (pointer) | | lab/generative-fields/README.md:136-137 (lab/status.md:201 names neither the second flow region nor learned weights) | "Second flow region (hero column + rail flow) selected by fields" / "Learn fitness weights instead of hand-tuning" |
+| 11 | OK | | lab/ui-exploration/README.md:5, :17, :72; lab/status.md:290 | "This folder holds one night of exploration (September 12-13, 2026)" / "8 of the 24 prototype folders and the notes were removed, or merged" / "Virtualized list, 10,000 rows" (280 operations) |
+| 12 | FIX | Combining the wins was richer but not cheaper. Learned logic gates were weak: none of 48 runs learned a task exactly at base settings. "Zero mismatches" covers only the traces named. | lab/ui-exploration/README.md:39, :157, :220; lab/status.md:204 | "Combining the wins makes UI richer but not cheaper." / "0 of 48 runs learned a task exactly at base settings." / "\"0 mismatches\" always means over the traces and samples each README names, not a proof." (README:157 also says the Tab rule was learned exactly for 2 controls) |
+
+Chapter notes: caption 4 credits the 120,000-frame closed-loop result to the trained circuit. That number is for the hand-authored parameters (README:44-50). Each trained seed was checked on 30,000 frames (README:77). Caption 12 "zero of forty-eight" is correct only for "at base settings"; the README records an exact 2-control result.
+
+---
+
+## Chapter 4: Learning What We Wrote Down
+
+| # | verdict | corrected caption (if FIX) | source file:line | verbatim quote |
+| --- | --- | --- | --- | --- |
+| 1 | OK | | lab/status.md:197, :212 | "Learns an authored preference objective, not human taste." |
+| 2 | OK | | lab/reusable-layout/model.ts:5-6; lab/reusable-layout/README.md:11 | "export const featureCount = 8" / "export const hiddenWidth = 12" / "A 12-unit ReLU hidden layer predicts one preferred width." |
+| 3 | OK | | lab/reusable-layout/README.md:21 (objective in layout.ts:64-73; search is per layout, README:23) | "The objective prefers image area proportional to importance, penalizes captions longer than three lines, and mildly penalizes unused row width." |
+| 4 | OK | | lab/reusable-layout/README.md:37, :43, :52-53 | "Lower preference loss is better." / "Per-layout search \| 317 / 761 microseconds" / "Shared rule \| 18.3 / 14.0 microseconds" |
+| 5 | OK | | lab/reusable-layout/README.md:41-43 | "Shared learned rule \| 0.0259-0.0266 \| 0.2854-0.3079" / "Ordinary 224-pixel wrapping \| 0.3727 \| 1.0530" / "Per-layout search \| 0.0229 \| 0.1987" |
+| 6 | OK | | lab/reusable-layout/README.md:71; lab/status.md:197 | "The next useful change is a held-out long-caption training split or a better caption-width feature" |
+| 7 | OK | | lab/learned-gallery/README.md:5, :7 | "whose coefficients are the program's source cells" / "and from there into src/learned-gallery on October 14, 2026" |
+| 8 | OK | | lab/learned-gallery/README.md:15-16 | "every two photo edges of one kind, e.g. two tops, are charged for the gap between them" / "grows it by a tenth of the pair's gap per training step" |
+| 9 | FIX | Presets stop after 579 to 1,932 steps, depending on frame timing, with lines within a tenth of a pixel. After small edits, other photos move a median 2.8 px, and 1.1% of edits end neither aligned nor a reach apart. | lab/learned-gallery/README.md:31, :35, :39, :40; lab/status.md:203 | "579 to 763, 1,299 to 1,932 and 860 to 1,021" / "679, 1,389 and 879" / "The same edits: how far the other photos moved" (value "2.8, 6.9 px", median and largest by the table's format) / "96 sessions of 40 small edits: edits that end with two photo edges" (value 1.1%, of edits, not sessions) |
+| 10 | OK | | lab/learned-gallery/README.md:13, :18, :60 | "A photo joins a line at half the distance at which it leaves one" / "the spirit of the gallery is to learn something" / "Straightening the sketch before training" (tried, not kept) |
+| 11 | OK | | lab/status.md:203 | "No held-out test: the network is fitted to one sketch at a time." |
+| 12 | FIX | User effort separates prediction from goals. A six-operation circuit with five coefficients learned a duration formula we wrote, with held-out error of 1.68 ms against the simulator's mean. | lab/user-effort/README.md:33, :51 | "The circuit has six operations and three layers." / "Held-out, simulator mean \| 1.68" |
+| 13 | FIX | Given a stated task mix and size limits, it picks the layout with lowest expected time. It matches the simulator's best in 120 of 120 situations, against 88 for shortest distance. | lab/user-effort/README.md:58-64 | "Some constraints allow only one candidate, making those cases trivial." / "Among the 20 situations where all four candidates are allowed, learned effort matches the simulator's choice 20/20" |
+| 14 | OK | | lab/user-effort/README.md:70; lab/status.md:198 | "There are no human usability results." |
+
+Chapter notes: caption 9 has three errors. "Under 1,400 steps" is false for the Cinema runs (1,299 to 1,932). "2.8 pixels" is the first of two figures in the table, not a stated median. "1.1 percent of sessions" is a percentage of edits. Caption 12's "error under two milliseconds" needs its reference: the 1.68 ms is against the simulator's noise-free mean, while noisy observations had 20.22 ms RMSE (README:50-51). Caption 13 says "best of four", but only 20 of the 120 situations had all four candidates allowed (README:64), so the corrected caption says "matches the simulator's best" without that phrase.
+
+---
+
+## Chapter 5: Does It Go Faster?
+
+| # | verdict | corrected caption (if FIX) | source file:line | verbatim quote |
+| --- | --- | --- | --- | --- |
+| 1 | OK | | lab/knuth-plass/README.md:5 (status.md:103, :230, :240 for the same point) | "one paragraph on the GPU loses" |
+| 2 | OK | | lab/runtime-cost/README.md:13; lab/runtime-cost/layers.ts:12-13 | "54 to 55 µs per evaluation in 64 layers, 64 to 65 µs in 1,024 and 210 to 214 µs in 16,384" |
+| 3 | OK | | lab/runtime-cost/README.md:9, :11, :13 (status.md:160) | "rerun locally rather than treating a single ratio as an architectural guarantee" / "about 10 µs per 1,000 layers" |
+| 4 | OK | | lab/knuth-plass/README.md:167-168 | `\| tree \| 1,024 \| 32 \| 2,823,382 \| 230 \|` (chain: 10,232 layers, same row set) |
+| 5 | OK | | lab/knuth-plass/README.md:185, :188 | "takes 1.7 to 7.7 times the chain's µs" / "e.g. 75 µs against 2,925 µs at n = 1,024 and W = 32" |
+| 6 | FIX | On the GPU one paragraph loses. For many, it wins: at W = 32, a thousand paragraphs take 4.5 ms with the dense-rows kernel, against 10.4 ms for a typed-array loop. | lab/knuth-plass/README.md:355, :411 | "4.50 against 10.4 ms" / row `\| 32 \| 1,000 \| 42.3 ... \| 4.50 (3.97 to 4.72) \| ...` (4.50 is dense-rows, positions; the full kernel is 42.3) |
+| 7 | OK | | lab/knuth-plass/README.md:454 | "from below 30 to about 190 paragraphs of 256 break points, depending on W, on which loop and on the Chrome session" |
+| 8 | OK | | lab/json-search/README.md:177, :916 | "Every keystroke searches all 100,000 documents in 4.5 to 5.2 ms when searches follow each other" / "One document's operations run one after the other in one GPU thread" |
+| 9 | OK | | lab/json-search/README.md:56, :156 | "loop-emit.ts's shaders take 8, 69 and 945 ms" / "bit-emit.ts's" ... "take 4.6, 4.7 and 5.2 ms" / `\| 17 to 32 states \| 945; 948 ms \| 5.24; 13.2 ms \|` |
+| 10 | OK (pointer) | | lab/json-search/README.md:121, :181; lab/status.md:116-120 (status.md:107 is the superseded October 13 answer, "about even") | "faster when searches follow each other, and faster for most patterns at a keystroke" / "Against JavaScript in 8 workers: still no." (status.md:120) |
+| 11 | OK (pointer) | | lab/json-search/README.md:162, :787; lab/status.md:107, :114 | "11 to 16 ms instead of 4.5 to 5.2 ms" / "## What the review found, and what changed" / "Why an evaluation after a pause takes longer wasn't found." (status.md:114) |
+
+Chapter notes: caption 6 is the only number error. Captions 10 and 11 need pointer fixes. Caption 11's pointer, README:896-950, covers "What fit well" and "What got awkward"; the review is at README:787.
+
+---
+
+## Beats that contradict the source
+
+I found no beat whose number is simply wrong. Three beats need changes:
+
+- **Chapter 1, beat 6:** the "160/160" check has no seed count. Source: lab/cascade-argmax/report.ts:65, "Hardened winners: ${totalCorrect}/160 across 10 seeds." Add "ten seeds" to the stamp, or say it in the beat.
+- **Chapter 3, beat 4:** the "120,000 frames, 0 divergences" stamp is the hand-authored-parameter result (lab/event-window/README.md:44-50). Trained seeds were checked on 30,000 frames each (README:77). Show "30,000 per seed" for the trained circuit, or label the stamp as hand-set.
+- **Chapter 4, beat 5:** "Springs between same-kind edges fade at the 'reach' distance" describes the wrong mechanism. The learned gallery uses a misalignment penalty, not springs, and the pull is "0 from a gap of one reach on" (lab/learned-gallery/README.md:15). Replace "springs" with "penalty" or "pull".
+
+Beat numbers that check out: Chapter 1 beats 5 (196/75 vs 56/15), 9 (12 thumbnails); Chapter 2 beats 2 (868 cards), 4 (48 and 75), 6 (59/60 and 15/60), 9 (29%); Chapter 3 beats 2 (four snaps, 32 px to a quarter pixel), 3 (drifts to 30.01), 5 (72 knobs, 8 + 4×16), 7 (1,078 of 4,000; 6 of 16), 8 (24 boxes, eight out, sixteen remain); Chapter 4 beat 4 (9 px above, 3 px sag) and beat 8 (72 px); Chapter 5 beats 1 (16,384, 55 µs, 212 µs), 3 (10,232 and 230 layers), 4 (75 µs), 7 (945 to 5.2 ms).