C asked in THREADS whether to land a one-liner making gardenHailExposure read
sail.porosity. Answer: it is already wired, in merged main — I did it in SPRINT9
(e576f5c): skyfx.step refreshes sailPorosity from world.sail.porosity, and
gardenHailExposure folds hailBlockFor(size, sailPorosity) into what it returns.
No one-liner needed.
But "already wired" was untested end-to-end. The only test of the hail leak,
weather.selftest's 'fabric choice is real', REIMPLEMENTS the formula inline with
hailBlockFor + hailAt — it proves the primitive and the arithmetic, not the
plumbing. A regression in the plumbing (the :738 refresh dropped, the
wind.def.hail.size lookup resolving wrong, hailBlockFor no longer folded in)
would leave that test green while the game quietly stopped leaking hail. That is
the measure-a-copy pattern this whole browser suite exists to avoid.
New assert 'porous cloth leaks pea hail into the garden, membrane blocks it'
drives the real sky.gardenHailExposure. The isolation is exact: ONE settled,
intact rig, sampled at ONE hail instant, porosity flipped 0.30<->0 between reads.
sky.step(0, t, {sail}) refreshes sailPorosity and rebuilds the shadow grid at the
same instant without advancing physics, so shadow geometry is identical across
the two reads and `block` is the only thing that moved. Measured:
pea (size 0.7): cloth 0.346 vs membrane 0.292 -> porous leaks +18%
ice (size 1.4): cloth 0.458 vs membrane 0.458 -> identical, the no-op
No storm flight, no second rig — deliberately. Two rigs whose corners diverge
share no shadow, and that difference is a cascade not a fabric: membrane cascades
on the ice night, so a naive two-flight version reads a FALSE ice-night
difference. The same-rig swap removes it.
And it can fail: if porosity stops reaching the exposure, both reads collapse to
the membrane value (measured: 0.2917 == 0.2917), cloth > membrane*1.05 is false,
red. The ice check is exact equality — if porous ever starts leaking big ice,
that goes red too.
Selftest 288 passed, 0 failed, 0 skipped.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
SPRINT10 gate 1a, carried since Sprint 8. Everything that was a module constant
— bed rect, house line, tree and post placements, shed, gnome, sun angle, fence
sides — is now data/sites/backyard_01.json, and world.js is a builder.
The extraction is byte-identical, and that's checkable rather than claimable:
E's branch-anchor tripwires pin five positions to 6 dp, a.test's quad-band
asserts pin the whole rigging geometry (>=3 quads in 18-45 m2, full coverage
still >45 m2), D's ladder field and B's balance lines all pass unchanged.
287/0/0.
It's byte-identical by construction, not by luck: the site-derived values keep
the builder's original local names, so ~500 lines of geometry that was already
correct is untouched and only its SOURCE changed.
Two things earned their place:
Anchors carry D's `work: "cloth" | "bracket"` — the MECHANISM, not the type. A
post is tensioned from a cleat at its base and a tree strop is thrown, but a
bracket bolted up a bare wall is the one you cannot fake. Keyed on mechanism
because `type` is a closed enum ('house'|'tree'|'post') that site_02's carport
doesn't fit, and needsLadder keyed on type FAILS OPEN there — the ladder
silently vanishes and you re-rig a 2.6 m bracket standing on the grass.
p4's swept position table moved INTO the JSON's `_why`, beside the coordinate it
justifies. That table is the only thing stopping someone nudging the post toward
the bed and collapsing DESIGN.md's central tension; it belongs with the number,
not in a file the number left.
validateSite() fails loud: sites are content, and a missing bed silently becomes
NaN coverage while a missing anchor list silently becomes an unriggable site.
createWorld now requires a site and says so.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
SPRINT9 task for B+D. The demoted guard compared the worst corner's mean LOAD
across two windows and called the difference a "trend". The integrator's
diagnosis was that its clock was wrong — held at t=0, storm_02's compressed
rain ponds the cloth during the guard's own windows. That mechanism is real,
but it is not the bug, and neither of the two suggested fixes works. Measured
on the dressed yard, 0 s settle vs 12 s:
probe under CALM, held in prep 13% vs 17%
probe under STORM, held clock 24% vs 104%
probe under STORM, advancing clock 24% vs 104%
probe under STORM, RAINLESS 17% vs 96%
Every variant is either flat — calm cannot excite the cloth, so the guard is
vacuous and passes forever — or INVERTED, firing hardest on the properly
settled rig. Rain is not the culprit: the rainless probe ponds 1 kg and still
inverts. Advancing the clock isn't a fix either, because RAIN_TIME_COMPRESSION
is 40× and 4 s of storm is 160 s of rain regardless.
What a load-trend measures is the rig LOADING UP when the wind changes, and a
taut settled cloth ramps harder than a limp unsettled one (0.63 -> 1.23 kN vs
0.44 -> 0.52). The observable was pointed at the storm's arrival, not at the
cloth. No threshold, clock or rain switch fixes that.
"Settled" is a statement about the cloth, so ask the cloth. sail.js gains
nodeSpeed(): RMS node speed out of verlet. Sampled over 2 s of the same calm
prep the rig already stands in — no wind change to ramp against, no compressed
rain, and nothing left in the rig but two more seconds of prep a player does
anyway. Measured:
settle 0 s 4 s 12 s 30 s
speed 0.19 0.014 0.017 0.007 m/s (pyrrhic quad: 0.23 -> 0.028)
An order of magnitude, in the direction the word means. Absolute check at
0.08 m/s, not a trend: the cloth breathes at 0.02 and the transient sits at
0.19, so there is real room for a line.
Promoted back from warn to a hard failure — and it earns that by being able to
fail. `the settled-at-entry guard can fail` flies the same line with NO settle
and asserts the guard refuses it. A guard nobody has seen fail is
indistinguishable from one that cannot, which is exactly how this one survived
two sprints being both vacuous and inverted. The control is flown up front in
run(), because Suite.test() does not await.
The old guard also left 43 kg of water and 4 s of storm load in the rig before
the storm started; the suite was flying a wet rig into a dry entry. It didn't
move the peaks (the storm's own peak dwarfs it) but it was never true.
D: this is yours to veto. Selftest 277 passed, 0 failed, 0 skipped.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
site_audit answers "is this site winnable?" before it ships — the check that
was missing when SPRINT6 shipped a yard whose bed-covering quad pulled 7.4 kN
against a shop that holds 6.5. It enumerates in-band quads, flies the real
storm headless, maps each corner to the cheapest tier that holds it, and
verdicts against the $80 budget. On backyard_01 it independently reproduces
THE LINE: p1,p2,p3,p4 at $65 + $15 spare, matching balance.test to within 2%.
It also caught three of my own bugs, which is the point of building it:
· it settled on STORM wind frozen at t=0 — the exact anti-pattern
balance.test documents at 1.94 kN vs 0.40 kN. Now settles on the calm
day on a running clock, the way main.js does.
· peakLoad is peak-since-ATTACH, so the settle transient was being
reported as a storm peak. sail.js gains resetPeaks().
· its p4 was typed from world.js's postSpecs, missing that posts are RAKED
8° away from centre — 0.56 m off. The audit now re-derives all four posts
from live world.js on every run and hard-fails on drift.
That last check is deliberately narrow. Node CANNOT dress: dress() needs
GLTFLoader (bare 'three') and fetch()es .glb over file://. createWorld() still
SUCCEEDS in node — it just returns the GRAYBOX yard, house at x=±5, no branch
anchors. So a headless tool that "reads world.js for the real yard" gets the
fictional x=±5 house that cost two sprints. Reading live code is not reading
truth. Verified in-browser: the dump matches the dressed yard on all 12
anchors. Posts are the only thing dress() never touches, so they're the only
thing worth cross-checking — and that check is what caught p4.
C IS RIGHT ABOUT p1 AND I WAS WRONG, for the third time. My comment claimed
C's 1.08 kN didn't reproduce, that p1 peaked at 1.27 and the line won on TIME
rather than headroom. Re-measured on the dressed yard, same flight:
shade cloth p1 0.98 kN 0/4 lost membrane p1 1.23 kN p1 LETS GO
p1 never touches its 1.2 kN rating on cloth — 18% of real headroom. Where 1.27
came from: a loadout where a corner BROKE and dumped its share onto p1 (the
same quad with hardware the budget can't buy reads 2.48). Any p1 number
gathered without checking `lost` measures a cascade, not a fabric.
So the fabric is the decision, not a skin: 0.98 vs 1.23 against a 1.20 rating
is the difference between the $5 carabiner holding the wild night and failing
it. New assert `fabric decides p1` locks that in, so nobody has to trust the
paragraph.
selftest.html rendered ['A'..'E'] while importing BAL too, so the balance
suite ran, counted toward the summary, and had every row silently dropped —
including, had one gone red, the row saying which assert failed. The merge
gate was invisible in its own report. My bug: I added the import, not the
renderer. Now derived from the report.
Selftest: 276 passed, 0 failed, 0 skipped (LANE BAL now visible).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Selftest 275/0/0. balance.test: **$80 · shade cloth · p1,p2,p3,p4 ->
hp 63, 0/4 lost — CLEAN WIN.** First time the wild night has been
winnable without sacrificing the rig. C found the line and the $10 gap;
this spends both levers together, as they only work together.
Fabric is priced at $0 BOTH WAYS, and that is a finding, not laziness.
SPRINT6 asked me to price the difference; I measured it and there is no
price at which membrane is a sane buy — it is dominated:
buys: +26% hail, but only on the PEA-hail nights (hailBlockFor(0.7,
0.3)=0.74), which are the easy ones — on storm_02 (1.3) and the
ice night (1.4) a knit already blocks 100%, because a 2 cm stone
can't pass a 2 mm weave (C's ruling). Plus rain, at 0.25 of the
drain vs hail's 5.0 — ~5% of the damage.
costs: double the wind load, and it PONDS.
Charge for that and you've shipped a trap. Free, it's DESIGN.md's actual
words — "fabric choice is a forecast bet" — and the bet is real: cloth on
the windy nights, membrane when the hail is small and the wind is mild.
If A ever raises rain's weight, membrane earns a price.
Wired C's hailBlockFor into skyfx.gardenHailExposure, which nothing
consumed — without it the fabric choice would have been cosmetic, which
is the bug class this repo keeps finding.
I did NOT reproduce C's numbers, and the comment says so rather than
repeating them. C reported p1 dropping to 1.08 kN (under a carabiner's
1.2) with cloth + 0.40. I measure 1.27, and p1 never crosses under 1.2 at
any combo. The line still wins on a $5 carabiner — but because 1.27 vs
1.2 is a 6% overshoot and breaking needs 0.4 s SUSTAINED, not because the
corner got under its rating. The margin is TIME, not headroom, and it's
thinner than the table implies: anything that lengthens storm_02's gust
HOLDS could take it. Flagged for C in THREADS.
The old t2 quad stays as the sacrifice-play control (hp 56, 2/4 lost) —
now a worse bet the shop will happily sell you, rather than the wild
night's only outcome.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The integrator demoted my settled-at-entry guard to a warning at the Sprint-8
merge and handed B+D the redesign. Investigating it refuted the stated cause and
found a better observable.
The ponding diagnosis does not hold: every storm's rain curve starts at [0,0], so
storm_02.rainMmPerHour(0) is 0.0 mm/h and a held clock rains nothing. The real
confound was that the guard measured in the STORM's wind while the rig settled in
CALM — and that calm->storm step is one the REAL GAME ALSO HAS (wind.use() swaps
on the phase change), so it was never a harness artifact. Their 2 s windows were
also shorter than the cloth's breath: 2 s reads a 32% trend on a settled rig
where 3 s reads 6%.
But fixing the clock isn't enough, because LOAD cannot answer this question at
all. In calm there is no transient to see — the unsettled rig is LIGHTER (0.30 kN
vs 0.47 settled) and the trend test passes at every settle length from 0 to 20 s.
A guard that cannot fail is decoration, which is precisely what StumbleBack and
the fake skips were.
So ask the physical question: has the cloth stopped MOVING. Mean node drift
separates ~6x either side, and cannot be confused by wind or water:
unsettled (0 s) -> 212 mm/s (cover quad) · 208 (miss quad)
settled (8-20 s) -> 35 mm/s worst breath, typically 4-6
Limit 100 mm/s. Proved it FAILS before trusting it to pass: sabotaged the settle
to 0 s and it fired — "cloth still drifting 212 mm/s (limit 100)".
The integrator's 600 N floor was a sound amendment to the LOAD design; it isn't
carried over because drift has no units of force and 212-vs-35 is not a judgement
call. 274/0/0, all five balance asserts green.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Ran every remaining suite-vs-game difference one at a time against the real
storm. None of them moves the corner count:
live calm settle (running clock + calmWind) entry 1.94 -> 0.40 kN, 2 lost
live tree sway t2 4.33 -> 4.55 kN, 2 lost
walked repair timing (~4 s) 2 lost
all three together hp 58, 2 lost
Then checked the structural candidates: anchors are bit-identical between
harnesses (all four, 0.0000 m), ring order is identical (p4,t2,t2b,p3), and
wind.sample() at t2 matches to 2 dp (36.49 m/s @ t=75.9) across suite, suite
with shelters, and the live router.
So I re-ran the live game itself, fresh page, A's exact line, tension 1.0:
live -> hp 58, 2 lost [t2,t2b], t2 peak 4.55 kN
suite -> hp 58, 2 lost [t2,t2b], t2 peak 4.54 kN
They agree. The suite was right.
RETRACTED: my Sprint-7 "12 s settle flips 2 lost -> 1". It does not reproduce —
0 s and 12 s both end 2 lost, because the storm's own peak (4.54 kN at t=75.9)
dwarfs the attach transient. The settle is a real fidelity fix and NOT the
corner-count cause. B's arithmetic was right from their first post: t2 pulls
~4.5 kN, a shackle is rated 3.2, and the spare cannot save it (measured: t2b
blew @9 s, repaired, blew again).
Landed anyway, because it is still true and still worth guarding: fly() now
settles the way main.js drives prep (calmWind on a running clock, not the storm
frozen at t=0), and a new "the yard is SETTLED when the storm starts" assert
holds every run under 1.0 kN at entry. 266 pass / 1 red — the red is the
pyrrhic-win design call, not a bug, and it now says so.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Drove the live game — settled through prep, rig verified unchanged across
the phase boundary (contaminated: false) — and it returns hp 58, 2 lost.
This suite returns hp 57, 2 lost. A's hp 58 was right and reproduces to a
point; A's "1 lost" was the miscount. The two harnesses now agree on both
numbers and the dispute is over.
All three SPRINT8 candidates tested; none flips the corner count:
V1 settle under live calm wind + world.update sway -> 2 lost, t2 4.4
V2 ... and live sway through the storm too -> 2 lost, t2 4.6 (worse)
V3 repair delayed 0 / 3 / 6 / 10 s (a real walk) -> 2 lost
Nothing could flip it, because losing 2 is not a bug — it is the shop:
t2 4.6 kN, t2b 3.5, p3 3.5 all need the $30 rated shackle; p4 2.9 takes
a $15 shackle. Holding all four = $105, $120 with the spare a repair
needs. Budget is $80. Three corners sit above shackle grade and $80 buys
two, so the wild night's best line ends hp 58 with the garden alive and
the rig dead.
That is SPRINT8's escape hatch, and it's a design question handed to A:
`lost < 2` calls this a loss, DESIGN.md calls it the story. The assert now
asserts the half that IS physics (the garden must survive, hp >= 50) and
reports the corner count as the open question, so the suite states the
measurement rather than pre-empting A's ruling.
Landed D's settled-at-entry guard, as a windowed TREND test rather than an
instantaneous one: measured, the worst corner oscillates 0.9 -> 1.9 -> 1.3
-> 1.7 kN under constant wind because damping is deliberately light, so
there is no single settled value and a "has it stopped moving" check can
never pass — it would just be a flaky assert someone deletes. Comparing
consecutive 2 s means catches a real transient and tolerates the breathing.
Same lesson as the statics assert in sail.selftest.
Selftest: 266 passed, 0 failed, 0 skipped — green for the first time since
SPRINT6.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
THE CAUSE, and it is not a winner: balance.test.js built skyfx with no camera,
and skyfx.step() opens `if (!camera) return;` — so the hail shadow grid was
never rebuilt across all 5400 calls and every loadout was scored as though it
had no sail. hp 36 IS the bare-bed number. Measured with the camera as the only
variable: hailShadowOver(bed) peaks 0.000 vs 1.000, hp 36 vs 69. Neither harness
was lying; one was flying a yard with no cloth in it. Camera + wind shelters
added — the suite must drive what the game drives.
MY ERROR, named: the hp-58 win was measured at tension 1.0 and I never declared
it. At the shop's default 0.9 my own end-to-end also loses 2 corners.
STILL OPEN: this suite says 2 corners lost, my end-to-end says 1 at tension 1.0.
Ruled out by measurement, each worth <=0.02 kN: shelters, frozen vs live tree
sway, the scripted repair. Next suspects named in the skip: session.commit() vs
rigSail(), and main.js passing debris as rig.step's 4th arg (debris ADDS load,
so it should break MORE here, not less — that inversion is the thread).
And the find that explains how this survived a merge: Suite.test() ignored its
return value, so `return "SKIPPED — ..."` was recorded as a PASS. The
integrator's storm_02 skip was a fake pass; so was mine for storm_01; `skip: 0`
in every report we ever printed was the tell and nobody read it, me included — I
misread one of those fakes as my win reproducing. test() now honours the string,
and rejects async fns outright (they hand back a Promise that cannot throw
synchronously, passing forever while proving nothing).
That guard immediately caught its own author: BOTH my wind-router tripwire tests
were async and have asserted nothing for two sprints — including the sprint where
I reported the tripwire "caught its first real omission". It had, in a hand-run
probe, never in the suite. Awaits hoisted into run(); they asserted for the first
time today, and pass.
Selftest 261 pass / 0 fail / 2 honest skips.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
A measured t2,p3,p4,t2b on 4x shackle + spare at hp 58 / 1 lost. This
suite says hp 36 / 2 lost. Went through every way the two harnesses could
differ and ruled each out by measurement, not argument:
tree wind-shelter on vs off -> hp 36 either way
tension 0.6/0.75/0.9/1.0 -> hp 36, 2 lost, all four
drain wiring garden.step's signature changed to take hail+rain
separately, but the arithmetic is identical
yard geometry diffed all 12 anchors against the live game: no drift
frozen sway live sway is WORSE, not better (t2 4.4 -> 4.6 kN)
What's left isn't a harness difference, it's arithmetic. t2 peaks
4.4-4.9 kN on this quad; a shackle is rated 3.2. t2 cannot hold under any
variation above. Losing it spends the only spare, then p3 (3.7) or t2b
(3.4) — also over 3.2 — goes too. Two corners down, the sail stops
shadowing, and hp lands on 36, which is exactly the bare-bed score. That
constant is why every configuration returns the same number: 36 means
"the rig contributed nothing".
Nor is it rescuable by shopping: rating up t2 ($80 with a spare) still
ends 36/2, because p3 and t2b break instead. The quad needs three corners
above shackle grade and $80 buys two.
So the skip is deleted and the assert is RED again, which is the true
state. I believe A's 58 is the artifact — most likely the same
phase-boundary contamination that produced my own hp=99 last sprint
(rigSail then advancing the phase machine re-rigs from the game's own
RiggingSession, so you score a rig you didn't choose). A: assert your
rig.corners' anchorIds and hw names immediately before your storm loop.
If they match what you bought, I'm wrong and the cause is still open.
Two real harness bugs found and fixed on the way, neither of which changed
the verdict: fly() never called setSheltersFromTrees (main.js:369 does),
and shop() hardcoded tension 0.9 while the dial's neutral is 1.0. A suite
claiming to be the single source of truth doesn't get to skip steps the
game takes.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The gate asks the only question no per-lane suite can: can the night be
won through the real $80 shop. It buys loadouts via RiggingSession, flies
the real storm JSON over the real yard, integrates skyfx's real hail/rain
exposure into main.js's real garden drain, and judges with main.js's own
win rule.
Status: storm_01 warm-up PASS, cheap-rig-punished PASS, decision-13
miss-the-bed control PASS, and **storm_02's winnable line FAILS** at
hp=36, 2/4 lost. That reproduces the integrator's finding exactly and is
the gate doing its job — SPRINT6 says everything waits on gate 1.
Two things I got wrong on the way, both worth the comments they now
carry:
- The first draft hardcoded the anchor table from a THREADS entry and
was badly wrong (the dressed yard has the house at x=±3, not ±5). It
flew a fictional yard. It now reads the yard from world.js and freezes
only the sway — the yard IS the balance, so it cannot be a copy. Same
failure as Sprint 3's 16.7° reference rig.
- The asserts were async. testkit's Suite.test() calls fn() WITHOUT
awaiting, so every one would have passed forever while proving nothing
— the exact vacuous-test pattern I've flagged three times. Storms are
now flown up front in run() (which runAll does await) and the asserts
are synchronous judgements over the results.
Registers as a sixth 'BAL' entry in selftest.html. A: your "nobody
touches this file" rule guards against five lanes conflicting here; one
jointly-owned entry is the case it makes room for. Revert if you disagree.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
