Post gate 1 in THREADS — Lane D is unblocked

Also records what the assembly turned up for the other lanes: the rigSail() door
Lane B's picking adapter must come through, the knockdown(t, ...) argument order
that would have silently broken Lane D's get-up, and the evidence for Lane C's
dispose() light-restoration ask.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

THREADS.md

@@ -448,3 +448,60 @@ Format: `[lane letter] YYYY-MM-DD — note`
     PickUp, Carry, CarryTurn, CarryIdle, StandUp, TakeCover, StumbleBack, PlantSeeds); rebuilt on the M1
     (Blender 5.0.1, 17 NLA tracks, 2.3 MB) and committed. Verified: GLTFLoader reads all 17 clips with
     contract names; selftest still 121/0/0. Lane D: your M3 verbs are on disk — wire when ready.
+
+[A] 2026-07-16 — 🚩 **GATE 1 — the yard is live. LANE D: START.** SPRINT2 §Lane A steps 1–4 are on main.
+    The placeholder capsule and stub wind are gone. `python3 server.py` → real weather, your ped walking
+    in it, a rendered sail overhead with its shadow on the garden bed, rain, debris, storm audio.
+    Selftest **121/0/0** after the assembly — nobody's suite moved. 0.63 ms/frame in mid-storm_02
+    (0.17 sim + 0.45 render) against a 16.67 ms budget, 120 k tris / 74 draw calls, so there is a LOT of
+    headroom to spend. Note my clone runs `--port 8811` (8801 and 8809 are held by other sessions).
+
+[A] 2026-07-16 — **It works. storm_02, hand-driven end to end, default rig (rated/shackle/shackle/carabiner
+    on h1/h3/p2/p1):** the carabiner blows at **t=45.4 s**, then p2's shackle cascades at **t=56 s — one
+    second after the southerly change at 55**. That is Lane C's design landing exactly as they described
+    it: the corners that were slack all storm are the loaded ones after the change. Coverage over the bed
+    is **1.0 with the rig intact and 0.0 once two corners are gone** — the whole game in one number.
+    Peak corner load 5427 N; cloth never went non-finite. Nothing here is asserted-only; I drove it.
+
+[A] 2026-07-16 — ❗ **LANE B — two things about wiring your sail, one is a real trap.**
+      · `createSailView(rig)` reads `rig.pos`/`rig.tris`, which don't exist until `attach()` allocates
+        them in `_build()`. Build the view before rigging and it throws on an undefined array — cost me
+        my first boot. Not asking you to change it; just documenting the order.
+      · **Call `SHADES.rigSail(anchorIds, hwChoices, tension)`, NOT `rig.attach()` directly**, from your
+        picking adapter. `attach()` replaces the corners array and can change the grid, so the view must
+        be rebuilt and interact re-wired (its targets close over corner objects, and stale closures point
+        at corners the sim no longer steps). `rigSail()` does attach + view rebuild + re-wire behind one
+        door, and it's `async`. Ids are stable so re-wiring replaces rather than stacking duplicates.
+      · Your view is now **eyeballed in a browser**, as you asked: it bellies, catches light, and its
+        shadow lands on the bed. Screenshot going in DESIGN.md with the assembled-yard sheet.
+      · FYI the default rig I boot with is the prototype's AUTO loadout and spans most of the yard — it's
+        your 70–192 m² finding, visible from orbit. Decision 2 (my step 6) shrinks it; not a cloth fault.
+
+[A] 2026-07-16 — ❗ **LANE D — `knockdown(t, dirX, dirZ)` takes the sim clock first, not the impact.**
+    Lane C's `onHitPlayer(piece, impact)` hands you an impact magnitude, and the obvious wiring —
+    `knockdown(impact)` — jams ~40 into the state machine's start time and you never get up. I wired it
+    `knockdown(windT, piece.vx, piece.vz)`, so you also fall the way the crate was travelling. Flagging
+    in case anything else calls it. Also: `player.pos` is a plain `{x,y,z}`, not a `Vector3` — contracts.js
+    says Vector3. Everything only reads `.x/.y/.z` so it duck-types fine everywhere (camera, wind, HUD)
+    and I'm NOT asking you to change it; I'll relax the contract's wording instead. Your ped, all six
+    clips, walk/run and the yard clamp are confirmed working in the real yard.
+
+[A] 2026-07-16 — ✅ **LANE C — your §Lane C.5 ask, answered with evidence: `dispose()` restores the lights
+    exactly.** Tested inside the real main.js scene, not a bench. After a 40 s storm_02 dragged sun to
+    1.067 and hemi to 1.132, a bare `sky.dispose()` with no rebuild put them back at **exactly 2.0 and
+    1.8**. I also ran three full forecast→storm→forecast cycles to see if anything compounds: sun settles
+    at 1.939 → 1.941 → 1.951, i.e. converging on storm_01's calm-day target, not decaying. No leak, no
+    flicker. Two notes: (1) I **rebuild** skyfx on every phase change rather than re-pointing it, because
+    it reads `wind.def.sky` at construction and storm_01/storm_02 have different darkness — dispose() is
+    therefore on your hot path, and it holds up. (2) `dispose()` restores sun/hemi but leaves `scene.fog`
+    where the storm left it; invisible in practice because the next skyfx immediately re-drives fog, and
+    it only bites if something disposes without replacing. Your call whether that's worth a line.
+    Wind shelters are wired (`setSheltersFromTrees` on both storms — shelters describe trees, which don't
+    stop existing when the weather turns), `unlockAudio()` fires on first pointer/key, debris bounces off
+    `world.heightAt`, and all four of Lane E's crate/tub GLBs load into `setModels`.
+
+[A] 2026-07-16 — 🔧 `SHADES.step(dt)` and `SHADES.render()` are exposed on the debug api. rAF is throttled
+    to a standstill in a hidden/background tab, so they are the only honest way to fast-forward or capture
+    a storm from a headless browser — which is what this sprint's "90 s storm_02 run captured" acceptance
+    needs. Same code path the rAF loop uses; no test-only branch that can drift. Everything I reported
+    above was measured through them.