settled-reach/docs/workshops/planet-down-cascade/round-2-notes.md

title, author, workshop, round, created

title	author	workshop	round	created
Round 2 Notes — Planet-Down Cascade Workshop	qatux	planet-down-cascade	2	2026-05-01

Round 2 Notes — Planet-Down Cascade Workshop

Compiled from five Round 2 agent files: Gestalt, Tyre, Paula, Burnelli-Sheldon, Ozzie.

---

1. Attractor-Matching Algorithm — CONVERGED

All five agents reached alignment on attractor-matching. The algorithm is a five-phase pipeline combining Paula's priority ordering with Burnelli-Sheldon's objective function and the Hungarian algorithm agreed by Gestalt and Tyre.

Converged Algorithm (Five Phases)

Phase 0 — Score matrix + HQ hard zeros Build an N×M matrix of compatibility scores between N named cities and M geographic attractors. Hard-zero any attractor that is physically incompatible with the city's economic role (Paula's H1-H4 constraints: maritime corp must be coastal, resource corp must be near resource concentration, etc.).

Phase 1 — Sort cities into three constraint tiers

• Tier A: Extraction/resource corps — most geographically constrained; fewest valid attractor assignments
• Tier B: Manufacturing/industrial/transport corps — moderately constrained
• Tier C: Service/commercial/financial corps — least constrained; most flexible

Phase 2 — Tier A greedy assignment Assign Tier A cities greedily, sorted by constraint tightness (fewest valid attractors first). This is Paula's insight: extraction corps must be near their resource; assign them first to prevent geographic mismatches from cascading.

Phase 3 — Hungarian algorithm on remaining cities Run maximum-weight bipartite matching on Tier B and C cities against remaining attractors. Burnelli-Sheldon's scoring function: maximize aggregate plausibility across the whole planet, not just the highest-weight individual assignments.

Phase 4 — Synthetic attractor overflow If N named cities > M geographic attractors: generate synthetic attractors (Burnelli-Sheldon) at seed-derived offsets along road corridors. SyntheticPlacementReason: PopulationOverflow | PoliticalDecision | CorpExpansion. High-tier economic worlds always get synthetic attractors regardless.

Phase 5 — FoundingOrientation derivation Post-assignment: if geographically_triggered == false (Paula), FoundingOrientation = AdminFacing. Cities that exist due to political decisions rather than geography get AdminFacing orientation; they sit at Province centroids or political midpoints.

Attractor Assignment Data Type (Paula)

enum AttractorAssignment {
    Geographic { attractor_type: FeatureTag, quality_score: f32 },
    Synthetic   { reason: SyntheticPlacementReason },
}

enum SyntheticPlacementReason {
    PopulationOverflow,
    PoliticalDecision,
    CorpExpansion,
}

Mismatch Flag Threshold — OPEN FOR ROUND 3

Tyre: flag for lead review when best available attractor score < 0.15
Paula: soft constraint table identifies mismatches at score < 0.35

These are not equivalent. Paula's 0.35 threshold catches more borderline cases; Tyre's 0.15 only catches outright incompatibilities. The lead must resolve which threshold governs the flagged_for_review behavior in Round 3.

Paula's Hard Constraints (H1–H4)

Physical impossibility filter — hard-zeros before any scoring:

• H1: Maritime/coastal corps cannot be assigned to inland attractors
• H2: Resource extraction corps cannot be placed in areas lacking the target resource feature tag
• H3: Agricultural corps cannot be placed in terrain with slope above threshold
• H4: Deep-space station corps cannot have a planetary surface attractor (applies to orbital body placement only)

Paula's is_physically_possible() function runs before score matrix population; these are zero, not low scores.

Ozzie's Player Experience Verdict

Paula's priority ordering + Burnelli-Sheldon's scoring function is correct. "A planet where every city feels 90% correctly placed is better than a planet where the top 5 cities feel 100% correctly placed but smaller cities feel arbitrary." Mismatch flagging is important — silent wrong placements are trust-breakers.

---

2. Three-Component District Mix Algorithm — CONVERGED (Lead-Locked)

Burnelli-Sheldon's three-component model was locked by the lead before Round 2 began. Round 2 produced the full algorithm with pseudocode, resolved all three open sub-questions, and confirmed self-containment.

The Three Components

1. Population tier guarantees — minimum required district counts by population band
2. Economic role multiplier table — integer weights (sum to 100, minimum value 3) per district type per economic role
3. Founding age character modifier — modifies prosperity_baseline and character tags (not weights)

Population Tier Guarantees

Settlement Size	Required Districts
Village (< 1,000)	Residential, Mixed
Town (1,000–9,999)	Residential, Commercial, Mixed
City (10,000–99,999)	+ Entertainment
Large City (100,000+)	+ Administrative
Metropolis (500,000+)	+ Industrial (if applicable), + Civic

BS-Q1 resolved: Town (1k-9,999) has no dedicated Entertainment district. Entertainment at Town scale lives inside the Commercial district. Dedicated Entertainment is a city-scale phenomenon (10k+ threshold).

Integer Multiplier Table (Partial — Lead to confirm full table in Round 3)

Each row sums to 100. Minimum value across all cells: 3 (no zero weights — any district type can appear in any economic role, just rarely).

Economic Role	Residential	Commercial	Industrial	Administrative	Entertainment	Civic	Mixed
Mining/Extraction	35	12	28	8	3	5	9
Manufacturing	30	15	25	8	5	7	10
Research Hub	28	18	10	15	8	12	9
Commercial Hub	22	30	8	10	12	8	10
Administrative	20	15	5	30	8	15	7
Transit/Port	25	20	18	7	5	5	20
Energy	33	10	30	8	3	6	10
Agricultural	35	18	10	5	7	8	17

Political archetype weight modifiers applied after role table (Burnelli-Sheldon):

• CompanyTown: Administrative −10, Industrial +10
• AdminCapital: Administrative +15, Commercial −8, Entertainment −7
• FreePort: Commercial +12, Mixed +8, Administrative −20

BS-Q3 resolved: Energy economic role has minimum Entertainment weight of 3. The guarantee floor (≥1 Entertainment district at City scale) handles large energy cities without special-casing.

Founding Age Character Modifier

BS-Q2 resolved: Age modifier applies only at Backwater tier and above (WorldTier: Backwater | Waypoint | Passage | Epicenter | Regional). Pure waypoint/passage bodies are always architecturally nascent regardless of calendar age.

founding_age_years derivation for sub-settlements (Burnelli-Sheldon):

• Mining camp: parent_city_age - 20
• Planned satellite town: parent_city_age - 5 to parent_city_age - 15 (seed-derived)
• Organic suburb: parent_city_age * 0.7 (grew after city was established)

Age modifiers affect:

• prosperity_baseline offset (old cities start more established; new cities start raw)
• Character tags: legacy_infrastructure, retrofitted, modern_grid, raw_settlement
• Block shape irregularity signal (see Ozzie's Round 3 proposal below)

Self-Containment Confirmed

The district distribution algorithm references only local city/body/system fields. No neighboring city queries. This was a hard requirement from the lead and is confirmed by Burnelli-Sheldon and cross-checked by Gestalt.

SettlementClass Enum (Burnelli-Sheldon)

Generalizes the latent settlement concept from the brief:

enum SettlementClass {
    NameLocked,          // Has a name in atlas_city_names; fully generated at Layer 2
    PopulationBudget,    // Unnamed; placed by population overflow; active if body_population_density > threshold
    EconomicTriggered,   // Unnamed; placed by economic activity; active if route_traffic_score > threshold  
    OrganicGrowth,       // Unnamed; placed by geographic probability; geographically_triggered = false
}

active: bool field on GeneratedSettlement derived from SettlementClass conditions. province_placed_at_generation: bool is immutable and set at Layer 2 generation time.

---

3. TerritorialStatus — CONVERGED

All agents converged on a single priority-ordered algorithm. Paula's placed_at_generation flag incorporated; Burnelli-Sheldon's economic health conditions incorporated; Tyre's corporate road maintenance thresholds incorporated.

Priority-Ordered Algorithm

fn derive_territorial_status(province: &ProvinceWorldState) -> TerritorialStatus {
    // Priority 1: Explicitly abandoned (was settled, now gone)
    if province.placed_at_generation && !province.active {
        return TerritorialStatus::AbandonedZone;
    }
    // Priority 2: Genuinely uninhabited wilderness
    if !province.placed_at_generation && province.settlement_count == 0 {
        return TerritorialStatus::WildernessBuffer;
    }
    // Priority 3: Active resource extraction
    if province.primary_economic_activity == EconomicActivity::Extraction
        && province.corporate_presence_score > 0.4 {
        return TerritorialStatus::ExtractiveZone;
    }
    // Priority 4: Contested territory (overlapping jurisdiction scores)
    if province.jurisdiction_overlap_score > 0.3 {
        return TerritorialStatus::ContestZone;
    }
    // Priority 5: Established territory
    if province.infrastructure_quality > 0.6 && province.corporate_road_maintenance > 0.5 {
        return TerritorialStatus::CoreTerritory;
    }
    // Default: frontier
    TerritorialStatus::FrontierTerritory
}

Enum Values

enum TerritorialStatus {
    CoreTerritory,      // Established, maintained infrastructure
    FrontierTerritory,  // Active but underdeveloped
    ExtractiveZone,     // Resource extraction; corporate presence dominant
    ContestZone,        // Overlapping jurisdiction; political pressure active
    WildernessBuffer,   // Never settled; no generation at Layer 2
    AbandonedZone,      // Was settled; now inactive (placed_at_generation = true, active = false)
}

Key Distinction: AbandonedZone vs. WildernessBuffer

placed_at_generation: bool is the only runtime-available signal. A province that was never settled and an abandoned province both have settlement_count == 0 — the flag is the differentiator. Gestalt confirmed this is the critical bit for ghost-city emergent behavior.

Ozzie's Province Boundary Legibility Requirement

Ozzie flags: Province boundaries must be visible on the planetary map as natural features (drainage basin boundaries, watershed lines), not arbitrary grid lines. If Province boundaries aren't legible, TerritorialStatus doesn't communicate to the player. This is a player experience requirement, not an optional UI decision. To be addressed in Round 3 UI/UX pass.

---

4. Five Explicit Spatial Arrangement Patterns — CONVERGED

Gestalt updated position in Round 2: all five archetypes get explicit spatial arrangement patterns, not just three. Paula introduced Contested and OrganicGrowth in Round 1; Gestalt adopted them.

CompanyTown — Spine Pattern

Linear axis pointing from residential to facility. Residential blocks at one end; industrial facility at the other; administrative and commercial nodes distributed along the spine. The facility must be visually legible from the residential terminus — the spine terminates in something visible.

Player experience (Ozzie): "Everything points toward the facility. The city has a posture." The geometry implies surveillance — the admin building faces the residential blocks.

AdminCapital — Radial Pattern

Administrative hub at center; streets radiate outward; prosperity gradient decreases with distance from hub. All approaches to the city are oriented toward the hub.

Player experience (Ozzie): Power is visible from everywhere. Interesting degenerate case: AdminCapital in decline — hub is geometrically centered but prosperity gradient has inverted (center crumbling, outer ring richer). Ghost-city effect is emergent from this inversion alone, no authored ghost-city feature needed.

FreePort — Multi-Node Pattern

Three to five nodes, each with distinct character (maritime, tech, black market, etc.). Nodes connected by secondary roads; no dominant center. Settlement grew from several independent decisions.

Player experience (Ozzie): Productively disorienting. Nodes must be visually distinct to serve as landmarks — if every node looks generically "mixed," the player can't navigate. Node-level identity must be legible from block character.

Contested — Dual-Center Overlay Pattern (Paula)

Two underlying geometric patterns from two different powers, neither fully resolved. Grid that shifts angle; roads that don't match buildings; a defensive wall repurposed as a property line; a plaza designed for a different political purpose.

Player experience (Ozzie): The player feels the conflict in the urban structure without text explanation. Both underlying geometries must be legible — if the overlay is too subtle, it looks broken rather than historically layered. The seams must be visible.

OrganicGrowth — Irregular Local Density Pattern (Paula)

No spine, no hub, no nodes. Density peaks where people naturally congregated. The center emerged; it wasn't declared. Distinct from CompanyTown (no spine), FreePort (one mass, not nodes), AdminCapital (center emerged, not declared).

Player experience (Ozzie): Most "lived-in" feel of all five. The player reads it as older and more authentic — human decision-making over time rather than planning.

Acceptance Criterion (Ozzie)

Can the player identify the archetype from 15 seconds of walking around? This is the acceptance criterion for explicit spatial arrangement implementation. Each pattern must produce recognizable geometry at the street level.

---

5. Tyre's Four Blocker Schemas — LOCKED

All four ARCH blockers (ARCH-1 through ARCH-4) confirmed with concrete SQL DDL and Rust types. These are the implementation schemas.

ARCH-1: Heightmap Storage (atlas_body_heightmaps)

CREATE TABLE atlas_body_heightmaps (
    body_id INTEGER NOT NULL REFERENCES bodies(id),
    data    BLOB NOT NULL,  -- float32 LE, 512*256 entries = 524,288 bytes per body
    PRIMARY KEY (body_id)
);

Storage estimate: ~512KB/body, ~200MB for 400 bodies. Acceptable.

Rust read:

fn load_heightmap(conn: &Connection, body_id: i64) -> Result<Vec<f32>> {
    let data: Vec<u8> = conn.query_row(
        "SELECT data FROM atlas_body_heightmaps WHERE body_id = ?1",
        [body_id],
        |row| row.get(0),
    )?;
    Ok(bytemuck::cast_slice(&data).to_vec())
}

ARCH-2: BodyWorldState as Bevy Resource (NOT a database)

#[derive(Resource)]
struct GenerationCache {
    entries: LruCache<i64, Arc<BodyWorldState>>,  // key = body_id
}

struct BodyWorldState {
    body_id:           i64,
    seed:              u64,
    heightmap:         Vec<f32>,      // 512×256, loaded from ARCH-1
    river_network:     RiverNetwork,  // D8 drainage routing output
    attractors:        Vec<GeoAttractor>,
    settlements:       Vec<GeneratedSettlement>,
    provinces:         Vec<ProvinceWorldState>,
    generated_at:      std::time::Instant,
}

LRU cache at 50 bodies (~5MB total per Tyre's estimate). Arc<BodyWorldState> for cheap clones across systems. Never serialized; fully reproducible from seed + systems.db.

ARCH-3: City Name Table (atlas_city_names)

CREATE TABLE atlas_city_names (
    id        INTEGER PRIMARY KEY,
    body_id   INTEGER NOT NULL REFERENCES bodies(id),
    name      TEXT    NOT NULL,
    corp_id   INTEGER REFERENCES corporations(id),  -- nullable; corp HQ constraint
    tier_hint INTEGER,  -- nullable; expected WorldTier for this city
    reserved  BOOLEAN NOT NULL DEFAULT 0
);

CREATE INDEX idx_city_names_body ON atlas_city_names(body_id);

Replaces authored positions in atlas_cities. Names are reservations; positions emerge from attractor-matching at Layer 2 runtime.

Rust load:

fn load_city_names(conn: &Connection, body_id: i64) -> Result<Vec<CityNameRecord>> {
    let mut stmt = conn.prepare(
        "SELECT id, name, corp_id, tier_hint FROM atlas_city_names
         WHERE body_id = ?1 ORDER BY id"
    )?;
    // ...
}

ARCH-4: Body Radius Column

ALTER TABLE bodies ADD COLUMN body_radius_km REAL;

Rust read with planet_class fallback:

fn body_radius_km(row: &Row) -> f64 {
    row.get::<_, Option<f64>>("body_radius_km")
        .unwrap_or(None)
        .unwrap_or_else(|| default_radius_for_class(
            row.get("planet_class").unwrap_or("")
        ))
}

Performance Estimates (Tyre)

Operation	Estimate	Notes
D8 drainage routing	~50ms	512×256 heightmap; priority-flood
Attractor scoring + Hungarian	~15ms	N≤30 cities; trivially fast
Settlement placement	~20ms	includes name fulfillment
Province classification	~40ms	TerritorialStatus + ProvinceWorldState
Province WorldTier assignment	~10ms
Total	~136ms	5× headroom vs. 700ms budget

---

6. Background Thread Architecture — LOCKED

Tyre's Round 2 confirmed the full background generation architecture.

Rayon Thread Pool + Coordinator

struct GenerationQueue {
    pending: BinaryHeap<(Priority, BodyGenRequest)>,  // max-heap by priority
    in_flight: HashSet<i64>,                          // body_ids currently generating
}

fn launch_background_generation(body_id: i64, priority: Priority) {
    rayon::spawn(move || {
        let state = generate_body_world_state(body_id);
        GENERATION_CACHE.write().insert(body_id, Arc::new(state));
    });
}

Priority ordering: player-targeted body (highest) → adjacent bodies in travel route → bodies mentioned in recent dialogue → bodies in active corp supply chains → all others.

Aho-Corasick for Text Scanning (SystemNameIndex)

struct SystemNameIndex {
    automaton: AhoCorasick,
    patterns:  Vec<String>,  // system and body names
    body_ids:  Vec<i64>,     // parallel to patterns
}

impl SystemNameIndex {
    fn scan(&self, text: &str) -> Vec<i64> {
        self.automaton.find_iter(text)
            .map(|m| self.body_ids[m.pattern().as_usize()])
            .collect()
    }
}

Used to detect body name references in news tickers, NPC dialogue, and player-readable documents — triggers background generation for mentioned bodies before the player decides to travel there.

Diegetic Placeholder (Ozzie's Three-Tier Proposal)

When the player opens a planetary map for a body whose Layer 1-2 cascade hasn't completed:

Tier A (most worlds, ~3-5s gap): Terrain + coastlines from heightmap (already loaded); settlements shown as "unconfirmed" markers. Player sees the shape of the world but not the civilization. This is the normal fallback — most maps complete before the player opens them.

Tier B (frontier/remote worlds): Old orbital survey data with visible timestamp ("Last comprehensive survey: 41 years ago"). Historical positions shown; may not match generated reality. Creates discovery tension: map says one thing; world shows another.

Tier C (system just mentioned): Black circle with blinking cursor. "Survey data unavailable. Scan in progress." Highest drama — player is about to explore somewhere they just heard about.

Priority fallback chain:

1. Generation complete → full map
2. Heightmap loaded, settlements not placed → terrain + coastlines + "settlement survey pending"
3. Only systems.db data → known city names as points, no positions, "Positional survey pending"
4. Nothing → blinking cursor + system timestamp + "No survey data"

Design principle (Ozzie): "The placeholder should read like information, not like a loading state. The player should learn something from it, even in the worst case."

---

7. Tile Condition and Prosperity — CONFIRMED

Paula's Threshold Offsets (Gestalt Adopted in Round 2)

Tile condition derived from prosperity_current (not prosperity_baseline):

Condition	Threshold
Intact	prosperity_current > 0.63
Worn	prosperity_current 0.43–0.63
Cracked	prosperity_current 0.23–0.43
Broken	prosperity_current < 0.23

Paula's rationale for 0.63/0.43/0.23 over Gestalt's original 0.6/0.4/0.2: offsets from round numbers prevent boundary oscillation when prosperity fluctuates near the threshold. Gestalt adopted Paula's values in Round 2.

prosperity_baseline vs. prosperity_current

Two distinct fields. prosperity_delta = prosperity_current - prosperity_baseline is derived, never stored. Paula flags this as a rendering legibility requirement: the client needs both fields to show historical vs. current state.

---

8. Name Reservation Fulfillment (Paula) — NEW

Paula introduced a four-stage name fulfillment pipeline:

• Stage 0 (build-time): Build name reservation table from atlas_city_names; mark HQ-constrained names
• Stage 1 (Layer 1 runtime): Assign names to geographic features (rivers, mountain passes, bays) first — these are features, not cities
• Stage 2 (Layer 2 attractor-matching): Assign reserved city names to generated settlement positions during or immediately after attractor-matching; HQ-constrained names placed first (Tier A)
• Stage 3 (overflow): Remaining unnamed settlements generated procedurally; remaining reserved names fulfilled if attractor match exists, otherwise deferred

atlas_feature_names table added (distinct from atlas_city_names):

CREATE TABLE atlas_feature_names (
    id       INTEGER PRIMARY KEY,
    body_id  INTEGER NOT NULL REFERENCES bodies(id),
    name     TEXT NOT NULL,
    tag_hint TEXT  -- nullable; expected FeatureTag for this name
);

---

9. Cascade Transition Moments (Ozzie) — DESIGN NOTE

Ozzie identifies five tier transitions as player experience opportunities. These are not authored setpieces — they emerge from each layer correctly setting up the next layer's opening condition.

Transition	What produces it
Entering atmosphere	Coastlines visible from space; lit cities at night (Layer 1 terrain + Layer 2 settlement positions)
Crossing Province boundary	Road condition change; signage style change (TerritorialStatus + corporate road maintenance)
Entering Region (city footprint)	Density increases; wilderness thins; city visible before arriving (Region extent field)
Entering District	Perimeter treatment marks the threshold (District perimeter_treatment field)
Entering building	Door threshold; interior lighting transition

"The cascade is the experience. Design each handoff so the player feels the seam." No action required in Round 3 — this is a design note to carry forward to Phase 4 implementation.

---

10. WorldTier Enum — BUG FLAGGED

The code has wrong values: Peripheral | Connected | Core. Required values (from the brief and all agents): Epicenter | Regional | Backwater | Passage | Waypoint.

This is a code bug, not a design question. Needs a ticket. No Round 3 discussion required.

---

11. Open Questions for Round 3

Q1 — Mismatch flag threshold [MUST RESOLVE]

Tyre: score < 0.15 → flagged_for_review
Paula: soft constraint table flags mismatches at score < 0.35
These are not compatible. The lead must choose one value (or a two-level system: warning at 0.35, hard-flag at 0.15).

Q2 — founding_age → layout_mode [OZZIE PROPOSAL]

Ozzie proposes: founding age should modify layout_mode as well as prosperity_baseline. Old settlements → irregular layout modes. Young settlements → grid layout. This would require layout_mode to be a weighted choice at District generation, not a fixed archetype value. Needs evaluation from Gestalt and Tyre.

Q3 — Province boundary legibility [OZZIE REQUIREMENT]

Province boundaries must be visible on the planetary map as natural features (watershed lines, drainage basins). Currently unspecified whether the planetary map renders Province boundaries. UI/UX item for Round 3.

Q4 — L3-Q7: Port/station as special city type [DEFERRED TO ROUND 3]

Not addressed in Round 2. Still open.

Q5 — atlas_city_names population path [NEEDS CLARIFICATION]

How are city names added to atlas_city_names? Hand-authored? Generated from brand files? Generated from Miri's naming system? Tyre locked the schema; Paula added Stage 0-3 fulfillment stages; neither specifies who writes the source rows before Stage 0.

Q6 — Attractor multiplier table full values [NEEDS CONFIRMATION]

The full integer multiplier table needs all economic roles confirmed, including any roles not covered in Burnelli-Sheldon's Round 2 examples. Round 3 should produce the locked table.

---

12. Items NOT Raised in Round 2 (Carried Forward as Locked)

These were settled before or during Round 1 and not reopened:

• SeedChain (FNV-1a) — locked from generation-cascade workshop
• D8 drainage routing — accepted by all agents, confirmed in Tyre's ARCH-1
• Scatter deferred — lead decision; Ozzie accepted; Gestalt noted spawn_category: Option<PropCategory> hook in TileEntry for future activation
• District = 256m — confirmed by Tyre, accepted by Ozzie as correct player experience scale
• Block = 64m — confirmed as 4×4 per district
• Province = 1 regional grid cell (~540km×270km on reference body) — confirmed by Tyre
• Area = atlas layer, not navigation tier — confirmed by Ozzie
• Self-contained district generation — lead decision; confirmed by all agents

---

Agent Positions Summary

Item	Gestalt	Tyre	Paula	Burnelli-Sheldon	Ozzie
Attractor algorithm	Hungarian + 5 phases	Hungarian + HQ-first	Priority ordering + mismatch flags	Objective function + synthetic attractors	Paula ordering + BS scoring
District mix	Three-component (confirmed)	Schema support	Accepted	Authored	Accepted
TerritorialStatus thresholds	Priority-ordered (Rust code)	Priority-ordered (Rust code + corporate road)	placed_at_generation flag	Economic health conditions	Accepted
Spatial patterns	All five explicit	No position	Introduced Contested + OrganicGrowth	Accepted	All five produce distinct feel
ARCH blockers	Schema acceptance	All four locked	atlas_city_names schema contribution	—	—
L4-Q2 thresholds	Adopted Paula's 0.63/0.43/0.23	0.63/0.43/0.23	Proposed 0.63/0.43/0.23	Accepted	—
founding_age → layout_mode	Not raised	Not raised	Not raised	Age modifier only	Proposed for Round 3

---

Round 2 complete. Five agents in agreement on all locked items. Two MUST-RESOLVE items for Round 3: mismatch flag threshold (Q1) and founding_age→layout_mode (Q2). WorldTier enum bug needs a ticket before implementation begins.