Post Sprint 4 gate 1 and the garden-HP finding

The face's first act was to expose that garden HP barely responds to rigging: a
perfect rig scores 53% on storm_02 and rigging nothing at all scores 48%. Cause
is measured (rain shadow decays 0.38 -> 0.04 as wind builds) and it is not a bug
in anyone's lane — but it means decision 7's headline score is nearly
independent of the game. Flagged for Lane C with the numbers; the design call
about whether garden HP is even the right storm score is left open.

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

THREADS.md

@@ -825,6 +825,57 @@ Format: `[lane letter] YYYY-MM-DD — note`
     `pickup_anchor` empty, read that, else the table top is fine. That plus B's three lines above and
     the §7 scenario is hand-playable.
 
+[A] 2026-07-17 — 🚩 **GATE 1 (Sprint 4) — THE GAME HAS A FACE. You can play a whole round with a mouse.**
+    On main. `python3 server.py` → forecast card → click a storm → click anchors to rig → ENTER → ride it
+    → aftermath → play again. No console. Selftest **184/0/0**. What landed: `hud.js` (world-anchored
+    per-corner kN load bars, wind meter, gust telegraph banner, garden HP + "% kept dry by the sail",
+    carry chip, event ticker), Lane B's picking wired to the phase machine, forecast card, aftermath with
+    verdict + gnome collateral, plant damage swaps, page retitled. **John: this is your cue to play a
+    round and write the three sentences.**
+
+[A] 2026-07-17 — 🔴 **THE MEASUREMENT THAT MATTERS, AND IT IS BAD: garden HP barely responds to rigging.**
+    The face's first act was to expose this. Same storm_02, scored end to end:
+      · good rig (small twisted quad, rated hw, eased to 0.85, **holds 4/4 corners all night**) → **53%**
+      · cheap drum-tight 123 m² span (loses all 4 corners) → **49%**
+      · **NO SAIL AT ALL** (control, nothing rigged) → **48%**
+    Five points between a perfect rig and *not turning up*. The garden score is very nearly independent
+    of the entire rigging game.
+    **Cause, measured, and it is nobody's bug:** sun coverage over the bed holds ~50% all storm, but
+    `skyfx.rainShadowOver(bed)` decays **0.38 → 0.04** as the wind builds (avg 0.23). Driving rain blows
+    under the sail and the shadow walks off the bed — Lane C's model being *right about weather*.
+    **Why decision 7's drain constant cannot fix it:** the rigged-vs-bare gap is the dry fraction itself
+    (~23%), so no value of GARDEN_DRAIN separates them — at 1.6 both died, at 0.9 both sit near 50. I set
+    0.9 so the loop is playable and scores *something* (good rig 53 = win, bare 48 = loss), and wrote the
+    numbers into the constant's docstring so the next person doesn't re-derive them. **The lever is the
+    shadow geometry, not the drain.**
+    **Lane C — this is yours and I'm not touching it:** options I can see are capping the rain-angle
+    offset (a 4 m sail in a 20 m/s wind currently throws its shadow clean past a 4 m-deep bed), or
+    softening how fast offset grows with speed, or storm_02's rain curve. **Or the honest design answer:
+    a sail genuinely does not keep rain off in a gale — that's why DESIGN.md pairs sails with DRAINAGE —
+    in which case garden HP is the wrong headline score for a storm and "corners lost" (which IS
+    responsive: 1 vs 4) should carry the aftermath. That's a design call above my pay grade; flagging,
+    not deciding.** Ponding (decision 10) doesn't touch this — it's about load, not about the bed.
+
+[A] 2026-07-17 — 🙏 **LANE B — two small asks, both from wiring your UI into the loop (which is excellent,
+    by the way: markers, cycle, shift-remove-with-refund and the quad preview all worked first try
+    through real PointerEvents).**
+      · **`session.reset()`** — "play again" needs last round's rig gone. I do it from main.js by
+        unrigging every pick and `setSpares(0)`, which walks the budget back to $80 via your own refunds,
+        so it's correct — but it's five lines of me reaching into your lane's state machine, and one
+        method on your side would say it better.
+      · I pass `panel: true` — your prep table is genuinely good and I didn't rebuild it, so it and
+        hud.js share the screen (yours top-left, mine top-centre/bottom). If you'd rather own the whole
+        prep screen, say so and I'll pass `panel:false` and rebuild the table in hud.js.
+
+[A] 2026-07-17 — 🔧 **Testing note that has now bitten me three times in this environment, for whoever
+    hand-drives the game next (Lane D, your on-record runs especially).** rAF is throttled in a hidden
+    tab, and *input events wake it*. So: project an anchor to a pixel, click it, and rAF fires in
+    between → `cameraRig.update()` snaps the camera back to the follow rig → your click lands on
+    nothing, and it looks exactly like broken picking. Lane B's picking is fine; my test was racing the
+    camera. Project and dispatch in the SAME js call and it's deterministic. (Previous two: assigning to
+    `KeyboardInput.holding`, which is a getter; and hand-driving `hud.update` once, which leaves the
+    throttled label canvases blank.) None of these were game bugs — all three looked exactly like game bugs.
+
 [A] 2026-07-17 — ✅ **DECISION 2 LANDED — and the yard finally teaches the right lesson.** Posts in to
     (−4.5,5.5)/(4.0,6.0), p3 at (0,7), E's house + both gum trees dressed in, their `branch_anchor_*`
     registered. **7 anchors → 11.** Quads covering the bed went from "nothing under 110 m²" to **34 in