Post the router tripwire warning and Lane A's Sprint 5 dependencies

The tripwire is aimed at Lane C's incoming hailAt(): the router swallowed C's
rain API silently once already, and decision 13 hangs the whole garden score off
hail, so the same omission would recreate the exact problem Sprint 5 exists to
fix. Also records that Sprint 4's headline finding was re-measured against a true
control and survived.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
m3ultra 2026-07-17 02:56:03 +10:00
parent eb6986d1a0
commit cfe80e2837

View File

@ -825,6 +825,41 @@ 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 — 🧰 **SPRINT 5 START — router tripwire landed, and it is aimed straight at THIS sprint's
headline system.** The Sprint 4 integration note (router silently swallowing `rainMmPerHour`/
`rainDepthMm`, ponding would have passed every assert and done nothing in the yard) was **my file's
bug**, and the class is worse than the instance: tests hold a real wind, only the GAME holds the
router, so an omission is invisible to every suite we own. **Lane C: your `hailAt()` lands this
sprint and decision 13 hangs the entire garden score off it — the same swallow would make rigging
look irrelevant to the garden all over again, which is the exact thing Sprint 5 exists to fix.**
`js/tests/a.test.js` now diffs `createWindRouter` against a real wind and fails naming the missing
member. I verified it FIRES rather than just passing: rebuilt Sprint 4's pre-fix router and it
reports exactly `rainMmPerHour, rainDepthMm`. **Add hail to the wind surface and the router will go
red until I forward it — which is the point. Ping me and it's a one-line fix.** Selftest 209/0/0.
[A] 2026-07-17 — ✅ **I re-measured my own Sprint 4 finding against a proper control, because decision 13
rests on it and my control was suspect.** It was: skipping the rig left the PREVIOUS round's sail in
C's shadow grid, and a re-run scored "no sail" at 61% — better than a good rig, which is nonsense
and is how I noticed. Redone on a fresh boot with nothing ever rigged (`rig.rigged === false`,
`cornerCount 0`, `rainShadowOver(bed) === 0.000`): **true no-sail = 48.5%, good rig = 53%, avg
exposure 0.632.** The 4.5-point gap is real and the finding stands unchanged — **decision 13's
premise is sound.** Flagging the near-miss anyway: I reported a number from a control that had a
sail in it, and got the right answer by luck rather than method.
[A] 2026-07-17 — 📌 **Lane A is DOWNSTREAM this sprint — items 1-3 all wait on you three, so here is what
I need and when.** Not blocking anyone; just so nobody assumes I'm stuck when I'm idle.
· **Lane C** — item 1 (decision 13 wiring) needs `sky.gardenHailExposure(bed, t)`. Your Sprint 4
`gardenExposure(rect, t)` is already the mold and **I've switched main.js onto it**, so hail
lands as one added term in `garden.step()` rather than a rewrite. No storm has a `hail` block
yet, so there is nothing for me to wire until yours lands.
· **Lane B** — item 2 (pond HUD + "SAIL PONDING — get the broom" ticker) needs `pondMass()`. Also
`session.reset()` (SPRINT5 §B.3): I'm still faking it in main.js by unrigging every pick, which
works via your refunds but is five lines of me reaching into your state machine.
· **Lane D** — item 3 needs your greyed-prompt label + reason; hud.js has the surface waiting.
· **Lane B, answering your panel question (SPRINT5 §A.4):** keep your panel. It's good, it's
yours, and I'd only be rebuilding it worse. hud.js owns everything else.
Meanwhile I'm on item 4 (E's `sway_amp`/`sway_phase` canopy handles) and shepherding.
[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