Lane D R20 (v4.0-beta): the density A/B + correcting my own sparsity misread (ledger #7, part 2)

SELF-CORRECTION first. My part-1 note called the 95-98% patronage null rate
"sparsity-throttled" and made it the headline metric. Both halves were wrong:
(1) it was measured at 21:00, when only 4 of 69 shops are open — retail is shut BY
DESIGN, so a high night null is correct behaviour, not sparsity; (2) it sampled each
town's first venue, and katoomba's is the pub — 1000m from the retail cluster with 1
neighbour. I had parked the camera on the one isolated venue in town. Same town, same
seed: at the pub 99.4% null / 0 visits; on the actual main street 77.2% / 64 visits.
The gig-crowd table stands (it measures the mechanism — 0 NaN, rosters, venue-win —
which is location-independent); only my sparsity reading was bad.

THE REAL A/B (main street, 14:00, same seed, pre-cache from git vs E's widened):
hub density 8 -> 25 shops within 160m; null 90.2% -> 77.2%; total visits 17 -> 64
(3.8x); hero visits 17 -> 19; texture visits 0 -> 45; hero share 100% -> 30% of visits
from 26% of shops.

THE DIRECTIVE LANDS, measured from the crowd side: the secondhand heroes did NOT lose
footfall (17 -> 19). The 45 texture visits are added ON TOP, not taken from them. The
street is 3.8x busier while the heroes stay over-indexed. "More alive, not a different
game."

FILED: (a) venue placement at density — katoomba's rsl/band_room sit in the strip
(13/10 neighbours) but the pub is 1000m out with 1; a gig there has no passing retail
crowd. Quality observation, A/F's lane. (b) GIG_RANGE is a 34m radius but
_nearestOpenShop searches only the ped's own 64m chunk — 8.7% of in-range peds are
chunk-blind. Real but small; v4.x candidate, not a mid-beta hot-path change.

POST numbers are vs E's committed caches but BEFORE A's absorb (11/80 still overflow-
drop). Final re-run + the other four towns once A lands.

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

docs/LANES/LANE_D_NOTES.md

@@ -32,22 +32,51 @@ frames. Every town generates 3 venues (pub/band_room/rsl — charter's 2–4) on
   **castlemaine's 40% is not a leak**: at the 6-shop floor, 3 of its 6 shops ARE venues, so the "other
   shop" hits are mostly *other venues*. A quirk of the sparse floor, not the mechanism.
 
-### The measured finding: the crowd is SPARSITY-throttled, and that's exactly what the widening fixes
-**94.9–97.7 % of patronage checks return null** on every town — peds spend nearly all their time in
-**shopless chunks**. Katoomba is the clearest case: 19 shops sit in ~5 door-chunks of a ~78×78-chunk
-(5 km) town, so `_nearestOpenShop` (which searches the ped's own 64 m chunk) has nothing to find 97 % of
-the time. **This is the quantified version of Fable's ledger finding #2 ("real towns are sparse")** — the
-gig/patronage volume is thin not because the mechanism is wrong but because the town has almost no shops
-per chunk. The density widening (3–6× shops) attacks this directly; **the null % is my headline
-before/after metric.**
+### CORRECTION to my own first read of that null % — I misattributed it (measurement wins)
+My first pass called the 94.9–97.7 % null rate "the crowd is sparsity-throttled" and made it the headline
+before/after metric. **Both halves of that were wrong, and I'm correcting the record:**
+1. **It was measured at gig hours.** At 21:00 only **4 of 69** katoomba shops are open — retail is shut *by
+   design*. A high null rate at 21:00 is **correct night behaviour**, not sparsity. The gig IS the nightlife.
+2. **It was sampled at each town's first venue** (`shops.find(s => s.venue)`). For katoomba that is the
+   **pub, which sits 1,000 m from the retail cluster with 1 neighbour** — I had parked the camera on the one
+   isolated venue in town. Measured there, the daytime null was 99.4 % with **0 visits**; measured on the
+   actual main street, the same town same seed gives **77.2 % and 64 visits**. The number was an artefact of
+   where I stood.
 
-- **Secondary leak (filed, not fixed):** `GIG_RANGE` is 34 m — a *radius* — but `_nearestOpenShop` only
-  searches the ped's own 64 m chunk, so an in-range ped just across a chunk edge is blind to the gig.
-  Measured on katoomba: **8.7 %** of in-gig-range ped-samples are chunk-blind (852 of 9,740). Small next
-  to the 97 % sparsity throttle, so **not worth a hot-path change mid-beta** — filing it. If the widening
-  leaves the null rate high, this becomes worth fixing (search the ped's chunk + 8 neighbours).
+The gig-crowd table above still **stands** — it measures the *mechanism* (0 NaN, rosters populate,
+venue-win %), which is location-independent. Only the sparsity interpretation was bad.
 
-*Part 2 (density re-audit + post-widening re-run of this table) follows once E's caches and A's absorb land.*
+### The real density A/B — the main street, retail hours (14:00), same seed, like-for-like
+Camera on the **densest retail cluster** (the actual main street), pre-widening cache (from git) vs E's
+widened cache, 2,000 frames each:
+
+| main street @14:00 | PRE (20 shops) | **POST (80 shops)** |
+|---|---|---|
+| hub density (shops within 160 m) | 8 | **25** |
+| null % | 90.2 | **77.2** |
+| **total visits** | 17 | **64** (3.8×) |
+| **hero visits** (opshop/book/record/video/pawn/toy) | 17 | **19** |
+| texture visits (milkbar/dept/stall) | 0 | 45 |
+| hero share of visits | 100 % | **30 %** |
+| hero share of shops | 84 % | 26 % |
+| NaN | 0 | 0 |
+
+**The widening lands John's directive, measured from the crowd side.** The secondhand heroes did **not**
+lose footfall — they went **17 → 19 visits**. The 45 texture visits are added *on top*, not taken from them.
+The street is **3.8× busier** while the heroes stay **over-indexed** (26 % of shops, 30 % of visits). That is
+precisely "the player should notice the town feels more alive, not that the game changed."
+
+### Filed, not fixed
+- **Venue placement at density (A/F):** katoomba's 3 venues — rsl **13** shops within 160 m, band_room **10**,
+  **pub 1** (1,000 m from the cluster). A gig at the pub has almost no passing retail crowd. It still draws a
+  roster (peds stream everywhere), so it's a *quality* observation, not a break. Placement is A's/F's lane.
+- **`GIG_RANGE` vs the chunk lookup (mine):** GIG_RANGE is a 34 m *radius*, but `_nearestOpenShop` searches
+  only the ped's own 64 m chunk, so an in-range ped across a chunk edge is blind to the gig — **8.7 %** of
+  in-range ped-samples (852/9,740). Real but small; a hot-path change mid-beta isn't worth it. Fix (chunk +
+  8 neighbours) is a v4.x candidate.
+
+*All POST numbers are vs E's committed caches but **before A's density absorb** (11 of 80 shops still
+overflow-drop). Final re-run + the other four towns follow once A lands.*
 
 ---