@woosh/meep-engine 3.24.0 → 3.26.0

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

@@ -1,7 +1,8 @@
 # Cloth — Design
 
-> Design document. Written 2026-09-10; **M0, M1, M2 and M3's rigged path are implemented**, and
-> every place they contradicted it has been corrected in place with the measurement named beside it.
+> Design document. Written 2026-09-10; **M0 through M5 are implemented** — the solver, chains,
+> collision, the rigged path, self-collision and the worker — and every place they contradicted it has
+> been corrected in place with the measurement named beside it.
 > §17 says what is done and what is not; `MEASUREMENTS.md` is the evidence.
 >
 > Scope: a cloth and soft-chain simulator that lives inside `engine/physics`, collides against the
@@ -133,12 +134,19 @@ documented as *not* serialised because shapes are shared assets the pipeline wir
 `ParticleEffect` holds a `ParticleLayout` and a `ParticleProgram` the same way. `ClothRig` serialises
 the proxy's identity and the skin ordinal, and the asset pipeline resolves the rest.
 
-**The proxy addresses joints by index, never by name.** A joint is a `Node3D` inside a
-`SceneBundleInstance`, not an entity, so an `EntityReference` to one is impossible by construction —
-and reintroducing strings at runtime to work around that would be the wrong answer. Instead the
-binding is resolved **once, at import**: the builder has `SceneBundleInstance#nodes` (the by-name map
-the engine keeps because sockets and effect anchors are authored as bone names) and turns names into
-integer indices into `Skin#joints`. The runtime component holds integers.
+**The proxy addresses joints by index, never by name.** The binding is resolved **once, at import**:
+the builder turns authored bone names into integer indices into `Skin#joints`, and the runtime
+component holds integers. Reintroducing strings at runtime would be the wrong answer.
+
+**A joint is an entity, and this paragraph used to say it could not be.** It said "a joint is a
+`Node3D` inside a `SceneBundleInstance`, not an entity, so an `EntityReference` to one is impossible
+by construction", and the engine moved: a model is spawned by `prefab_instantiate`, its joints *are*
+entities, each carrying a `TransformAttachment` holding its offset from its parent joint, and that
+attachment is what `cloth_write_back_rig` writes. Names are resolved through `Prefab`/`PrefabInstance`
+rather than through `SceneBundleInstance#nodes`. The *conclusion* is unchanged and is now better
+supported — indices into `Skin#joints` are stable across respawns where entity ids are not, so the
+proxy still holds integers — but it is a choice rather than an impossibility. §11.2 and §13 carried
+the same description.
 
 ### 3.3 `ClothDynamics`
 
@@ -155,7 +163,7 @@ export class ClothDynamics {
     drag = 0.1;         // 0..1 — aerodynamic coupling to the air (§10)
     substeps = 2;       // solver budget
     iterations = 4;     // solver budget
-    flags = 0;          // ClothDynamicsFlags.SelfCollision, ...
+    flags = ClothDynamicsFlags.StrainLimit;   // | SelfCollision, ...
 }
 ```
 
@@ -271,7 +279,8 @@ engine/physics/cloth/
     cloth_dynamics_map.js           normalised coordinates → row parameters; every constant measured
     ClothCollider.js                component: the RigidBody-analogue for collision
     ClothColliderFlags.js
-    ClothSystem.js                  main-thread system: gather, step, write back
+    ClothWorld.js                   every cloth in a scene, and everything that is not arithmetic
+    ClothSystem.js                  main-thread system: a ClothWorld stepped inline
     ClothInstance.js                one live cloth: the binding between a subtree and a ClothState
     cloth_seed_subtree.js           §11.1's walk: entities → node_parent + animated_position
     cloth_seed_rig.js               §11.2's proxy: joints → node_parent + animated_position
@@ -280,14 +289,14 @@ engine/physics/cloth/
     cloth_write_back.js             that pose → Transform64 + TransformAttachment
     cloth_write_back_rig.js         that pose → Node3D.transform_local
     cloth_gather_colliders.js       the index's overlapping records, in the cloth's own frame
-    WorkerClothSystem.js            drop-in worker variant (WorkerSystem subclass)
-    ClothWorkerCore.js
-    cloth.worker.js
-    makeClothWorker.js
-    cloth_worker_protocol.js
-    ClothSerializationAdapter.js
-    ClothRigSerializationAdapter.js
-    ClothColliderSerializationAdapter.js
+    WorkerClothSystem.js            drop-in worker variant: the same ClothWorld, stepped over there
+    ClothWorkerCore.js              worker side: a ClothState view per registered cloth
+    cloth.worker.js                 the entry point, a real module worker
+    makeClothWorker.js              the spawn expression, isolated because it needs import.meta
+    cloth_worker_protocol.js        the command region: a count, then a block per cloth
+    ClothSerializationAdapter.js    the component + its ClothDynamics, by value
+    ClothColliderSerializationAdapter.js   five authored scalars, the same way
+    ClothRigSerializationAdapter.js NOT BUILT — §3.2's asset identity, and the proxy codec
   collider/
     ClothColliderIndex.js           the index of live cloth colliders + their swept AABBs
     ClothColliderRecord.js          the packed layout: kind, params, both poses, bounds, interpolated pose
@@ -295,10 +304,17 @@ engine/physics/cloth/
     cloth_collider_pack.js          AbstractShape3D → packed record
     cloth_collider_bounds.js        the swept AABB, shared by the index and each cloth's own table
     cloth_collider_sdf.js           pose interpolation, localisation, and the field dispatch
+  wind/
+    AbstractClothWind.js            §10's one interface: sample the air, and say whether it varies
+    ClothAmbientWind.js             a constant plus a band-limited gust — the air where no field is
+    ClothFluidWind.js               every live FluidComponent, with the ambient underneath it
+    cloth_sample_air.js             the air into the cloth's own frame, on the main thread
   solver/
     ClothState.js                   SoA particle + topology + constraint storage over one buffer
+    cloth_step_instance.js          one cloth, one step, over nothing but memory — what crosses
     cloth_step.js                   the fixed step: predict, warm start, iterate, dual update, integrate
     cloth_solve_vertex.js           the per-vertex 3x3 block update
+    cloth_wind_accelerate.js        §10's aerodynamic term, and the factor that makes a flag a flag
     constraint/                     one module per row type (§6)
     cloth_color_particles.js        graph colouring of the particle graph
     constraint/cloth_leash_row.js   §6's slack row and its tether row, which are one row model
@@ -340,10 +356,19 @@ Two systems:
 - **`ClothSystem`** owns the simulation. Per fixed step: refresh the animated targets, gather the
   overlapping colliders from the index, step, write back.
 
-Cloth runs at the fixed rate and is interpolated for display, exactly as `PhysicsSystem` does — the
-same producer/`__interp_restore` contract, so a cloth-driven `Transform64` is authoritative during the
-fixed pass and interpolated outside it. Reusing the existing contract rather than inventing a second
-one is what keeps a cloth-driven bone from fighting an animation-driven one.
+  **M5 note: it owns it jointly with `WorkerClothSystem`, and "two systems" is now three.** The two
+  are interchangeable — same components, same declared access, same position in the derived order —
+  and they share a `ClothWorld`, which is the registry and every phase of a step that is not
+  arithmetic. `ClothSystem` calls `cloth_step_instance` between the two halves; `WorkerClothSystem`
+  puts a thread there. §12 has why that is what makes the bit-parity gate structural.
+
+Cloth runs at the fixed rate and its poses are **held** between ticks rather than interpolated, which
+on a display faster than the fixed step is visible and is not wrong. The first draft of this paragraph
+said cloth reuses `PhysicsSystem`'s producer/`__interp_restore` contract; M5 measured that it cannot —
+that contract is entity-keyed and a rigged garment's joints are not entities — and §13.1 and §18 carry
+what the cloth-shaped version would be and what it would cost. What keeps a cloth-driven bone from
+fighting an animation-driven one is not interpolation but `TransformAuthority`, which `cloth_seed_rig`
+claims (§11.2, `MEASUREMENTS.md` §25).
 
 ### 4.1 Ordering, and why the answer is not to be ordered
 
@@ -502,10 +527,22 @@ are in `MEASUREMENTS.md`; the corrections are folded into the listing above and
    it has no effect at all. The ramp exists for **transient** rows, a contact that should arrive soft
    rather than shock the mesh on its first frame, and M0 has none. M2 has to measure it.
 
-Chosen: **α = 0.25, γ = 1, β = 1e5 (unexercised), k_min = k_max = 8·(m/h²)**. γ sits at 1 because its
-second job — decaying the penalty — has nothing to do while the band is a single point, so the whole
-decay lives in α, whose only job is the multiplier. When M2's contacts make the band real, γ becomes
-live and has to be re-measured.
+Chosen at M0: **α = 0.25, γ = 1, β = 1e5 (unexercised), k_min = k_max = 8·(m/h²)**. γ sits at 1
+because its second job — decaying the penalty — has nothing to do while the band is a single point, so
+the whole decay lives in α, whose only job is the multiplier.
+
+**M2 made the band real and the line above is out of date in three places.** `β` is **1e3**, not 1e5:
+M2's contacts are the first transient rows in the system and the ramp is finally live, and both ends
+of the range measured worse than the middle — no ramp at all settles at 1.95 J of residual kinetic
+energy against 0.12 J at 1e3, a fast ramp gives up most of what the low floor bought
+(`MEASUREMENTS.md` §17, and `cloth_solver_constants.js`'s own docblock carries the argument). The band
+is no longer a single point for a **contact**: `CLOTH_CONTACT_K_MIN_RATIO = 0.25` is its floor,
+against a ceiling of `8·(m/h²)` — a margin decision in the middle of a flat region, with two decades
+of ramp above it. And `γ` **is still 1, and was never re-measured**: this paragraph said it would be
+"when M2's contacts make the band real", M2 made the band real, and the sweep was not run. That is now
+a decision rather than an omission — nothing measured since has asked for a decaying penalty, and the
+one place it would help is recorded in §18 as a coupling rather than as a bug — but it is an
+**unmeasured** constant and the only one left in the set, so it is named here as one.
 
 **Adaptive initialisation** is VBD's: seed the iteration at `x + h·v + h²·ã` where `ã` interpolates
 between zero and full external acceleration according to whether the previous step looked like free
@@ -721,8 +758,16 @@ what the fabric row does unaided and it is simply inert.
 So **`stretch` is the weakest field in §3.3's parameter set**, and the honest statement is that at low
 budgets the bound belongs to the budget rather than to the fabric. The row is worth its 13–15% of a
 garment frame where the residual is visible and is not worth it where the residual is already around
-one per cent, which is why it is a flag — `ClothDynamicsFlags.StrainLimit` — rather than always on,
-and why the library entries at 2×4 clear it. `MEASUREMENTS.md` §11.
+one per cent, which is why it is a flag — `ClothDynamicsFlags.StrainLimit` — rather than always on.
+
+**And the flag defaults to *set*, which is the opposite of what §3.3 used to show.** `ClothDynamics`
+starts at `ClothDynamicsFlags.StrainLimit`, so a garment that says nothing gets the row. Of the four
+library entries at 2×4, three clear it — silk, cotton and hair, and they clear it by writing
+`flags: ClothDynamicsFlags.SelfCollision`, which *replaces* the default rather than adding to it — and
+**`CLOTH_ROPE` does not**: it sets no flags at all, so it keeps the default and runs the strain-limit
+row at 2×4. That is the right answer for a rope, whose `stretch` is its most characteristic property
+and whose forty particles make the row free (`cloth_dynamics_library.js` says exactly that), but "the
+library entries at 2×4 clear it" was never true of it. `MEASUREMENTS.md` §11.
 
 ---
 
@@ -760,8 +805,12 @@ descent direction, and the update takes a full step (§5.3). What is asserted in
 every LDLᵀ pivot positive on every update (which *is* positive definiteness, checked where it is
 used); nothing non-finite across 10,000 steps of absurd cloth; and full-step energy increases bounded
 and rare — 0.004% of updates on a realistic cape, never above a fifth of the local energy scale, and
-1.5% / 1.0 across the absurd fuzz. Those measured figures are the thresholds the standing gate holds
-the solver to, so a change that makes it worse fails.
+1.5% / 1.0 across the absurd fuzz. **The gate is those figures doubled, not those figures**: the spec
+holds 3% / 2 on the absurd fuzz and 0.01% / 0.5 on the cape, which is twice each measurement rather
+than the measurement itself. The last sentence of this paragraph used to claim otherwise. The margin
+is deliberate — a full step's energy behaviour is a distribution over a fuzz corpus and a gate pinned
+to its own sample is a gate that fails on an unrelated change — but "a change that makes it worse
+fails" is true only of a change that makes it *twice* as bad.
 
 **P2 — Over-stretch, the rubber cape.**
 *Mechanism:* long-range attachments (Kim et al. 2012). Each particle carries the geodesic distance to
@@ -806,12 +855,35 @@ of `θ` it scales the shape it poses by `cos(θ/2)`. At the half-radian per step
 `CLOTH_ANCHOR_ROTATION_LIMIT` already calls a spin, a 25 cm collider loses 7.8 mm — twice a silk
 garment's thickness — halfway through every step. `MEASUREMENTS.md` §19.
 
-*Limit, stated:* both halves are swept in translation first. A collider spinning fast enough that a
+**Post-M6 found the mirror case, and M2 had argued it away rather than measured it.** (a) folds the
+*collider's* travel into the discovery reach and nothing folds in the *particle's*, so a **static**
+collider is only ever discovered within `2·(thickness + inflation)` — 16 mm for a garment, which is
+half a metre a second of approach. The docblock said anything faster was already bounded by §7 P1's
+velocity clamp; that clamp is `4 · shortest_row · substeps · iterations / dt`, about **154 m/s** for a
+garment, and everything in between was uncovered. Measured, one particle at 8 mm thrown at a static
+3 cm capsule with no gravity at 2 × 4: **no row is ever created before the particle is already
+inside, at any speed**, and from **3 m/s** the row the next step finally makes is evaluated on the far
+side and pushes it the rest of the way out — which is P4(a)'s orientation-over-history choice
+collecting its bill when discovery is late. The reach now carries `|v_i|·dt` per particle as well.
+That is free at rest and 0.8% of a step for a cloth falling at 3 m/s, and `cloth_library_bench.mjs`
+cannot see it because the bench has no colliders. `MEASUREMENTS.md` §54.
+
+*Limit, stated:* all three are swept in translation first. A collider spinning fast enough that a
 point on its surface travels more than its own radius within one substep can still be missed, because
 the discovery margin is built from the *centre's* travel. Full CCD for cloth is out of scope.
+
+*And the second limit, which post-M6 measured rather than assumed:* **discovery being right is
+necessary and not sufficient.** A row that exists is still evaluated at substep positions, so a
+particle crossing a whole collider inside one substep has a row that never sees it touching. Swept,
+in half-metre steps from 1 to 12 m/s, the particle is stopped up to **6.0 m/s at two substeps and
+through the whole range at four** — a clean threshold, and it is `ClothDynamics#substeps` rather than
+the reach. This row has always said "more substeps in the affected `ClothDynamics`"; that is where it
+lands.
 *Spec:* a capsule driven through a hanging sheet at 2 to 40 m/s, swept against unswept; assert the
 swept pass creates rows at every speed and that no particle spends a step more than half a collider
-radius inside. `cloth_collision.spec.js` carries the ECS-level companion.
+radius inside. The mirror — a particle thrown at a *static* capsule from 1 to 10 m/s, with a step
+length of zero standing in for the unswept side — is in `cloth_contact_row.spec.js`.
+`cloth_collision.spec.js` carries the ECS-level companion of both.
 
 **P4 — Folds, tangles, and stays stuck.** The named requirement, so four mechanisms:
 
@@ -851,10 +923,21 @@ radius inside. `cloth_collision.spec.js` carries the ECS-level companion.
   solver whose whole design commitment is that it needs none, and no authored scene is that
   symmetric. `MEASUREMENTS.md` §22.
 
-  *(d) A bounded escape hatch.* If a particle's constraint residual stays above a threshold for N
-  consecutive steps, it blends to its animated position over a short window. Local, bounded, on by
-  default with a conservative threshold, and counted in `ClothDiagnostics` so that a garment relying on
-  it is visible rather than silently rescued.
+  *(d) A bounded escape hatch. **NOT BUILT, and this row is the design for one rather than a
+  description of one.*** If a particle's constraint residual stays above a threshold for N consecutive
+  steps, it blends to its animated position over a short window. Local, bounded, and counted in
+  `ClothDiagnostics` so that a garment relying on it is visible rather than silently rescued.
+
+  **It has been deferred at every milestone that could have built it** — M1 for want of a residual
+  monitor, M2 to M4 on the grounds that self-collision is where a particle gets *pinched* rather than
+  merely held, M4 onward as still open — and it is deferred deliberately rather than forgotten: M2
+  measured the one stuck configuration whose residual is **zero** (§7 P4's own note, `MEASUREMENTS.md`
+  §22), which is the quantity this row watches, so the mechanism would not have caught the case that
+  motivated looking for it. The sentence that used to stand here said "on by default with a
+  conservative threshold", which read as a shipped default and was never true of any build.
+  `ClothDiagnostics` is not built either; every reference to it in this document is a design for one.
+  What *is* shipped and does the job an author reaches for is `Cloth#blend` (§3.1), which is the same
+  blend applied deliberately instead of automatically.
 
 *Spec:* deliberately invert half a sheet through itself, run, assert the residual falls below threshold
 and the mesh is self-intersection-free within N steps; separately assert the escape hatch is not
@@ -863,7 +946,38 @@ triggered by a correctly authored garment under normal animation.
 **P5 — Jitter at rest.**
 *Mechanism:* the multiplier decay `α·γ < 1` bleeds accumulated force out of a resting configuration so
 it cannot ring; per-cloth sleep when the maximum particle displacement over a window falls below a
-threshold; wake on collider motion, anchor motion, wind change, or a `ClothDynamics` change.
+threshold; wake on collider motion, anchor motion, wind change, a collider arriving or leaving, or a
+`ClothDynamics` change.
+
+**Post-M6 note, and "wake on collider motion" was the wrong question.** Motion is what the test asked
+and it is not what a sleeping cloth needs to know. `ClothColliderSystem#link` **places** a new
+collider — previous pose equal to current, deliberately, so its first step sweeps nothing — so a
+collider *spawned* inside a sleeping cloth has not moved and never woke it. Measured: a 6-link rope
+settled and asleep, a sphere of radius 0.2 spawned around its lower half, still asleep 300 steps later
+with **4 of its 6 links inside**. §1's first commitment names exactly this case. The test now also
+compares the **set** of handles the broadphase returns with the set the cloth last stepped against —
+one integer per record, against a pose comparison that was already there — so a collider appearing or
+leaving wakes it whatever the poses say. Its own limit, stated: a `PlaneShape3D`'s AABB is unbounded,
+so a plane is in every cloth's set the moment it exists and every sleeping cloth wakes once when one
+appears anywhere in the scene. It finds nothing, and sleeps again thirty steps later.
+
+**Post-M6 note, and it is this row's own sentence coming true two milestones late.** "Maximum particle
+displacement over a window" is what this row has said since M0 and it is not what M1 built: M1's test
+is the largest particle **speed** the step produced, held under `CLOTH_SLEEP_SPEED_RATIO · reach` for
+`CLOTH_SLEEP_STEPS`. On a free-hanging chain the two agree. On a cloth **resting on a collider** they
+do not, and the gap is total: four of the seven library fabrics — cotton on a floor with or without
+friction, leather and rope on a floor with it — **never sleep at all**, where the same rope with no
+collider under it sleeps at step 283. The cause is not friction, which the frictionless column rules
+out; it is that a contact's penalty ramps by `β·|C|` and `γ = 1` never brings it down, so what a
+resting cloth settles into is a **bounded limit cycle** rather than a rest state: measured on cotton,
+a tenth of a millimetre of travel a step — invisible — at a peak speed of 1.5e-2 m/s, eighteen times
+the threshold. Displacement tells those apart and an instantaneous speed cannot. The sleep test now
+reads displacement from a window anchor, at `CLOTH_SLEEP_DISPLACEMENT_RATIO = 5e-4` of reach, chosen
+to be no *looser* than the speed test it replaces rather than the fastest value that works; every
+entry on a floor and on a sphere then sleeps within **961 steps**, and the free-hanging column gets
+uniformly faster rather than slower. The limit cycle itself is recorded and not fixed — `γ` is
+unmeasured-by-decision (§5.2) and a tenth of a millimetre is not a rendering problem.
+`MEASUREMENTS.md` §53.
 *M0 found the gap, and it is wider than "nothing is damping it".* The mechanism reaches **hard** rows
 only, because a soft row has no multiplier to decay — and a soft row whose penalty exceeds about
 `8·(m/h²)` does not merely fail to dissipate, it makes the step **add** energy. Measured on a hanging
@@ -874,9 +988,19 @@ which arrives with the component in M1 — so **damping is load-bearing for P5 r
 control**, and the M1 spec has to gate on a soft cloth actually settling. `MEASUREMENTS.md` §6.
 *Spec:* a settled cloth reaches sleep within a bounded number of steps and its positions are bit-identical
 across the following 300.
+**M6 note: a cloth also wakes on the air changing, and the test has one sample in it.** §10's "sleep
+wakes on a wind change" is the same shape as the collider test beside it — ask a question three orders
+of magnitude cheaper than the step it decides whether to skip — and the question is the air at the
+cloth's own centre against the air the last *applied* step saw. The last applied rather than the last
+sampled, so a gust that builds slowly accumulates instead of being reset by every step that declined
+to act on it. *Its limit, stated:* one point. A gust that reaches only the hem of a sleeping banner
+and leaves its middle still will not wake it. The collider test has no such gap because a collider's
+pose is seven exact numbers and a field is a continuum.
+
 *M1 landed both halves and measured them.* Every library fabric, on a 12-link chain set swinging at
 3 m/s, sleeps: **220 steps for denim, 770 for silk**, everything else between, and the order is the
-damping order. Sleep stops the **write-back** as well as the step, which is what makes "bit-identical"
+damping order. (Those two figures are the speed test's; the post-M6 note above replaced it, and every
+entry sleeps sooner under the displacement window than it did under the speed one.) Sleep stops the **write-back** as well as the step, which is what makes "bit-identical"
 a fact rather than a hope — a pose that is not rewritten cannot drift, and one rewritten from unchanged
 inputs is only *probably* identical. A cloth wakes on anchor motion, on a `ClothDynamics` change, on a
 `blend` change, and on an explicit `ClothSystem#wake` for anything it cannot see.
@@ -981,8 +1105,18 @@ loop, so §14 makes the analytic gradients shared code that both sides use.
 ### 8.3 Friction
 
 Coulomb friction as a row on the same contact, with `μ` combining `Collider#friction` with
-`ClothCollider#friction_scale`. The combine rule is the one `physics/contact/combine_material.js`
-already applies, so cloth and rigid bodies agree about what a surface feels like.
+`ClothCollider#friction_scale`.
+
+**The combine rule is *not* `physics/contact/combine_material.js`, and this paragraph used to say it
+was.** Nothing in `cloth/` imports that module. `combine_material` answers a different question — how
+two *bodies'* materials combine into one contact coefficient, which is a `sqrt(μ₁·μ₂)`-shaped rule
+over a symmetric pair — and cloth's question is not symmetric: one side is a collider with a material
+and the other is a garment with an opt-in scale on top of it. `ClothColliderSystem` therefore packs
+`Collider#friction · ClothCollider#friction_scale` into the index record, one multiply at link time,
+and a `friction_scale` of 1 means "whatever this surface already is". The *claim* the old sentence was
+making — that cloth and rigid bodies agree about what a surface feels like — is still true and is why
+`Collider#friction` is the base: what is not true is that the agreement comes from sharing a function.
+§13's reuse ledger carried the same wrong entry.
 
 **M2 made three of those words exact.** The clamp is `[0, μ·f_n]` rather than `±μ·f_n`, because the
 row's `C` is the *magnitude* of the tangential slip — §6 carries the derivation and what writing it
@@ -1090,8 +1224,7 @@ the bodies in the scene.
 
 So the design is: **a cloth overlapping a `FluidComponent` samples its velocity field per particle and
 applies aerodynamic drag against it**, scaled by `ClothDynamics#drag`. The term is an external
-acceleration, `a_drag = drag · (u_air − v) · |n·û|`, with 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.
+acceleration, `a_drag = response · facing · (u_air − v)`.
 
 The payoff is that a character running past a cape gets a wake, because the fluid solver already
 produces one; a fire's convection lifts a banner; a door slamming pushes a curtain. None of that needs
@@ -1106,8 +1239,69 @@ Cost control: sampling is per particle per *step*, not per iteration, and a clot
 field's bounds skips it entirely. Sleep (P5) wakes on a wind change so a settled banner does not stay
 asleep through a gust.
 
-This is deferred to M6 — it is the feature most likely to be cut for schedule, and nothing else depends
-on it.
+**M6 built it and corrected this section in four places.**
+
+**The factor above is not `|n·û|`, because half of what this system simulates has no `n`.** This
+paragraph originally wrote the term as `a_drag = drag · (u_air − v) · |n·û|`, "with 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". It is right about what it wants and wrong that a normal is available to want it
+with. A chain's particles span a **line** — every direction perpendicular to it is equally a normal,
+so picking one is the history-dependent fabrication §7 P4(a) exists to keep out — and a rope's
+aerodynamics are the *complement* of a sheet's anyway: it catches the flow across it and slices along
+it. Both are one quantity, **the part of the flow the particle's own incident rows cannot let past**:
+take the span `T` of the directions to its stretch-row neighbours in the current configuration, and
+`facing = ‖û − proj_T(û)‖`.
+
+| rank of `T` | what the particle is | the factor |
+|---|---|---|
+| 2 | a point on a surface | `\|û·n\|` with `n = b₁×b₂` — this paragraph's own expression |
+| 1 | a link of a chain | `√(1 − (û·t)²)` — the cross-flow, which is the rope's answer |
+| 0 | an isolated particle | `1` — a bead has no preferred direction |
+
+One expression, three topologies, no stored normal, no orientation, no sign, nothing carried between
+steps. `MEASUREMENTS.md` §47.
+
+**And the factor's headline claim is about *laminar* air, which is a limit rather than a fault.** On
+the playground's banner, turning a uniform wind through ninety degrees takes the mean factor from
+0.221 to **0.000** and the aerodynamic acceleration from 43.2 m/s² to 0.08 — a flag becoming a rope,
+exactly as promised. Turning a **wake** through ninety degrees does nothing at all: 0.216 to 0.280. A
+wake has velocity in every direction, so no orientation of a surface is edge-on to one, and the factor
+is correctly reporting that there is nothing to slice through. That makes this section's argument for
+reading a simulation *stronger* than this section knew. `MEASUREMENTS.md` §51.
+
+**`drag` is not what multiplies the flow, and the difference is a stability argument.** One external
+acceleration is held for the whole fixed step, so an explicit `rate · (u_air − 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 the step multiplies by is the **per-step response**
+`(1 − e^(−rate·dt))/dt` (`cloth_drag_response`), the exact solution of the same linear ODE, which
+closes a fraction of the gap that is strictly below one for every rate and every step length. It is
+also the step `GlobalFluidEffector` already takes for the air itself, which is a symmetry rather than
+a coincidence: both are relaxations toward a velocity. `MEASUREMENTS.md` §49.
+
+**The field answers in grid cells per second and cloth needs metres.** `FluidField#sampleVelocity`
+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 is not such a caller: its 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. `ClothFluidWind` converts.
+`MEASUREMENTS.md` §46.
+
+**And this section never said which thread samples, which M5 made a question.** 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, while the *answer* is three floats a particle. So `cloth_sample_air` runs on
+the **main thread** in both systems and writes into `ClothState#air_velocity` — a region of the
+cloth's own `SharedArrayBuffer`, so nothing is copied — and everything built from it runs in
+`cloth_step_instance` with the rest of the arithmetic, which is what keeps §12's parity structural.
+Measured: 58–62 ns a particle for a field sample, a twenty-fifth of that for the ambient (one sample
+for the whole cloth, which is what §10's "skips it entirely" is worth), and one per cent of a step for
+the term itself. `MEASUREMENTS.md` §48, §49.
+
+**Where the air comes from is a scene's choice and there is no default.** `ClothWorld#wind` is `null`
+until something assigns a source, exactly as the collider index is: a scene without one gets M5's
+cloth rather than an error. Null rather than a still-air ambient, because a source answering zero
+everywhere is not "no wind" — the row is a relaxation toward the air, so still air still resists a
+*moving* cloth, anisotropically. That is better physics than `ClothDynamics#damping`'s isotropic decay
+and it is not free, so it is a thing a scene asks for. What a cloth does in air that is not moving is
+`damping`'s job (§7 P5, where it is load-bearing); what it does in air that *is* is this.
 
 ---
 
@@ -1148,6 +1342,19 @@ for the same reason — a local transform is what a joint angle *is*.
 The authored pose is not lost by being overwritten. It is captured once, when the cloth seeds, and
 lives in the cloth from then on — which is what `blend = 0` returns to, what the leash centres are
 measured from, and what a re-seed of a live cloth reads instead of the shape the solver left behind.
+
+**Post-M6 found both halves of that last clause to be false in the code**, and they are the same
+mistake twice: the authored pose lives in the cloth, so the cloth is the only thing that can give it
+back, and it did not. `ClothWorld#reseed` cleared `ClothInstance#seeded` *before* the walk, and the
+capture was keyed on `seeded` — so the one path that exists to re-walk a live cloth was the one path
+that could remember nothing, and `read_rest_pose` fell back to `TransformAttachment#transform`, which
+this very paragraph says the write-back has been overwriting every step. Reproduced on a 6-link rope
+authored horizontally and settled for 300 steps: a re-seed took the authored tip from **x 0.600,
+y −0.012 to x −0.003, y −0.600**, and `blend = 0` then landed on the sagged pose. The capture is now
+keyed on there *being* a previous capture. And the same for removal: `unlink` dropped the registry
+entry and nothing put the authored local transforms back, so a `Cloth` removed left its subtree frozen
+in the solver's last shape and a `Cloth` added back seeded *that* as the pose it returns to.
+`cloth_release_subtree` is the other half of the seed, announced once on the anchor.
 The consequence, stated: **in the entity path the animated pose is constant in the anchor's frame.**
 That is a property of the case rather than a limitation of the code — a subtree's authored pose is
 rigid relative to its anchor — but it does mean a subtree whose *links* are independently animated is
@@ -1184,15 +1391,22 @@ how anything moves.
 
 ### 11.2 Skinned garments — `Cloth` + `ClothRig`
 
-A character's cape is not an entity hierarchy and cannot be made into one.
-`shade_node_to_entity_composition` expands a model into entities and attaches a `ShadedGeometry` to
-each node that draws — but a skinned node contributes its transform and its name and **no geometry**,
-because its vertices deform against a skeleton the renderer owns and the GPU poses. Its joints are
-`Node3D`s inside the entity's `SceneBundleInstance`, and making them entities is explicitly a design
-this program does not do (D47). So for a skinned garment there is no `ShadedGeometry` component and no
-bone entities: the geometry is registered with `GPUAnimationManager` through
-`register_instance_animation`, and the only writable handle is the joint's `Node3D.transform_local` —
-the same handle the animation systems write.
+A character's cape is not an entity hierarchy **of its own**: a skinned node contributes its transform
+and its name and **no geometry**, because its vertices deform against a skeleton the renderer owns and
+the GPU poses. The geometry is registered with `GPUAnimationManager`, and what cloth writes is a
+joint's offset from its parent joint.
+
+**Where that offset lives is no longer a `Node3D`, and the three paragraphs that follow were written
+when it was.** M3 wrote `Node3D.transform_local` on joints inside a `SceneBundleInstance`, and this
+section still describes that, including a flat assertion that bone entities are "explicitly a design
+this program does not do (D47)". The engine's Rows-Not-Nodes work deleted `Node3D`: a model is spawned
+by `prefab_instantiate`, its joints **are** entities, and the writable handle is
+`TransformAttachment#transform` on the joint entity — which is what `cloth_seed_rig` collects and
+`cloth_write_back_rig` writes. Nothing about the design changes with it and one thing gets simpler:
+the rig path and the entity path now write the *same component*, so §11's "the solver is identical
+either way; only seeding and write-back differ" is now true of the write-back's data type as well as
+of its shape. Read `Node3D.transform_local` below as `TransformAttachment#transform` on a joint
+entity, and `SceneBundleInstance` as `PrefabInstance`.
 
 **And cloth has to *claim* those joints, which §11.2 originally read as though it did not.** The
 sentence above says the handle is "the same handle the animation systems write", and they do not
@@ -1208,6 +1422,14 @@ race the enum exists to prevent, and for a cape that is the point of simulating
 whose joints are also keyed it is an authoring error, and the claim is where it surfaces.
 `MEASUREMENTS.md` §25.
 
+**Post-M6: the claim is a loan, and it was written as a gift.** The consequence above is the right
+trade only while the cloth is *there*. `cloth_seed_rig` revoked the GPU's authority over every joint
+it drove and nothing ever re-granted it, so a garment removed left its joints owned by a CPU that had
+stopped writing them — neither animated nor simulated, stuck in the pose the solver last produced, and
+with no component left anywhere naming which joints those were. The seed now records exactly the
+joints its revoke *changed*, and `cloth_release_rig` hands those back when the `Cloth` is removed or
+the `ClothRig` is taken away; a joint that was already the CPU's before cloth arrived stays the CPU's.
+
 **The anchor's world pose is computed, never read back.** A joint of an animated skeleton has no
 CPU-side `transform_global` — nothing maintains it — so the rig path evaluates the anchor with
 `pose_evaluate_world` over the clips the entity is playing, which is the engine's own sanctioned
@@ -1291,20 +1513,32 @@ For a **rigged** garment, only steps 5–8 run, over the joint graph rather than
 10. **Validate**: manifoldness, no zero-length edges, and — the P4(c) precondition — that the skinned
     bind pose is collision-free against the character's `ClothCollider` set.
 
-Vertex painting (per-vertex stiffness or slack multiplier) is supported through an optional texture or
-vertex-colour channel and is never required. Steps 5 and 6 are the default, and the intent is that most
-garments never override them.
+Vertex painting (per-vertex stiffness or slack multiplier) — **not built.** The sentence that used to
+stand here said it "is supported through an optional texture or vertex-colour channel"; nothing reads
+a texture or a colour channel, and `ClothProxy` has no per-vertex override to read one into. Steps 5
+and 6 are the whole of what a garment gets, which is the design's own claim that most garments never
+need to override them, made by there being no override. The shape of one, if a garment ever needs it,
+is a per-particle multiplier beside the geodesic — one array, read where `slack` and `stretch` are
+read — and it is the kind of authored knob §3.4 spent a section removing, so it should arrive with a
+garment that demonstrably needs it rather than ahead of one.
 
 ---
 
 ## 12. Data layout, threading, the worker
 
-**One `SharedArrayBuffer` for the whole cloth world**, not one per instance. `WorkerSystem`'s model is
-a single shared buffer, a single command region and a single atomic publishing one in-flight step, and
-`WorkerFluidSystem` already shows how a variable set of simulated things fits that model: the command
-region carries a count and then a list of ids to step. Cloth does the same — each instance gets a
-region inside the buffer, and the command region names which instances are live this step, so sleeping
-(P5) and culled (§12.1) instances cost nothing but their absence from a list.
+**One `SharedArrayBuffer` per cloth**, and the command region names which cloths are live this step —
+so sleeping (P5) and culled (§12.1) cloths cost nothing but their absence from a list. `WorkerSystem`'s
+model is a single shared buffer, a single command region and a single atomic publishing one in-flight
+step, and `WorkerFluidSystem` shows how a variable set of simulated things fits it.
+
+**M5 corrected "one buffer for the whole cloth world", and `reseed` 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, a rigged garment whose model has just loaded —
+builds a different one while other cloths have steps in flight. A world buffer would therefore need an
+allocator with relocation, and a relocation invalidates every view of every region on both threads at
+once. One buffer per cloth costs one cold-plane message per seed (`add_cloth` / `remove_cloth`, the
+shape `WorkerFluidSystem` already has) and makes a re-seed a re-registration, which is the same code
+path as a first seed. `MEASUREMENTS.md` §39.
 
 SoA throughout:
 
@@ -1315,13 +1549,67 @@ SoA throughout:
 | topology | `Int32Array` | edge pairs, bend stencils, colour ranges, tether anchors |
 | rest data | `Float32Array` | rest lengths, bend weights, `d_geo` |
 | duals | `Float32Array` | `λ` and `k` per persistent constraint |
-| colliders | `Float32Array` | packed records for this step |
+| colliders | `Float32Array` | packed records for this step — `CLOTH_COLLIDER_SLOTS` of them |
 | contacts | `Float32Array` | transient rows + their warm-start `λ`, keyed by (particle, collider slot) |
 
-`ClothDynamics` reaches the worker through the command region, written every step — a dozen words into
-memory the worker already shares, cheaper than tracking dirtiness, and it keeps
+The **step's parameters** reach the worker through the command region, written every step — fourteen
+words into memory the worker already shares, cheaper than tracking dirtiness, and it keeps
 `cloth.dynamics.slack = 0.2` working live, which is the point of a value object rather than a preset
-that has to be re-applied.
+that has to be re-applied. (Thirteen at M5; M6's §10 adds the drag response, and the air itself
+travels as a region of the same buffer rather than as words — `ClothState#air_velocity`, written by
+the main thread and read by the step, which is the one direction the buffer could always carry and
+nothing had used.)
+
+**M5 corrected "`ClothDynamics` reaches the worker".** By the time the step can use them a cloth's
+dynamics have been through `cloth_dynamics_map.js` — a damping retention, a velocity clamp, 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 copies agreed. What
+crosses is `ClothStepParam`: `dt`, local gravity, substeps, iterations, retention, clamp, contact
+radius, self radius, collider count, and whether self-collision is on. `Float64` throughout, so the
+round trip is exact — an `f32` command region would round the clamp, and a clamp that rounds is a
+velocity that rounds. `MEASUREMENTS.md` §40.
+
+The same block is what makes the parity gate below structural rather than aspirational:
+`ClothSystem` fills the words of a private scratch array and calls `cloth_step_instance`;
+`WorkerClothSystem` fills the same words of the shared command region and the worker calls the same
+function. Neither system computes a step parameter of its own, so neither can compute one differently.
+
+**M6 found the one thing that is not a parameter and still differs: the clock.** A gust is a function
+of time, and a worker cloth is not advanced until its registration is acknowledged — so the two
+systems reach a cloth's *first step* at different tick counts, and a clock that counted ticks hands
+that cloth a different gust on the same step. Measured with the clock put back on ticks, the gate
+fails at step 1, byte 0, which is the step's own result word. `ClothWorld#time` therefore counts the
+steps the world has taken rather than the ticks it has been asked about: it advances at the first
+`advance` of a tick, so a tick in which nothing is advanced does not move the weather. That is also
+the right semantic on its own terms — a paused simulation should not have the wind move.
+`MEASUREMENTS.md` §50.
+
+**Post-M6: a world clock fixes the first cloth in a scene and no other.** The paragraph above is
+right about *one* cloth and the gate it was measured against had one. With cloth A already running,
+cloth B's registration takes k ticks during which A is still being advanced — so the world clock
+moves, and B reaches its own first step at a different clock value under the two systems. Measured
+with a two-tick delivery: **0.1000 s against 0.1333 s** at B's first step, and the gate fails at B's
+step 1, byte 0, exactly as it did for the tick clock. A gust of zero gives zero differences, which is
+what identifies the clock as the cause rather than the latency. So the gust reads **the asking
+cloth's own age** — `ClothInstance#age`, seconds *this instance* has stepped — and `ClothWorld#time`
+is left to do the one job it can do correctly, which is telling a source that reads the scene when to
+walk it. The visible consequence is that two garments spawned a second apart are a second apart in
+the gust rather than in phase with it; for a bounded sum of sinusoids that is indistinguishable from
+weather, which is why this is free. `MEASUREMENTS.md` §57.
+
+**And post-M6 found the other one, which is not a clock: the two systems ran a tick's phases in
+different orders.** `ClothSystem` ran advance, step and finish per cloth, in hierarchy-depth order, so
+a **nested** cloth advanced against an anchor the cloth above it had already written *this* step;
+`WorkerClothSystem` cannot do that — its `apply` writes step T−1 back at the top of a tick and its
+`collect` then advances everything for step T. Measured on a 4-link rope hung from link 3 of a 6-link
+rope, no wind, 120 steps: the parent identical, the child differing at **step 1, byte 24**. Both
+systems now run three loops — advance every cloth, then step every cloth, then finish every cloth — so
+a nested cloth reads its parent one fixed step stale on both sides, and `ClothWorld`'s depth sort,
+which existed only to make the other answer true, is gone. That was necessary and not sufficient: the
+write-back also composed each node's world pose against the **live** anchor rather than the anchor the
+step ran on, which for a worker writing step T−1 during tick T is a different anchor. It now uses the
+pose `advance` cached, which is the same value for `ClothSystem` and the honest one for both.
+`MEASUREMENTS.md` §56.
 
 `Float32` for particle state, not `Float64`. The simulation runs in the cloth's **local frame**, so
 coordinates are garment-sized rather than world-sized and f32 has ample precision; the payoff is half
@@ -1340,6 +1628,16 @@ fixed `CLOTH_CONTACT_SLOTS` per particle inside `ClothState`'s single buffer —
 saturate on a twenty-collider scene and to average a tenth of one — which keeps §12's one-allocation
 property and bounds the worst case at the four *most violated* colliders, which is the four that matter.
 
+**And M5 moved the per-step collider table itself into that buffer**, at a fixed
+`CLOTH_COLLIDER_SLOTS`, which is where the table above always put it. M2 kept it on `ClothInstance`
+and grew it by doubling, on the correct grounds that its size is a property of the world rather than of
+the cloth; what decides is that an array which can be *replaced* mid-run is memory the worker has to be
+told about again before it can name it. So the size stays a property of the world and the region gets a
+capacity. **Sixty-four**, because the measurement showed the bound is a *scene* rather than a garment —
+a cloth's table holds every collider on every character standing inside its query box, which is ten for
+one body and thirty for three — and because an overflow discards colliders in the index's own order
+rather than in order of how much they matter. It warns once. `MEASUREMENTS.md` §41.
+
 **The worker.** `WorkerClothSystem` is a `WorkerSystem` subclass and follows `WorkerFluidSystem`
 exactly, because that pattern is already proven in this repo: `collect` packs colliders and animated
 targets into shared memory and writes the command words, a single `Atomics.store` publishes the step,
@@ -1353,6 +1651,15 @@ identical order. That is what makes the worker a deployment choice rather than a
 it is why the core is a pure function over typed arrays from milestone zero even though the worker does
 not arrive until milestone five.
 
+**M5 measured it and the number is zero**, at every step of a run rather than at the end of one: the
+whole `ClothState` buffer — particles, velocities, every dual and penalty, the collider table, the
+warm-started contact multipliers, the self-collision pair list — compared byte for byte after each of
+420 steps across two scenes, one with a walking anchor and one with colliders and self-collision live.
+What the scene sees differs by exactly one tick: the pose written at tick `T` is step `T − 1`'s. That
+is §4.1's own sentence in a second setting — the cloth's *shape* is one fixed step stale and its
+*position* is not, because the attachment cascade carries the subtree rigidly with the anchor.
+`MEASUREMENTS.md` §40.
+
 Testing the bridge needs no worker: `SystemWorkerLoopback` gives a real `SystemWorkerHost`, a real
 `SharedArrayBuffer` and real `Atomics` in-process, with message delivery and step execution as explicit
 events a spec can order. Only the thread is faked.
@@ -1387,13 +1694,13 @@ What this design takes from the engine rather than building:
 | "Opt a collider into a second simulation" | `FluidObstacle` + `FluidObstacleSystem`, `AcousticBody` |
 | Collider index shape | `AcousticOccluderIndex` + `OccluderBody` |
 | Component holds a built shared asset | `Collider#shape`, `ParticleEffect#program` — the convention `ClothRig#proxy` follows |
-| Surface material combination | `physics/contact/combine_material.js` |
+| Surface material combination | ~~`physics/contact/combine_material.js`~~ — **not reused**, see §8.3: cloth's `μ` is `Collider#friction · ClothCollider#friction_scale`, which is a scale on one material rather than a combination of two |
 | Constraint-row doctrine | `physics/constraint/solve_constraints.js` |
 | Subtree walk | `TransformAttachmentSystem#findChildrenOf` / `#countChildrenOf`, `TransformAttachment` |
 | Animated targets | `mesh_apply_skeletal_vertex_skinning` (flat arrays, worker-safe) |
-| Wind / aerodynamics | `FluidField#sampleVelocity`, `fluid_build_world_to_grid`, `GlobalFluidEffector` |
+| Wind / aerodynamics | `FluidField#sampleVelocity` (in grid cells a second — §10 converts), `fluid_build_world_to_grid`, `GlobalFluidEffector` as the shape of the ambient *and* as the exact-ODE relaxation step `cloth_drag_response` copies |
 | Worker offload | `ecs/async/WorkerSystem.js`, `SystemWorkerHost`, `SystemWorkerLoopback`, `WorkerFluidSystem` as the worked example |
-| Fixed step + render interpolation | `PhysicsSystem`'s producer/`__interp_restore` contract |
+| Fixed step | `EntityManager`'s fixed-step loop, gate and `fixedStepTick` |
 | Transforms | `Transform64`, `Node3D` |
 | Particle → render-vertex mapping | `Skin` — joints + inverse-bind matrices + the four-weight palette; cloth writes joints and the existing pass does the rest |
 | Reaching a model's joints from its entity | `SceneBundleInstance` (`skins`, `nodes` by name), `register_instance_animation` |
@@ -1404,6 +1711,24 @@ What this design takes from the engine rather than building:
 
 ---
 
+### 13.1 What is *not* reusable — render interpolation
+
+`PhysicsSystem`'s producer/`__interp_restore` contract was in the ledger above and M5 took it out,
+because it cannot express a rigged garment. `Interpolated` is an **entity-keyed marker**: the
+`InterpolationSystem` files snapshots under a `key` it assigns from the entity id at link time. A
+rope's links are entities and a skinned garment's joints are not — `shade_node_to_entity_composition`
+does not expand a skinned node, "and that is a boundary rather than an omission" (§3) — so half the
+feature has nothing to put the component on.
+
+Cloth also needs only half of what that contract does. `__interp_restore` exists to hand the
+simulation its authoritative pose back before it integrates, because the render blend writes into the
+components the simulation reads. Cloth's state is `ClothState.position` in the cloth's local frame and
+its write-back never touches the anchor it reads, so **cloth never reads back what it writes** and has
+nothing to restore. It needs the publish half, over a pose per node rather than a component per entity.
+§18 carries what that would cost. `MEASUREMENTS.md` §43.
+
+---
+
 ## 14. New shared code this justifies
 
 Three pieces belong in `core`, not in `cloth`, because the cloth need exposes a gap the engine has
@@ -1623,13 +1948,36 @@ placement into a bounded quality question and leaves the scheduler alone.
 and belongs with the collision rows that make a particle get *stuck* in the first place — a chain has
 no configuration to be stuck in. Chebyshev acceleration, still gated on contacts that arrive at M2. `β`,
 which M0 could not choose and M1 has no transient rows to choose it with either — every row M1 adds is
-persistent. `ClothSerializationAdapter` and its siblings: nothing in M1's scope list names them, and a
-codec written before `ClothRig` exists would be revised by M3 before it was ever loaded.
+persistent. The serialization adapters: nothing in M1's scope list names them, and a codec written
+before `ClothRig` exists would be revised by M3 before it was ever loaded — **true of one of the three;
+the correction follows this block.**
 Interpolation: cloth writes `Transform64` at the fixed rate and §12's producer/`__interp_restore`
 contract is not wired, which shows as a cloth updating at the fixed rate rather than the frame rate
 and is a visible-but-not-wrong gap. M5 is where it belongs, with the worker.
 **This is the first shippable feature.**
 
+**Corrected 2026-09-13: the deferral above only ever fitted `ClothRig`'s adapter, and it was applied to
+all three of them from here to the end of the plan.** It fits `ClothRigSerializationAdapter`, whose
+component points at a built, shared, immutable asset and therefore needs the asset-identity story §3.2
+only gestures at; and it fits `ClothProxy`'s own codec, which genuinely does depend on what §11.3
+step 9 adds to a proxy. It never fitted `Cloth` or `ClothCollider`. Those two are scalars — `blend`,
+`layer`, `mask`, `flags` and a `ClothDynamics` value object of ten more; `inflation`,
+`friction_scale`, `layer`, `mask`, `flags` — and neither holds a proxy, a skin, or anything either
+geometry path introduces. The evidence that the revision this sentence feared was never coming is M3
+itself: it changed the design in four places (`MEASUREMENTS.md` §24–29) and not one of them was a
+field on either component.
+
+What turned a sequencing call into a hole is that it was **re-deferred rather than re-examined**. M2
+deferred all three "per M1's own reasoning"; M3 deferred them again for M1's reason while, in the same
+list, deferring the unrigged path that the reason had just been made to wait on; and §11.3 step 9 is
+in no milestone at all. A wait with no scheduled end is not a sequencing decision, and what it cost is
+that M6 closed this plan with a subsystem a scene could not contain: a `Cloth` could be added from
+code and from nowhere else. `ClothSerializationAdapter` and `ClothColliderSerializationAdapter` are
+built and specced as of 2026-09-13, outside any milestone and with no `MEASUREMENTS.md` section,
+because there is no measurement behind them — a codec has nothing to measure, and that file's sections
+belong to milestones. `ClothRigSerializationAdapter` and the proxy codec stay deferred, on the reason
+as narrowed here.
+
 **M2 — collision. DONE, 2026-09-10.** `ClothCollider`, `ClothColliderFlags`, `ClothColliderSystem`,
 `ClothColliderIndex`, the packed record and its swept bounds, analytic SDF gradients and
 `PlaneShape3D` in `core` (§14.1, §14.3), the contact row and its friction row, the backstop row, and a
@@ -1657,10 +2005,15 @@ available, loses on every axis and is gone.
 **Deliberately not in M2:** P4(d)'s bounded escape hatch, still — M2 has the contacts that make a
 particle get stuck, and also measured the one stuck configuration whose *residual is zero*, which is
 the quantity the escape hatch was to watch (§7 P4). It belongs with the self-collision of M4, where a
-particle can be pinched between two rows rather than merely held by one. The backstop row is built,
-specced and driven by the playground, but nothing **authors** one: its plane comes from a garment's own
-skinned surface and a skinned garment is M3. Two-way coupling, per §2. `ClothSerializationAdapter` and
-its siblings, per M1's own reasoning.
+particle can be pinched between two rows rather than merely held by one. The backstop row is built and
+specced, but nothing **authors** one: its plane comes from a garment's own skinned surface and a
+skinned garment is M3. (**"and driven by the playground" was not true and has been removed** — no page
+under `playground/` writes `ClothState#backstop_plane`, then or now. The row's own docblock made the
+same claim and has been corrected. What holds it up is `cloth_backstop_row.spec.js`, which is a
+solver-level spec rather than a scene, and that is the honest status of a row with no author.) Two-way coupling, per §2. The serialization adapters, per
+M1's own reasoning — which, as M1 now records, reached only `ClothRig`'s. The other two were not
+blocked by anything M2 had in hand or M3 was about to add, and this line is the first of the two
+restatements that carried them anyway.
 
 **M3 — skinned garments, the rigged path. DONE, 2026-09-10.** `ClothRig`, `ClothProxy`,
 `cloth_proxy_from_joints` (§11.3 steps 5–8), the rig seeder, and joint write-back into
@@ -1695,7 +2048,13 @@ budget. §11.3 step 10's bind-pose collision validation, which `cloth_proxy_from
 because it has a joint tree and no collider set — and which `MEASUREMENTS.md` §29 makes the argument
 for, because a garment authored inside its own body reads as a *tether* failure and costs an hour to
 diagnose. `ClothProxy`'s binary codec and `ClothRigSerializationAdapter`, for M1's own reason: a
-codec written before the unrigged path exists would be revised before it was ever loaded.
+codec written before the unrigged path exists would be revised before it was ever loaded. **Those two
+only, corrected 2026-09-13.** As written this sentence carried `Cloth`'s and `ClothCollider`'s
+adapters with them, over a set of three, for a reason that held for one — and it did so in the same
+list that defers the unrigged path the reason had just been made to wait on, which is what closed the
+loop: the dependency and the thing depending on it were deferred by the same paragraph. Neither scalar
+component holds a proxy, so §3.2's asset-identity question — the real content of M1's reason — was
+never theirs to answer. Both adapters were built on 2026-09-13; M1 carries the full correction.
 
 **M4 — self-collision. DONE, 2026-09-11.** `core/geom/3d/hash-grid/PointHashGrid3.js`, the
 particle-particle row (`solver/constraint/cloth_self_row.js`), the pair search
@@ -1762,13 +2121,156 @@ realisations, a self-tangled sheet unties itself every time the gust stops, so M
 configuration to escape from. The case P4(d) names is a particle wedged between a collider *and* a
 fold, which is collision and self-collision together, and M4 has not measured it.
 
-**M5 — the worker.** `WorkerClothSystem`, `ClothWorkerCore`, `cloth.worker.js`, the protocol.
-*Proofs:* bit-parity between `ClothSystem` and `WorkerClothSystem` as a standing gate; loopback specs
-covering step ordering, message ordering and shutdown; a measured main-thread cost reduction.
-
-**M6 — wind.** Fluid-field sampling, aerodynamic drag, the ambient fallback.
-*Proofs:* a playground with a banner in a simulated wake; a measured cost showing the per-step sampling
-stays inside budget. Cuttable without affecting anything else.
+**M5 — the worker. DONE, 2026-09-12.** `WorkerClothSystem`, `ClothWorkerCore`, `cloth.worker.js`,
+`makeClothWorker` and the protocol — plus the two pieces that had to exist for the parity gate to be
+structural rather than hopeful: `ClothWorld`, which is every cloth in a scene and everything about
+stepping one that is not arithmetic, owned by *both* systems; and `cloth_step_instance`, which is the
+arithmetic, driven by a `Float64` parameter block that is also the command region's per-cloth record.
+`ClothState` gains shared-memory backing, a descriptor, the collider table and a result region.
+*Proofs, all green:* bit-parity over the **whole `ClothState` buffer at every step** of two runs — a
+walking anchor for 240 steps, and colliders plus self-collision for 180 — with the write-back's
+one-tick lag pinned tick by tick rather than asserted at the end; the state a worker steps being the
+main thread's memory rather than a copy; a cloth being neither stepped **nor advanced** until its
+registration is acknowledged, which is what keeps the two systems' step *sequences* identical rather
+than merely similar; a re-seed retiring its registration and waiting again; a despawn between dispatch
+and step not failing the bridge; sleep removing a cloth from the dispatch and `wake` putting it back;
+shutdown settling the step in flight, releasing the gate and dropping the worker; and the derived
+execution order landing `WorkerClothSystem` exactly where `ClothSystem` lands. **10 tests in one new
+spec file**, with the M0–M4 suites unchanged at 183. The engine suite is green at 18,579.
+
+**M5 changed the design in four places**, each with the measurement behind it in `MEASUREMENTS.md`
+§38–44 and each folded back above. In one line each: §12's one buffer for the whole cloth world is one
+buffer per cloth, because `reseed` resizes one while others are in flight; §12's collider table does
+belong in that buffer and therefore needs a capacity rather than a growth policy, and the capacity is
+bounded by the *scene* — thirty records for three characters — rather than by the garment; §12's
+"`ClothDynamics` reaches the worker through the command region" is the *mapped* step parameters rather
+than the component, because mapping them twice is two copies that cannot be proved equal; and §13's
+reuse of `PhysicsSystem`'s interpolation contract does not hold, because that contract is entity-keyed
+and a rigged garment's joints are not entities.
+
+**And the strongest result is again a number rather than a correction.** §12 asks the two systems for
+bit-identical results. Over 420 steps across two scenes, comparing the entire state buffer after every
+one of them, the number of differing bytes is **zero** — and it is zero by construction rather than by
+luck, because there is one `ClothWorld`, one `cloth_step_instance`, and one parameter block that both
+systems fill and neither system interprets. The main thread's share of a thousand-particle garment goes
+from 3.62 ms to 0.18 ms; across the library's shapes, 92% to 96% of it crosses. `MEASUREMENTS.md` §40,
+§41.
+
+**Deliberately not in M5:** **render interpolation**, which §18 said would land here and which M5
+decided against with three findings rather than a deferral — the named contract is entity-keyed and
+cannot reach a rigged garment's joints, cloth needs only the half of it that has no name, and the
+worker removes the cheap implementation by owning `ClothState` outside the fixed pass. What it needs
+instead is a published pose slot, and §18 now carries what that costs (about 0.12 ms a frame on the
+§17 workload, which roughly triples the main thread's share of cloth and leaves it at a seventh of
+its pre-M5 cost) and what it buys (half a link length a step at a walk, a whole one at a sprint).
+`MEASUREMENTS.md` §43. **A playground page**, for a reason about the dev server rather than the cloth:
+`SharedArrayBuffer` needs a cross-origin isolated page, and adding `COOP`/`COEP` to
+`vite.config.mjs` changes how every other playground page in the package loads its subresources —
+to demonstrate a bridge `SystemWorkerLoopback` already tests more precisely than a page could.
+**Culling (§12.1)**, which is a policy over the same dispatch list sleep already uses and belongs with
+a camera. And **a deeper pipeline**: `WorkerSystem` allows one step in flight and the fixed-step gate
+means a cloth could not use a second.
+
+**M6 — wind. DONE, 2026-09-13.** §10 end to end: `wind/AbstractClothWind.js` and the two sources
+behind it (`ClothAmbientWind`, `ClothFluidWind`), `wind/cloth_sample_air.js`,
+`solver/cloth_wind_accelerate.js`, `ClothState`'s air and external-acceleration regions,
+`cloth_drag_response`, the parameter block's fourteenth word, and `ClothWorld`'s wind source, clock
+and wake test.
+*Proofs, all green:* the normal-facing factor on both topologies, which is the whole of what M6 adds
+to the physics — a sheet reading 1.000 broadside and 0.000 edge-on, a chain reading the reverse, and
+neither a skip row nor a strain-limit row able to fabricate a plane out of a line; the two sources
+through the interface, including a field answering in metres rather than grid cells and `varies()`
+being a promise the sampler acts on; the ECS path end to end — a garment blown downwind, one inside a
+`FluidComponent` reading the simulation while one ten metres away reads the weather, a settled banner
+sleeping in a steady wind and waking on a gust, and a scene with no source producing the cloth M5
+shipped **byte for byte** across 120 steps; the drag response closing a fraction of the gap to the
+air that is strictly below one at every step length from 1/240 s to 1 s; and §12's parity gate
+extended to a third run with wind live. **25 tests across three new spec files** — the term's 9, the
+sources' 10, the ECS path's 6 — plus the parity spec's eleventh, for 26 in all, with the M0–M5
+suites unchanged at 193. The engine suite is green at **18,638**, and the same suite run against M5's
+own commit in a detached worktree reads 18,612 on this machine, so the difference is exactly M6's
+twenty-six. A fifth playground page, `playground/wind.html`, with a banner hanging in a real
+`FluidSimulator`'s wake.
+
+**M6 changed the design in five places**, each with the measurement behind it in `MEASUREMENTS.md`
+§45–§52 and each folded back above. In one line each: §10's `|n·û|` cannot be written for a chain,
+which has no normal and wants the complementary factor anyway, so both are one expression over the
+span of the incident rows; §10's "samples its velocity field" needs a unit conversion, because
+`FluidField` answers in grid cells a second and a garment blowing at a speed that depends on the
+voxel size is not a garment; §10 never said which thread samples and it cannot be the worker's, so
+the field stays where it is and three floats a particle cross in the cloth's own buffer; `drag`
+cannot multiply the flow directly, because one acceleration held for a whole fixed step overshoots
+the air once `rate·dt > 1`; and §12's thirteen-word block is fourteen, with a clock that has to count
+steps rather than ticks or the two systems' weather diverges at step 1.
+
+**And the strongest result is again a number rather than a correction.** §10 offers the normal-facing
+factor as the difference between a flag and a rope. In uniform air it is: turning the wind ninety
+degrees at the same speed takes the banner's aerodynamic acceleration from **43.2 m/s² to 0.08**, a
+factor of five hundred. In a **wake** it does nothing at all — 0.216 against 0.280 — because a wake
+has velocity in every direction and no orientation of a surface is edge-on to one. That is not a
+failure of the factor; it is the measurement saying §10's argument for reading a simulation is
+stronger than §10 knew, and that the flag-versus-rope claim is a statement about laminar air.
+`MEASUREMENTS.md` §51.
+
+**Deliberately not in M6:** **a spatially varying ambient.** The gust is uniform in space, so a long
+banner does not see it arrive at one end before the other — and that is what makes the no-simulation
+case cost one sample for a whole garment instead of one a particle (§48). Spatial structure is what a
+fluid field is *for*, and a second, worse one inside the fallback is the duplication §10 exists to
+avoid. **A blend at a field's edge**: a point inside a volume reads the volume and a point outside
+reads the ambient, so a garment straddling the boundary sees a step rather than a ramp. Where the
+ambient is the far field the volume relaxes toward — `GlobalFluidEffector`'s own `wind` — the step is
+small and is mostly the disturbance the volume exists to carry; where it is not, the answer is a
+volume large enough to hold what moves through it. **Two-way coupling into the fluid**, per §2's
+one-way rule: cloth reads the air and does not disturb it, and anything that should has
+`FluidObstacle`. And **per-substep sampling**, because §10 says per step and §48 measures the sample
+at 58 ns a particle — the one part of this that is not free is the one part per-substep sampling
+would double.
+
+**Post-M6 — six defects, six fixes, and the plan corrected where the code proved it wrong. DONE,
+2026-09-13.** No new mechanism and no new milestone: a pass over what M6 left, taken in the order the
+defects were found.
+
+1. **A cloth resting on a collider never slept.** §7 P5 has asked for "maximum particle displacement
+   over a window" since M0 and M1 built an instantaneous speed; four of the seven library fabrics
+   never slept at all on a floor, because a resting contact is a bounded limit cycle whose *speed* is
+   eighteen times the threshold and whose *travel* is a tenth of a millimetre a step.
+   `CLOTH_SLEEP_DISPLACEMENT_RATIO`, and every entry on a floor or a sphere sleeps.
+   `MEASUREMENTS.md` §53.
+2. **A static collider was tunnelled from 3 m/s.** M2 folded the collider's travel into the discovery
+   reach and argued the particle's own away with a velocity clamp three orders of magnitude too large
+   to be the bound. The reach carries `|v_i|·dt` too; what is left is the substep count, measured.
+   §7 P3, `MEASUREMENTS.md` §54.
+3. **Seeding took three things from the scene and gave none of them back**: the authored pose across a
+   re-seed, the authored pose on removal, and the GPU's authority over a rig's joints. And `ClothRig`
+   was read once rather than watched, so a rig arriving a fixed step late seeded a skeleton as a rope.
+   §11.1, §11.2, §18.
+4. **A collider arriving and a collider retiring were both asked about a pose.** A collider spawned
+   inside a sleeping cloth has not *moved*; a handle retired and reused inside one tick is the same
+   handle. The wake test compares the handle set, and a retired slot is cold for a step.
+   `MEASUREMENTS.md` §55.
+5. **The parity gate had one cloth in it.** A nested pair and a staggered spawn are two scenes in
+   which the two systems could differ and did — a tick's phases ran in different orders, the
+   write-back composed against a newer anchor than its own step, and the gust read a world clock that
+   moves while a second cloth is registering. §12, `MEASUREMENTS.md` §56, §57.
+6. **The plan said eight things the code does not do**, each corrected in place above: P4(d)'s escape
+   hatch and `ClothDiagnostics` recorded as never built rather than "on by default"; §5.2's constants
+   line brought to `β = 1e3` with the contact floor recorded and `γ = 1` named as the one unmeasured
+   constant left; §7 P1's gate stated as twice its measurements rather than as them; §3.3's `flags`
+   default; §6's claim about the library at 2×4, which was never true of `CLOTH_ROPE`; §8.3 and §13's
+   `combine_material.js`, which nothing imports; §3.2 and §11.2's joints-are-`Node3D`s, which the
+   engine's own Rows-Not-Nodes work made false; §11.3's vertex painting; and the backstop row's
+   playground, which does not exist. §18 gains the wind span rank as a limit, recorded not fixed.
+
+*Proofs, all green:* eleven specs that were red before their fix and green after — the P5 collider
+sleep gate over the whole library × three scenes, the swept-versus-unswept throw at a static capsule
+and its three companions, the re-seed and the removal on the entity path, the rig's authority and the
+two `ClothRig` edges, the four collider-lifecycle cases, and the two parity scenes. **The cloth suite
+is 251 tests across 26 files**, against M6's 234.
+
+**Deliberately not in this pass:** the `γ` sweep; tightening §7 P1's gate to its measurements;
+building the escape hatch or `ClothDiagnostics`; render interpolation; culling; the unrigged path;
+M4b; the wind span rank, which is recorded in §18 and not fixed; the `ClothRig` serialization adapter;
+and the physics adapter registry gap.
 
 **Performance budget — measured at M0, re-measured at M1, and it still does not hold on its own.** One
 character's full cloth complement — 1,024 particles at 2 substeps × 4 iterations, on a triangulated
@@ -1818,7 +2320,31 @@ attributing cost by deletion applies unchanged. What it licenses is that the col
 between nothing and a quarter of a frame and does not scale with the collider count over the range a
 character occupies. Every library entry's own budget is untouched. `MEASUREMENTS.md` §23.
 
-Re-measure at M4 and M5.
+**Re-measured at M5, and no entry is re-sized — but not for the reason the table reads.** The absolute
+column came back 15% to 25% above M4's, on a machine carrying nineteen other node processes at 30–38%
+background CPU, which is exactly the swing M4's own lesson predicts. What licenses leaving the library
+alone is a *paired* measurement instead: `cloth_library_bench.mjs` never touches
+`WorkerClothSystem` — it drives `cloth_step` over a `ClothState` directly — so the only thing M5
+changed that it can see is the buffer layout, and an interleaved A/B of the two layouts in one process
+reads 0.95 to 0.98 with the two states staying bit-identical for 1,600 steps. §33's ordering stands
+entry for entry. `MEASUREMENTS.md` §39, §42.
+
+**Re-measured at M6, and no entry is re-sized — now with a measured reason rather than only a
+disclaimer.** §10's aerodynamic term, priced in the bench's own §33 scenario, moves each entry by
+−2.7% to +9.3% across three runs, with the sign not monotone in `drag`; and with the *physics* held fixed so the two
+sides simulate the same cloth, the whole feature is **one per cent of a step**. The rest of that
+column is a different cloth — a rope blown horizontal costs 3.24× a rope hanging straight down, which
+is §7's warning arriving in a new setting and is about the rope. Three runs of the same bench within
+an hour put the §17 baseline row at 3.49, 3.83 and 4.26 ms, so the absolute column is still the
+machine: M5's advice to re-measure it quietly stands, and M6 adds that a process count is a proxy for
+load rather than a measure of it. `MEASUREMENTS.md` §49, §52.
+
+**And the budget now means something slightly different.** The worker moves the cost rather than
+reducing it, so 2 ms is still 2 ms — but it is 2 ms on a thread that is not drawing the frame, and the
+question it answers has become "does all the cloth in the scene fit in one worker tick" rather than
+"does one garment fit in a frame". The main thread's share of the §17 workload is 0.18 ms.
+`MEASUREMENTS.md` §41. Re-measure the absolute column on a quiet machine, and check the process count
+first.
 
 ---
 
@@ -1889,15 +2415,42 @@ arbitrary planar configuration. Four coplanar particles that are not an affine i
 read as bent. *Mitigation:* accepted for the fabrics the library targets. If a case appears, the fix is
 a rest-curvature offset in the stencil, which is a change to one row and not to the solver.
 
-**Swept collision is translation-first, and it is two mechanisms rather than one. — MEASURED.** P3
+**Swept collision is translation-first, and it is three mechanisms rather than one. — MEASURED.** P3
 states the limit. M2 found that the half nobody had written down — sweeping the contact **set**, not
 just the poses — was the half that mattered: without it a capsule at 20 m/s created zero rows and the
 sheet was never touched. With the collider's travel folded into the discovery reach, 2 to 40 m/s all
-behave. What remains is that both halves are built from the collider's *centre*: a collider spinning
-fast enough that a point on its surface travels more than its own radius within one substep can still
-be missed. *Mitigation:* more substeps in the affected `ClothDynamics`; genuine CCD stays out of scope.
-The shape of a fix, if one is ever wanted, is to build the discovery margin from the swept **surface**
-travel — `|Δt| + θ·R` — which is one more term and no new structure. `MEASUREMENTS.md` §20.
+behave. Post-M6 found the third: the *particle's* own travel, which M2 argued was covered by §7 P1's
+velocity clamp and is not, by three orders of magnitude — so a **static** collider was tunnelled from
+3 m/s. That is fixed and measured (§7 P3, `MEASUREMENTS.md` §54). What remains is that all three are
+built from the collider's *centre*: a collider spinning fast enough that a point on its surface
+travels more than its own radius within one substep can still be missed. *Mitigation:* more substeps
+in the affected `ClothDynamics`; genuine CCD stays out of scope. The shape of a fix, if one is ever
+wanted, is to build the discovery margin from the swept **surface** travel — `|Δt| + θ·R` — which is
+one more term and no new structure. `MEASUREMENTS.md` §20.
+
+**A handle is a slot index, and a slot was reused the instant it was retired. — FIXED.** §12 says a
+cloth drops its warm-started contacts when the collider behind a handle changes, and `ClothColliderIndex`
+docblocks said the same in two places; the mechanism was `cloth_contact_find` matching on the handle
+alone, which can only work if the handle is *absent* for a step. `add` popped the retired slot
+immediately, so a collider removed and another added within one tick were the same handle. Measured: a
+particle settled on the old floor carried **lambda 0.0981 and a friction anchor in the old collider's
+frame** onto the new one. `remove` now retires into a list `advance` drains one step later — every
+cloth has by then stepped against an index the handle was not in, which is what makes the slot cold.
+It composes with the wake test above: a sleeping cloth notices the handle leaving its set and wakes,
+so it clears its slots before anything can take the number.
+
+**Open — the contact penalty ramps on the *unsigned* residual, and that is load-bearing by accident.
+— MEASURED.** `cloth_contact_dual_update` climbs `k` by `β·|C|`, so a row that is **not touching**
+ramps as hard as one that is, and with `γ = 1` nothing brings it back down: every contact in a scene
+is at `k_max` within a few steps of being discovered, which makes §5.2's measured choice of `β`
+describe a ramp that is not running. Post-M6 made this visible rather than introducing it — with the
+particle's own travel in the discovery reach, rows now appear tens of centimetres out instead of
+sixteen millimetres, so the pre-stiffening happens long before contact. *And the obvious repair is a
+net loss:* making the ramp one-sided takes the speed at which a thrown particle is still stopped from
+12 m/s down to 9.5 with holes, at four substeps — trading cloth passing through a character, which is
+visible, for a hair rope creeping for thirty-seven seconds instead of three, which is not. Recorded
+rather than fixed; the thing that would actually resolve it is a `γ < 1` for contacts, which is
+§5.2's own open number. `MEASUREMENTS.md` §54.
 
 **Open — a rigid collider driven through pinned cloth wraps rather than parts.** A contact row bounds
 the interpenetration; it cannot prevent it, because the cloth has nowhere to go. The playground's
@@ -1942,6 +2495,57 @@ set.
 garment or a runtime hierarchy. Culling (§12.1) covers the off-screen case; the far-but-visible case is
 unaddressed.
 
+**Open — a wake has no direction, and the aerodynamic model has only one term. — MEASURED.** §10's
+normal-facing factor is the whole of M6's aerodynamics, and in uniform air it does exactly what §10
+promises: ninety degrees of flow angle is a factor of five hundred in the force a banner feels. In a
+fluid wake it does nothing — 0.216 against 0.280 — because a wake has velocity in every direction.
+What that leaves open is whether a cloth *in* a wake wants something the linear drag row does not
+carry: the fluttering a real flag does in one comes from a pressure difference across the sheet and a
+shed vortex, not from a relaxation toward a local velocity, and this design has no term for either.
+*Mitigation:* none is needed for what M6 claims — the cloth reads the air the simulation produces and
+is moved by it. It is named because "a banner in a wake looks alive" is what a reader will expect from
+§10 and is not what a drag row alone produces. `MEASUREMENTS.md` §51.
+
+**Open — the aerodynamic factor decides what a particle *is* on a 14.5° threshold, and a bent chain
+reads as a sheet.** §10's normal-facing factor is one expression over the rank of the span of a
+particle's incident stretch rows (`cloth_wind_accelerate.js`): rank 2 is a surface and gets `|û·n|`,
+rank 1 is a link of a chain and gets the complementary `√(1 − (û·t)²)`, rank 0 is a bead and gets 1.
+Rank is decided by `CLOTH_WIND_SPAN_MIN = 0.25` — how much of a second incident direction has to
+survive projection out of the first — and a quarter is **about fourteen and a half degrees**. Below it
+two rows describe the same line and their cross product is a normal built out of rounding, which is
+the failure the threshold exists to prevent and is why it is not smaller.
+
+What it costs is that a **chain bent past that angle at a link is a surface at that link**, and gets
+the factor for one. A rope hanging straight reads as a rope; a rope draped over a collider reads as a
+sheet at every link on the curve, and does so for as long as it is draped, because the rank is
+recomputed from the configuration every step and the configuration is not changing. The magnitude is
+§51's: turning the flow ninety degrees is a factor of five hundred in a banner's acceleration, so the
+two branches are not close together, and a rope reading as a sheet catches the wind broadside where it
+should be slicing it.
+
+*Not fixed, and recorded rather than guessed at.* The threshold is a single number doing two jobs — a
+numerical guard against a degenerate cross product, and a physical statement about when a chain stops
+being a line — and separating them is the shape of a fix: rank the span with a tolerance chosen for
+conditioning, and blend between the two factors over an angular window chosen for looks. Both halves
+would need a measurement neither M6 nor this pass has, and what a draped rope does in wind is a
+question about a scene rather than about a step.
+
+**Open — the ambient is uniform in space and the field boundary is a step.** Two limits of §10's
+fallback, both deliberate and both cheap to see: a gust lifts a whole banner at once rather than
+travelling along it, and a garment carried out of a fluid volume crosses a discontinuity rather than a
+ramp. The first is what makes the no-simulation case cost one sample rather than one a particle; the
+second is small where the ambient is the far field the volume relaxes toward and visible where it is
+not. A blend would want a falloff distance, which is an authored quantity of exactly the kind §3.4
+spent a section removing.
+
+**Open — a fluid volume's wake is steady at a grid a frame can afford. — MEASURED, and it is the
+fluid system's rather than cloth's.** At 18, 26 and 34 cells across, with the simulator's damping and
+vorticity confinement at both ends of their range, the air a banner's width behind a solid post varies
+by under 0.03 m/s: a velocity deficit, not a shedding street. The deficit is real and is a third of
+the free stream, which is what the cloth reads; what is not there is the unsteadiness. Resolving a
+shedding shear layer costs 15 ms a step at 26 cells and 35 at 34, against 5 ms at 18.
+`MEASUREMENTS.md` §51.
+
 **Open — `stretch` is a weak control, and it is not obvious what would make it a strong one.** M1
 measured the strain-limit row removing about a third of the peak over-stretch and never reaching its
 own allowance, because it is a second hard row competing with the first for the same trust region and
@@ -1953,11 +2557,40 @@ penalty band, making `k_max/(m/h²)` a material property rather than a global (w
 §4 shows trades stretchiness against settling); or accepting that near-inextensibility is what fabric
 *is* and demoting `stretch` to a documented weak knob. M2's contacts do not bear on it either way.
 
-**Open — the write-back has no interpolation.** §12 gives cloth `PhysicsSystem`'s producer /
-`__interp_restore` contract, and M1 does not wire it: cloth writes `Transform64` at the fixed rate and
-nothing blends between ticks, so a cloth updates at 60 Hz on a 165 Hz display. That is visible and it
-is not wrong — the poses are authoritative, they are simply held. It lands with M5, where the worker
-makes the fixed-step producer contract load-bearing for a second reason.
+**Open — the write-back has no interpolation, and M5 decided it does not land with the worker.** Cloth
+writes `Transform64` at the fixed rate and nothing blends between ticks, so a cloth updates at 60 Hz on
+a 165 Hz display — 105 of every 165 frames repeat a pose. That is visible and it is not wrong: the
+poses are authoritative, they are simply held. **How** visible is now measured, on M3's cape geometry:
+a node covers 0.47 link lengths in a fixed step at a walk and 1.33 at a sprint (`MEASUREMENTS.md` §43).
+
+What M5 changed is the shape of the remaining work, in three findings that between them delete the
+sentence this note used to end with.
+
+- **`PhysicsSystem`'s producer / `__interp_restore` contract cannot express half the feature.**
+  `Interpolated` is an entity-keyed marker and a rigged garment's joints were `Node3D`s, not entities
+  (§13.1). There was nothing to put the component on and no key to file a snapshot under.
+  **Post-M6: a joint is an entity now** (§3.2, §11.2), so this finding's *reason* is gone even though
+  its conclusion is not — the published-pose slot below is still the cheaper half and still the one
+  cloth needs, and an entity-keyed marker on a hundred joints a garment is not obviously better than
+  one array copied at join. What changed is that it is a trade rather than an impossibility.
+- **Cloth needs only the publish half.** `__interp_restore` undoes render-time writes before the
+  simulation reads them; cloth's state is its particle array and its write-back never touches the
+  anchor it reads, so there is nothing to restore. The restore it *does* depend on — an anchor on a
+  physics-driven character — it already gets from `PhysicsSystem`.
+- **The worker removes the cheap implementation.** A render-time pass cannot read
+  `ClothState.position`, because the worker owns it from dispatch until the next tick's join, which is
+  essentially all of the time outside the fixed pass. What is needed is a **published pose slot**: the
+  last two steps' node poses, copied out at join and blended at render time — the same double-buffered
+  publish slot `WorkerFluidSystem` names as the unbuilt prerequisite for its own render-time reads.
+
+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. For the §17 workload that is about
+0.12 ms a frame — 20.5 ms a second at 165 Hz, against the 10.9 ms a second M5 leaves on the main
+thread and the 217 ms a second it cost before. **Interpolating a cloth would roughly triple the main
+thread's share of it and leave it at a seventh of what it was**, which is the honest shape of the
+trade: the feature is affordable because M5 happened, and it is not free. The cloth-shaped version is
+*simpler* than the engine's, not harder: no restore pass, no serialization adapters, no log, and it
+covers the rigged and entity paths identically because both end in a pose per node.
 
 **Open — the subtree is walked once.** A rope's links do not come and go, so `cloth_seed_subtree` runs
 on first step and `ClothSystem#reseed` is how a caller says the structure changed. That is the same
@@ -1965,3 +2598,13 @@ contract `TransformAttachment#parent` already carries, and it is the right defau
 have is a way to *notice*. An entity added under a live `Cloth` is silently not simulated until
 someone re-seeds, which is a class of authoring mistake with no diagnostic behind it. `ClothDiagnostics`
 is where one would go.
+
+**Post-M6 narrowed this: a `ClothRig` is not part of it and never was.** §3.1 says the discriminator
+between the two paths is a component's *presence*, and `ClothSystem#dependencies` is
+`[Cloth, Transform64]` — so a `ClothRig` added to a live cloth completed no tuple the system observed
+and one removed broke none. A character whose rig arrived a fixed step after its `Cloth` simulated its
+**whole skeleton as one rope** (in a dev build, through `gpu_authority_assert_cpu`, it threw), and one
+whose rig was taken away kept driving the joints. Both edges are now watched by an `EntityObserver` on
+`Cloth` + `ClothRig` inside `ClothWorld`, so the discriminator is read whenever it changes rather than
+once. The **subtree** case above is untouched and stays open: an entity appearing under a live rope is
+still a `reseed` the caller has to ask for.