rega's contact sheet showed what no gate could: page 3 read as ONE SOLID GREEN BAR. 32 contiguous cells fill most of row 1 of 52, so the page said "a big green block" where the Driver's intent is "32 boxes lost in 5,200". Rarity is the whole message and a bar cannot carry it. ⚠ AND THE COMMENT I DELETED SAID THE OPPOSITE, WHICH IS THE PART WORTH KEEPING. It read: "Row-major, so the shaded run reads as a contiguous block from the top — a scattered shading of the same COUNT would be honest arithmetic and an unreadable picture." I wrote that reasoning about a picture I had never looked at, and it was exactly backwards. Scattering is what makes the eye hunt for them, which IS the point. DETERMINISTIC, NEVER Math.random(): a 32-bit FNV-1a hash of the ZONE ID feeds a mulberry32 PRNG, so the same packet prints identically every time — two copies of one zone must not disagree — while different zones get different constellations, so a print run is not 28 sheets wearing the same pattern. Verified: two consecutive renders produce byte-identical files (md5 febafc1813c6 both times). Partial Fisher-Yates over the index space rather than shuffling all 5,200, so a large share degrades into an even spread rather than clumping. ★ AND THE NEW ASSERTION IS THE ONE THAT WOULD HAVE CAUGHT THIS. check-packet-render now measures the shaded cells' VERTICAL SPREAD as a fraction of the grid height, at the RENDERED layer via getBoundingClientRect — because a COUNT cannot tell a scatter from a bar. 32 shaded is 32 shaded either way, which is precisely why every existing assertion stayed green on a broken page. POISON-TESTED rather than trusted: rebuilding the same 32 cells as a contiguous run makes it FAIL with "span only 0% of the grid height". The real packet measures 95% (32 cells across 26 distinct rows). The 50% floor is deliberately loose — a genuine scatter spans nearly the whole page, a bar spans ~1%, and anything between deserves a human look. ⚠ The poison test first ran on a copy in /tmp and the gate REFUSED it — "outside any checkout, so which build produced it cannot be checked". A sensible guard, and it meant my first poison run proved nothing; re-ran inside the tree. en and ar both PASS at 9 sheets. Page 2 (the empty life grid reading as blank graph paper) is UNTOUCHED and held for the Driver with the page-order question — shading a reader's life we do not know would be a guess presented as a fact, which is a product decision, not mine. |
||
|---|---|---|
| .. | ||
| api | ||
| colors | ||
| components | ||
| composables | ||
| constants | ||
| data | ||
| i18n | ||
| layouts | ||
| lists | ||
| maps | ||
| packet | ||
| scripts | ||
| stores | ||
| styles | ||
| utils | ||
| vendor/cldr | ||
| index.js | ||
| ProfileLoader.vue | ||
| README.md | ||
library/ (@map) — the shared map template
The other half of the architecture (see ../plugin-designs/README.md):
every map in plugin-designs/<your-map>/ composes the reusable, parameterized pieces that live here.
Fix something here and every map benefits on the next build; break something here and every map
breaks — read components/WARNING.md before touching shared pieces.
| Folder | What lives there |
|---|---|
ProfileLoader.vue |
The root of every bundle: parses profile-config, loads the profile, provides the stores + config |
components/ |
Shared UI — map, legends, controls, popup (PeopleGroupDetail), tables, charts, hints (README) |
composables/ |
Shared logic — map engine (useMapInstance), provider switch, shadow-DOM styles, theming |
stores/ |
Per-instance Pinia stores (ui / map / data) — provided by ProfileLoader, injected by children |
api/ |
Data-source registry (sources.json) + fetch layer — the JAMstack runtime wiring |
colors/ |
Color sets maps opt into via profile-config.colorSet |
i18n/ |
The shared string catalogs (all maps speak the same languages) |
data/ |
Small shared datasets baked at build time (big served data lives in ../data/) |
constants/ |
Shared constants |
scripts/ |
Maintainer pipelines (posters, research) — not part of any bundle |
The rule of thumb (same as WARNING.md): custom code in your app-profile, reusable code here — and things only move from the first to the second once they've earned it.