docs(docs): Sprint 22 planning — Q-052/Q-053/Q-054, D-108 amendment

- Q-052: Storyteller hint delivery — parallel diegetic channel model
  with 8 ranked channels, scaling properties, signal pollution gating
- Q-053: Insert workspace boards — design philosophy and information
  architecture (general-purpose communication layer, not mechanic)
- Q-054: Insert workspace board — rendering primitive data contract
  with 6 open technical questions
- D-108: Amended with MobileChunk Idle state note and D-111 cross-ref
- Ticket #162 scoped for Sprint 23 (storyteller module activation)
- Ticket #566 done (D-108 documentation update)
- Tickets #570-572 created (EngagementRecord, MovementHistoryBuffer,
  triangle lifecycle rules)

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

decisions/architecture.md

@@ -324,7 +324,8 @@ Technical foundation decisions that constrain implementation: engine, client-ser
 - **Source:** Generator Architecture Workshop (#562), 2026-02-27. `docs/workshops/generator-architecture/workshop-outcomes.md` §D-READY-13.
 - **Raised by:** Tyre (struct design), Miri (cultural grammar — `miri-round4.md`), Nigel (replayability requirements), Ozzie (player experience). Visual grammar: Araminta (`araminta-round4.md` §2).
 - **Dissent:** Nigel initially proposed instanced districts for vessels; lead ruled entity-carried MobileChunk for persistence.
-- **Cross-reference:** D-100 (DamageOverlay applies to vessel damage), D-109 (LocalOverlay mandate), Q-046 (departure schedule — resolved by this D-record)
+- **Note:** The `Idle` movement state is the canonical primitive for player-owned stationary installations (space stations, orbital platforms, parked vessels as permanent bases). A MobileChunk in `Idle` with no `scheduled_departure` is architecturally equivalent to a static chunk from the simulation's perspective — it participates in the same tile/zone system. This design prevents future over-engineering of a separate 'player installation' system.
+- **Cross-reference:** D-100 (DamageOverlay applies to vessel damage), D-109 (LocalOverlay mandate), D-111 (MobileChunk Idle state as stationary installation primitive), Q-046 (departure schedule — resolved by this D-record)
 
 ### D-109: DamageOverlay / RegenerationStrategy Prohibition — Architectural Mandate
 - **Date:** 2026-02-27
@@ -373,4 +374,4 @@ Technical foundation decisions that constrain implementation: engine, client-ser
 
 ---
 
-*32 decisions. Last updated: 2026-02-27 (D-110 through D-112 added — z-level and subterranean architecture)*
+*32 decisions. Last updated: 2026-02-28 (D-108 amended Sprint 22 — Idle state as stationary installation primitive note added, D-111 cross-reference added)*

decisions/questions.md

@@ -335,6 +335,88 @@ Tracked questions awaiting discussion or resolution.
 - **Context:** When multiple NPCs are nearby and the dialogue log is scrolling, it can be hard to tell who is speaking. A floating speech bubble icon (not the text itself — just the indicator) over the speaker's sprite would anchor dialogue to world position. Color-coding to match the dialogue log's per-character colors reinforces the mapping.
 - **Assigned to:** Stig + Araminta
 
+### Q-052: Storyteller hint delivery — parallel diegetic channels when player does not act
+- **Status:** Open (Sprint 22 analysis complete, awaiting implementation scoping)
+- **Priority:** High
+- **Question:** When a TriangleActivated event fires and the player does not investigate, what mechanisms create conditions for discovery? How do these scale from v0.1 (1-2 triangles) to the full game (300 worlds, 10+ simultaneous triangles, 8 archetypes)?
+- **Core design principle:** "The storyteller is not delivering messages — it is creating conditions under which the player's existing relationships, existing investments, and existing world naturally produce signal." Player inaction is a valid outcome, not an error state. Consequences happen; the world moves on.
+- **Channel inventory (ranked by deniability — least nudge-like first):**
+  1. **Behavioral tell escalation** — activated triangle NPCs exhibit more pronounced tells (D-024 axis 9). Always active, proximity-gated. Feels like the world being alive. Scales infinitely, zero authoring per triangle.
+  2. **Environmental change** — something physically different at the triangle location (locked door, moved cargo, light on at wrong hour). Archetype-agnostic: engineer reads the system fault, diplomat reads the guard rotation, merchant reads the sealed bay. Infinite scale, zero authoring per triangle.
+  3. **Ambient sound cue** — audible change in the triangle zone (hushed conversation, footsteps at unusual time, a door that was open now shut). Uses D-018 three-range system. Proximity-gated.
+  4. **Overheard NPC conversation** — secondary NPCs gossip about the activated NPC's changed behavior. Fires when two NPCs share a scene in a social site. Scales with the social simulation, not with authoring. Constraint: the NPC speaks from their own concerns ("He owes me for last week's haul and now he's not answering"), never from narrative convenience ("I think something is wrong with Kael").
+  5. **Unprompted NPC remark** — a non-job-giver NPC proactively comments when the player approaches. Uses D-028 Layer 4 unprompted disclosure with `situation: [triangle_activated]`.
+  6. **FRIEND message** — the FRIEND NPC (D-034) reaches out. Structurally unique: when the FRIEND IS the triangle anchor (smuggler/Kael), the message is simultaneously the nudge and the tell — its timing, phrasing, and whether it sounds normal are the investigative data. Reserve for the triangle the FRIEND is directly connected to; degrades on overuse (one FRIEND per character = hard limit).
+  7. **Internal monologue** — player character's inner voice notices something. Proximity-gated to triangle NPCs exhibiting tells. Character-specific voice (D-032, D-090).
+  8. **Job-giver app message** — institutional backstop of last resort. Fires only if no other channel has produced player engagement. One per session maximum, for the single highest-engagement triangle only. Job-giver per archetype: smuggler = handler ("Dock 7, pickup, ask for Kael"), detective = Commission superior ("Welfare check, dock-level, concern logged by port authority"), engineer = fault log, diplomat = peer request, merchant = market signal. Three sender types: named NPC (personal), institution (semi-personal), automated system (impersonal).
+- **Delivery model — parallel channels, not linear funnel:**
+  - All channels activate on TriangleActivated. The player encounters whichever their playstyle naturally intersects first.
+  - Channels have capacity, not triangles: monologue holds 1 thread (highest engagement wins), gossip holds 2-3, tells are unlimited. Lower-engagement triangles naturally get quieter channels — no starvation.
+  - App message has a long fuse; only delivers if no other channel has been "hit" (storyteller detects player engagement via any channel). Prevents the pattern from being predictable across playthroughs.
+  - Diegetic test for all channels: could you explain the output without reference to the activated triangle? If yes, diegetic. If no, quest marker.
+- **Scaling properties (v0.1 → full game):**
+  - Channel priority inverts at scale. v0.1: authored channels (monologue, job-giver) dominate. Full game: universal channels (environmental, overheard, tells) are the foundation because they scale with the simulation, not with authoring.
+  - Job-giver coherence breaks if overused — handler sending player to 3 activated locations in one session becomes transparent. Backstop for highest-engagement triangle only.
+  - Hint adaptation: storyteller tracks `PlayerHintEngagement` — how often the player engages after each channel tier. Extends fuses and reduces probabilities as player demonstrates skill. Hours 1-5: full hints. Hours 15+: player reads the world by behavioral tells alone. "Not harder combat — a quieter, more trusting world." Resets per new playthrough.
+  - ~15-20 hour meta-awareness cap: beyond that, the game likely needs a complementary active system (case board, network map) the player reads rather than passively receives. Separate design problem, out of scope here.
+- **Signal pollution gating:**
+  - Monologue: only when player is within proximity of a triangle NPC exhibiting tells.
+  - Gossip: only when the player initiates conversation with a connected secondary NPC. Passive, not pushed.
+  - FRIEND message: only if the FRIEND has a plausible in-world reason to reach out at this moment (established relationship cadence).
+  - Job-giver: once per session, backstop only.
+  - Environmental/tells: always active, no gating needed (they ARE the world).
+- **Implementation implications:**
+  - Storyteller needs a `ChannelSet` per activated triangle tracking which channels have fired and whether the player has engaged.
+  - Post-activation state machine: `Activated → [channels live] → Resolved (player engages) | Consequences (timeout) | Expired`.
+  - NPC behavioral state changes need to register as conversation topics for social-network propagation (simulation feature, not content feature).
+  - App message content uses D-028 tagged line pools with new `situation: [app_message]` tag and sender-type sub-tag. Rendered in neural insert UI as message thread, not monologue overlay.
+- **Content pipeline:**
+  - Universal channels (environmental, overheard, tells): zero per-triangle authoring. Build once as simulation features.
+  - Authored channels (monologue, FRIEND, job-giver): per-character/per-archetype investment. Layer on top as richness.
+  - Job-giver treated as authored feature shipping archetype by archetype, not universal system shipping once.
+- **Context:** Raised during Sprint 22 storyteller scoping (#162). Analysis by Gestalt (systems) and Paula (narrative) across two rounds.
+- **Cross-reference:** D-023 (storyteller activation), D-016 (monologue system), D-018 (three-range hearing), D-024 (NPC axes — tell system), D-028 (dialogue architecture), D-032 (separate monologue pools), D-034 (THE FRIEND), D-090 (character voice), #162 (storyteller module activation)
+- **Assigned to:** Gestalt, Paula
+
+### Q-053: Insert workspace boards — design philosophy and information architecture
+- **Status:** Open (Sprint 22 analysis complete)
+- **Priority:** High
+- **Question:** How do boards function as the player's primary active information surface, and what design principles govern their behaviour across archetypes, game phases, and concurrent use?
+- **Core design principle:** Boards are a **general-purpose communication layer** to the player, not a mechanic in themselves. The renderer is agnostic — it takes structured data and draws it. What creates a board, what populates it, and what its lifecycle is are decisions owned by the upstream system (quest, journal, navigation, business management, faction tracking, etc.), not the renderer.
+- **Design principles established:**
+  1. **Epistemology map, not truth map.** "The board maps the player's epistemology, not the game's truth." Nodes appear as the player encounters them. Connections are always the player's work. The board never reveals information the player hasn't acquired through gameplay.
+  2. **Passive nodes, active edges.** Things appear automatically when observed/learned; relationships between them are the player's inference. This makes the board a thinking tool, not a checklist.
+  3. **Multiple concurrent boards.** A character can be on an investigation while running a business while tracking a social network. Boards attach to whatever upstream system creates them — a quest, a business, a journal category, a transit network. The workspace presents them as tabs or equivalent navigation.
+  4. **Archetype-specific readings.** Same diagram data, different professional questions. Detective reads evidence chains, smuggler reads trust networks, engineer reads system diagrams, diplomat reads faction leverage, merchant reads supply lines. The rendering primitive is identical; the upstream system determines what nodes and edges mean.
+  5. **Cross-board convergence as discovery.** When the same node appears on multiple boards, that IS the discovery moment. Consistent visual identity (same icon, same colour) lets player recognition do the work — no automatic highlighting, no "this person appears on another board!" popup. The player connects the dots.
+  6. **Monologue as diagram interaction surface.** When the player focuses a board node, the monologue system can fire character-specific commentary. "He was at both meetings" is monologue, not board UI. This connects the active information system (Q-053) to the passive hint system (Q-052).
+- **Transit maps — core navigation mechanic:**
+  - Transit maps are boards whose upstream system is the navigation/transport layer, not the political geography layer. They respond to political geography (route closures, faction control) but their primary function is **how the player gets around**.
+  - Implementation: Network renderer with position-constrained layout mode (nodes pinned to world coordinates). Same rendering primitive as investigation boards (free layout mode), different layout constraint.
+  - Transit maps exist from day one as a live, simulation-fed surface — not a static reference image.
+- **Scaling properties:**
+  - v0.1: one or two board types (investigation + transit map) validate the rendering primitive and workspace navigation.
+  - Full game: boards proliferate naturally as upstream systems ship — business dashboards, faction maps, crew manifests, engineering schematics, social network visualisations, reference material (field guides, legal codes).
+  - Board count is not a design problem — it's a UX problem (workspace navigation, tab management, search/filter). The primitive scales inherently.
+- **Context:** Raised during Sprint 22 planning. Initial framing included d2 syntax as in-game format; lead directed that d2 remains a dev tool only and is not involved in the in-game system. Analysis by Gestalt (systems) and Paula (narrative) across three rounds with multiple lead corrections.
+- **Cross-reference:** Q-054 (rendering primitive data contract — the technical "how"), Q-052 (storyteller hint delivery — boards as the complementary active system), D-056/D-057 (insert diegetic conventions)
+- **Assigned to:** Gestalt, Paula
+
+### Q-054: Insert workspace board — rendering primitive and data contract
+- **Status:** Open
+- **Priority:** High
+- **Question:** What is the board rendering primitive and its data contract? A board is a **general-purpose structured information surface** rendered inside the insert workspace. The renderer is agnostic to data source — it takes structured data and draws it. Upstream systems (quests, journal, navigation, faction tracking, reference material, business management, or anything with structured data worth visualizing) are responsible for creating boards, populating them, and managing their lifecycle. The renderer does not know or care why a board exists. Open questions:
+  1. **Data contract:** What is the schema the renderer consumes? Minimum viable: typed nodes + typed edges + optional metadata (label, confidence, timestamp). What node and edge types must the v0.1 contract support?
+  2. **Rendering vocabulary:** What visual primitives does the renderer expose — node shapes, edge styles, grouping/clustering, highlight states? What is explicitly out of scope for v0.1?
+  3. **Lifecycle API:** What interface does an upstream system use to create, update, and close a board? Is this an ECS component, an IPC message, a client-side data structure, or some combination?
+  4. **Player agency:** Is the board a read-only surface (upstream system writes, player reads) or can the player annotate — add notes, draw edges, pin nodes? If player writes are allowed, who owns that state?
+  5. **Insert integration:** How does the board surface within the insert UI — as a spoke, a workspace tab, a contextual overlay? How does the player navigate between multiple open boards?
+  6. **v0.1 scope:** What is the minimum board implementation that validates the primitive — one upstream consumer, one node type, one edge type — without committing to a full vocabulary prematurely?
+- **Context:** Q-052 §scaling note flagged "a complementary active system (case board, network map) the player reads rather than passively receives" as out of scope for the hint delivery question. This is that system. Lead direction (Sprint 22): the rendering infrastructure is agnostic to data source; what attaches to a board, what populates it, and what its lifecycle is are decisions owned by the upstream system, not the renderer.
+- **Source:** Team Lead direction, Sprint 22 planning, 2026-02-28.
+- **Assigned to:** Gestalt, Paula
+- **Cross-reference:** Q-053 (board design philosophy — the "what" and "why"), Q-052 (storyteller hint delivery — boards noted as separate design problem), D-056/D-057 (insert diegetic conventions), D-023 (storyteller — one natural upstream consumer), D-024 (NPC axes — node content candidate)
+
 ---
 
-*51 questions (12 resolved, 2 partially resolved, 37 open). Last updated: 2026-02-27 (Q-051 added)*
+*54 questions (12 resolved, 2 partially resolved, 40 open). Last updated: 2026-02-28 (Q-053 filed — board design philosophy; Q-054 revised — rendering primitive data contract)*