settled-reach/docs/workshops/generation-cascade/BRIEF.md

title, description, type, status, workshop, agent, round, created

title	description	type	status	workshop	agent	round	created
Workshop Brief	Audit the generation pipeline implementation state, map all layers from heightmap to walkable tile, produce D-records and ticket dependency flows	workshop	active	generation-cascade		0	2026-04-24

Generation Cascade Workshop Brief

Goal: Audit the full generation pipeline from planetary heightmaps to walkable tile environments. For each layer: document what exists, what's stub, and what's missing. Produce D-records and a ticket dependency chain that formally blocks character and apartment work behind the complete pipeline.

Ticket: #897 Priority: HIGH — load-bearing for Sprint 38 and all downstream Phase 4/5 work Participants: Gestalt (systems design), Tyre (architecture/feasibility), Miri (worldbuilding/cultural inputs) Source: Lead directive (2026-04-24): "we keep cycling back to these topics. I want them parked behind the full cascade from now on."

---

Context

The generator-architecture workshop (2026-02-27) designed the full data model: DistrictSkeleton, BlockSkeleton, ChunkData, two-phase generation (Phase 1 skeleton, Phase 2 chunk fill). The outcomes are at docs/workshops/generator-architecture/workshop-outcomes.md.

The architecture is designed. The implementation is mostly stubs. The Rust types in server/src/simulation/generator.rs compile but no code actually produces filled instances. The team keeps drifting to character creation, apartment generators, and tycoon starting states — all of which sit several pipeline layers below what's actually built.

This workshop is NOT a redesign. It's an implementation audit and cascade formalization.

What exists (confirmed working)

Layer	What	Status
Galactic	System definitions, star data	Done — systems.db, wiki
System	Body definitions, orbital mechanics	Done — systems.db
Planetary surface	Heightmaps, terrain simulation	Done — tooling/planet-gen/planet_simulation.py
Atlas markers	City placement, roads, rail, rivers, mountains	Done — tooling/planet-gen/generate_atlas.py, markers.json
City naming	Gemma-driven cultural naming	Done — tooling/planet-gen/gemma_naming.py
Economics	Supply chains, corporations, brands, trade flows	Done — tooling/economy-db/, systems.db

What exists as types only (stubs, no generation logic)

Layer	What	Location
District skeleton	DistrictSkeleton, BlockSkeleton, enums	server/src/simulation/generator.rs
Chunk streaming	Load/unload system	server/src/simulation/chunk_streaming.rs
Triangle system	TriangleAssignment, TrianglePurpose	server/src/simulation/triangle.rs

What's missing entirely

This is what the workshop must map. Suspected gaps include:

• Regional/continental subdivision (between heightmap and city)
• City-to-district decomposition (how does a city marker become N districts?)
• District skeleton generation (the actual Phase 1 code)
• Block fill / zoning assignment
• Chunk tile generation (Phase 2)
• Infrastructure placement within districts (roads, utilities at local scale)
• Vertical structure generation (multi-floor buildings)

---

Key Questions to Resolve

1. Pipeline Inventory (all participants)

For each layer from planetary heightmap to walkable tile:

• What is the layer's input and output?
• What code/data exists today?
• What's the minimum viable implementation?
• What decisions from the generator-architecture workshop apply?

2. Layer Dependencies (Tyre)

• What is the strict dependency order? Which layers can be parallelized?
• Where are the data format boundaries (file vs. runtime, Python vs. Rust)?
• What's the testing strategy per layer? Can each layer be validated independently?

3. Cultural and Worldbuilding Inputs (Miri)

• At which layers do cultural inputs (society profiles, naming, architectural style) enter the pipeline?
• What wiki/content data is needed before each layer can generate?
• Are there content gaps that block generation even if the code existed?

4. System Interactions (Gestalt)

• How does each generation layer interact with the economics layer?
• Where do social sites, NPC population, and zone palettes enter?
• What's the minimum viable "viewable world" — the thinnest vertical slice from heightmap to rendered tiles?

5. Ticket Dependency Chain (all participants)

• What tickets exist for missing layers? What new tickets are needed?
• What is the formal dependency chain that blocks character work (#694, #619) and apartment work (#681, #682)?
• Which existing tickets (#615, #616) should be re-scoped or deferred?

---

Workshop Format

3 rounds:

Round 1 — Inventory

Each participant audits the pipeline from their domain perspective. List every layer, its state (done / stub / missing), inputs, outputs, and the key file paths. Write findings to docs/workshops/generation-cascade/{agent}-round1.md.

Round 2 — Proposals

Based on the combined inventory, propose: the ordered implementation plan, the ticket dependency graph, and the D-records needed. Identify the thinnest vertical slice that produces viewable output. Write proposals to docs/workshops/generation-cascade/{agent}-round2.md.

Round 3 — Convergence

Lock the D-records, finalize the ticket dependency chain, and produce the formal blockers. Each participant reviews the proposed D-records and flags disagreements. Write final positions to docs/workshops/generation-cascade/{agent}-round3.md.

---

Required Reading

Before Round 1, all participants must read:

• docs/workshops/generator-architecture/workshop-outcomes.md — the designed architecture
• server/src/simulation/generator.rs — the current data model (stubs)
• server/src/simulation/chunk_streaming.rs — chunk load/unload system
• tooling/planet-gen/generate_atlas.py — what the atlas generator produces
• decisions/architecture.md — D-110 (signed z-levels), D-108 (MobileChunk)
• CLAUDE.md §Development Cascade — the phase definitions

---

Expected Outputs

1. D-record(s) in decisions/ defining the generation pipeline layers, their order, and their implementation status
2. Ticket dependency graph — new tickets for missing layers, ticket_deps entries blocking character/apartment work
3. Updated existing tickets — #615, #616, #619, #681, #682, #694 re-scoped or formally blocked
4. Implementation priority order — which layer to build next (informs #899 and future sprints)