docs(decisions): file Q-081 through Q-088 + tickets #722-735

Plugin research session — Q-records for architectural evaluation:
Q-081: VisionCone3D client-side fog refinement (high priority)
Q-082: VoronoiShatter destruction effects
Q-083: ThemeGen dynamic insert styling
Q-084: Isometric point-and-click navigation pattern
Q-085: Portal rendering for server-side visibility
Q-086: Day/night cycle — server time driving client lighting
Q-087: Water shader for environment zones
Q-088: Spatial audio for information-aware sound

Q-077 expanded with Retro Terrain + Spatial Gardener references.

Tickets: DB tooling --help (#722), decision coverage report (#723),
version display (#724), auto-size labels (#725), cargo deny config
(#726), icon fonts (#727), resolution testing (#728), install wizard
(#729), license screen (#730), konami code (#731), minimap (#732),
nested tooltips (#733), speech bubbles (#734), settings epic (#735).

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

decisions/questions-architecture.md

@@ -202,6 +202,7 @@ 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
 
 ---
@@ -227,4 +228,61 @@ Technical foundation questions: engine, protocols, data structures, performance,
 
 ---
 
-*32 questions (7 resolved, 1 partially resolved, 24 open). Last updated: 2026-03-23.*
+### Q-081: VisionCone3D for client-side fog refinement
+- **Status:** Open (high priority — solves the 2D→3D fog transition problem)
+- **Question:** VisionCone3D (https://github.com/Tattomoosa/VisionCone3D) — 3D vision cone raycasting in Godot. MIT, Godot 4.4+. Proposed architecture: (a) Server does authoritative shadowcasting per D-011/D-015, sends visible chunk list in ObserverSnapshot (coarse grid truth). (b) Client uses VisionCone3D to re-trace locally against actual 3D wall geometry within the server-approved visible area. (c) The client's vision cone output drives 3D fog-of-war rendering with smooth, geometry-following edges instead of tile-stepped boundaries. This solves the stepped edge display issue from communicating visibility as grid chunks — the client refines to sub-tile accuracy using real 3D geometry. No information leak: client can only refine within server-approved visible chunks, never see beyond. The cone configuration mirrors the server's D-015 vision cone (forward/peripheral/blind spot zones). Performance tuning options available per the plugin docs.
+- **Cross-reference:** D-011 (LOS shadowcasting), D-015 (vision cone), D-043–D-049 (fog system), fog_state.gd (current 2D fog implementation)
+
+---
+
+### 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.
+- **Cross-reference:** Combat system, damage visualization, environment interaction
+
+---
+
+### Q-083: ThemeGen for dynamic insert styling and value-level theming
+- **Status:** Open
+- **Question:** ThemeGen (https://github.com/Inspiaaa/ThemeGen) — themes-as-GDScript-code with semantic colours, reusable styles, theme variations, and live preview in editor. MIT. Directly relevant to dynamic inserts: (a) Value-level theming — common/uncommon/rare items get different colour palettes from the same base layout. (b) Faction-themed inserts — Frost Compact cold blues, Reach Authority golds, derived programmatically from a base theme. (c) Danger/security level indicators — zone inserts shift colour based on threat level. (d) Player customisation — let players pick an insert accent colour, ThemeGen derives the full palette. The code-based approach means themes can be generated from server data (faction ID → theme variation) without authoring each one.
+- **Cross-reference:** Diegetic UI / insert system, Stig (UI developer), Araminta (visual design)
+
+---
+
+### Q-084: Isometric point-and-click navigation pattern
+- **Status:** Open
+- **Question:** Reference: isometric-2d-point-and-click-movement (https://github.com/Domogo/isometric-2d-point-and-click-movement). This is 2D but the interaction pattern applies to our 3D isometric setup: click ground tile → convert screen position to tile coordinate → server pathfinds (A* on tile grid) → client animates character along path. Key problems to solve: (a) mouse→3D isometric tile coordinate conversion (ray from camera through click point to ground plane, accounting for D-148 45° map rotation). (b) Path visualization (preview line showing where character will walk). (c) Click-to-move vs WASD — do we support both? (d) Server roundtrip latency — does the client predict movement or wait for server confirmation? Study for interaction patterns, implement in our 3D stack.
+- **Design notes:** Character stays center-screen, map scrolls around them (not character moving on static map). Character always faces toward mouse cursor — this creates a natural looking-direction that drives the D-015 vision cone direction. Unresolved: what happens visually when walking one direction while looking backward (walk animation vs facing direction conflict — later solve). Latency: 200ms feels instant in web interactions (Jeroen's rule from web design) — if server roundtrip is under 200ms, click-to-move without client prediction may be acceptable. Needs user testing to verify.
+- **Cross-reference:** D-148 (camera angle), D-010 (server authority), D-015 (vision cone facing), navigation/pathfinding
+
+---
+
+### Q-085: Portal rendering for spatial transitions and viewports
+- **Status:** Open
+- **Question:** Portal concept — not the Godot plugin (client doesn't need it — transparency handles adjacent rooms, SubViewport handles remote camera feeds). The SERVER needs portal logic: when the shadowcasting/vision cone hits a door opening, visibility extends through it into the next room. Portals are openings in the tile grid that allow raycasts to pass between rooms/zones. Study the plugin (https://github.com/VojtaStruhar/godot-portals-plugin) for the spatial math patterns, implement in Rust server's visibility system. Key: doors open = portal active = vision extends through. Doors closed = wall = vision blocked.
+- **Cross-reference:** D-011 (LOS), D-015 (vision cone), z-level system, information boundary design
+
+---
+
+### Q-086: Day/night cycle — server time driving client lighting
+- **Status:** Open
+- **Question:** Reference: DynamicDayNightCycles (https://github.com/eisclimber/DynamicDayNightCycles). The game time is server-authoritative — server ticks time, sends current time-of-day in ObserverSnapshot. Client renders lighting accordingly. Station interiors: artificial lighting follows schedules (dim at night cycle, full during work shifts). Exterior/rural zones: sun position, sky color, shadow direction from time of day. Station viewports could show star position shifting. NPC schedules already tied to time (D-097 schedule state machine). Key question: how granular is the lighting transition — smooth real-time interpolation or discrete time blocks (morning/afternoon/evening/night)?
+- **Cross-reference:** D-097 (NPC schedules), environment lighting, server game clock
+
+---
+
+### Q-087: Water shader for environment zones
+- **Status:** Open
+- **Question:** Godot Realistic Water (https://github.com/godot-extended-libraries/godot-realistic-water) — water rendering with reflections, refraction, waves. May be too realistic for our toon aesthetic — evaluate whether it can be styled down or if a simpler toon water shader is better. Use cases: docking bay water features, hydroponic farms, waste processing, rural rivers/lakes, rain puddles, port zones, fountains. Question: does toon water need reflections or just stylized wave animation + color? The Retro Terrain reference (Q-077) already handles water tile transitions — this adds the surface rendering. Also check if GL compatibility renderer supports the shader features.
+- **Cross-reference:** Q-077 (world generation / terrain), environment aesthetics, GL compatibility renderer
+
+---
+
+### Q-088: Spatial audio for information-aware sound
+- **Status:** Open
+- **Question:** spatial_audio_player_3d (https://github.com/Danikakes/spatial_audio_player_3d) — 3D spatial audio with occlusion and environmental awareness. Directly tied to the information system: sound carries information. Footsteps through walls = muffled (you know someone's there but not who). Conversation in the next room = faint/unintelligible (partial information). Gunshot echoes in corridors = direction cues. The server already knows which audio events are in hearing range (part of the ObserverSnapshot). The client needs spatial rendering: distance attenuation, wall occlusion, reverb based on room size/material. Also ties into Inigo's audio design specs. Evaluate whether this plugin handles occlusion raycasting or just basic 3D positioning.
+- **Cross-reference:** D-011 (LOS — audio equivalent), Inigo (sound designer), information boundary, audio propagation rules
+
+---
+
+*40 questions (7 resolved, 1 partially resolved, 32 open). Last updated: 2026-03-23.*