Files
settled-reach/docs/workshops/v01-content-scoping/v01-content-scoping-workshop-brief.md
T
jpmschweitzerandClaude Opus 4.6 b672b9c269 feat(docs): restructure wiki taxonomy with templates and Krenn System entry (#301, #319)
Move wiki from docs/wiki/ to root wiki/. Add 14 category templates with
YAML frontmatter, governance model, hierarchical spatial structure
(system > station > district > location). Populate Krenn System entry
as first concrete star system. Update cross-references in workshop and
sprint docs.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-02-13 00:58:45 +01:00

12 KiB

Workshop Brief: v0.1 Content Scoping

What Actually Ships in the Vertical Slice?

Project: The Settled Reach (D-021) Date: 2026-02-12 Called by: Jeroen Prerequisite: Wiki Review workshop established long-term content strategy (300-world generator model, cultural ingredients menu, three-system NPC architecture, Sacred/Profane/Middle Kingdom). This workshop applies that strategy to v0.1. Participants: GESTALT, PAULA, TYRE, MELLANIE, STIG, DUDLEY + SI (tickets) + QATUX (documenter)


Context

The Wiki Review workshop (4 rounds + lead interview) produced a comprehensive long-term content strategy documented in docs/workshops/wiki-review/SUMMARY.md. The key outcome: the full game targets 300 worlds populated by generators fed by style briefs. But v0.1 is NOT a generator test. v0.1 is proof of the interaction model — 1 district, hand-authored, proving that the player can touch the world and the world can touch back.

The existing wiki (wiki/, 45 files, ticket #368) contains the content for Sova Transit District: 17 NPCs across 3 tiers, 5 triangles, 3 social sites, knowledge vocabulary (FactIds, entity attributes, relationship states), and an authoring guide. This content has known gaps and issues identified in Rounds 1-2 of the Wiki Review.

This workshop scopes and prioritizes the content work needed to ship v0.1.

Key constraint: v0.1 must be architecturally compatible with the 300-world future. Hand-authored Sova content becomes the benchmark output that generators must match. Every structure we create now is a generator template later. Don't build anything that only works for 1 district.

Design constraints from existing decisions:

  • D-005: Single-character perspective
  • D-020: Godot 4 client + Rust/bevy_ecs server
  • D-027: Smuggler + detective vertical slice, two-character proof
  • D-034: THE FRIEND production-level NPC pattern (Kael, Sera)
  • D-035: Monologue system with tagged prerequisites
  • D-036: Krenn System / Sova Transit District setting
  • D-037: Contraband types
  • D-039: 6 wow moments in a 30-minute session
  • D-041: Knowledge graph architecture
  • Wiki Review: WASD direct control, context-sensitive interaction

Required Reading

Before responding, read:

  1. docs/workshops/wiki-review/SUMMARY.md — the long-term content strategy (essential context)
  2. docs/workshops/wiki-review/lead-interview.md — lead's decisions on cultural ingredients, NPC composition, archetypes, randomization, scale
  3. wiki/index.md — current wiki structure
  4. wiki/npcs/index.md — NPC roster and triangles
  5. decisions/content.md — D-028, D-034, D-035, D-036, D-037
  6. decisions/scope.md — D-027, D-039

Topic 1: Wiki Fixes — Known Issues from Rounds 1-2

What needs fixing in the existing wiki before it can drive implementation?

The Wiki Review identified these specific issues:

1a. Hael → Naia Tamm rename

Unanimous decision. Resolves Kael/Hael sonic collision (T-03). Hael becomes Naia Tamm, following Krenn naming conventions. This NPC is also the first instance of THE MIRROR pattern — honest, no contradiction arc, no secret.

  • Paula: Execute the rename across all wiki files. Update relationship references, triangle diagrams, cross-references.
  • Mellanie: Review Naia Tamm's voice — does she need voice samples now that she's a MIRROR (Tier 1 emotional depth)?

1b. Smuggler lens parity

The wiki is detective-shaped. The smuggler perspective needs equal depth:

  • Smuggler-specific NPC attributes: trust_read, exposure_risk, loyalty_assessment, leverage_held, social_debt, moral_weight, cover_integrity, loyalty_conflict

  • Moral arc phases for smuggler: Comfort → Doubt → Reckoning → Compromise

  • Every NPC profile needs a smuggler-lens section with the same depth as the detective-lens section

  • Paula: Propose the smuggler attribute vocabulary and add smuggler-lens sections to all NPC profiles.

  • Gestalt: How do smuggler attributes map to EntityKnowledge keys in the knowledge graph?

1c. Triangle 1 (Hub Power) strengthening

Weakest triangle. Smuggler role is passive. Needs a concrete fork — the Nils-vs-Voss escalation decision.

  • Nils needs a stub wiki page at minimum

  • The player needs a decision point, not just observation

  • Gestalt: Design the Triangle 1 fork. What does the smuggler decide? What does the detective observe?

  • Paula: Write the Nils stub page. Define Triangle 1's escalation sequence.

1d. Drin tier promotion

Drin is doing Tier 2 work (Triangle 2, Triangle 5, compromised by Harek) in a Tier 3 profile.

  • Gestalt: Should Drin be promoted to Tier 2? What are the mechanical implications?
  • Paula: If promoted, expand the profile to full Tier 2 depth.

1e. Full canonical names

Miri generated 12 Krenn-style names in Round 1. Apply them to NPCs currently using single names.

  • Paula: Apply Miri's names where appropriate. Check naming consistency.

Questions:

  1. Paula: Are there other wiki gaps not listed above? What did you discover during Round 1-2 review that still needs fixing?
  2. Gestalt: Do any triangles need restructuring beyond Triangle 1?
  3. Mellanie: Are the voice samples in Tier 1 profiles (Kael, Sera) distinct enough for monologue authoring?

Topic 2: v0.1 NPC Architecture

Which subset of the three-system NPC model ships in v0.1?

The long-term strategy defines three NPC systems:

  • System A: 9 thematic patterns (FRIEND, MIRROR, ANCHOR, GHOST, CATALYST, THRESHOLD, REMNANT, SYSTEM, NOBODY)
  • System B: 6 functional motivations (HANDLER, WITNESS, TURNCOAT, CIVILIAN, OPERATOR, SKEPTIC)
  • System C: Composition rules (pattern x motivation per NPC)

v0.1 has 17 NPCs across 3 tiers. Not all patterns and motivations need to be present.

Questions:

  1. Gestalt: Which patterns and motivations are REQUIRED for v0.1? Which can be deferred? Map the existing 17 NPCs to pattern + motivation assignments.
  2. Paula: Do the existing NPC profiles already implicitly match patterns/motivations? Make the mapping explicit.
  3. Gestalt: Does THE NOBODY ship in v0.1, or is dynamic tier promotion a v0.2 feature? If v0.1, which NPCs are NOBODYs?
  4. Dudley: What server-side entity data does each pattern/motivation require? What's the ECS component design?

Topic 3: v0.1 Content Directory Structure

How does wiki content become engine-readable data?

The wiki (wiki/) is the authoring source. The engine needs content in a structured format the server can load. The directory structure must:

  • Support the v0.1 content (1 district, hand-authored)
  • Be architecturally compatible with the 300-world generator output (same schema, same addressing)
  • Allow hot-reloading during development
  • Support content validation

Questions:

  1. Tyre: Propose the content/ directory structure for v0.1. What format — YAML? RON? How does it mirror the wiki structure?
  2. Tyre: How does content addressing work? canonical_id per entity? How do wiki pages map to content files?
  3. Dudley: What does the server content loader need? What's the load sequence? How does an NPC profile become a spawned entity?
  4. Gestalt: What's per-district vs. global? Where does the FactId catalog live? Where do NPC profiles live? Where do triangle definitions live?
  5. Stig: What does the client need from content files? NPC display names? Dialogue text? Location descriptions? What format makes client loading simple?

Topic 4: Interaction Model Basics for v0.1

What's the minimum viable interaction for the vertical slice?

The Control & Interaction workshop will design the full system. But v0.1 needs SOMETHING — the player must be able to:

  • Walk up to an NPC and initiate dialogue
  • Receive monologue observations
  • Examine objects/environment
  • Overhear conversations (proximity-based)

This topic scopes the v0.1 minimum, not the full design.

Questions:

  1. Gestalt: What's the minimum interaction set that proves the core loop? Walk + talk + observe + monologue? Or does v0.1 need more?
  2. Stig: What UI elements does the minimum interaction model need? Interaction prompt? Dialogue box? Monologue display? Knowledge panel?
  3. Dudley: What server events support the minimum interaction? Proximity triggers? Interaction requests? Dialogue state?
  4. Mellanie: How much monologue content does v0.1 need? What's the minimum pool size before it feels repetitive?

Topic 5: v0.1 Scope Boundary

What's IN v0.1 and what's explicitly OUT?

v0.1 proves the interaction model. It does NOT prove generators, randomization, or cultural variety. Be ruthless about scope.

Candidates for IN:

  • WASD movement + collision
  • Context-sensitive interaction (approach NPC → prompt → dialogue)
  • Monologue system (tagged triggers, FactId prerequisites)
  • Knowledge graph (player learns facts, relationships change)
  • 2 playable characters (smuggler, detective) seeing same world differently
  • THE FRIEND arc (Kael for smuggler, Sera for detective)
  • 5 triangles with at least 1 fork each
  • 6 wow moments (D-039)
  • 3 social sites (Terminal, Last Shift, Maintenance Corridors)
  • NPC routines (schedule-based movement)

Candidates for OUT (v0.2+):

  • THE NOBODY / dynamic tier promotion
  • Archetype transitions
  • Multiple FRIEND candidates per character
  • Secondary contraband variation
  • Gate network / multi-world
  • Content generation / randomization
  • Modding support

Questions:

  1. Gestalt: Is this IN/OUT split correct? Anything missing from IN that's essential for the 30-minute session? Anything in IN that's scope creep?
  2. Tyre: What's the technical risk in the IN list? What might take longer than expected?
  3. Dudley: What server features are blocked by content that doesn't exist yet?
  4. SI: Map the IN list to tickets. What already has tickets? What needs new ones?

Topic 6: Ticket Generation

What implementation tickets come out of this workshop?

SI had a preliminary list of 28 tickets from Wiki Review Round 2, but the 300-world reframe makes some obsolete and creates new ones.

Expected ticket categories:

  • Wiki fixes (rename, smuggler lens, triangle strengthening, Drin promotion, canonical names)
  • Content file creation (wiki → YAML/RON conversion for engine)
  • Content directory structure setup
  • Content loader implementation (server-side)
  • Content validation schema
  • Minimum interaction model (client UI elements)
  • Monologue content pool (minimum viable)
  • PC-as-NPC content (the other character exists as an NPC)

Questions:

  1. SI: Review the Round 2 ticket list (docs/workshops/wiki-review/si-ticket-changes.md). Which survive? Which are obsolete? What's new?
  2. SI: Which tickets belong to Sprint 3 (Know) vs. later sprints? What's the dependency chain?
  3. Tyre: What tickets should be split between server/client/copy teams?

Workshop Format

1-2 rounds.

Round 1: Topic responses. Each participant addresses their assigned questions with concrete proposals. Wiki fixes should include actual content (not just "we should fix this"). Directory structures should be actual file trees. Ticket proposals should have title, description, and team assignment.

Round 2: Integration + ticket finalization. Resolve disagreements, finalize the IN/OUT boundary, produce the ticket list. SI creates tickets. Qatux documents decisions.

Expected Outputs

  • Wiki fix list with assignments and content ready to apply
  • NPC pattern/motivation mapping for all 17 v0.1 NPCs
  • Content directory structure with schema proposal
  • v0.1 interaction model minimum — enough for Stig/Dudley to implement
  • Scope boundary document — clear IN/OUT with rationale
  • Ticket list — implementation tickets with team assignments and sprint targets
  • Decision amendments — updates to existing decisions based on scoping