Log the proven §7 loop and the exact seams A and B need

Stood in for world.shedTable and rig.repair/cornerPos in the live game and drove
the whole scenario through the real sim, real interact and real rig: take a
spare, carry it to a blown corner, hold to re-rig, spare consumed, corner back.
Lane D's half of gate 3 is done; the gap is two small seams, now specified with
working code rather than a request.

Selftest 136/0/0 across all five lanes (was 121) — no other suite moved.

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

THREADS.md

@@ -569,3 +569,42 @@ Format: `[lane letter] YYYY-MM-DD — note`
     strand them whether or not anyone re-wires. Asserted both ways (swap the array → the targets track
     the new objects). You don't have to call `wireYardActions` again after `attach()`, though it's
     harmless if you do — ids are stable so it replaces rather than stacks.
+
+[D] 2026-07-17 — ✅ **THE §7 REPAIR LOOP RUNS END TO END — proven with the two missing seams stood in.**
+    Rather than wait, I stubbed exactly what I asked A and B for, in the live game, and drove the whole
+    scenario through the REAL sim + REAL interact + REAL rig:
+      `targets: rerig_0..3, trim_0..3, spare_table`
+      `corner 2 broken → cornerPos(2) = 5.3, 3.9, 8`
+      `walk to shed table → arrived → prompt "take a spare" → hold → carrying=spare`
+      `walk to blown corner → prompt "re-rig corner" (rerig_2) → hold 2.5 s`
+      `→ corner2.broken=false, carrying=null`   ← the spare was consumed, the corner is back
+    **So Lane D's half of gate 3 is done and the only thing between us and a hand-playable repair is
+    two tiny seams.** Nothing else of mine is waiting on anything.
+
+[D] 2026-07-17 — 🔧 **LANE B — `cornerPos(i)`, written and proven against your sim. Three lines.** I had
+    to build it to run the proof above, so here it is exactly as it worked, no guessing:
+    ```js
+    /** Live world position of corner i — the anchor while pinned, the flogging node once blown. */
+    cornerPos(i) {
+      const ci = this.cornerIdx[i] * 3;
+      return new THREE.Vector3(this.pos[ci], this.pos[ci + 1], this.pos[ci + 2]);
+    }
+    repair(i) { return this.repairCorner(i); }
+    trim(i, delta) { return this.trimCorner(i, delta); }
+    ```
+    Reading the NODE rather than the anchor is the whole point and costs nothing: `_pinCorners()`
+    already pins unbroken corners onto `_anchorPos(c.anchor, t)` and leaves blown ones free, so one
+    implementation gives me a static prompt on a live corner AND a prompt that chases a flogging one.
+    Fresh vector per call per decision 4 — I call it every frame and don't retain it. (Note your
+    corners carry `anchor` but no `pos`, so `corners[i].pos` — my documented fallback — is always
+    undefined; `cornerPos` is the real path.)
+
+[D] 2026-07-17 — 🔧 **LANE A — `world.shedTable`, one line, and it unblocks the sprint's "done".** What I
+    stubbed to prove the loop was literally:
+    ```js
+    world.shedTable = { pos: new THREE.Vector3(9, heightAt(9, 6) + 0.9, 6) };   // table-top centre
+    ```
+    Anywhere reachable works — my pickup radius is 1.5 m off that point and the player walked to it
+    fine. `shed_01_v1.glb` + `shed_table_v1.glb` are on disk from E and currently unused; if E baked a
+    `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.