chore(meta): cascade refocus — supersede v0.2 cluster, re-home backlog tree, capture workshop WIP

Governance:
- D-166 amendment (2026-06-12): outside-in build order (geo → econ-on-world →
  building templates → door boundary contracts → NPC/interiors → gameplay);
  Phase 5 ramps in parallel once outsides are walkable (gate: T-962)
- D-114/D-115/D-117/D-118/D-120 marked superseded by D-166 (inbound anchors fixed)
- D-221 amended: milestones retired, cascade-hierarchy gating is canonical
- Q-077/Q-068/Q-036 resolved (answered by events); Q-110 (scale anchoring) and
  Q-111 (live-econ coupling) opened from cascade grounding

Ticket tree (147 stray backlog tickets dispositioned):
- New parents: T-1036 (post-cascade gameplay parking), T-1037 (maintenance initiative)
- Re-homed: 15 → Phase 4 (T-750), 30 → Phase 5 (T-749), 11 → Phase 6 (T-751),
  21 → gameplay parking, 28 → maintenance; children follow their epics
- Cancelled 12 administrative shells (mirror tickets, emptied pre-cascade umbrellas,
  v0.2 pivot shell T-603); T-9/T-28 closed done; T-745 in_progress
- New grounded tickets T-1038..T-1044: inter-settlement road/rail graph, L3→L4
  dispatch threading, river-channel-anchor bug, 64m landform-repeat bug,
  region seam blending, road-entry octants, drainage re-run fix

Docs:
- CLAUDE.md cascade paragraph updated to the amended rule
- 20 v0.1-era docs/design files marked superseded with pointers;
  content-structure-canonical retitled (v0.2 label dropped)

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

governance/questions/architecture.md

@@ -138,7 +138,7 @@ Technical foundation questions: engine, protocols, data structures, performance,
 ---
 
 ### Q-068: Procedural terrain generation patterns — chunk loading and noise
-- **Status:** Open (reference/inspiration)
+- **Status:** Resolved (2026-06-12) — the seed-deterministic chunked-terrain question this reference was held for shipped in the Phase-4 cascade: T-963 (Layer 0 canonical heightmap), T-953 (Layer 1 topography/drainage/sub-biome), T-955 (Layer 3 settlement placement), all done; chunk streaming follows the D-225/D-227 derive-on-demand model rather than this demo's pattern.
 - **Question:** Block-based 3D Procedural Map Generation Demo (https://godotengine.org/asset-library/asset/2698) — Perlin noise terrain with chunk-based loading/unloading. Not directly usable (block-based, Godot 4.2) but the patterns are relevant: seed-deterministic generation for consistent worlds across sessions, chunk loading within player proximity for memory/performance, terrain type placement from noise values. Reference for when the world generator produces location terrain and the client needs to stream it. The chunk load/unload pattern maps to our simulation tier system (Active → Background → State-saved).
 - **Cross-reference:** Generator architecture, D-097 (simulation tiers), D-096 (chunk loading)
 
@@ -201,7 +201,7 @@ Technical foundation questions: engine, protocols, data structures, performance,
 ---
 
 ### Q-077: World generation architecture → PROMOTED TO WORKSHOP
-- **Status:** Promoted — see `docs/workshops/world-generation/BRIEF.md`
+- **Status:** Resolved → [D-166](../decisions/architecture.md#d-166-development-cascade--6-phase-first-things-first-build-order) — the promoted workshop ran 2026-03-24 and produced the development cascade (`docs/workshops/world-generation/workshop-outcomes.md`); the asset-library references were consolidated into the brief and remain available there. Loop closed 2026-06-12.
 - **Question:** Outgrew Q-record format. All references (CityCrafter3D, Chunk Manager, Retro Terrain, Spatial Gardener, GridMapLayer, PathMesh3D, DeformableMesh, Poly Haven) consolidated into the workshop brief.
 - **Cross-reference:** `docs/workshops/world-generation/BRIEF.md`
 
@@ -428,4 +428,23 @@ Technical foundation questions: engine, protocols, data structures, performance,
 
 ---
 
-*58 questions (11 resolved, 1 partially resolved, 46 open). Last updated: 2026-06-05.*
+### Q-110: Region/chunk physical-scale anchoring — what is a region in metres, and what anchors a heightmap pixel?
+- **Status:** Open — surfaced 2026-06-12 during cascade-work grounding (post-D-239 implementation)
+- **Question:** The refinement chain's nominal physical anchors (workshop brief: 78 km L1 cell → ~1 km region → 64 m chunk → 1 m voxel, `docs/workshops/tile-derivation-contract/tile-derivation-contract-workshop-brief.md:19-22`) are mutually inconsistent in the implementation, and no record fixes metres-per-heightmap-pixel. Evidence: (1) `region_profile.rs:3-4` documents ~1 km² regions, ~6,000/body (80×75); (2) `derive_all_regions` (`region_profile.rs:1014-1044`) actually tiles the 512×256 L1 working grid at 8 cells/region spanning ±90° latitude — for a planet-scale equirect map an L1 cell is body-relative (~78 km on an Earth-like body), making such a region ~624 km, not 1 km; (3) `cascade.rs:235-237` claims "8 cells per region on a 128×64 working grid → ~80×32 = ~2,560 regions" — internally inconsistent and inconsistent with `heightmap.rs` GRID 512×256; (4) `chunk_context.rs:137-141` assumes a region is 16 chunks ≈ 1.024 km; (5) D-239 §10 asserts "D8 ≈ 152 m/cell" — true only if the whole 512-cell grid spans ~78 km, i.e. one nominal L1 cell, not a planet; (6) D-201's tier-4 "Region" is the 50–500 km Province, colliding with the D-239 ~1 km RegionProfile vocabulary. Voxel/chunk scales are absolute (D-222: 1 m / 64 m) but the heightmap pixel is body-relative — the cascade currently glues them with three contradictory assumptions. **Which anchoring model is canonical?**
+  - **(a) Full-planet anchoring:** fix metres/pixel per body from `body_radius_km` (D-204): `px_m = 2πR/1024`. Regions become fixed ~1 km cells whose count varies per body (millions for a planet) — requires lazy region derivation (already the D-225/D-227 model) plus an explicit L1→region resampling stage; the 8-cells-per-region shortcut and the ~6,000/body budget die.
+  - **(b) Working-window anchoring:** L1–L3 stay planet-equirect; the voxel cascade (region→chunk→voxel) operates on bounded windows (~one 78 km L1 cell) anchored at points of interest (settlements), with fixed metres/pixel inside the window. Matches the brief's chain literally and keeps ~6,000 regions/window; needs a window-addressing scheme in BodyWorldState and a rule for inter-window terrain.
+  - **(c) Body-relative everything:** keep pure grid-ratio anchoring (region = L1cell/8, chunk = region/16) and let metre meanings float per body — rejected-shaped: breaks the D-222/D-227 absolute 1 m tile vocabulary, D-239 §9 chokepoint widths, and the budget math.
+- **Context:** Blocks metre-precise tuning of the cross-region blend and the landform region-anchoring fix; needed for Atlas scale bars (T-960) and the D-239 §10 ~45 ms/body budget accounting (assumes ~6,000 regions/body). A D-201 amendment is likely required to disambiguate Region-vs-Province vocabulary.
+- **Cross-reference:** D-201, D-202, D-204, D-222, D-225, D-227, D-239 §9/§10, Q-105
+
+---
+
+### Q-111: Live-econ coupling of generation inputs — which inputs refresh from the rolling sim vs stay static-authored?
+- **Status:** Open — surfaced 2026-06-12 during cascade-work grounding
+- **Question:** The generation cascade reads every economic input from static systems.db at build/dispatch time (D-199 read-set via `city_context_reader.rs`; D-200 tier-1), while the live economy independently rebuilds `EconStateResource` — all 7 D-181 signals per (system_id, commodity_id) — every ECON_TICK_RATE (`economy.rs:107-120`). `EconStateResource` has NO generation consumer (only the IPC bridge + debug command read it). D-227 already names the coupling mechanism — the derived economic base is "recomputed on expiry, and force-evicted on an event (e.g. the player tanks a system's economy)" — but no record fixes the policy. For each generation input, which bucket: **(a) static-authored forever** (economic_role, founding_age_years, D-237 specializations — authored identity); **(b) epoch-refreshed** (re-read at save/load or world-epoch boundaries: prosperity_baseline_bps? world_tier? dominant commodity/BulkClass?); **(c) live-coupled via D-227 force-eviction + re-derivation** (settlement active/ghost flips per D-196, building condition/occupancy per D-217/T-999, road MaintenanceAuthority degradation)? And what is the eviction contract: who emits the event (an EconEvent threshold? storyteller?), which cache tiers evict (BodyWorldState regions/quarters vs chunk/voxel caches), and at what granularity (per-settlement, per-body, per-system)?
+- **Context:** T-1007 defers economic_tier derivation "until it earns a use case in the rolling sim" and T-982's dominant-commodity lookup is static build-time — both park fields whose home depends on this answer. T-999 is the only ticketed live-econ→world consumer. D-198 fixed the reverse direction (econ sim never reads spatial layers); this is the forward direction. Per the cascade-first direction (2026-06-12 D-166 amendment: geo → econ-on-world → templates → door contracts → NPC/interiors → gameplay), default-static is acceptable through Phase 4; the answer gates Phase 5+ (a Reach a character travels through must show economic life without invalidating walked terrain) and the save model (D-227).
+- **Cross-reference:** D-181, D-196, D-197, D-198, D-199, D-200, D-217, D-227, D-237; T-999, T-1007, T-982; Q-103 (mutator schema), Q-105 (region clock state)
+
+---
+
+*60 questions (13 resolved, 1 partially resolved, 46 open). Last updated: 2026-06-12.*

governance/questions/scope.md

@@ -5,19 +5,19 @@ Game concept, prototype boundaries, production pipeline, and feature decisions.
 ---
 
 ### Q-002: Scope of v0.1 playable prototype
-- **Status:** Resolved → [D-117](../decisions/scope.md#d-117-tycoon-is-the-v02-bookmark--zero-investigation-content), [D-166](../decisions/architecture.md#d-166-development-cascade--6-phase-first-things-first-build-order)
+- **Status:** Resolved → [D-117](../decisions/scope.md#d-117-tycoon-is-the-v02-bookmark--zero-investigation-content-superseded), [D-166](../decisions/architecture.md#d-166-development-cascade--6-phase-first-things-first-build-order)
 - **Resolution:** The v0.1 prototype framing is superseded. D-117 establishes the tycoon as the v0.2 bookmark; D-166 defines the 6-phase development cascade as the authoritative build order. Prototype scope is determined by the cascade phases, not a standalone v0.1 spec.
 - **Date resolved:** 2026-03-24 (D-166 development cascade)
 - **Assigned to:** Full team
 
 ### Q-004: One campaign spanning all eras or separate era scenarios?
-- **Status:** Resolved (implicitly) → [D-117](../decisions/scope.md#d-117-tycoon-is-the-v02-bookmark--zero-investigation-content), [D-166](../decisions/architecture.md#d-166-development-cascade--6-phase-first-things-first-build-order)
+- **Status:** Resolved (implicitly) → [D-117](../decisions/scope.md#d-117-tycoon-is-the-v02-bookmark--zero-investigation-content-superseded), [D-166](../decisions/architecture.md#d-166-development-cascade--6-phase-first-things-first-build-order)
 - **Resolution:** v0.2 is single-era (contemporary Settled Reach). The development cascade (D-166) defers all multi-era considerations well beyond current scope. The question remains interesting for the full game but is not load-bearing for any active phase.
 - **Date resolved:** 2026-04-05 (closed as implicitly resolved)
 - **Assigned to:** Gore, Miri to lead discussion
 
 ### Q-005: Scale for prototype - locations, characters, factions
-- **Status:** Resolved → [D-117](../decisions/scope.md#d-117-tycoon-is-the-v02-bookmark--zero-investigation-content), [D-118](../decisions/scope.md#d-118-small-business-owner-starting-state--3-configurations), [D-166](../decisions/architecture.md#d-166-development-cascade--6-phase-first-things-first-build-order)
+- **Status:** Resolved → [D-117](../decisions/scope.md#d-117-tycoon-is-the-v02-bookmark--zero-investigation-content-superseded), [D-118](../decisions/scope.md#d-118-small-business-owner-starting-state--3-configurations), [D-166](../decisions/architecture.md#d-166-development-cascade--6-phase-first-things-first-build-order)
 - **Resolution:** Scale is determined by the development cascade (D-166), not pre-scoped. 301 systems in the star map. All NPCs generated (D-122). Single character type (tycoon, D-117). Starting configurations defined in D-118. The "~10-20 characters" estimate is obsolete — NPC count is a generator output, not a hand-authored target.
 - **Date resolved:** 2026-03-24 (D-166 development cascade)
 - **Assigned to:** Gestalt, Tyre, Miri
@@ -34,7 +34,7 @@ Game concept, prototype boundaries, production pipeline, and feature decisions.
 - **Assigned to:** Team Leader
 
 ### Q-011: Character selection and playable characters
-- **Status:** Resolved → [D-117](../decisions/scope.md#d-117-tycoon-is-the-v02-bookmark--zero-investigation-content), [D-115](../decisions/scope.md#d-115-character-creation-scoped-to-skills--bookmark-for-v02), [D-122](../decisions/content.md#d-122-all-npcs-generated--no-named-hand-authored-characters)
+- **Status:** Resolved → [D-117](../decisions/scope.md#d-117-tycoon-is-the-v02-bookmark--zero-investigation-content-superseded), [D-115](../decisions/scope.md#d-115-character-creation-scoped-to-skills--bookmark-for-v02-superseded), [D-122](../decisions/content.md#d-122-all-npcs-generated--no-named-hand-authored-characters)
 - **Resolution:** v0.2 has one playable character type: the tycoon (small business owner starting state, D-118). One bookmark. All NPCs are generated — no canon named characters. Character creation is skills + bookmark only. The "how different are their starting positions?" question is answered by the small business owner economic variation (D-118: bar, logistics contract, storage franchise as starting configurations). The "canon characters vs original" question is answered by D-122: all NPCs generated, no canon characters exist in v0.2.
 - **Date resolved:** 2026-03-05 (Where's the Fun? Workshop)
 - **Question:** Which characters are playable in the prototype? How different are their starting positions? Can you play canon characters or only original ones?
@@ -58,7 +58,7 @@ Game concept, prototype boundaries, production pipeline, and feature decisions.
 - **Source:** Wiki Review Workshop R4, lead interview
 
 ### Q-034: PC archetypes
-- **Status:** Partially resolved → [D-117](../decisions/scope.md#d-117-tycoon-is-the-v02-bookmark--zero-investigation-content) (v0.2 scope only: tycoon bookmark, zero investigation)
+- **Status:** Partially resolved → [D-117](../decisions/scope.md#d-117-tycoon-is-the-v02-bookmark--zero-investigation-content-superseded) (v0.2 scope only: tycoon bookmark, zero investigation)
 - **Partial resolution:** v0.2 scope is settled — one bookmark (tycoon, small business owner start per D-118). Smuggler and detective are abandoned for v0.2. The full 8-archetype model, fluid archetype transitions, and "vulnerable window" mechanics remain undesigned for the full game. The "detective, smuggler, tycoon are jobs you can have, not the game's identity" framing (Where's the Fun? Workshop) is the guiding principle for future archetype design.
 - **Question:** Should the full game support 8 fluid PC archetypes (Smuggler, Detective, Engineer, Diplomat, Medic, Scholar, Soldier, Merchant) with transition mechanics where archetype shifts during play based on player behavior? The lead approved 8 archetypes with fluid transitions as a game mechanic. v0.1 ships smuggler + detective only (D-027). Full archetype spec, transition triggers, and "vulnerable window" mechanics are undesigned. NOTE: The character-creation-game-setup workshop (Q-011) will address this — coordinate.
 - **Assigned to:** Nigel, Gestalt
@@ -71,8 +71,9 @@ Game concept, prototype boundaries, production pipeline, and feature decisions.
 - **Source:** Wiki Review Workshop R4, lead interview
 
 ### Q-036: District skeleton as generator output
-- **Status:** Open
+- **Status:** Resolved → [D-222](../decisions/architecture.md#d-222) (spatial hierarchy: Quarter as the skeleton unit), T-957/T-985 (Layer-4 quarter skeleton, done)
 - **Question:** For the 300-world model, should the district skeleton (social sites, NPC slots, triangle templates, economic function, access topology) be the atomic output unit of the world generator? D-025 defines social sites as the atomic template unit for hand-authoring. The generator model reframes the district as a composed output from ingredient inputs. How does this interact with D-025?
+- **Resolution (2026-06-12):** Answered by events: the generator's atomic output unit shipped as the **QuarterSkeleton** (D-222 naming; T-957 Layer-4 skeleton + T-985 QuarterWorldState, both done) — zoned blocks, reservations, access topology, and building footprints as a composed output. Social-site templates (D-025) remain the authoring unit for the Phase-6 interior/NPC layer that colonizes the skeleton; NPC slots and triangle templates deliberately stay out of the generator output per the cascade order.
 - **Assigned to:** Tyre, Gestalt
 - **Source:** Wiki Review Workshop R4
 
@@ -118,4 +119,4 @@ Game concept, prototype boundaries, production pipeline, and feature decisions.
 
 ---
 
-*17 questions (6 resolved, 3 partially resolved, 8 open). Last updated: 2026-04-05 (Q-002, Q-004, Q-005, Q-007 closed as resolved)*
+*17 questions (7 resolved, 3 partially resolved, 7 open). Last updated: 2026-06-12 (Q-036 closed as resolved — quarter skeleton shipped)*