@woosh/meep-engine 3.24.0 → 3.26.0

package/src/engine/physics/cloth/MEASUREMENTS.md

@@ -2237,3 +2237,1635 @@ it too, at seed, alongside the subtree walk and the graph colouring that seeding
 already does. Nothing pays it per step.
 
 ---
+
+## 38. What M5 proved wrong in PLAN.md
+
+Four things, and the first two are the same mistake read from two directions:
+§12 described the worker's memory as a property of the *world*, and it is a
+property of the *cloth*.
+
+| # | The design said | The measurement said |
+|---|---|---|
+| 0 | §12 — "**One `SharedArrayBuffer` for the whole cloth world**, not one per instance", with "each instance gets a region inside the buffer" | It is one per cloth, and the reseed contract is why. A `ClothState` is sized at seed from that cloth's particle and row counts, and `ClothSystem#reseed` — a chain gaining a link, a `ClothDynamics` change the row tables depend on — builds a new one of a different size while other cloths are mid-flight. A world buffer would need an allocator with relocation, and a relocation invalidates every view of every cloth in it. One buffer per cloth costs one cold-plane message per seed and makes a re-seed a re-registration. §39 |
+| 1 | §12 — the collider table is a region of the per-cloth layout; `ClothInstance` (M2) — it lives on the instance instead, "because its size is a property of the *world* … §12 puts it in the shared buffer when M5 needs it there" | §12 was right about *where* and M2 was right about *why*, and the two are not in conflict: the size is a property of the world, so the region has a capacity rather than a growth policy. A growable array is memory the worker would have to be told about again mid-run. What the capacity has to be sized against is not a garment but a **scene** — a cloth's table holds every collider on every character standing inside its query box: ten for one body, twenty for two, thirty for three. §41 |
+| 2 | §12 — "`ClothDynamics` reaches the worker through the command region, written every step" | Every step, yes; `ClothDynamics` , no. By the time the step can use them a cloth's dynamics have been through `cloth_dynamics_map.js` — a retention, a velocity limit, a self-collision radius, gravity rotated into the local frame — and sending the raw component would mean running that mapping a second time on the far side with no way to prove the two agreed. What crosses is the **step's own parameter block**, and `ClothSystem` fills the identical block in a private scratch array. §40 |
+| 3 | §18 — "**Open — the write-back has no interpolation.** §12 gives cloth `PhysicsSystem`'s producer / `__interp_restore` contract … It lands with M5" | It does not, and the contract named is not the one cloth needs. `Interpolated` is an **entity-keyed marker** — `InterpolationSystem` files snapshots under a key it assigns from the entity id — and a rigged garment's simulated things are `Node3D`s inside a skinned model, which are not entities. Cloth also needs only half of the contract it was pointed at: `__interp_restore` exists to undo render-time writes before the sim reads them, and cloth never reads back what it writes. §43 |
+
+**And one thing the implementation confirmed rather than corrected**, which is
+the milestone's own gate. §12: "`ClothSystem` and `WorkerClothSystem` must
+produce bit-identical results. Identical code over identical data in an
+identical order." They do, and the number is zero — not at the end of a run but
+at **every step of one**, over the whole `ClothState` buffer. §40.
+
+---
+
+## 39. One buffer for the whole cloth world is one buffer per cloth
+
+§12's opening sentence is the one M5 could not implement as written, and the
+obstacle is not the worker — it is `ClothSystem#reseed`, which M1 built and M5
+inherited.
+
+A `ClothState` is one allocation whose every region is sized from the cloth:
+particle count, stretch rows, bend rows, leash rows, backstops, colours. Seeding
+produces it. **Re-seeding produces a different one**, and re-seeding is an
+ordinary event rather than a teardown: `cloth_dynamics_change_needs_reseed`
+returns true whenever a field the row tables depend on moves, a chain that gains
+a link says so through `reseed(entity)`, and a rigged garment re-seeds when its
+model finishes loading. Each of those changes at least one region's length.
+
+Putting every cloth in one buffer therefore means an allocator with relocation —
+and a relocation is not a local event. Every view of every region of the moved
+cloth has to be re-cut, on both threads, while other cloths in the same buffer
+have steps in flight against their own regions. The engine has `OffsetAllocator`
+and it could do this; what it cannot do is make the *re-cut* free, and the
+re-cut is the part that has to be coordinated across a thread boundary.
+
+One buffer per cloth costs, instead, exactly one cold-plane message per seed:
+
+```
+  add_cloth    { id, state: {buffer, six counts}, self_exclusions }
+  remove_cloth { id }
+```
+
+and makes a re-seed a re-registration, which is the same code path as a first
+seed. The registration is what the worker is waiting for, so a cloth that
+re-seeds is simply not stepped for the few ticks the message takes — the same
+window a newly spawned garment already sits in.
+
+**The layout is not serialized anywhere.** The descriptor carries the buffer and
+the six counts, and the worker runs the *same* `allocate` the main thread ran, so
+there is no second description of the layout that could drift from the first.
+That is worth saying because the alternative — a table of byte offsets in the
+message — is the obvious implementation and it is the one that rots.
+
+### What it cost to move the collider table inside
+
+M2 left `collider_table` on the instance, growing by doubling. M5 moved it into
+the state at a fixed `CLOTH_COLLIDER_SLOTS`. The layout change is a `Float64`
+result region at the head of the buffer (three words, 8-byte aligned where the
+buffer's own alignment is free) and the table plus its key array inserted before
+the contact slots.
+
+Both are on the hot path's critical structure, so the question is whether the
+step got slower. It did not:
+
+```
+  interleaved A/B in one process, per-frame minimum over 1,200 frames
+
+  case                HEAD's layout   M5's layout   ratio   states agree
+  400p 2x4               1.100 ms       1.082 ms    0.983   bit-identical
+  400p 2x4 + self        1.454 ms       1.399 ms    0.962   bit-identical
+  576p 2x2               0.847 ms       0.803 ms    0.949   bit-identical
+  1024p 2x4              4.582 ms       4.487 ms    0.979   bit-identical
+```
+
+0.95 to 0.98 is not a speed-up; it is noise with a sign. The bit-identical
+column is the load-bearing one: the two states are built from the same rest pose
+and stepped with the same inputs, and they stay equal to the last bit for 1,600
+steps, so the layout change moved bytes and nothing else.
+
+### Two things about measuring it that cost an hour
+
+**The machine was not idle and could not be made idle.** Nineteen node processes
+and 30–38% background CPU throughout — other work in the same checkout. M4's own
+lesson says a timing run needs a quiet machine; what M4 did not have to answer is
+what to do when the machine will not go quiet. The answer is to stop measuring
+absolutes and measure a **ratio from interleaved samples**: whatever the rest of
+the machine is doing, it is doing it to both variants inside the same frame.
+
+**And an interleaved A/B has to alternate its order**, which the first version of
+this harness did not. Running A then B every frame charges A for everything the
+rest of the machine evicted between frames, and B reads the cache A just warmed.
+The bias is not small:
+
+```
+  ratio, M5 against HEAD     A always first     alternating
+  400p 2x4                       0.693             0.983
+  400p 2x4 + self                0.738             0.962
+  576p 2x2                       0.662             0.949
+  1024p 2x4                      0.882             0.979
+```
+
+A 30% "improvement" that is entirely an artifact of going second. Anyone
+re-running a paired measurement in this repo should alternate.
+
+---
+
+## 40. The parameter block is the protocol, and that is why the parity is structural
+
+§12 asks for bit-identical results between the two systems and calls the
+mechanism "identical code over identical data in an identical order". M3 met the
+same bar between the entity and rig paths (§25) by making the row builder and
+the pose reconstruction **one function each** rather than two that agreed. M5
+does the same thing one level down, and the shape it takes is a block of words.
+
+`cloth_step_instance(state, exclusions, params, offset)` reads every number it
+needs out of a `Float64Array`: `dt`, gravity already rotated into the cloth's
+local frame, the substep and iteration counts, the damping retention, the
+velocity clamp, the contact radius, the self-collision radius, the collider
+count, and whether self-collision is on at all. `ClothSystem` fills that block in
+a thirteen-word private scratch array and calls the function. `WorkerClothSystem`
+fills a thirteen-word slice of the shared command region and the worker calls the
+function. **Neither system computes a step parameter of its own**, so neither can
+compute one differently.
+
+`Float64` throughout the block is load-bearing rather than incidental. Every
+number in it is produced in double on the main thread and consumed in double by
+the step, so the round trip through shared memory is exact. An `f32` command
+region would round the velocity clamp, and a clamp that rounds is a velocity that
+rounds.
+
+The same argument decided where the *results* live. The step answers with three
+scalars — the largest speed left, which the sleep test reads, and two diagnostic
+counts — and a `ClothState` attached over shared memory in a worker is a
+different JavaScript object over the same bytes, so a plain field on it is
+invisible to the main thread. They go in the buffer, in `Float64`, at the head
+where the alignment is free. `Float32` would have been enough for a diagnostic
+count and not for the speed: it is compared against `CLOTH_SLEEP_SPEED_RATIO ·
+reach`, and an f32 round on one side of that comparison and not the other is a
+cloth that falls asleep one step earlier than its twin and diverges from there.
+
+### The number
+
+```
+  240 steps, a 10-link rope, anchor walking a sine with a turn in it
+  180 steps, three 10-link strands in cotton, two colliders, one of them moving
+
+  differing bytes in ClothState's buffer, per step:   0
+  differing bytes at the end of the run:              0
+```
+
+**Compared every step, not at the end.** A divergence that appears at step 200
+and one that appears at step 2 read the same from the end of a run and they are
+very different bugs — the first is drift, the second is a wrong parameter. The
+comparison is the whole buffer rather than selected fields: particle positions
+and velocities, every dual and penalty, the collider table, the contact slots and
+their warm-started multipliers, the self-collision pair list, and the step's own
+result words.
+
+The second run is there because the first never takes two of the branches:
+`cloth_contact_find` with records in the table, and `cloth_self_find` at all.
+Cotton is one of §33's three entries that set `ClothDynamicsFlags.SelfCollision`,
+and the run is self-checked — it asserts that the collider table filled, that
+contact rows were created, and that self-collision pairs were found — because a
+parity test over a branch that did not run is a parity test over nothing.
+
+### What the write-back does, which is not identical and is not meant to be
+
+The scene's poses lag by one tick. At tick `T` the worker system joins step
+`T − 1` and writes it back, then dispatches step `T`. The spec pins that exactly:
+the local transforms the worker system writes at tick `T` equal the ones
+`ClothSystem` wrote at tick `T − 1`, every tick, for the whole run.
+
+**The local transforms rather than the world ones**, and the reason is a sentence
+M1 already wrote. A node's world pose is a function of its local pose *and of the
+anchor's pose now*, so two scenes whose steps are one tick apart show the same
+shape in different places: "the cloth's *shape* is one fixed step stale; its
+*position* is not, because the attachment cascade carries the whole subtree
+rigidly with the anchor". §4.1 says that about running cloth before the poser.
+The worker's one-tick lag is the same statement with the same consequence, which
+is a reassuring place for it to land: the quality cost of the worker is a cost
+the design had already priced.
+
+---
+
+## 41. What the main thread stops paying for
+
+§17 asks M5 for "a measured main-thread cost reduction". The loopback is what
+makes it measurable: in production the worker's step and the main thread's tick
+overlap, but under `SystemWorkerLoopback` they are two calls on one thread, so
+`em.update()` is *exactly* what the main thread pays and `runPendingStep()` is
+*exactly* what moved.
+
+```
+  400 warm-up ticks then 900 measured, 3 rounds, minimum of the minima
+  a garment as an entity subtree, anchor walking; "+ body" is a ten-part
+  character collider set in the scene
+
+  workload              ClothSystem   WorkerClothSystem    the worker's   main thread
+                        main thread         main thread           step        saved
+
+  COTTON 1024p             3.623 ms            0.181 ms       4.084 ms       95.0%
+  COTTON 1024p + body      5.222 ms            0.206 ms       4.845 ms       96.1%
+  SILK 400p                1.666 ms            0.059 ms       1.488 ms       96.5%
+  SILK 400p + body         1.853 ms            0.066 ms       1.739 ms       96.4%
+  DENIM 576p               1.106 ms            0.081 ms       0.992 ms       92.7%
+  ROPE 40 links            0.130 ms            0.006 ms       0.129 ms       95.5%
+```
+
+**92% to 96%**, and the figure is not a surprise — `MEASUREMENTS.md` §7 put 69%
+of a frame in the stretch rows and 18% in the bend rows, and those are what
+crossed. What is worth stating is what is *left* on the main thread: the anchor's
+pose, the local-frame carry, the leash centres, the broadphase query and its
+rewrite into the cloth's frame, the sleep test, and the write-back. All of it
+reads components, walks hierarchies or queries an index, and all of it together
+is a fifth of a millisecond for a thousand-particle garment.
+
+The columns are minima taken from separate runs on a machine carrying other work,
+so they do not add up exactly — the 1024p inline minimum landed below the
+worker's own step minimum, which is impossible within one scene and ordinary
+across two. The ratio is the result; the absolute column is an upper bound.
+
+**Note what this does not do**, and §17 already says it: the worker moves the
+cost, it does not reduce it. "2 ms on the worker" with several characters in
+flight is a scheduling question, and `WorkerSystem` answers it with one step in
+flight at a time and a fixed-step gate — so the budget §17 sets is now a budget
+for *all the cloth in the scene together*, on one thread, per tick. What changed
+is that it no longer competes with the renderer for the same thread.
+
+### How full the per-cloth collider table gets
+
+This is the measurement that sized `CLOTH_COLLIDER_SLOTS`, and it moved the
+number, because it showed the table is bounded by the **scene** rather than by
+the garment:
+
+```
+  600 ticks, a garment walking through a scene of ten-part character bodies
+
+  garment   colliders in the scene    worst    mean    capacity
+  SILK              10                  10     10.0      64
+  COTTON            10                  10     10.0      64
+  DENIM             10                   8      7.7      64
+  ROPE              10                  10      9.0      64
+  COTTON            20                  20     19.1      64
+  COTTON            30                  30     24.9      64
+```
+
+A garment's query box is its own particle bounds fattened by a step's travel, and
+a garment is worn *on* a body — so what lands in the table is every collider that
+body carries, and every collider carried by anyone standing close enough to touch
+it. One character fills ten slots. Three fill thirty. There is no garment-shaped
+number here at all.
+
+Thirty-two was the first choice, against M2's twenty-collider scene, and three
+characters would have been inside 88% of it with an **arbitrary** drop past that
+— `ClothColliderIndex#query` answers in its own order, not in order of how much a
+collider matters, so an overflow discards colliders the cloth may be resting on.
+Sixty-four is six characters, nine kilobytes a cloth, and 1.4% of the §17
+workload's state — the same order as the 16% §33 already spends on
+self-collision storage that four of seven entries never read. The drop still
+warns once, because the capacity is a bound and not a rule.
+
+---
+
+## 42. The library, re-measured, and why no entry is re-sized
+
+§17 says to re-measure at M5 and re-size anything that drifted outside. The
+absolute table taken with `cloth_library_bench.mjs` reads 15% to 25% above M4's:
+
+```
+  M4's §33          M5's run          entry
+  1.427 → 1.802     1.641 → 2.069     SILK      2x4
+  1.478 → 1.802     1.547 → 2.002     COTTON    2x4
+  1.297 → 1.765     1.458 → 2.020     DENIM     2x2
+  1.315 → 1.828     1.435 → 2.039     LEATHER   2x2
+  0.116 → 0.129     0.126 → 0.133     ROPE      2x4
+  0.165 → 0.183     0.183 → 0.215     CHAIN     2x6
+  1.438 → 1.798     1.571 → 1.997     HAIR      2x4
+```
+
+**That is the machine, not the milestone**, and the paired measurement in §39 is
+what says so. `cloth_library_bench.mjs` does not go anywhere near
+`WorkerClothSystem` — it calls `cloth_self_find` and `cloth_step` directly over a
+`ClothState`, so the only thing M5 changed that it can see is the buffer layout,
+and that is 0.95 to 0.98 with the states staying bit-identical. Every one of
+these entries is 400 to 576 particles at 2×4 or 2×2, which are exactly the four
+shapes §39 paired.
+
+The run was taken with nineteen other node processes on the machine and 30–38%
+background CPU, which M4's own lesson predicts will cost 9% to 29%. It cost 15%
+to 25%. **No entry is re-sized**: re-sizing a library on numbers taken from a
+busy machine would bake someone else's test run into a shipped garment.
+
+What the measurement *is* good for is the shape, and the shape is unchanged: the
+three entries that set `ClothDynamicsFlags.SelfCollision` are still the tightest,
+the chains still find no pairs at all, and leather still pays the most for the
+fewest. §33's ordering stands entry for entry.
+
+**The thing to re-measure on a quiet machine** is the absolute column, and the
+question it answers is no longer "does a garment fit in a frame" but "does all
+the cloth in a scene fit in a worker tick" — §41's last paragraph. Whoever does
+it should check the process count first; this section exists so they know to.
+
+---
+
+## 43. Interpolation: the named contract cannot express a rigged garment
+
+§18 carried "the write-back has no interpolation" as open and said it lands with
+M5, "where the worker makes the fixed-step producer contract load-bearing for a
+second reason". The second reason is real and it points the other way: the worker
+is what makes the simple implementation impossible.
+
+**Three findings, in the order they change the answer.**
+
+**1. `Interpolated` is entity-keyed, and a garment's joints are not entities.**
+The contract §13's reuse ledger points at is `PhysicsSystem`'s: an `Interpolated`
+marker component per interpolated body, carrying a `key` the
+`InterpolationSystem` assigns from the entity id at link time, and a list of
+interpolands each naming a component class and its serialization adapter. That
+works for a rope, whose links are entities. It cannot express a **rigged**
+garment at all: M3's write-back drives `Node3D.transform_local` on the joints of
+a skinned model, and `shade_node_to_entity_composition` does not expand a skinned
+node into entities — "that is a boundary rather than an omission" (D47, quoted in
+§3). There is no entity to put the component on and no key to file the snapshot
+under. §13's ledger row is wrong for half the feature.
+
+**2. Cloth needs half the contract, and it is the half with no name.**
+`__interp_restore` exists because the render-time blend writes into the very
+components the simulation reads, so the sim has to be handed its authoritative
+pose back before it integrates. Cloth's simulation state is `ClothState.position`
+in the cloth's local frame, and `cloth_write_back` writes nodes `1` upward —
+never the anchor, which is the one transform it reads. **Cloth never reads back
+what it writes**, so there is nothing to restore. It needs the record/publish
+half and none of the restore half, and it gets the restore it *does* depend on
+for free: an anchor on a physics-driven character is restored by
+`PhysicsSystem.__interp_restore` before cloth reads it.
+
+**3. The worker takes the cheap implementation away.** Without it, a render-time
+pass could read `ClothState.position`, reconstruct the pose and blend. With it,
+that memory is owned by the worker from dispatch until the next tick's join —
+which is essentially all of the time outside the fixed pass. An interpolating
+cloth therefore needs a **published pose slot**: the last two steps' node poses,
+copied out on the main thread at join, blended at render time from the copy. That
+is the same double-buffered publish slot `WorkerFluidSystem` documents as the
+unbuilt prerequisite for its own render-time reads, and it is the honest cost of
+the feature rather than an implementation detail of it.
+
+### What it would cost, and what it would buy
+
+The slot is nearly free to *fill*, because `cloth_write_back` already computes
+every node's local TRS and would only have to keep it. What costs is the
+per-frame pass, which is a pose per node blended and written — strictly less work
+than the write-back, because it reads two stored poses instead of reconstructing
+one from particles, so the write-back's own cost is an upper bound on it:
+
+```
+  write-back, 401 nodes    0.0487 ms
+```
+
+The arithmetic, spelled out, because the first draft of this section guessed at
+it and was wrong by a factor of two. A blend pass runs **every frame**, where the
+write-back runs every tick, and the write-back keeps running either way. So on a
+165 Hz display against a 60 Hz fixed step:
+
+```
+                                     400 nodes     1,024 nodes (§17)
+  a blend pass, per frame             0.049 ms        0.124 ms
+  ... at 165 frames a second           8.1 ms/s        20.5 ms/s
+
+  what the main thread pays today      3.5 ms/s        10.9 ms/s   (§41, x60)
+  what it paid before M5             100.0 ms/s       217.4 ms/s   (§41, x60)
+```
+
+**Interpolating a cloth would roughly triple what the main thread pays for it**
+— and leave it at a seventh of what it paid before the worker. That is the shape
+of the trade: the feature is affordable *because* M5 happened, and it is not free.
+
+What it buys is the size of the hold, measured on M3's cape geometry — five
+strips of 8 cm links, 8.5 cm apart, which is the garment §37 measured:
+
+```
+  600 steps past settling; the largest world-space distance a node covers in one
+  fixed step
+
+  anchor     worst        mean       worst, in link lengths
+  still     46.74 mm    12.51 mm            0.58
+  walk      37.90 mm    27.98 mm            0.47
+  sprint   106.71 mm    67.42 mm            1.33
+```
+
+Half a link length a step at a walk, and a whole one at a sprint. That is
+visible, and it is the *size* of what a display running faster than the fixed
+step shows as a hold — 105 of every 165 frames repeating a pose in the general
+case.
+
+**The decision: it does not land with M5.** §17's M5 is four artifacts and three
+proofs and interpolation is none of them; the feature it turns out to need is a
+publish slot, a second system, an ordering contract with `InterpolationSystem`,
+and a way to name a `Node3D` that the engine's interpolation layer does not have.
+Landing a worker and a half-built interpolator together would have been the thing
+§17 asks milestones not to do. What has changed is that the open question is no
+longer "wire the existing contract": it is "build the cloth-shaped half of a
+contract whose entity-shaped half does not fit", and §18 now says so with the
+three findings above beside it.
+
+The one piece of good news is that the cloth-shaped version is *simpler* than the
+engine's, not harder: no restore pass, no serialization adapters, no log — two
+poses per node and a lerp, driven by the same `alpha` `EntityManager` already
+exposes for the purpose, and it covers the rigged path and the entity path
+identically because both of them end in a pose per node.
+
+---
+
+## 44. Two things M5 deliberately did not build
+
+**A playground page.** M0 through M4 each added one and M5 does not, for a
+reason that is about the dev server rather than about the cloth: a
+`SharedArrayBuffer` needs a cross-origin isolated page, and
+`packages/meep-engine/vite.config.mjs` sends no `Cross-Origin-Opener-Policy` or
+`Cross-Origin-Embedder-Policy`. Adding them is four lines and it is four lines
+that change how **every** playground page in the package loads its subresources,
+including the Sponza path-tracer pages under `src/shade/playground/`. That is a
+change to shared infrastructure to demonstrate a bridge that
+`SystemWorkerLoopback` already tests more precisely than a page could — the
+loopback makes message delivery and step execution separate events a spec can
+order, and a real worker makes them a race nobody can observe.
+
+**A second step in flight.** `WorkerSystem` allows exactly one, for reasons its
+own docblock gives, and cloth has no reason to want more: the fixed-step gate
+means a cloth's step must complete before the next tick begins regardless.
+
+---
+
+# Cloth — M6 measurements
+
+> Written 2026-09-12, against the M6 implementation in `wind/`, `solver/` and
+> `ecs/`. Everything above this line is M0's through M5's and is unchanged.
+>
+> Two scripts, both runnable directly under node — the M0 note applies unchanged:
+>
+> ```
+> node src/engine/physics/cloth/ecs/__fixtures__/cloth_m6_measure.mjs
+> node src/engine/physics/cloth/ecs/__fixtures__/cloth_library_bench.mjs
+> ```
+>
+> The second is M1's, extended here with a section that prices §10's aerodynamic
+> term against each entry's own size and budget beside the one M4 added for
+> self-collision.
+>
+> **The behavioural numbers come off the playground**, driven from its own
+> `globalThis.cloth_wind_playground` handle rather than clicked, because the
+> question is what a banner does over four hundred settled steps and a screenshot
+> cannot answer that.
+
+---
+
+## 45. What M6 proved wrong in PLAN.md
+
+Five things. The first is the one the milestone is *about* — §10 names a
+quantity that half the system cannot have — and the second is the one that would
+have shipped a garment blowing at a speed that depended on how finely someone
+had voxelised the room.
+
+| # | The design said | The measurement said |
+|---|---|---|
+| 0 | §10 — `a_drag = drag · (u_air − v) · \|n·û\|`, "the normal-facing factor making a sheet catch the wind broadside and slice through it edge-on — the difference between a flag and a rope" | The **rope has no `n`**. A chain's particles span a line and every direction perpendicular to it is equally a normal, so any one this code picked would be the history-free fabrication §7 P4(a) exists to keep out — and a rope wants the *opposite* dependence anyway, catching the flow across it and slicing along it. Both are one quantity: the part of the flow the particle's own incident rows cannot let past. Rank 2 gives §10's `\|û·n\|` exactly, rank 1 gives the cross-flow, rank 0 gives 1. §47 |
+| 1 | §10 — "a cloth overlapping a `FluidComponent` **samples its velocity field** per particle" | It samples it and then has to **convert it**. `FluidField#sampleVelocity` answers in *grid cells* per second and documents that it deliberately does not rescale, "on the assumption that callers (vegetation sway, dust drift) interpret the field as a direction × magnitude wind". Cloth's drag row is a relaxation toward a velocity, so without the multiply by `cell_size` the same wind voxelised at 0.25 m instead of 1 m blows a garment four times as hard. §46 |
+| 2 | §10 — the whole section, which never says **which thread** samples | It cannot be the worker's. A fluid field is a hundred thousand floats its own solver rewrites every step and may itself live on another worker; the *answer* is three floats a particle. So the sample runs on the main thread and lands in a region of the cloth's own `SharedArrayBuffer`, where the worker already reads — nothing is copied — and everything built from it runs in `cloth_step_instance` with the rest of the arithmetic, which is what keeps §40's parity argument intact. §46 |
+| 3 | §10 — `drag` multiplies the relative flow directly | What the step multiplies by cannot be a rate. One acceleration is held for the whole fixed step, so an explicit `rate·(u − v)` overshoots the air once `rate·dt > 1` and diverges past 2 — and §1's first commitment is "not at 5 fps", which is a `dt` of 0.2 s and a rate of 10. What crosses is the **per-step response** `(1 − e^(−rate·dt))/dt`, the exact solution of the same ODE, which closes a fraction of the gap that is strictly below one for every rate and every step. It is also the step `GlobalFluidEffector` takes for the air itself. §49 |
+| 4 | §12 — "thirteen words into memory the worker already shares"; §10 — "sleep wakes on a wind change" | Fourteen now, and the gust needs a clock that counts **steps rather than ticks**. A worker cloth is not advanced until its registration is acknowledged (§39), so the two systems reach a cloth's first step at different tick counts — and a clock that counted ticks would hand that cloth a different gust on the same step under the two systems. That is a divergence the parity gate reports, and it is the only thing in M6 that did. §50 |
+
+**And one thing the implementation found that the design had no line for at
+all.** §10's normal-facing factor is what makes a flag a flag, and it does —
+measured on the playground's banner, turning a *uniform* wind ninety degrees
+takes the mean facing factor from 0.221 to **0.000** and the mean aerodynamic
+acceleration from 43.2 m/s² to 0.08. Turning a **wake** ninety degrees does
+nothing of the kind: 0.216 to 0.280. A wake has velocity in every direction, so
+there is no orientation of a banner that is edge-on to one. §10's argument for
+reading a fluid simulation is therefore stronger than §10 knew — the simulation
+knows something the factor's own intuition does not — and the factor's headline
+claim is a statement about *laminar* air. §51.
+
+---
+
+## 46. Which side of the worker bridge, and the units nobody had converted
+
+§10 describes what cloth does with the air and never says where the reading
+happens, which was fine until M5 put the arithmetic on a thread. M6 has to
+answer it, and both answers cost something real: sampling on the main thread
+gives back part of what M5 bought, and sampling in the worker means the field
+has to get there.
+
+**The field cannot get there.** A `FluidComponent` is not a parameter, it is a
+simulation:
+
+```
+  a 32³ fluid field, the size a room-sized volume wants
+
+  velocity_x   33 x 32 x 32     33,792 floats
+  velocity_y   32 x 33 x 32     33,792
+  velocity_z   32 x 32 x 33     33,792
+                               101,376 floats = 396 KB
+
+  rewritten, every one of them, every fixed step, by a solver that may itself
+  already be on a different worker (`WorkerFluidSystem`)
+```
+
+Against a cloth step that is 1 to 4 ms and a main-thread share that M5 got down
+to 0.18 ms, shipping 396 KB a step to feed it is not a trade, it is the feature
+costing more than the thing it feeds. And there is a second objection that is
+structural rather than arithmetic: `ClothSystem` would have to sample the field
+too, so the field would have to be on **both** sides and the two copies would
+have to be proved equal — which is exactly the shape `MEASUREMENTS.md` §40 says
+breaks the parity gate.
+
+**So the field stays where it is and the answer crosses.** `cloth_sample_air`
+runs on the main thread in both systems, writes one air velocity per particle
+into `ClothState#air_velocity` — a region of the cloth's own buffer — and the
+step reads it there. Nothing is copied and nothing is marshalled: §39's "one
+buffer per cloth" already made that memory shared, and this is the first thing
+to use it in the main-thread-writes direction.
+
+The **drag arithmetic** is not on the main thread. It reads positions and
+velocities the state already holds, so it belongs with the rest of the
+arithmetic, and it is one more word of the parameter block rather than a second
+computation. §49 is what it costs; §48 is what the sample costs.
+
+### The field answers in cells, and cloth wants metres
+
+`FluidField#sampleVelocity` is trilinear over a MAC grid and answers in **grid
+cells per second**. Its docblock says so and says why: it "does NOT rescale
+them, on the assumption that callers (vegetation sway, dust drift) interpret the
+field as a direction × magnitude wind and want consistent strength regardless of
+the underlying cell size".
+
+Cloth is not such a caller. §10's row is a relaxation toward a *velocity*, and a
+velocity in cells is a garment that blows differently depending on how finely
+someone voxelised the room:
+
+```
+  the same 3-cells-per-second flow, sampled by ClothFluidWind
+
+  cell size    what the field says    what the cloth is handed
+  2.00 m         3 cells/s                6.0 m/s
+  0.50 m         3 cells/s                1.5 m/s
+```
+
+A factor of four between two authorings of the same room. `ClothFluidWind`
+multiplies by `cell_size`, `cloth_wind.spec.js` gates on it, and it is the one
+line of M6 that would have been silently wrong rather than loudly wrong.
+
+---
+
+## 47. The factor §10 wrote as `|n·û|`, and the rope that has no `n`
+
+§10 asks for `|n·û|`, and it is right about what it wants: a sheet should catch
+the wind broadside and slice it edge-on. What it is wrong about is that a normal
+exists to take the dot product with. Half of what this system simulates is
+chains — `CLOTH_ROPE`, `CLOTH_CHAIN`, `CLOTH_HAIR`, and every cape whose proxy
+is strips (§37) — and a chain's particles span a **line**. Every direction
+perpendicular to it is equally a normal. Picking one would be the same
+fabrication §7 P4(a) rules out for a contact normal, and it would be worse than
+arbitrary, because a rope's aerodynamics are the *complement* of a sheet's: it
+catches the flow across it and slices along it.
+
+Both are one quantity. Take the span `T` of the directions to the particle's
+stretch-row neighbours **in the current configuration** and the factor is the
+part of the flow that span cannot let past, `‖û − proj_T(û)‖`:
+
+```
+  rank of T   what the particle is      the factor                what §10 wanted
+  2           a point on a surface      |û·n|,  n = b1 x b2       exactly this
+  1           a link of a chain         sqrt(1 - (û·t)^2)         the complement
+  0           an isolated particle      1                         (no case)
+```
+
+One expression, three topologies, no stored normal, no orientation, no sign, and
+nothing carried between steps — recomputed from the configuration every step,
+which is what P4(a) asks of a normal and what a baked one could not offer.
+
+Measured on the topologies the two paths actually build
+(`cloth_wind_accelerate.spec.js`):
+
+```
+  a 5x5 triangulated sheet in the XZ plane, interior particle
+
+  flow direction        facing
+  along the normal      1.000
+  along the surface     0.000
+  45 degrees            0.707      (the cosine, as a sheet should)
+
+  boundary and corner particles, which carry three rows and two
+  along the normal      1.000
+  along the surface     0.000
+
+  a 5-link chain along X, middle particle and end particle
+
+  along the chain       0.000
+  across it             1.000
+  60 degrees off it     0.866      (the *sine*, which is the rope's answer
+                                    and not the sheet's)
+```
+
+**And the rows that would have faked a plane out of a line do not.** §11.1's
+chain bends through a skip row to its grandparent, which runs parallel to the
+two links it spans; §6's strain-limit row is a second row on an edge that
+already has one. Either would give a straight rope a surface, and a straight
+rope with a surface slices through a wind blowing across it — the exact opposite
+of the right answer. A second direction has to survive projection out of the
+first by a quarter of its length (about fourteen degrees) before it counts, and
+a six-link chain carrying both kinds of row still measures 0.000 along itself
+and 1.000 across.
+
+### What it does on a whole garment, which is not 1
+
+A flat sheet held rigid and broadside would read 1. A banner does not:
+
+```
+  the playground's 16x16 silk banner, 500 settled steps in a uniform 9 m/s wind
+
+  mean facing over the free particles    0.221
+```
+
+That is the correct answer and it is worth stating because it looks like a
+failure. A free flag **streams**: at equilibrium its surface lies along the
+flow, which is edge-on, and what is left facing the wind is the part near the
+pinned edge that cannot turn. A flag that stayed broadside would be a flag
+nailed to a board. The factor is what produces that shape rather than a number
+the shape should make large.
+
+---
+
+## 48. What the sample costs the main thread
+
+This is §17's question for M6 — "a measured cost showing the per-step sampling
+stays inside budget" — and the answer has two very different halves depending on
+whether a fluid field actually reaches the cloth.
+
+```
+  cloth_m6_measure.mjs section 1, paired and alternated, per-frame minima
+  a triangulated sheet at 2 cm, the §17 topology
+
+  particles   ambient      field      ratio    per particle (field)
+        144    0.50 us     9.00 us    18.0x        62 ns
+        400    0.90 us    23.40 us    26.0x        58 ns
+        576    1.30 us    34.00 us    26.2x        59 ns
+      1,024    2.20 us    59.70 us    27.1x        58 ns
+```
+
+**A trilinear sample costs 58 to 62 nanoseconds a particle**, flat in particle
+count, which is what a per-particle pass with no term in the neighbour count
+should look like. For the §17 workload that is 0.060 ms a step.
+
+**A uniform source costs a twenty-fifth of that**, and the reason is §10's own
+cost-control sentence read one step further. §10 says "a cloth outside every
+fluid field's bounds skips it entirely"; what makes that worth having is that
+the *skip* is a property the source can answer for a whole cloth at once.
+`AbstractClothWind#varies` is that question, `ClothAmbientWind` answers `false`
+for every box, and the sampler then takes one sample and fills the region —
+which is a bounds scan and a write, both linear with a handful of operations
+each. Weather is nearly free; air is not.
+
+### The whole main thread, which is what M5's number was
+
+§41 measured `em.update()` under a `SystemWorkerLoopback` and called it "exactly
+what the main thread pays, because the worker's step is a separate call". M6
+runs the same measurement with a wind source attached:
+
+```
+  cloth_m6_measure.mjs section 4
+  a garment as an entity subtree, anchor walking; the field reaches all of it
+
+  garment          no wind      ambient       field     ambient   field
+  COTTON 1,024p     0.269 ms     0.293 ms    0.334 ms      +6%    +24%
+  SILK 400p         0.059 ms     0.063 ms    0.092 ms      +6%    +55%
+  ROPE 40 links     0.006 ms     0.006 ms    0.009 ms      +5%    +54%
+```
+
+The absolute column is this machine's and this scene's — the garment is strands
+rather than §41's patch — so the ratios are what the pairing licenses. Read
+against §41's own figures, a thousand-particle garment standing in a simulated
+wake pays about **a third more main thread** than one that is not, and about a
+twentieth more if the air is only weather. Against the 3.62 ms the same garment
+cost before M5, the whole of M6's main-thread share is under two per cent of
+what the worker removed.
+
+The ambient column's +5% to +6% is the bounds scan and the fill, and it is worth
+naming what it is *not*: a source that answers `varies() === false` is not
+approximated, it is exact, because `false` is a promise rather than a hint.
+
+---
+
+## 49. What the aerodynamic term costs the step, and the trap in measuring it
+
+The first version of this section measured a cloth in a gale against a cloth
+hanging still and reported the difference as the cost of the code. It is not,
+and §7 already said so — "the variants sit in different physical states, and an
+isolated loop over one accumulate measures a converged mesh rather than a moving
+one". The size of that mistake here:
+
+```
+  the same 40-link rope, 2x4, stepped 3,300 times
+
+  hanging dead straight       0.029 ms per step
+  blown horizontal at 9 m/s   0.095 ms per step      3.24x
+```
+
+None of that 3.24× is arithmetic. A rope blown out to 1.79 m of its own 2 m is
+fighting its own hard rows at every iteration; a rope hanging straight down has
+converged and is barely working. The wind's own code, measured on the same rope
+with the physics held fixed, is **0.7%**.
+
+### Holding the physics fixed
+
+Fill the external-acceleration array with exactly gravity and the two paths
+simulate the same cloth, so the only difference left is which predict and
+integrate run. (Exactly the same cloth: the region is `Float32`, so the uniform
+side is handed `Math.fround(-9.81)` too, and the harness asserts the two
+position arrays are bit-identical after every round. Without that the two
+accelerations differ by 4e-7 and a hanging sheet — which is chaotic — is
+somewhere else entirely three thousand steps later, which is the confound above
+arriving by the back door.)
+
+```
+  cloth_m6_measure.mjs section 2, paired and alternated
+
+  entry        budget   uniform   varying    path     + term    total
+  SILK          2x4      0.930     0.934     +0.4%     0.2%     +0.6%
+  COTTON        2x4      0.933     0.931     -0.2%     0.2%     -0.1%
+  DENIM         2x2      0.649     0.648     -0.2%     0.3%     +0.2%
+  LEATHER       2x2      0.645     0.647     +0.3%     0.3%     +0.6%
+  ROPE          2x4      0.029     0.029     +0.3%     0.7%     +1.0%
+  CHAIN         2x6      0.050     0.050     -0.2%     0.4%     +0.2%
+  HAIR          2x4      0.918     0.927     +1.0%     0.2%     +1.2%
+  COTTON §17    2x4      3.232     3.196     -1.1%     0.1%     -1.0%
+```
+
+**The whole feature is one per cent of a step, and the sign of the path column
+is noise.** Two loops rather than a branch inside one is why the uniform path
+does not pay: a cloth with no wind runs the code M0 through M5 measured, byte
+for byte, and `cloth_wind.spec.js` holds a 120-step run to exactly that.
+
+`cloth_wind_accelerate` itself — the Gram-Schmidt walk over incident rows plus
+the arithmetic — is 0.1% to 0.7% of a step, larger as a fraction on a chain
+because a chain's step is small rather than because its walk is long.
+
+### What `drag` does
+
+```
+  a 20-link rope hanging under gravity in a steady 2 m/s cross-wind, 2x4
+  "lean" is the tip's downwind travel once settled; "half" the step at which it
+  first passes half of that; "settle" the step the fastest particle first falls
+  under 1 mm/s
+
+  drag   rate 1/s   response   lean m   half   settle   peak m/s
+  0.00        0.0       0.00    0.000      -       67      0.11
+  0.05        3.0       2.93    0.468     21      111      1.02
+  0.08        4.8       4.61    0.602     20      115      1.28
+  0.12        7.2       6.78    0.704     19      116      1.48
+  0.20       12.0      10.88    0.802     18      119      1.67
+  0.30       18.0      15.55    0.857     17      134      1.77
+  0.45       27.0      21.74    0.897     17      143      1.85
+  0.70       42.0      30.20    0.926     16      149      1.90
+  1.00       60.0      37.93    0.942     16      152      1.95
+```
+
+Monotone in every column and exactly zero at zero, which is what makes it a dial
+rather than a switch. The library's own spread — leather at 0.05 to silk at
+0.45 — is 0.47 m of lean against 0.90 m at the same wind, which is the
+difference between a skirt that moves and a banner that flies.
+
+Two things in that table are worth naming. **Settling gets slower, not faster**,
+as drag rises: 111 steps to 152. A livelier cloth is a cloth with more to
+dissipate, and §7 P5's sleep still arrives for every value — a banner in a
+steady wind settles into a displaced equilibrium and sleeps there, which
+`cloth_wind.spec.js` gates on. And **peak speed approaches the air speed**,
+1.02 m/s to 1.95 against 2 m/s of air, which is `drag = 1` meaning what
+`cloth_dynamics_map.js` says it means: a cloth with no aerodynamic memory.
+
+### The response cannot overshoot, at any step length
+
+```
+  a free particle, no rows, no gravity, air at 10 m/s, drag = 1
+
+    dt      rate*dt   closed/step   v after 1 step   v after 20
+  0.00417      0.25      0.221199        2.2120        9.9326
+  0.01667      1.00      0.632121        6.3212       10.0000
+  0.03333      2.00      0.864665        8.6466       10.0000
+  0.10000      6.00      0.997521        9.9752       10.0000
+  0.20000     12.00      0.999994        9.9999       10.0000
+```
+
+An explicit `rate·(u − v)` at the fourth row would move the particle to 60 m/s
+in one step and to 590 in two. The exact form closes 0.9975 of the gap and
+stops. §1's first design commitment is "it does not explode… not at 5 fps", and
+this is that commitment discharged by construction rather than by a clamp.
+
+### Memory
+
+```
+  particles    state bytes   the two regions    share
+        144         97,400            3,456     3.5%
+        400        262,776            9,600     3.7%
+        576        377,528           13,824     3.7%
+      1,024        671,160           24,576     3.7%
+```
+
+Twenty-four bytes a particle, unconditionally — the same shape as M4's
+self-collision regions, and for the same reason: `ClothState` is one allocation
+sized at seed, and making `drag` a reseed trigger would be a change to the
+reseed contract rather than a tidy-up. Against §33's 16% for three regions four
+of seven entries never read, 3.7% for two regions every cloth in a windy scene
+does is not the thing to fix first.
+
+---
+
+## 50. The clock counts steps, not ticks, and the parity gate is why
+
+§12 asks the two systems for bit-identical results and M5 made that structural:
+one `ClothWorld`, one `cloth_step_instance`, one parameter block. M6 adds the
+first thing in the system that is a function of **time**, and time is where the
+two systems genuinely differ.
+
+A worker cloth is not stepped until its registration is acknowledged, and §39's
+own argument is that it is not *advanced* either — "not stepped, not written
+back" — so `ClothSystem` reaches a cloth's first step on tick 1 and
+`WorkerClothSystem` reaches it on tick 2 or later. A gust that is a function of
+ticks would therefore be a different gust on the same step:
+
+```
+  step    ClothSystem's clock    WorkerClothSystem's clock, ticking
+     1              dt                       2dt
+     2             2dt                       3dt
+   ...
+```
+
+Measured, by putting the clock back on ticks and running the gate: the two
+buffers differ at **step 1, byte 0**. Byte 0 is the first word of
+`ClothState#result` — the largest particle speed the step produced — so the very
+first step of the run is already a different step. Not drift, a wrong parameter,
+which is exactly the distinction §40 built the per-step comparison to make: from
+the end of a run the two would look like any other divergence.
+
+**The fix is not a synchronisation.** It is that the clock advances at the first
+`advance` of a tick rather than at `begin`, so a tick in which no cloth is
+advanced does not move the weather. A cloth that has not started stepping has no
+weather yet, which is the right semantic on its own terms — a paused simulation
+should not have the wind move — and it makes the two systems agree by
+construction rather than by arrangement. It sits **above** the sleep tests
+deliberately: a world whose every cloth is asleep still has weather, and §10's
+"sleep wakes on a wind change" is the whole reason it needs to.
+
+> **Corrected by §57.** Everything above is right about a scene with *one* cloth
+> in it, which is the scene this was measured in. A second cloth registering
+> while the first is running spends its registration ticks in a world whose clock
+> is moving, so the world clock — however it counts — hands it a different gust
+> under the two systems. The gust now reads the asking cloth's own age and
+> `ClothWorld#time` keeps only the job below: telling a source that reads the
+> scene when to walk it.
+
+### The number
+
+```
+  200 steps, two 9-link strands in silk, a real fluid volume with a sheared
+  flow in it, an ambient gust of 1.5 m/s on a 0.7 s period, and the anchor
+  walked out of the volume partway through
+
+  differing bytes in ClothState's buffer, per step:   0
+  steps sampled per particle:                       104
+  steps sampled once for the cloth:                  96
+```
+
+Both of the sampler's paths ran, and the run is self-checked on that, because
+§40's own lesson is that a parity test over a branch that did not run is a
+parity test over nothing. The run also asserts the banner actually moved — a
+rope that hangs straight down under a gale would make every byte agree for the
+wrong reason.
+
+---
+
+## 51. The banner in the wake, and what a wake turns out not to be
+
+§17 asks M6 for "a playground with a banner in a simulated wake". `wind.html` is
+that, and it is simulated in the strong sense: a `FluidField`, a
+`FluidSimulator`, a `GlobalFluidEffector` in its prevailing-wind regime, and a
+solid post written into `FluidField#solid`. The banner reads it through the same
+`ClothFluidWind` and `cloth_sample_air` a scene would.
+
+M5 skipped a playground for a reason about the dev server — a `SharedArrayBuffer`
+needs a cross-origin isolated page (§44) — and that reason does not reach M6:
+this page drives `cloth_step` in process, like the solver and collision pages,
+and needs no shared memory at all.
+
+### The post's deficit is a third of the free stream
+
+```
+  driven at 9 m/s, 18 x 18 x 29 cells at 8 cm, measured at the banner
+
+  post present     6.00 m/s
+  post absent      8.69 m/s
+```
+
+That 31% is the incompressible projection's answer to a solid standing in a
+flow, and there is no authored falloff anywhere in it. It is also the whole of
+§10's argument in one number: nothing cloth-specific was written to produce it.
+
+### Turning the flow: the factor works, and the wake does not care
+
+```
+  the 16x16 silk banner, 500 settled steps, gust off
+
+  source     flow    mean relative flow    mean drag accel    mean facing
+  ambient      0°           9.00 m/s          43.24 m/s²         0.221
+  ambient     90°           9.00 m/s           0.08 m/s²         0.000
+  field        0°           7.25 m/s          34.00 m/s²         0.216
+  field       90°           5.56 m/s          33.83 m/s²         0.280
+```
+
+**In uniform air the factor is everything.** Turn the wind ninety degrees at the
+same speed and the banner is not merely less driven, it is *undriven* — 0.08 m/s²
+of aerodynamic acceleration against 43.24, a factor of five hundred. That is
+§10's flag-versus-rope claim, and it is the sharpest single result in M6.
+
+**In a wake it does nothing.** The factor reads 0.216 broadside and 0.280
+edge-on — slightly *higher* edge-on, which is noise around "no dependence at
+all". The reason is not a failure of the factor: a wake has velocity in every
+direction, so no orientation of a surface is edge-on to it, and `‖û − proj_T(û)‖`
+is correctly reporting that there is nothing to slice through.
+
+This is a correction to §10's intuition rather than to its design. §10 offers
+the factor as the thing that makes reading the fluid worth doing; the
+measurement says the factor's headline behaviour is a statement about *laminar*
+air, and that what reading the fluid actually buys is the half §10 stated more
+quietly — a wake is a place where the air is slower and turned, and no
+orientation escapes it.
+
+### What the wake is not: a shedding street
+
+```
+  the air a banner's width downstream of the post, over 4 settled seconds
+  "wobble" is the largest deviation from its own mean, m/s
+
+  cells   damping   confinement   speed    wobble   ms/step
+     18       0          0         3.11     0.002      5.0
+     18     0.2        0.6         3.07     0.001      5.2
+     26       0          0         7.29     0.005     15.5
+     26     0.2        0.6         6.29     0.232     16.0
+     34       0          0         6.77     0.031     34.7
+     34     0.2        0.6         5.79     0.000     37.0
+```
+
+At every resolution the page can afford, and with the simulator's damping and
+vorticity confinement at both ends of their useful range, the wake is a
+**steady** velocity deficit rather than a von Kármán street. The banner's own
+free corner moves 1.44 µm a step with the post present and 0.12 µm without — a
+factor of twelve, and both of them settled rather than fluttering.
+
+That is the fluid solver's answer at this scale and not the cloth's: resolving a
+shedding shear layer needs a grid whose step is 15 ms at 26 cells and 35 ms at
+34, against the 5 ms an 18-cell volume costs. It is recorded here rather than
+tuned away because the page says "a banner in a simulated wake" and a reader is
+entitled to know that the wake is steady.
+
+---
+
+## 52. The library, re-measured, and why no entry is re-sized
+
+§17 says to re-measure with `cloth_library_bench.mjs` and re-size anything that
+drifted outside. The bench gains a section that runs §33's own scenario — the
+reversing gust that folds the sheet, each entry's own self-collision flag — with
+and without §10's aerodynamic term.
+
+**And the first thing it measured is §42's warning, three times.** Three runs of
+the same bench on the same machine inside an hour, same code, no wind in any of
+these columns:
+
+```
+  the §17 workload's baseline row, "M0 rows only", 1,024p at 2x4
+
+  run A    3.490 ms      12 node processes, nothing else of this session running
+  run B    3.826 ms       8 node processes, this session driving a browser
+  run C    4.257 ms       9 node processes, this session running the test suite
+```
+
+Run B had *fewer* processes than run A and was slower anyway, because the four
+that had gone were idle and what run B was actually sharing the machine with was
+a Vite dev server and a browser pane. §42 said "check the process count first";
+M6's amendment is that a process count is a proxy for load and not a measure of
+it, and that the only quantity worth reading off this bench is the **paired
+ratio** inside one run.
+
+The size of what that does to the library, before wind is anywhere near it:
+
+```
+  §33's scenario, self-collision on, no wind — the same measurement in four places
+
+  entry      M4 §33    M5 §42    M6 run A    M6 run C
+  SILK        1.802     2.069      1.730       2.042
+  COTTON      1.802     2.002      1.742       1.905
+  DENIM       1.765     2.020      1.693       1.967
+  LEATHER     1.828     2.039      1.676       1.814
+  ROPE        0.129     0.133      0.123       0.134
+  CHAIN       0.183     0.215      0.186       0.208
+  HAIR        1.798     1.997      1.722       1.930
+```
+
+**Silk reads 2.042 ms in run C with no wind in it at all** — the same code M4
+measured at 1.802 and M6 measured at 1.730 forty minutes earlier. Anything a
+re-sizing decision took from that column would be a reading of the machine.
+
+### What the wind term costs, paired
+
+```
+  cloth_library_bench.mjs, §33's scenario, with and without the wind term
+  three runs, each paired inside itself
+
+  entry      drag     run A     run B     run C
+  SILK       0.45     +4.5%     +3.4%     -2.3%
+  COTTON     0.20     -0.5%     -0.1%     +0.5%
+  DENIM      0.08     +6.2%     +6.9%     +5.5%
+  LEATHER    0.05     +0.7%     +2.1%     +8.5%
+  ROPE       0.12     +1.0%     +9.3%     -1.1%
+  CHAIN      0.05     -2.7%     -1.1%     +0.3%
+  HAIR       0.30     +6.1%     +8.1%     +4.4%
+```
+
+Between −2.7% and +9.3%, and **not monotone in `drag`** — the entry with the most
+of it comes back negative twice and the entry with the least comes back at
++8.5%. That is what a column carrying both a code cost of one per cent (§49) and
+a *different cloth* should look like, and the second is the larger term: a
+garment blown out of its drape is not the garment beside it, which is §7's
+warning in its fourth setting.
+
+**No entry is re-sized**, and M6 has a measured reason to add to M5's. M5's was
+that the absolute column came off a busy machine. M6's is §49: with the physics
+held fixed so both sides simulate the same cloth, the whole aerodynamic term is
+**one per cent of a step** — an order of magnitude below the run-to-run spread of
+the thing that would decide a re-sizing, and two below the levers §17 prices.
+Re-sizing on that would bake noise into a shipped garment.
+
+§33's ordering stands entry for entry: the three entries that set
+`ClothDynamicsFlags.SelfCollision` are still the tightest, the chains still find
+no pairs at all, and leather still pays the most for the fewest.
+
+**What is true, and is the thing to watch**, is that those three entries are now
+within a few per cent of 2 ms on this machine with wind live — and were already
+within a few per cent of it *without*. `MEASUREMENTS.md` §42's closing advice
+stands and M6 adds one clause to it: re-measure the absolute column on a quiet
+machine, take a paired reading even then, and if the answer is that the library
+is genuinely at its ceiling, the lever to spend is the one §17 prices rather than
+the feature that happened to be measured last.
+
+---
+
+# Cloth — post-M6 measurements
+
+> Written 2026-09-13, against the fixes listed in §17's post-M6 entry.
+> Everything above this line is M0's through M6's and is unchanged, except where
+> a section below is named *inside* the one it corrects.
+>
+> The scripts are the ones the milestones already carry; where a number here
+> came from something else, the section says what.
+
+---
+
+## 53. A cloth resting on a collider never slept, and the speed was not the thing to read
+
+§7 P5's gate is free-hanging chains, and every library fabric passes it. Put the
+same chain on a floor and four of the seven never sleep at all.
+
+```
+  8-link rope, 10 cm links, 2 % of lateral lean, dropped for 2,400 steps
+  "-1" is "still awake when the run ended"
+
+  entry      free    floor mu=0    floor mu=0.5    sphere mu=0
+  SILK        386        1029             398             631
+  COTTON      236          -1              -1             362
+  DENIM       101         198             164             220
+  LEATHER     139         192              -1            2312
+  ROPE        283         911              -1             427
+  CHAIN       144         419             245             293
+  HAIR        143         271            2129             280
+```
+
+A cloth that sleeps in 283 steps hanging free and never sleeps lying on the
+ground is not a cloth that is behaving differently; it is a **test** that is
+reading the wrong quantity.
+
+### What is actually happening
+
+Traced on cotton on a frictionless floor, six hundred steps after it has come to
+rest, the configuration is a clean **period-4 limit cycle**:
+
+```
+  step   peak speed   peak travel   contact penalty, four live slots
+     0    6.806e-3      5.801e-5     628.4  1544.9  1553.7  561.1
+     1    9.568e-3      5.328e-5     628.9  1545.1  1554.0  561.6
+     2    1.443e-2      6.116e-5     629.3  1545.7  1554.3  562.1
+     3    1.229e-2      1.061e-4     629.8  1546.3  1554.8  562.6
+     4    6.806e-3      5.801e-5     630.2  1546.6  1555.3  563.2   <- repeats
+```
+
+The cloth travels **a tenth of a millimetre a step**, which nobody can see, at a
+peak particle speed of **1.5e-2 m/s**, which is **eighteen times** the sleep
+threshold of 8.0e-4 m/s. Both numbers are correct and they disagree about
+whether the cloth is at rest, because a limit cycle has bounded displacement and
+un-bounded-below speed.
+
+The penalty column says where the cycle gets its energy: it climbs
+monotonically — `k + β·|C|` in `cloth_contact_dual_update` — and **never comes
+back down**, because `γ = 1` and `clamp_band`'s floor is the contact's own
+`0.25·(m/h²)`. Two of the four slots are already at the ceiling of `8·(m/h²)`,
+which is exactly the ratio §6 measured a row adding energy above.
+
+### Two candidates, and only the second survives
+
+The *friction re-anchor* — `cloth_contact_row.js` moving the anchor to the
+particle whenever the row's force clamps out — is **not** it, and no experiment
+is needed to say so: cotton fails on a floor whose friction is **zero**, where
+`friction <= 0` zeroes the friction multiplier before the anchor is ever read.
+It is ruled out by the μ = 0 column of the table above.
+
+The *penalty ramp* is it, and the fix for it is not in scope: `γ` is
+unmeasured-by-decision (§5.2), a `γ < 1` would have to be re-measured against
+every hard row in the system, and the motion it sustains is a tenth of a
+millimetre. **The defect worth fixing is that the sleep test disagrees with the
+plan.** §7 P5 has said "maximum particle displacement over a window" since M0 and
+M1 implemented an instantaneous speed.
+
+### The rule, and the threshold
+
+Displacement from an anchor taken when the window opened, re-anchored the moment
+any particle leaves the threshold; `CLOTH_SLEEP_STEPS` consecutive steps inside
+it is sleep. Swept over the ratio, every entry × every scene, "steps to sleep":
+
+```
+  ratio of reach     worst    where                      any awake at 2,400?
+  1e-3 (as speed)      -1     COTTON on a floor                  4 of 28
+  1e-3                872     SILK on a frictionless floor            no
+  5e-4                961     SILK on a frictionless floor            no
+  2e-4                965     SILK on a frictionless floor            no
+  1e-4               1773     COTTON on a frictionless floor          no
+```
+
+**5e-4 is the value**, and it is chosen to be *no looser* than the speed test it
+replaces rather than to be the fastest: over a 30-step window at the engine's
+60 Hz fixed step, half a thousandth of a reach per window is the same millimetre
+a second per step that `CLOTH_SLEEP_SPEED_RATIO` named. 1e-3 would sleep sooner
+and would be a real relaxation of the gate; 1e-4 costs nearly twice the worst
+case and buys nothing visible.
+
+With it in place, the table at the top of this section reads:
+
+```
+  entry      free    floor mu=0    floor mu=0.5    sphere mu=0
+  SILK        325         961             309             573
+  COTTON      180         361             277             325
+  DENIM        92         195             128             194
+  LEATHER     127         175             109             151
+  ROPE        235         840             941             393
+  CHAIN       143         425             201             261
+  HAIR        132         260             177             246
+```
+
+Nothing is awake, the worst case is 961 steps and the free-hanging column has
+not got worse — it is uniformly *faster*, because a chain settling through a
+swing covers less ground per window than its instantaneous speed suggested.
+
+### What it costs
+
+One compare-only pass over the particle positions per cloth per step, on the
+main thread, in `ClothWorld#finish`, with no square root — the displacements are
+compared squared — and one `Float32Array` of `3·particle_count` per instance. It
+does not enter the step, so `cloth_library_bench.mjs` cannot see it and does not:
+the library column is unchanged across this commit.
+
+*Reproduce:* `cloth_pathology.spec.js`, the two P5 sleep tests. The table above
+is the same scenario driven from a script rather than through vitest.
+
+---
+
+## 54. A collider that does not move is not a collider a cloth cannot hit
+
+§20 measured the discovery reach missing a **moving collider** and fixed it by
+folding the collider's travel into the reach. The mirror case was argued away in
+the same docblock rather than measured: a fixed margin of `2·(thickness +
+inflation)` "covers half a metre a second of approach", and anything faster is
+"one the velocity clamp of §7 P1 is already the bound on".
+
+**It is not.** That clamp is `4 · shortest_row · substeps · iterations / dt`,
+which for a garment's rows at 2 × 4 is about **154 m/s** — three orders of
+magnitude above the half metre a second the margin actually covers. Everything
+between is uncovered, and a character walks through it.
+
+### The reproduction
+
+One particle at 8 mm thickness, thrown along +X at a **static** 3 cm capsule,
+no gravity so that nothing but the contact can change its velocity, 2 substeps ×
+4 iterations. "Warned" is whether a row existed by the time the particle was
+first sampled inside the contact offset; "far side" is whether it ended past the
+capsule rather than bounced off it.
+
+```
+              with |v|·dt in the reach          as M2 shipped
+  speed      warned    far side    x_final     warned    far side    x_final
+    1 m/s      yes         no       -0.672        no         no       -1.464
+    2          yes         no       -1.268        no         no       -2.058
+    3          yes         no       -1.371        no        YES      +13.315
+    4          yes         no       -2.220        no        YES      +14.294
+    5          yes         no       -0.532        no        YES      +25.516
+    6          yes         no       -1.287        no        YES      +19.800
+    8          yes        YES      +26.285        —         YES      +26.467
+   10          yes        YES      +31.285        no        YES      +33.133
+```
+
+Two separate readings. **`warned` is never true without the term, at any
+speed** — the first row a particle ever gets is the one that finds it already
+inside, which is the opposite of what a speculative contact is for. And from
+**3 m/s** the particle is not stopped at all: the row the next step finally
+creates is evaluated where the particle now is, which is on the far side, and
+its normal points away from the collider, so the first thing the contact does is
+push it the rest of the way out. §7 P4(a) chose orientation over history
+deliberately and this is the price of that choice when discovery is late.
+
+### What the fix does and does not buy
+
+Swept, in half-metre steps from 1 to 12 m/s, whether the particle is stopped:
+
+```
+  substeps     stopped up to      through from
+      2            6.0 m/s          6.5 m/s
+      4           12.0 m/s          — nothing in range
+```
+
+A clean threshold, and it is `substeps` rather than discovery: a row that exists
+is still evaluated at substep positions, so a particle that crosses a whole
+collider inside one substep has a row that never sees it touching. §7 P3 has
+always said "more substeps in the affected `ClothDynamics`"; this is the first
+measurement of where that lands. Discovery being right is necessary and not
+sufficient, and the two are now separable — unswept at four substeps still
+tunnels at 8 m/s.
+
+### What it costs
+
+Interleaved A/B in one process, alternating which side runs first, `dt` against
+zero — zero being exactly the reach M2 shipped:
+
+```
+  1,024 particles, one ground plane, best of eight interleaved pairs
+
+  approach            with travel     as M2 shipped      ratio
+  at rest                45.16 ns         45.35 ns       0.996
+  falling at 3 m/s       92.32 ns         55.88 ns       1.652
+```
+
+**At rest it is free** — the square root disappears into the measurement's own
+noise. Moving, it is 36 ns a particle a step, and that is not the arithmetic: it
+is the records a wider reach lets past the AABB reject, which is the feature
+rather than its overhead. Against the 4.5 ms §23 measures for this workload it
+is **0.8 % of a step**, and `cloth_library_bench.mjs` cannot see it at all,
+because the bench drives `cloth_step` with no collider table — the library
+column is unchanged across this commit, which is the regression check rather
+than the measurement.
+
+### And it moved a sleep number, which is a coupling worth naming
+
+`cloth_contact_dual_update` ramps the penalty by `β·|C|` on the **unsigned**
+residual, so a row that is not touching ramps too. That was nearly invisible
+while rows only appeared within 16 mm; with the reach carrying a falling cloth's
+travel, rows now appear tens of centimetres out and reach `k_max` long before
+contact, and `γ = 1` never brings them down again. §53's table moves with it:
+most entries settle *sooner*, and hair on a floor with friction goes from 177
+steps to **2,202** — a creep at 1.6 times the sleep window's threshold rather
+than a cloth that has stopped.
+
+Making the ramp one-sided is the obvious repair and **the measurement says not
+to**:
+
+```
+  stopped up to, half-metre steps from 1 to 12 m/s
+
+                        2 substeps            4 substeps
+  ramp on |C|             6.0 m/s              12.0 m/s, no holes
+  ramp on max(C, 0)       6.0 m/s, hole at 5    9.5 m/s, holes at 10–11.5
+```
+
+The pre-stiffening of a speculative row is what gives a fast arrival something
+solid to hit; removing it trades a visible failure — cloth through a character —
+for an invisible one — a hair rope taking thirty-seven seconds to stop creeping
+instead of three. So the ramp is left alone and the coupling is recorded in §18.
+
+---
+
+## 55. A collider arriving and a collider retiring, and what each one was not told
+
+Two defects at the two ends of a collider's life, both of them a *set* question
+answered with a *pose*.
+
+### Arriving
+
+§7 P5's wake test compares each overlapping collider's previous pose with its
+current one. `ClothColliderSystem#link` calls `placePose`, which sets both — on
+purpose, so a new collider's first step sweeps nothing, because it did not move,
+it appeared. The two facts together say a collider that appears inside a
+sleeping cloth has not moved.
+
+```
+  6-link rope, 10 cm links, left to settle: asleep at step 236
+  a sphere of radius 0.2 spawned around its lower half, never moved
+
+  300 steps later:   asleep      links inside the sphere
+  before             yes         4 of 6
+  after              no          0 of 6
+```
+
+§1's first commitment names this case in its own words, and the gate for it was
+`cloth_collision.spec.js`'s "a collider that appeared but has not moved does not
+wake anything" — a test that was passing because the thing it asserted was the
+defect.
+
+The fix is the **handle set**: `ClothInstance` keeps the handles the last step
+gathered, and the wake test compares this step's against them before it compares
+poses. One integer per record, on a path that was already doing a broadphase
+query, against a step three orders of magnitude more expensive.
+
+Two details it turns on. The wake test's query has to use the **same reach** the
+last step's gather used, or it is comparing the answers to two different
+questions and wakes on the margin rather than on the world; `gather_reach` is
+recorded beside the set. And a `PlaneShape3D`'s AABB is unbounded, so a plane is
+in *every* cloth's set the moment it exists: adding one anywhere wakes every
+sleeping cloth once, which costs the thirty steps it takes to find nothing and
+go back to sleep. That is stated rather than worked around — a bounded collider
+five metres away does not wake anything, and the spec pins both.
+
+### Retiring
+
+`ClothColliderIndex#add` popped a retired slot immediately. A handle is a slot
+index, and `cloth_contact_find` matches warm-started contacts on the handle
+alone — so a collider removed and another added within one tick are, to every
+cloth in the scene, the same collider.
+
+```
+  a rope settled on a floor for 400 steps, then in one step:
+  remove the floor, add a different collider
+
+  the floor's handle:         0
+  the replacement's handle:   0        <- the cloth cannot tell
+  the particle's multiplier:  0.0981 before, 0.0970 after
+  the friction anchor:        carried, still in the old floor's frame
+```
+
+Both index docblocks claimed the opposite — "any cloth holding warm-started
+contacts against it drops them on its next step" — and the claim is true only if
+the handle is *absent* for a step, which nothing made it. `remove` now retires
+into a list `advance` drains one step later. The cost is one slot held back for
+one step; the alternative, a generation word beside the handle, is the same
+guarantee threaded through the per-cloth table, the key array and the warm-start
+scan.
+
+### They compose, and that is not a coincidence
+
+The deferral makes the handle absent for a step; the set comparison is what makes
+a **sleeping** cloth notice that absence, wake, and clear its slots before
+anything else can take the number. Either alone leaves a case open: without the
+deferral the slot is reused before the cloth steps, and without the set test a
+sleeping cloth never steps at all.
+
+*Reproduce:* `cloth_collision.spec.js` — the far collider, the overlapping
+collider, the leaving collider and the replaced collider — and
+`ClothColliderIndex.spec.js`'s retirement test.
+
+---
+
+## 56. The parity gate had one cloth in it, and a second cloth is a different gate
+
+§40 made the gate structural: one parameter block, one `cloth_step_instance`,
+neither system computing a number of its own. Every scene it was measured on has
+exactly one cloth in it, and two of the three things that can differ between the
+systems only exist when there are two.
+
+### A nested pair
+
+`ClothSystem` ran advance, step and finish **per cloth**, walking
+`ClothWorld#instances` in hierarchy-depth order — a sort that existed precisely
+so a nested cloth would advance against an anchor the cloth above it had already
+written this step. `WorkerClothSystem` cannot do that: the step it writes back at
+the top of a tick happened on another thread during the last one, so its `apply`
+writes T−1 and its `collect` then advances everything for T.
+
+```
+  a 4-link rope hung from link 3 of a 6-link rope, no wind, 120 steps
+
+  outer cloth:  identical, every step
+  inner cloth:  differs at step 1, byte 24
+```
+
+Byte 24 is inside the particle positions, which is the honest place for it: the
+child is simulating against a different anchor, not reporting a different number
+about the same one.
+
+**Three loops on both sides** — advance every cloth, then step every cloth, then
+finish every cloth — and the depth sort has nothing left to decide, so it is
+gone. What a nested cloth reads is its parent one fixed step stale, which is the
+same trade §4.1 already makes for an anchor and measures at a few centimetres.
+
+**That was necessary and not sufficient**, and the second half is more
+interesting than the first. `cloth_write_back` composed every node's world pose
+as `anchor ⊗ local particle position`, reading the anchor from the live
+`Transform64`. For `ClothSystem` that is the anchor the step ran on, because the
+step happened between the two. For the worker it is not: it writes step T−1's
+particles against tick T's anchor.
+
+```
+  the inner cloth's anchor, as each system's write-back left it
+
+  step    reference       worker (before)    worker (after)
+     2    0.038945        0.069849           0.038945
+     3    0.038341        0.069079           0.038341
+     4    0.037680        0.068171           0.037680
+```
+
+The worker's column before the fix is the parent's *current* anchor plus a
+one-step-old shape — a pose that describes neither step. Nothing rendered can
+tell, because the attachment cascade re-derives position from the anchor and the
+local transforms either way (§4.1); a nested cloth reading that pose as its own
+anchor can. The write-back now uses `ClothInstance#anchor_translation` and
+`#anchor_rotation`, which `advance` already caches and which the collider gather
+already reads for the same reason.
+
+### What the gate is now
+
+`WorkerClothSystem.spec.js` compares the whole buffer of **both** cloths at every
+one of 120 steps, with the parent's anchor walked through a turn so the child has
+something to be wrong about, and self-checks that the child actually moved.
+
+---
+
+## 57. A world clock is right for the first cloth in a scene and wrong for the second
+
+§50 put the wind clock on steps rather than ticks so that a cloth's first step
+got the same weather under both systems. It did, and the scene it was measured
+in had one cloth.
+
+With cloth A already running, cloth B's registration takes k ticks — and A is
+advanced on every one of them, so the world clock moves while B waits. B
+therefore reaches **its own first step** at a different clock value under the two
+systems:
+
+```
+  A primed and running, B spawned, a two-tick delivery for B's registration
+
+  B's own step 1:   reference clock 0.1000 s
+                    worker clock    0.1333 s
+
+  differing bytes in B's buffer:  step 1, byte 0, and every step after
+  the same run with gust = 0:     none
+```
+
+The `gust = 0` row is what identifies the cause. Latency is not the problem —
+§39 already made an unacknowledged cloth neither stepped nor advanced, so B's
+step *sequence* is identical — the problem is that a shared clock is not a
+property of the cloth asking.
+
+**The clock is now the asking cloth's own age**, `ClothInstance#age`, seconds
+*this instance* has stepped, handed to `AbstractClothWind#sample` per call. The
+source holds no clock: `ClothAmbientWind#__time` is gone and `begin` keeps only
+the job it can do correctly, which is telling a source that reads the scene —
+`ClothFluidWind`'s field walk — when to walk it. `ClothWorld#time` stays for
+exactly that.
+
+*What it changes behaviourally:* two garments spawned a second apart are a second
+apart in the gust rather than in phase with it. For a bounded sum of three
+sinusoids with no spatial structure (§48) that is not a weaker model, it is the
+same model sampled at a different phase — and a scene in which every banner
+gusts in lockstep was the odder of the two pictures.
+
+*What it does not change:* a fluid field's velocities are a snapshot of the tick,
+not a function of a clock, so `ClothFluidWind` passes the age through to its
+ambient fallback and ignores it otherwise.
+
+*Reproduce:* `WorkerClothSystem.spec.js`, the staggered-spawn parity test.
+
+---
+
+## 58. The library, re-measured, and what the bench can and cannot see
+
+`cloth_library_bench.mjs`, before this pass and after it, on the same machine
+within the hour:
+
+```
+  entry     budget     before      after     delta
+  SILK      2x4       1.561 ms    1.649 ms    +5.6%
+  COTTON    2x4       1.655 ms    1.546 ms    -6.6%
+  DENIM     2x2       1.261 ms    1.343 ms    +6.5%
+  LEATHER   2x2       1.346 ms    1.246 ms    -7.4%
+  ROPE      2x4       0.043 ms    0.042 ms    -2.3%
+  CHAIN     2x6       0.063 ms    0.063 ms    +0.0%
+  HAIR      2x4       1.537 ms    1.702 ms   +10.7%
+```
+
+**Both signs, no pattern, ±11%** — which is §42's and §52's lesson arriving a
+third time, and here it is not merely a disclaimer: **the bench cannot see any
+of this pass's solver work**, and reading the code is what says so rather than
+reading the column. It builds a `ClothState` and calls `cloth_step` with a null
+collider table, so `cloth_contact_find` — the one function §54 changed — never
+runs; and it never constructs a `ClothWorld`, so the sleep window, the wake test,
+the write-back's anchor and the wind clock are all outside it. The column is a
+**regression check** on the paths this pass did not touch, and it passes: no
+entry moves outside the spread three runs of the unchanged bench already produce
+(§52 put the §17 baseline row at 3.49, 3.83 and 4.26 ms within an hour).
+
+What *is* priced, and is priced by a paired measurement rather than by this
+column, is §54's discovery reach: free at rest, 1.65× on the discovery pass for a
+cloth falling at 3 m/s, which is 0.8% of a step. §53's sleep window is one
+compare-only pass over positions on the main thread, in `ClothWorld#finish`,
+which the bench also cannot see and which sits beside a write-back that already
+walks every node.
+
+**No entry is re-sized.** Three passes have now said the same thing about this
+column and the advice does not change: re-measure it on a quiet machine, take a
+paired reading even then, and check the process count first.
+
+---
+
+## 59. The broadphase was a scan, and the margin it scanned with was metres wide
+
+Two defects, found from one downstream console line: a cape overlapping **80**
+cloth colliders against a per-cloth table of 64. Both are about the gather, and
+only one of them is the one the warning names.
+
+### The margin
+
+`cloth_gather_colliders` fattened the cloth's particle bounds by the §7 P1
+velocity clamp read as a distance — `4 · shortest_row · substeps · iterations`.
+That is not a distance the cloth can travel; it is a bound on what the solver
+could undo. Over the shipped library at 60 Hz:
+
+```
+  entry       sub x it   row 2cm    row 4cm    row 8cm
+  SILK        2 x 4      0.64 m     1.28 m     2.56 m
+  COTTON      2 x 4      0.64 m     1.28 m     2.56 m
+  DENIM       2 x 2      0.32 m     0.64 m     1.28 m
+  CHAIN       2 x 6      0.96 m     1.92 m     3.84 m
+```
+
+The fattening is routinely larger than the garment. `cloth_contact_find` had
+already reached this conclusion for itself at §54 — it calls the same clamp
+"about 154 m/s … three orders of magnitude" past the speeds that matter and
+reaches with `|v_i|·dt` instead — and the gather was never brought along.
+
+Being enormous also hid what it was **missing**. The narrowphase reaches
+`(radius + inflation) · (1 + CLOTH_CONTACT_MARGIN) + collider travel +
+|v_i|·dt`; the gather's fixed term was `2 · contact_radius` and nothing else, so
+a wide enough `ClothCollider#inflation` was a contact the gather never handed
+over. `cloth_gather_reach` is now that expression, maximised over the records
+the gather cannot yet know it will get — which is what `ClothColliderIndex`'s
+`max_inflation` and `max_collider_travel` are for. It is a **bound** and not an
+estimate: the gather reads velocity before the step and `cloth_contact_find`
+reads it after `damp`, which only ever scales down.
+
+Measured on the rope of §20 — eight 10 cm links at 2 × 4, five colliders placed
+2 m away and one against the tail:
+
+```
+  gather margin, hanging       3.2006 m  ->  0.0209 m
+  colliders gathered                  6  ->  1
+```
+
+The 3.2006 m does not move when the rope is thrown at 9 m/s. The new one does,
+which is the entire point of it.
+
+### The scan
+
+`ClothColliderIndex#query` was a linear scan over every live record, run once
+per cloth per step — `clothes × colliders`. The docblock defended it on two
+grounds and both were wrong. The set size ("twenty or so, and never the whole
+world") was §41's count of colliders overlapping **one garment**, which is a
+narrowphase input being used to size a world-wide structure. The churn argument
+("a tree over twenty leaves that all move every frame costs more to keep than to
+skip") is answered by `PhysicsSystem`, which keeps two dynamic BVHs over bodies
+that all move every frame and pays for it with `compute_fat_world_aabb`'s refit
+skip. The third ground, `PlaneShape3D`'s unbounded AABB, is real and is not a
+reason for anything: the half-space is constructed in exactly one place in this
+engine — the JSON shape adapter — and no scene builds one, so the planes sit in
+a list beside the tree that is empty in every scene that has ever run.
+
+Colliders drifting 0.4 to 2 mm a step, every cloth gathering every step, paired
+runs with the order alternated:
+
+```
+  colliders  cloths   scan pose  scan gather   tree pose  tree gather   gather
+      64        8       0.012        0.001        0.010        0.004     0.4x
+     256       16       0.047        0.009        0.046        0.011     0.8x
+    1024       32       0.207        0.073        0.205        0.029     2.5x
+    4096       64       0.961        1.090        0.912        0.076    14.4x
+   16384      128       4.684        9.930        4.293        0.205    48.5x
+```
+
+`pose` is `advance` plus a `setPose` per collider, which is O(colliders) once a
+step in both and is unchanged — tree maintenance is inside the noise. `gather`
+is the `clothes × colliders` term, and it is gone. Below a few hundred
+colliders the scan is very slightly ahead, on numbers too small to matter.
+
+### Two things the tree got wrong first, both measured
+
+**A leaf inserted before its pose homes at the origin.** `add` built the leaf
+and `link` placed it immediately afterwards — but `insert_leaf` picks a sibling
+from where the box *is*, and `node_move_aabb` refits ancestors without ever
+asking whether the leaf still belongs under them. So a scene added-then-placed
+built its whole tree out of one coincident point and never rebuilt it: a root 21
+deep whose every branch overlapped every query, **128 gathers at 128 ms against
+0.2 ms** for the same leaves inserted at their real positions. The leaf is now
+created on the first `setPose`, and a leaf that escapes its slack is removed and
+re-inserted rather than refit.
+
+**A `Float32` leaf over a `Float64` world loses a bound.** The tree's nodes are
+`Float32` and the table is `Float64` precisely because a world coordinate can be
+far from the origin. One `Float32` ulp is a proportion of the magnitude — a
+millimetre at 10 km, a whole metre at 10,000 km — so a box widened by a fixed
+5 cm and then stored can come back **45 cm inside its own record**, and a leaf
+smaller than its record is a collider the tree silently stops answering with.
+The slack now carries a relative term of two ulps as well as the constant. It
+fails without it, and only for a cloth grazing a face: a query box as wide as
+the collider survives losing one side, which is why the first spec written for
+this passed and pinned nothing.