docs(workshops): create world generation workshop brief from Q-077

Q-077 promoted to full workshop brief with 9 reference implementations,
7 key questions, 5 zone types, and agent assignments (Tyre, Gestalt,
Nigel, Miri, Ozzie).

Also: Q-089 through Q-092 filed (starfield, Markov names, event audio,
modular settings menu), make clean-imports target added.

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

Makefile

@@ -208,6 +208,15 @@ test-ipc-integration:
 test-ipc-benchmark:
 	tests/run-ipc-benchmark
 
+# --- Clean ---
+
+clean-imports:
+	@echo "Removing Godot import cache..."
+	rm -rf client/.godot/imported/
+	@echo "Re-importing assets (this may take a while on first run)..."
+	$(GODOT) --headless --path client --import --quit
+	@echo "Import cache rebuilt."
+
 # --- Lint ---
 
 lint: lint-server lint-client

decisions/questions-architecture.md

@@ -180,7 +180,7 @@ Technical foundation questions: engine, protocols, data structures, performance,
 
 ### Q-074: Screenshot manager for in-game captures and bug reports
 - **Status:** Open
-- **Question:** ScreenshotManager (https://github.com/ASecondGuy/ScreenshotManager) — evaluate for improving the existing F12 bug reporter's screenshot capture. We already have F12 screenshot + bug report in-game. This plugin could improve it: better file management, auto-naming, viewport isolation, gallery/history. Evaluate what patterns we can adopt into the existing bug reporter flow.
+- **Question:** Two references for improving the existing F12 bug reporter: (a) ScreenshotManager (https://github.com/ASecondGuy/ScreenshotManager) — better screenshot file management, auto-naming, viewport isolation. (b) BugReporter (https://github.com/ASecondGuy/BugReporter) — patterns for attaching system info, game state snapshots, reproduction steps to bug reports. Both from the same author. Evaluate what patterns we can adopt into our existing bug reporter flow.
 - **Cross-reference:** `/bug-report` skill, character creator screenshot system
 
 ---
@@ -199,11 +199,10 @@ Technical foundation questions: engine, protocols, data structures, performance,
 
 ---
 
-### Q-077: CityCrafter3D — procedural city/settlement generation
-- **Status:** Open (high interest)
-- **Question:** CityCrafter3D (https://github.com/immaculate-lift-studio/CityCrafter3D) — procedural 3D city generation in Godot. The generation logic needs to be in Rust (server-side, D-020), but the patterns are highly relevant: road network generation, building placement rules, district zoning, lot subdivision, procedural layout algorithms. Study as a reference implementation for our Rust-side location generator. Key questions: what algorithms does it use (wave function collapse, L-systems, grid subdivision)? How does it handle building variety from limited asset sets? What's the data model for a generated city — can we extract the layout representation and replicate it in Rust with the client rendering from server-sent layout data?
-- **Additional references:** (a) Retro Terrain (https://github.com/NickToony/gd-retroterrain) — tile-based 3D terrain like Rollercoaster Tycoon / old strategy games. Terrain edges, height variation, water. Directly applicable to wilderness zones, rural villages, and outdoor areas. The tile-based approach maps to our server grid. Study for how terrain type transitions (grass→rock→water) are handled at tile edges. (b) Godot Spatial Gardener (https://github.com/dreadpon/godot_spatial_gardener) — procedural vegetation placement with instancing, density controls, collision awareness, LOD. For populating wilderness zones with trees, grass, bushes. Server sends vegetation density/type per tile, client uses gardener-style instancing to render it efficiently.
-- **Cross-reference:** Generator architecture, D-096 (chunk loading), D-097 (simulation tiers), location generation
+### Q-077: World generation architecture → PROMOTED TO WORKSHOP
+- **Status:** Promoted — see `docs/workshops/world-generation/BRIEF.md`
+- **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`
 
 ---
 
@@ -238,6 +237,7 @@ Technical foundation questions: engine, protocols, data structures, performance,
 ### Q-082: VoronoiShatter for destruction effects
 - **Status:** Open
 - **Question:** VoronoiShatter (https://github.com/robertvaradan/voronoishatter) — procedural Voronoi fracture of 3D meshes into rigidbody pieces. MIT, Godot 4.4+, native GDScript. Convex and concave mesh support, seamless materials, auto rigidbody generation. Use cases: wall breaches during combat, crate/container destruction, station hull damage, environmental destruction. Pure client-side visual effect — server sends "object destroyed," client shatters the mesh locally. The Voronoi pattern gives natural-looking irregular fractures. Could pre-compute shatter patterns at load time for performance, trigger on damage event.
+- **Companion:** Particle Scene Compositor (https://github.com/tvenclovas96/particle-scene-compositor) — spawn scene instances as particles. Destruction fragments + sparks/smoke/dust in one effect. Shatter → fragments fly → each fragment emits particles.
 - **Cross-reference:** Combat system, damage visualization, environment interaction
 
 ---
@@ -285,4 +285,32 @@ Technical foundation questions: engine, protocols, data structures, performance,
 
 ---
 
-*40 questions (7 resolved, 1 partially resolved, 32 open). Last updated: 2026-03-23.*
+### Q-089: Procedural star rendering for space viewports and star map
+- **Status:** Open
+- **Question:** Godot Starlight (https://github.com/tiffany352/godot-starlight) — procedural starfield rendering. Use cases: (a) Station viewport backgrounds — look out a window, see stars. (b) Star map navigation screen. (c) Docking bay exterior views. (d) Skybox for any exterior/surface zone. Could combine with Q-064 (planet generator) for full space vista — procedural stars + procedural planets visible from station viewports. Seed from system coordinates for consistent views per location.
+- **Cross-reference:** Q-064 (planet generator), station viewport design, star map UI
+
+---
+
+### Q-090: Markov chains for procedural name/text generation in Rust
+- **Status:** Open
+- **Question:** Pattern reference: Markov Machine (https://github.com/BirDt/markov-machine) — Markov chain text generation. Need a Rust crate, not the Godot plugin. Candidates to evaluate: `markov` crate, `markov_chain` crate, or hand-roll (Markov chains are ~50 lines of Rust). Use cases: NPC name generation from cultural name pools (train on corridor-specific names, generate plausible new ones), shop/business name generation, procedural signage text, news ticker filler, overheard conversation snippets. Faster and cheaper than LLM for short text that just needs to feel culturally consistent. Could train separate chains per corridor/culture for regional flavor. The existing voice pipeline (Gemma 2) handles dialogue variation — Markov is for the lightweight procedural text that doesn't need semantic coherence.
+- **Cross-reference:** Generator architecture, name pools, voice pipeline (server/src/voice/)
+
+---
+
+### Q-091: Event-driven audio system
+- **Status:** Open
+- **Question:** Event Audio (https://github.com/bbbscarter/event-audio-godot) — data-driven event→sound mapping. Game events trigger audio without hardcoded play() calls. Complements Q-088 (spatial audio handles WHERE, this handles WHEN/WHAT). Server sends game events in ObserverSnapshot (door opened, NPC entered, combat started), client maps these to audio via configuration. Inigo's audio design specs define the sound palette — this system is the dispatcher that connects game events to that palette. Evaluate whether we adopt the plugin pattern or build our own event→audio bus.
+- **Cross-reference:** Q-088 (spatial audio), Q-063 (footsteps), Inigo (sound designer), AudioManager autoload
+
+---
+
+### Q-092: Modular settings menu as foundation for #735
+- **Status:** Open
+- **Question:** Godot Modular Settings Menu (https://github.com/MarkVelez/godot-modular-settings-menu) — composable settings panels for keybinds, audio, video, accessibility. Evaluate as the foundation for epic #735 (Settings and input system). Instead of building keybind remapper, audio sliders, resolution picker, and controller support from scratch, start from this template and restyle to match our UI aesthetic. Key: the modular approach means we can add/remove panels as features are implemented without restructuring.
+- **Cross-reference:** Epic #735 (settings/input system), Frame0 wireframe session
+
+---
+
+*44 questions (7 resolved, 1 partially resolved, 36 open). Last updated: 2026-03-23.*

docs/workshops/world-generation/BRIEF.md

@@ -0,0 +1,68 @@
+---
+title: "World Generation Architecture Workshop"
+description: "Design the procedural world generation pipeline — from Rust server layout generation to Godot client rendering. Covers urban, rural, wilderness, and station interior zones."
+type: workshop
+status: draft
+agents: "TYRE, GESTALT, NIGEL, MIRI, OZZIE"
+---
+
+# Workshop Brief — World Generation Architecture
+
+**To:** TYRE, GESTALT, NIGEL, MIRI, OZZIE
+**From:** Jeroen
+
+## The problem
+
+We need a procedural generation pipeline that creates explorable locations — station interiors, settlements, rural villages, wilderness areas, industrial zones. The server generates the layout (Rust/bevy_ecs), the client renders it (Godot 3D isometric). No location is hand-authored — everything comes from the generator with cultural, economic, and narrative constraints.
+
+## Constraints
+
+- Server-authoritative (D-010, D-020) — generation logic in Rust, client renders from snapshot data
+- Chunk-based streaming (D-096) — only load what's near the player
+- Simulation tiers (D-097) — Active/Background/State-saved/Ungenerated
+- Tile-grid foundation — server works in 2D tile coordinates, client renders 3D
+- Must handle z-levels (D-148 confirms multi-height structures)
+- Toon shader aesthetic — all assets go through our shader pipeline
+- Assets from Poly Haven (CC0) and Quaternius — run through toon shader
+
+## Zone types to generate
+
+1. **Station interiors** — corridors, modules, docking rings, residential blocks, commercial areas
+2. **Urban/port zones** — streets, buildings, markets, docking facilities
+3. **Rural villages** — scattered buildings, fields, paths, natural terrain
+4. **Wilderness** — forests, terrain, water bodies, cave entrances
+5. **Industrial** — factories, extraction sites, refineries, warehouses
+
+## Reference implementations to study
+
+These are Godot plugins studied for patterns — the generation itself happens in Rust.
+
+| Reference | What to study | Relevance |
+|---|---|---|
+| [CityCrafter3D](https://github.com/immaculate-lift-studio/CityCrafter3D) | Road networks, building placement, district zoning, lot subdivision | Urban zones |
+| [Chunk Manager](https://github.com/repulobalna/chunk_manager) | Runtime chunk load/unload, LOD tiers, async generation, memory budget | Streaming infrastructure |
+| [Retro Terrain](https://github.com/NickToony/gd-retroterrain) | Tile-based 3D terrain, terrain edge transitions, height variation, water | Wilderness/rural zones |
+| [Spatial Gardener](https://github.com/dreadpon/godot_spatial_gardener) | Procedural vegetation placement, density controls, collision avoidance, LOD | Wilderness population |
+| [GridMapLayer](https://github.com/Caaz/grid-map-layer) | 2D tile rules → 3D grid rendering, autotiling | Client-side tile rendering |
+| [Block-based Procedural Map](https://godotengine.org/asset-library/asset/2698) | Perlin noise, seed determinism, chunk loading patterns | Terrain generation |
+| [PathMesh3D](https://github.com/iiMidknightii/PathMesh3D) | Extrude 2D profiles along paths (pipes, cables, corridors) | Station interior detail |
+| [DeformableMesh](https://github.com/cloudofoz/godot-deformablemesh) | Runtime mesh deformation for variety from shared assets | Environmental variation |
+| [Poly Haven](https://polyhaven.com) | CC0 3D models, textures, HDRIs | Environment asset sourcing |
+
+## Questions to resolve
+
+1. **What data does the server send?** Tile palette + grid + object placement? Or higher-level "room type + seed" that the client expands?
+2. **How are buildings generated?** Wave function collapse? L-systems? Grammar-based? Template stamping with variation?
+3. **How does the client render tiles?** GridMapLayer autotiling? Direct mesh placement? Hybrid?
+4. **How do z-levels work visually?** Transparency of upper floors? Cutaway? Layer toggle?
+5. **What's the minimum viable generator?** What ships in v0.2 vs what's future?
+6. **How do cultural constraints flow into generation?** Corridor heritage → architectural style → tile palette selection?
+7. **How does the generator handle interiors vs exteriors?** Same pipeline or separate?
+
+## This workshop does NOT produce
+
+- Working code
+- A locked technology choice
+- Implementation tickets (those come after)
+
+It produces an architecture document with the data flow, algorithm choices, and client-server boundary defined.