Log the work-field landing, the type-enum flag for A, and the site_02 block

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

THREADS.md

@@ -2947,3 +2947,42 @@ Selftest: **277 passed, 0 failed, 0 skipped**, LANE BAL now visible.
     open on carports until landed), C's venturi (landed, waiting on site JSON shape), E's carport
     (landed as a data-driven trap, waiting on site_02), B's site_audit tool (from the quad sweep).
     Gate 3 (John plays the week) remains open — the game has never been more ready for it.
+
+[D] 2026-07-18 — 🪜 **`needsLadder` LANDED on the work field (§gate 1), keyed to E's real carport.**
+    Took SPRINT10's spelling — **`work: 'bracket' | 'cloth'`** — over the boolean I proposed in
+    Sprint 9. Naming the mechanism positively beats a negation, and it's the field A is emitting;
+    `worksAtBracket` still resolves so nothing already setting it breaks, and `type === 'house'` stays
+    the fallback. **site_01 is a no-op, verified live**: no anchor there carries either field, and the
+    fascia/post/tree verdicts are identical. E's anchor tripwires stay green.
+    **Keyed to `carport_01_v1.glb` rather than my invented numbers — and E, your asset carries BOTH
+    mechanisms, which makes a per-structure rule wrong too:**
+    ```
+      beam_anchor_01/02  y=2.36  "carport"       rating_hint 0.22   → over the 2.20 m reach: BRACKET
+      post_anchor_01/02  y=1.75  "carport_post"  rating_hint 0.30   → under it, reachable: CLOTH
+    ```
+    **The beam is a double trap and I love it**: your worst rating in the game AND the corner that
+    costs a ladder trip in a southerly. That is a rule, not a bug — which is exactly what §Lane D asks
+    the traps to read as. Confirmed the regression too: **un-declared, both carport anchors fall back
+    to the type, read as "ground work", and `canReach` waves a 2.36 m bracket through from the
+    grass** — the mechanic deleting itself with no error. Pinned by a test now.
+    **Lane A — the mapping is `beam_anchor → work: "bracket"`, `post_anchor → work: "cloth"`.** Emit
+    `work` per anchor in the site JSON and the ladder follows with no code change. 288/0/0.
+
+[D] 2026-07-18 — ❗ **LANE A — one thing to watch when you emit the site JSON, from the same audit.**
+    `contracts.js` types `Anchor.type` as a closed enum **`'house'|'tree'|'post'`**, and E's carport
+    ships `anchor_type: "carport"` / `"carport_post"`. Whatever you map those to, two things stay true
+    and they pull in opposite directions:
+      · `needsLadder` no longer cares — it reads `work` — so the ladder is safe either way.
+      · but `world.js` filters trees for `wind.setSheltersFromTrees(...)` on `type === 'tree'`, and
+        **C's venturi + B's audit both key off geometry that reads `type`.** A carport typed `'post'`
+        would quietly join the sail-post family; typed `'carport'` it falls outside the enum contract.
+    Not my call and not blocking me — flagging it before it becomes a merge-time discovery, because
+    "a rule keyed on a type string that a new site doesn't fit" is the exact shape of the bug I just
+    landed the fix for. If you widen the enum, B/C/E and I can all read `type` honestly again.
+
+[D] 2026-07-18 — ⏳ **Playing site_02 cold: still blocked, third sprint — flagging, not nagging.** A's
+    site extraction hasn't started (lane/a is at the sprint-plan commit), so there is no site_02 to
+    play. Everything of mine that can be done ahead of it is done: the ladder field is landed and
+    tested against E's shipped GLB, and the moment `site_02_corner_block.json` exists my feel pass is
+    the only thing between it and gate 2. Nothing of mine blocks anyone. Douse guard still green, so
+    pond masses haven't moved.