hide_render does not survive glTF export — verified in three r175, every node
arrives visible:true. So garden_bed has been drawing plants_full, tattered AND
dead superimposed since Sprint 1, and my THREADS note told Lane A the opposite.
The asserts missed it by checking the nodes existed rather than that only one
was on. The flag now rides in extras, which does export, and consumers apply it
in one line; e.test.js pins the flag instead of the node.
Night dressing: house_yardside gains window_glow, an unlit emissive pane marked
hidden_by_default, plus window_light_anchor. A warm window means someone is
inside, which is why the player is out in the dark keeping the sail on. Plus a
moon sprite whose halo, not its disc, is the part that survives cloud.
End cards are rendered from the game's own props as a diptych: identical camera
and yard, only the night's outcome differs. The left third is left empty for
Lane A's text.
Cards are opt-in behind --cards because EEVEE's shadow pass is not
byte-reproducible across processes in 5.1 — proven with a minimal repro, not
PYTHONHASHSEED, and present even with a hard sun. The dawn shadow is the art, so
the cards become committed art rather than build output. Everything the game
loads stays byte-identical: 38/38 verified.
Selftest 241/0/0.
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>
Variants for A's five-night week. Each gets ONE new trick, and neither is
"the same storm but harder":
- storm_03b_earlybuster (night 3): same force as storm_03 (21 m/s gust, 13
sustained) but the change lands at t=18 instead of t=30. You rig for a hot
NW'er and get a southerly a third of the way in. Tests timing, not budget.
- storm_02b_icenight (night 5): LESS wind than the wild night (28 vs 32 gust,
19 vs 20 sustained) and 2.8× the hail — 32 hail-seconds vs 11.4, held 26 s
straight across the change, size 1.4 stones, ice on every gust ≥9. Hail is
the score (decision 13), so this asks the one question storm_02 only asks
for nine seconds: is the bed actually covered, and does the cover hold? A rig
that survives storm_02 by hiding in a small quad off the bed loses here.
Week escalation now reads 11.3 / 21.4 / 21.2 / 32.3 / 28.3 m/s peak gust with
0 / 2.4 / 2.4 / 11.4 / 32.0 hail-seconds — force ramps then plateaus while the
question changes underneath it.
Forecast uncertainty (DESIGN.md partial-information canon): `forecastFor(def,
lead)` + `stormStats(def)`, pure functions on a def rather than methods on the
wind — the card holds defs, doesn't want a field, and this keeps forecasting
off the wind contract and out of A's router. Bands widen with lead and resolve
to the exact truth at lead 0; deterministic per storm, so re-reading the card
can't reroll it.
The invariant, asserted across every storm at five leads: a band ALWAYS
contains the truth. That's the line between partial information and a lie — a
player who rigs for the top of the stated range must never be ambushed.
stormStats also measures what the card was estimating: storm_02 gusts to 32.3
m/s, not the 30 that `baseCurve peak + powBase + powRamp` implied.
Selftest 253/0/0; node 49/0/0.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Rebuilt the broom against B's FROZEN contract, which is not the shape I asked
for and is better: pondCentroid() (one pond, not a list — B's belly pools into a
single heaviest place) and drainPondAt(node, dt, radius) draining PER FRAME and
returning the kg shed that call. Added interact `onHold` for actions that do work
over the hold rather than at the end of it; the total is only knowable by
accumulating. Falls out nicely: an interrupted poke sheds only what it got
through, which is the honest rule.
Calibration, measured on B's live sim rather than modelled (flat rig, storm_02,
pond mass at poke → kg shed → outcome):
8s · 85 kg → 76 shed → wet (caught it before the ticker)
12s · 152 kg → 104 shed → stagger (you answered the warning)
20s · 281 kg → 182 shed → knocked (you ignored it)
Bands sit under those so all three are REACHABLE — my Sprint-5 guesses (60/120)
would have flattened the player on every poke, and my first pass at real numbers
(150/350) put the knockdown above anything this rig can shed, i.e. dead code.
That is the StumbleBack lesson exactly, so d.test.js guards reachability with the
measured numbers and will fail loudly when gate 1 moves pond masses.
Bug the live sim found that no stub could: a loaded belly SAGS toward you — real
ponds ride from y=1.2 down through y=-1.0 — and my reach gate rejected `up < 0`,
so the broom answered "nothing pooling here" with 281 kg hanging over the garden.
Sagging toward you is the mechanic working. Gate is now a physical band between
sagFloor and reach, with the floor set between two measured cases: a live 281 kg
belly at y=-0.8 (pokeable) and post-tear wreckage at y=-4.5 (nothing to poke).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
SPRINT6 gate 1's anchor lever, placed by measurement rather than by guess.
The wild night had no winnable line for a geometric reason: every anchor near
the bed (p1/p2/p3) is SOUTH of it, and nothing stands north short of the house
10 m away. So covering rigs had to span the yard and died, while rigs small
enough to survive sat beside the bed rather than over it. p4 supplies the
missing north-west corner.
Its position is swept, not chosen. Against the smallest quad covering 90% of the
bed: (-2.2,-1.2) → 44.4 m², (-3.2,-1.2) → 48.6, (-3.2,-2.0) → 51.7, beyond
z=-4 → no effect at all. Pulling it inward to 44.4 would put full coverage
INSIDE the survivable band and collapse DESIGN.md's central tension — covering
the bed has to cost risk. a.test.js's >45 m² floor is what shouts if anyone
moves it in. With the 8° rake the top anchor lands at (-3.72, -1.40), and full
coverage costs 51.6 m² against 63.5 before: a real new option, 19% cheaper,
still bigger than the 23-38 m² rigs that survive unaided.
Measured through the real $80 shop: t2+p3+p4+t2b, four shackles and a spare
($75), ends hp 58 with 1 corner lost — a WIN, where before every covering rig
lost 2-3 corners and ended at 36%. Hail damage falls 51 → 34 HP versus an
uncovered rig, so decision 13 is visibly doing its job.
Selftest 244/0/0; both yard tensions still green.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The aftermath was lying. Any run under 50 hp read "the rain found what you
skimped on" — including Lane B's twisted quad that holds 4/4 corners and skimps
on nothing. The verdict is the game's entire feedback channel: DESIGN.md wants
every disaster to replay as "…the shackle, I knew about the shackle", and
blaming the wrong thing teaches the opposite of the lesson the storm just spent
90 seconds giving.
The garden now keeps its damage split by cause, because the caller was pre-summing
hail and rain into one number and that sum is exactly the information the verdict
needs and can never recover afterwards. A garden that only knows it went 100 → 39
cannot tell a player whether their hardware let go or their perfectly-held sail
simply wasn't over the bed — opposite mistakes, opposite fixes.
verdictFor() is pure and lifted to module scope so it can be asserted directly.
It picks from modes the run can PROVE: cascade (naming the weakest link as going
first, not whichever was listed first), single corner, uncovered, rain, broomed,
ponded, clean. The integrator's exact case now reads "THE GARDEN IS GONE — and
every corner held. The hail fell where your sail wasn't."
Aftermath also gains decision 13's headline: "51 HP to hail, 13 to rain".
Verified live on the reported scenario, not just in asserts. Selftest 244/0/0.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
pondMass/pondCentroid/drainPondAt/dumpPond threw when this.water didn't
exist yet — Lane A's HUD reads pondMass() every frame, including in the
forecast/prep phases before the sail is rigged. Node tests always attach
first so they never hit it; the live game did on the first frame. Guarded
+ a pre-attach assert so it can't regress. Verified in the assembled game:
a flat quad ponds 780 kg (belly sagging below ground), dumps on break,
and the merged browser selftest is 219/0/0.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The water arc, carried since Sprint 3. Rain (Lane C's rainMmPerHour x the
exported RAIN_TIME_COMPRESSION, never hardcoded) lands on each node's
horizontal projection, runs down its steepest of 8 neighbours, and pools
where it can't get out. A flat sail's belly is a basin water flows into
and can't climb from; a hypar drains along its saddle ridge to the low
corners and off — so ponding cannot pincer §7, and measured on real yard
quads a flat rig holds 12 kg/m² vs a twisted rig's 1.7.
The 8-neighbour graph is load-bearing: a 4-way one can't follow the
saddle's diagonal ridge, so it trapped water in the gravity belly and a
hypar pooled as much as a flat sail. Steepest-GRADIENT descent (not
steepest drop) because a diagonal is √2 farther.
Gate 1, in asserts: a flat carport rig under a capped wind survives dry
(4/4) and dies wet (a corner at t=85s) — the control isolates water from
wind — and the broom saves it. Plus dump-on-break, dump-on-tension-up
(the turnbuckle counter-play), mass conservation, and a belly-tear safety
valve at 4 m of sag.
API for D and A, frozen in contracts.js: pondMass(), pondCentroid(),
drainPondAt(node, dt) -> kg-on-your-head. session.reset() for A's "play
again".
On D's tn-1.04 cliff: investigating it IS what surfaced the ponding load
regime. The 10 kN "spike" is real physics, not solver divergence — a
155 m² flat sail holding 2100 kg of water genuinely pulls ~21 kN, stays
finite, and tracks the water. So no physics-altering clamp (the
displacement clamp I tried moved the thesis 39->34%); instead an opt-in
`watchDivergence` tripwire that throws with a repro above 80 kN, live in
every selftest rig and never false-tripping, and a belly-tear that bounds
the runaway physically. Full writeup for D in THREADS.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
A's router tripwire ('wind router forwards EVERYTHING the real wind exposes')
went red the moment weather.js grew hailAt/hailSize — which is the tripwire doing
exactly its job. A's own comment on createWindRouter is the standing instruction:
"Anything new on the wind contract must be added here too." Without this, the
garden score (which hangs entirely off gardenHailExposure → hailAt) would be
inert in the game while every assert passed — the precise silent-swallow this
tripwire exists to prevent, and the second time it would have bitten hail.
Two forwards, matching the existing pattern. Selftest 216/0/0, tripwire green,
and hail now reaches skyfx in-game with no console patch (verified). Flagged to A
in THREADS since it's their file.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Rain honestly walks under a sail (a droplet's terminal velocity is ~9 m/s, so a
30 m/s crosswind blows it in at ~73° off vertical), which is why a perfect rig
scored 54% garden vs 48% for no rig at all. Hail is dense: terminal ~22 m/s, and
a dense stone couples weakly to the crosswind, so even a gale leans it ≤20°.
Steep hail is blocked by overhead cloth, so the garden score becomes
rig-responsive without faking the rain physics — and it was always DESIGN.md
canon (hail shreds gardens; drainage answers rain, later).
weather.core: `hail` block in storm JSON — authored bursts (envelopes) plus one
synced to every gust at/above `withGustsAbove`, so the biggest gusts arrive WITH
ice. `hailAt(t)` (max over live bursts), `hailSize`, validator. Gust-synced
bursts key off the deterministic gust timeline and draw ZERO randomness, so
tuning hail can't re-time the storm — asserted, same guarantee as the downdraft.
storm_02 bursts on the southerly change (peak 1.0 at t=56.5, 11.4 hail-seconds);
storm_03 a mild 0.5; storm_01 none.
skyfx: `hailVelocity` (steep, ≤20° lean, terminal-velocity reasoning cited so
nobody re-opens the rain-angle argument), a second RainShadow fed the steep
vector, `gardenHailExposure(bed, t)` in the gardenExposure mold (A wires the
drain), instanced falling stones (hidden under the cloth so you SEE the sail
working), and hail audio: ground clatter that fades as the sail intercepts, plus
the cloth DRUM that rises exactly as the sail catches hail — the "my sail is
earning its money" sound.
Decision-13 gate proven: no-sail garden takes 4.4× the hail of a bed under a
good rig over a full storm_02 (bar is ≥2×), through the real gardenHailExposure
and B's SailRig. Verified live too (router-patched): stones fall visibly steeper
than the rain beside them, and a bed-covering rig cuts hail exposure roughly in
half at the burst.
Selftest 214/0/0 (was 207); node 36/0/0.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Hail (SPRINT5 §E-1) ships two ways because Lane C's rain is a BoxGeometry with a
flat material and skyfx loads no external texture at all: hail_stone_01 as
geometry that drops into their existing InstancedMesh pattern, and hail_pips.png
as a 4-cell atlas for impacts. A flat quad can't be round and an impact is round
— that's the only reason the atlas is a texture. Both come with a copy-paste
recipe, because a grep showed exactly one of my five shipped textures is
consumed: sail_weave, the one I wrote a recipe for. grass_atlas has sat
unreferenced for four sprints.
plant_shred (§E-2) is elongated after the first pass came out radial and read as
green potatoes — it's the long axis plus the midrib that says "leaf".
tools/yardshot/ finally lands the DESIGN.md pictures, carried since Sprint 2. It
does NOT touch server.py or main.js: it's a Lane E stdlib server that serves the
repo and takes POST /shot, so the browser posts a Blob and bytes go straight to
disk instead of base64 through a console. do_POST is ~25 lines and Lane A is
welcome to lift it and delete this.
Three traps found on the way, all documented: toBlob is async so the WebGL buffer
is already cleared (toDataURL is sync); a backgrounded tab lays the canvas out at
0x0 and toDataURL then returns "data:,"; rAF is paused there so step() must be
driven by hand.
Selftest 209/0/0, 36 output files byte-identical across two runs.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The broom (SPRINT5 §Lane D-1, DESIGN.md's funniest correct mechanic): a third
carry type that queues behind the same hands, walk under the sail belly, hold-E
poke (Crank per E's anim_hint) → B's drainPondAt() → the water lands ON YOU,
sized to the joke: splash under 15 kg, stagger over 60, flat on your back over
120. Everything defers to E's baked metadata (carry_type, poke_tip.use on the
bristle end, anim_hint) — read, not invented. Duck-typed against the ponds[] /
drainPondAt seam I posted to B early, so it carries/walks/refuses-thin-air today
and lights up fully the moment B lands ponding.
Self-wires from createPlayer like the ladder; needs the live sail rig, which it
reads off interact.sailRig (published by wireYardActions, which main.js re-calls
through rigSail whenever attach() swaps the rig).
Greyed prompts (§Lane D-2, my offer, A's HUD hook): interact.visible() shows the
nearest UNAVAILABLE action with its reason when nothing's usable, instead of the
prompt vanishing — the confusion I logged last sprint. nearest() (what hold-E
acts on) is unchanged, so display and action stay separate. step() now reports
`usable` so the HUD can grey the radial. Fixed the ladder-place label to read as
a reason too ("the fascia needs the ladder — it's by the shed").
broom.js keeps no top-level THREE import (the vendored addons need index.html's
importmap) so d.test.js stays headless; the view loads via dynamic import that
only fires in a browser. 217/0/0 (was 207), 13 new asserts.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The router is a hand-maintained delegation list and it has already cost us once:
when Lane C added rainMmPerHour/rainDepthMm, it didn't forward them, and nothing
went red — every suite holds a real wind, only the GAME holds the router. Lane B's
ponding would have passed every assert it had and done nothing in the yard; the
integrator caught it by hand at merge.
The class matters more than the instance. Sprint 5's headline system is Lane C's
hailAt(), and decision 13 hangs the whole garden score off it — the same silent
swallow would make rigging look irrelevant to the garden all over again, which is
the exact thing the sprint exists to fix. The assert diffs the router against a
real wind and names what's missing. Verified it fires rather than just passing:
rebuilt Sprint 4's pre-fix router and it reports exactly rainMmPerHour,
rainDepthMm.
Garden drain now goes through sky.gardenExposure() — same arithmetic, but it's
Lane C's term to own, and decision 13 extends precisely this shape, so hail lands
as one added term rather than a rewrite. Numbers unmoved: good rig 53%.
Also re-measured Sprint 4's headline finding against a TRUE control (fresh boot,
nothing ever rigged, shadow over bed 0.000) because my original control left the
previous round's sail in the shadow grid: no-sail is 48.5% vs a good rig's 53%.
The finding stands, and decision 13's premise with it.
Selftest 209/0/0.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
New ladder.js. The whole mechanic is 200 mm: the fascia bracket sits at 2.48 m,
a 1.72 m person's hands reach 2.20, and E's ladder tops out at 2.90. The asset
and the yard were already built for each other; this is the verb between them.
Carry-ladder is a second carry type, so the ladder and the spare compete for the
same pair of hands and a fascia repair costs two trips while a post repair costs
one — DESIGN.md's "limited hands" rule doing real work, and the reason the house
is the expensive anchor to depend on (which E's ratingHint 0.35 / collateral
"gutter" was already saying in the data).
Climb height is code-driven with ClimbLadder playing on top — the knockdown
precedent, since _rotOnly strips the root and a clip can no more lift the body
than Falling could lay it down. You can't brace up there (both hands on the
rungs), the wind's bar drops to 0.6x, and being blown off is a fall that feeds
straight into the existing get-up chain.
needsLadder is scoped to the fascia on purpose: a height test would have roped in
the 3.95 m posts and 5.05 m limbs, made every repair a two-trip job, and silently
invalidated the recorded §7 run — and it isn't true to rigging either.
Landed with no change to main.js: createLadder self-wires from createPlayer,
which Lane A already hands the scene, world and interact.
Two bugs found by building on my own API, both now asserted: a canUse that reads
player.state cancels its own hold (starting a hold sets busy) — it ate the climb
AND the reach gate before I keyed both on physical height instead; and onLadder
had to become height-based for the same reason. Documented on register().
Selftest 194/0/0 (was 184). Full loop driven by hand in the real game.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
SPRINT4 §Lane A 1-5. Everything the game already simulated was invisible to a
stranger; you can now play a whole round with eyes and a mouse and never open the
console.
hud.js only ever READS — it takes no decisions and owns no state worth keeping,
so it can be this chatty without anything drifting. Corner load bars are
world-anchored rather than screen-anchored because a number in the corner of the
screen can't tell you WHICH shackle is about to go, and that is the entire
"...the shackle, I knew about the shackle" moment. They hold constant screen size
with distance: a house corner is 18 m away from the posts, where a world-sized
bar is a few unreadable pixels.
Prep is Lane B's createRiggingUI wired to the phase machine — their picking was
already complete, this is the hands. Forecast reads the three authored storms, so
the difficulty select came free: Sea Breeze / Southerly Buster / Wild Night with
real peak wind, gust character and change time.
Two bugs the wiring surfaced, both found by playing rather than reading:
- The rigging session survived "play again": a second round started at $35 with
three corners already hung, and the four anchors you clicked were silently
ignored because the session was full. resetRig() walks it back through the
session's own public moves, so the economy stays the one source of truth.
- The forecast card's lifetime was owned by its own button, so any other route
into prep left a card floating over a live game eating input. The phase owns it
now.
Verified by playing it: good rig on the wild night wins at 53%, the same yard's
cheap drum-tight span loses 4 corners, the gentle night with a good rig ends at
93% "not a leaf out of place". Selftest 184/0/0.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
SPRINT4 §Lane C 2/3/4.
PONDING DATA (decision 10). rainAt() was a dimensionless 0..1 — fine for drop
count and opacity, useless for water mass. Lane B would have had to invent the
mm/hr scale, which is exactly the "default-off code tuned by a constant I
invented" they rightly reverted. So the scale is storm data now:
rain.peakMmPerHour (validated 0..300; a rain curve without one is a hard error,
since ponding would silently use the default instead of what the author meant),
plus wind.rainMmPerHour(t) and rainDepthMm(t0,t1). RAIN_TIME_COMPRESSION=40 is
exported from weather.core so B applies it cloth-side rather than either of us
hardcoding 40 twice: how hard it rains is mine, how much water a sail holds is
theirs.
Calibrated to B's own arithmetic, and the numbers land on it:
storm_02 80 mm/hr severe -> 50.9 mm = 3.12 kN/corner (B predicted 3.1)
storm_03 30 mm/hr moderate -> 8.3 mm = 0.51 kN/corner (teases a carabiner)
storm_01 8 mm/hr shower -> 0.9 mm = 0.06 kN/corner (harmless, as designed)
against a storm_02 wind load of 0.2-1.1 kN. A flat rig should drown in the wild
night; a hypar pools nothing and won't notice. Asserted with B's arithmetic so
the storms are provably fit for their water before their cloth lands.
DECISION 7 helper for Lane A: sky.gardenExposure(bed, t) = rainAt x (1-shadow),
the whole drain term in one call. Note it moves on its own — the rain shadow
follows the wind, so the southerly change walks the dry patch off the bed and
the drain climbs with no corner having failed.
NIGHT PASS. sky.night is now the author's call (was: inferred from a darkness
threshold), and darkening scene.background did nothing anyway — the cloud dome
covers it at 0.85 opacity, so an overcast-grey texture was what you actually saw.
The dome now tints AND crushes (a lerp alone lands #717273: it runs in linear
space and the texture is baked near-white). Stops at 0.78 because the yard has no
lights and a storm you can't see is a black screen. Lightning now lights the
cloud it's inside (#3e3e3f -> #d4ddf2), and fires on the biggest gusts via
sky.lightningGustPow, not just the three authored strikes — driven off the
telegraph so the flash lands with the gust that earned it.
Also: c.test's storm list was hardcoded to two storms while the node runner globs
the directory, so storm_03 was untested in the browser half. Its own ponding
assert caught it.
Selftest 195/0/0 (was 184). Verified live: night reads as night, flash lights the
cloud, exposure responds.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Pond (SPRINT4 §E-1, decision 10): pond_water.png and pond_normal.png, for a
patch Lane B builds from the cloth's own nodes — same ride-the-nodes rule as the
tears, since a rigid disc would sit still while the belly moves under it. Alpha
is a radial feather and RGB darkens toward the centre, both encoded radially so
the shading survives being scaled per pondMass (radius ~ sqrt(mass)). Water is
grey-green, not blue: rain caught in a sail is shallow, murky and mirrors an
overcast sky.
Both at 256², not 512²: smooth low-frequency content, and at 512 they were
256 KB + 320 KB against ~20 KB for every other texture here. The chop is seven
waves at golden-angle directions rather than three crossed sines, which
interfered into a lattice and read as basketweave; the normal map gets six
integer-frequency waves for the same reason, and still asserts its own tiling.
broom_01 (§E-2): poke_tip sits on the bristle end deliberately — a broomstick
jabbed at a loaded sail holes it.
Renames fence_panel_broken to fence_panel_snapped to match SPRINT4 §A-4/§E-3.
Lane A's dress() guards every load, so the mismatch would not have crashed —
the wreckage would silently never have appeared, which is worse.
All 21 assets pass, 33 output files byte-identical across two runs, 186/0/0.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Re-measured on A's dressed yard. The bar clears at every value tested —
67% at the landed 0.12, 84% at 0.40, 85% at 0.45 — and the twisted rig
holds 4/4 at all three. storm_02 downdraftOfTotal 0.12 -> 0.45 per
decision 11. Both physics gates now close on the same storm JSON.
My "mathematically unachievable" claim was wrong, and the algebra says
exactly why: ratio = (f / (sin p + cos p·f))^2 depends on the REFERENCE
PITCH far more than on the downdraft. My synthetic reference was pitched
16.7 deg, where the bar genuinely is unreachable (asymptote 109%, needs
f=0.86). The yard is pitched 4.8 deg — house fascia 2.60 m to posts
3.95 m over ~16 m — where 0.45 gives 72% on paper and 85% measured. The
equation was right and the rig was fiction: I was measuring against a
sail the game cannot build. The integrator's "measured beats modelled"
call was correct, and C's 0.45 was right on the geometry that ships.
The assert now derives its reference from the yard's real pitch and says
so, with the pitch table in a comment, so the next person to touch this
can see in ten seconds why the number moves.
Also re-pointed §7's twisted rig off the 145 m2 quad decision 2 retired
onto a real 23 m2 one ('t1,p1,p2,p3', most twisted in the 18-45 band).
The repair leg's dodgy carabiner moves to p2: measured peaks are t1 2.43
/ p2 2.35 / p3 0.82 / p1 0.60 kN, and it had been sitting on p1 — the
lightest corner — so it rode out the storm and the leg skipped. It now
blows and one repair finishes 4/4. Removed its stale skip guard, which
still tested the old gusts.downdraft key.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The gust-only downdraft could not satisfy B's 60% no-free-lunch bar and the §7
twisted-survives gate together: the downdraft peaked at the gust peak, where
the horizontal peaked too, so a flat sail never reached 60% of a pitched one's
load without a spike so violent it also broke the twisted rig. The integrator
measured the pincer (0.58 -> 48% and still breaks twisted).
Fix: the downdraft is now a fraction of the LOCAL total wind speed, not of gust
power (weather.core verticalAt = -frac * localHoriz). It presses a flat roof
steadily across the whole storm — peak total 32.6 m/s dwarfs peak gust power
12.6 — so the ratio clears 60% at a gentle fraction, with no gust-peak spike.
It rides the local speed, so a tree's wind shadow shelters from falling air too.
speedAt() stays horizontal (a wind meter doesn't read falling air).
Field renamed downdraft -> downdraftOfTotal; the validator rejects the old name
rather than silently re-meaning it. The vertical now carries NO rng draws at
all, so the determinism guarantee (tuning can't re-time gusts) is structural,
not just separate-stream.
Measured both gates myself with B's SailRig (8-direction flat-vs-pitched sweep +
§7 legs). Target for storm_02 is 0.45: 69% of-max / 60% worst-heading on the
bar, twisted rated rig survives with ~21% margin. HELD at 0.12 this commit —
the current yard's only twisted quad ('h1,t2,p1,t1', ~190 m2) starts losing a
corner near 0.15 in the exact solver, so 0.45 would red B's §7. 0.12 ~= the old
gust-only 0.3 in peak downdraft (-4.2 vs -4.5 m/s). Bump to 0.45 is a one-number
joint step once A lands decision-2 anchors (18-45 m2 quads) and B re-points §7.
storm_03_southerly: campaign ramp between gentle and wildnight — peak gust 21
m/s, sustained 13, one moderate southerly change. Auto-swept by the suite.
Selftest 170/0/0 (all three §7 legs green). Verified live: downdraft/horizontal
ratio is exactly 0.12 in-game, rain occlusion still covers the bed.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Posts pulled in to (-4.5,5.5)/(4.0,6.0) with p3 at (0,7), and dress() now swaps
Lane E's house_yardside and both gum trees over the graybox, adopting their baked
anchors rather than my constants (decision 6). E's fascia sits at x=-3..3, not my
guessed -5..5 — narrowing the house span by 4 m is a real part of why small quads
exist at all.
Every anchor now carries E's rating_hint: fascia 0.35 with collateral "gutter"
(they encoded DESIGN.md's "the fascia board is a lie" straight into the asset),
tree branches descending 1.0/0.88/0.76 from fork to thin limb. branch_anchor_01
keeps the t1/t2 ids so nothing referencing them breaks; the rest are added.
The yard went from 7 anchors offering nothing under 110 m² to 11 offering 34
quads in the 18-45 m² band, 8 of which shade a quarter of the bed or more.
Measured through the same storm_02: the big house-to-post span loses its
carabiner at t=3.7 s and cascades to 2/4, while a 37.7 m² tree-to-post rig at
0.85 tension survives all 90 s intact and shades 58% of the bed. That is
DESIGN.md's thesis finally standing up in the yard rather than in a doc.
Lane B's "cascade at t=0.4 s from pre-tension alone" is gone: calm peaks are now
634 N (big) and 200 N (small) against a 1200 N carabiner, and no rig breaks
before the storm starts.
Two asserts pin it, because both halves are easy to lose by accident: at least 3
riggable quads in 18-45 m² must shade the bed, AND full bed coverage must stay
above 45 m² — if a small quad ever covers the whole bed, the rigging puzzle has
no wrong answers left. Selftest 172/0/0.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
E's recipe verbatim: grid (i,j) -> (u,v), repeat 6x6, sRGB. Without the
uv attribute three defaults every vertex to (0,0), the map samples one
texel and the membrane reads as flat colour — which looks like the
texture failing rather than like a bug, so E flagged it ahead of time.
Texture URL resolves against import.meta.url rather than the server root,
same as weather.js's STORM_DIR and the same thing the integrator's
/world/ -> relative pass was fixing. A missing texture warns and falls
back to flat colour instead of throwing: the cloth is the game, the weave
is a finish, and it must not be able to take the sail down.
Added anisotropy 4 — the sail is mostly viewed at a raking angle from
underneath, which is exactly where an unfiltered weave turns to moire.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The pre-merge thresholds were tuned against a mock that injected +18 gusts. In
the actual storm_02, gusts-over-baseline peak at 12.1 m/s — so stumbleGust:17
was above every gust in the game and StumbleBack was unreachable dead code, and
shoveGustMin:8 (a low bar in the prototype's 12-38 units) had become a high bar
in ours and threw away most of the shove.
Retuned against the real storm profile (12 gust events, peaks 12.1..6.1, 4
knockdowns, maxExposure 1.55): stumbleGust 17→9, shoveGustMin 8→4. A wild night
now reads shoved (26s of 90) → stumbling (4) → floored (2); a calm day stays 0/0.
d.test.js now loads the real storm JSON via weather.loadStorm and asserts every
threshold is REACHABLE and correctly ordered — the guard the first tuning lacked.
This matters because decision 8 (B+C) reweights the downdraft this sprint, which
is exactly the kind of change that silently killed StumbleBack the first time.
Also pinned the emergent 'unbrace into a gust → stumble' behaviour.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The aftermath screen needs something to point at (SPRINT3 §Lane E-2).
garden_gnome_01_broken snaps at the ankles with the base left where the player
last saw him, head rolled clear with the beard still on, hat off — recognisably
him rather than a shattered pile, because wreckage nobody can identify is just
gravel. fence_panel_broken loses a few palings and hangs one off a nail; most of
it stays standing, which is what makes the hole read as damage rather than as a
design choice. Both keep their intact twin's origin and ground plane so Lane A
swaps mesh-for-mesh with no offsets, asserted both ways.
Also asserts something claimed since Sprint 1 and never checked: that glTF
extras reach three's userData. They do — the gnome's collateral_value, the
canopy's sway_amp, branch_anchor rating_hint and the bin's mass_hint all arrive
as numbers. Had that silently dropped, Lane A's gnome would score $0 and every
anchor would rate identical, which reads as a gameplay decision rather than a
missing field.
Contact-sheet framing now keys the capsule off height, not max(dims): the broken
gnome is 0.39 m across but stands 0.11, so spread-based framing buried it the
same way it once buried the shackle.
Selftest 175/0/0, 30 output files byte-identical across two runs.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
SPRINT3 decision 9 / §Lane A.1. Lane D's §7 loop — rig, carry a spare, repair
mid-storm — had nowhere to pick a spare up, so wireYardActions self-skipped the
pickup and nothing in the game could put one in your hands.
world.shedTable.pos is published synchronously from constants even though the
meshes arrive later: createWorld() has to stay sync (a.test.js and the selftest
build a yard with no server), and wireYardActions reads the position at wiring
time. dress() then refines it onto Lane E's baked pickup_anchor — which moved it
5 cm off my guess at where a table top is, so it was worth reading.
dress() is async and separate from createWorld for the same reason: a fetch in
the constructor would make the selftest slow and flaky, or break it. Each load is
guarded individually, so a missing GLB leaves its graybox standing instead of
taking the boot down.
Verified by hand rather than by registration check: walk up, hold E, spare in
hand; a second hold says "hands full"; leaning on the table with E held for 6 s
deals exactly one spare (D's latch works); nothing fires from across the yard.
Selftest 169/0/0.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
rake_pivot shipped as a childless empty, so rotating it moved nothing — and
rotating the whole GLB instead, which is the only alternative, tips the concrete
footing out of the ground along with the post. DESIGN.md makes raking away from
the load a player decision, so the handle has to actually work.
It now holds post + pad_eye + top_anchor, with footing left on the root: rake it
8° and the post leans while the concrete stays planted. Asserted both directions
in e.test.js — the head must travel over 0.3 m and the footing under 0.01.
Same class as the canopy bug, found the same way: by driving the handle in a
test instead of eyeballing the model. Exported dims unchanged.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Textures (SPRINT2 §Lane E-2). sail_weave.png is a seamless 512² knitted
shade-cloth weave with the stripe banding real cloth has; the script proves the
wrap by evaluating a second tile and requiring an exact match, because Lane B is
being told to set RepeatWrapping and a bad wrap would seam across the whole
sail. Luminance rides in a narrow band so it multiplies the base colour instead
of replacing it — high contrast reads as burlap, not HDPE. Dropped the per-pixel
noise: invisible at ±0.012 and incompressible, it cost 305 KB of the 323.
sail_tears.png is a strip of 4 escalating rips. Each is a lens, not a slit —
fabric under tension parts widest in the middle and tapers to a point, and a
constant-width gap reads as a drawn line. Threads bridge the gap, scaled to the
local width; without them a dark lens is a hole rather than a tear.
Dressing (§Lane E-3): wheelie_bin_01 (240 L, 12 kg, `lid` on its own node so it
flaps before the bin goes over), washing_line_01 (a Hills Hoist — the `head`
freewheels, giving a second wind tell at head height), garden_gnome_01
(collateral bait: a smashed gnome reads where a damage number doesn't).
Bin and tramp land in models/debris/ for Lane C to glob. All 19 assets pass, 28
output files byte-identical across two runs, selftest 129/0/0.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
world.js sways a tree by rotating a `canopy` group whose origin sits at the
trunk top, so the blobs swing about the trunk. The trees shipped canopy_01..03
as siblings of `trunk` with each origin at its own blob centre — rotating one
spins a sphere in place, which is visually nothing. Lane A could not have swayed
these trees, and the canopy lean is the gust telegraph the player reads a beat
before it hits the sail, so the tell would have gone missing rather than looked
wrong.
Adds the `canopy` empty at the trunk top with the blobs parented under it, so
A's existing code works unchanged, plus sway_amp / sway_phase / sway_pivot_y
for the per-tree tuning SPRINT2 §Lane E asks for (gum_01 is big and leans less
at 0.85; gum_02 is whippy at 1.20 and shows a gust first).
sway_phase draws from its own RNG stream: taking it from the shared one would
consume a value and shift every blob draw after it, resilhouetting a tree the
other lanes have already tuned against. Exported dims are identical to Sprint 1.
e.test.js asserts the pivot by rotating the handle and measuring that a blob
actually travels — red before this change, green after.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
