jpmschweitzer/settled-reach
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

chore(meta): plan Sprint 25: Emerge

Browse Source 
Generator spike sprint. 5 tickets across copy and server teams:
- #609 zone identity spec (copy)
- #610 Krenn culture profile (copy)
- #611 NpcBlueprint struct design (server)
- #612 Template assembly generator (server)
- #613 NPC generation pipeline (server)

Sprint proof: throwaway render — rural Krenn village from minimal
input (zone type + culture profile, no per-location spec).

Closed #586 (tile data model epic — child #594 done).

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
jpmschweitzer
2026-03-06 19:59:24 +01:00
co-authored by Claude Sonnet 4.6
parent ea21884f3d
commit 7d7aec9cec
4 changed files with 237 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/backups/settledreach.db.backup
BIN
View File
Binary file not shown.
docs/sprints/sprint-25/copy.md
+60
View File
@@ -0,0 +1,60 @@
# Sprint 25: Emerge — Copy Tasks
**Goal:** Prove the generator can extrapolate from minimal input — a rural Krenn village from zone type and culture profile alone, no per-location spec.
**Branch:** `copy`
**Agents:** Miri (worldbuilding lead), Mellanie (voice/dialogue review)
## New Tickets
| # | Title | Blocked by |
|---|-------|------------|
| #609 | Zone identity spec | — |
| #610 | Krenn culture profile | — |
Use `tooling/db/ticket show <id>` for full details.
## Key Decisions
- `decisions/scope.md` — D-114 (generator-first proof-of-life), D-119 (generator spike critical path)
- `decisions/content.md` — D-121 (voice is culture-driven, job as modifier), D-122 (all NPCs generated), D-128 (culture implicit in starting location), D-129 (NPC personality: traits + behavior first)
- `decisions/architecture.md` — D-012 (chunk-based map, borderless generation future)
## Notes
**#609 — Zone identity spec**
- Output: a YAML or Markdown document defining zone type taxonomy for the Settled Reach's social vocabulary.
- What each zone TYPE means (not a specific location): urban residential, rural agricultural, industrial transit, informal/fringe, commercial, etc. What does each feel like? Who lives or works there? What emotional register does it carry? What is the density, pace, noise level?
- This is a general taxonomy — NOT a spec for a specific village. The generator needs the zone types as input parameters so it can extrapolate any location.
- Downstream consumers: Tyre (generator zone template parameters for #611/#612), Araminta (zone visual grammar), Mellanie (culture-primary voice cards).
- File location: `content/global/zone-identity-spec.md` (or YAML if preferred — coordinate with Tyre on what format #611 needs to ingest).
- Krenn System context: check `decisions/content.md` D-036 amendment and D-128. Station Sova's districts (D-093) are an example of zone types in action but the spec must generalize beyond Sova.
**#610 — Krenn culture profile**
- Output: one full culture profile for Krenn System / Station Sova, usable as generator input constraints and AI content templating prompt seeds.
- Must encode: naming conventions and phonemes, speech patterns and registers (formal/informal), economic values and class markers, attitudes toward work/leisure/authority, sensory palette (what Krenn space looks/smells/sounds like), social norms and taboos, dress and appearance codes.
- D-128: culture is implicit in starting location. This profile IS the cultural context for every generated NPC in the Krenn System — not just flavor text.
- D-121: voice is culture-driven, job modifies. The culture profile must be specific enough that Tyre can use it to constrain generated NPC voice parameters.
- D-123: this profile feeds the AI content templating pipeline. Culture vectors = prompt constraints. The profile must be concrete enough to function as a constraint, not just atmospheric description.
- File location: `content/global/culture-krenn.md` (or YAML — coordinate with Tyre).
- Existing Sova atmosphere notes live in `decisions/content.md` D-036 (amended post-workshop). Pull from those but go deeper on cultural mechanics.
## Dependency Chain
```
#609 (zone identity spec) ──┐
├──> server #611 (NpcBlueprint struct)
#610 (Krenn culture profile)┘ └──> #612 (template gen) ──> #613 (NPC pipeline)
```
Copy deliverables (#609, #610) are prerequisites for all server work in this sprint. Both can be written in parallel — they are independent of each other.
## PR Workflow
When ready to submit, create a PR with `tea` CLI. All flags are required to avoid TTY prompts (see CLAUDE.md "Gitea access" section):
```bash
tea pr create --repo jpmschweitzer/settled-reach --login schweitz --title "feat(copy): zone identity spec and Krenn culture profile" --description "body" --base main --head copy
```
docs/sprints/sprint-25/joint.md
+100
View File
@@ -0,0 +1,100 @@
# Sprint 25: Emerge — Joint
**Goal:** Prove the generator can extrapolate from minimal input — a rural Krenn village from zone type and culture profile alone, no per-location spec.
## Pre-Sprint
| Item | Owner | Blocks |
|------|-------|--------|
| Coordinate output format for zone identity spec (#609) | Miri + Tyre | #611 |
| Coordinate output format for culture profile (#610) | Miri + Tyre | #611, #612 |
| Confirm `NpcBlueprint` file location and module wiring | Tyre | #612, #613 |
The critical coordination question: does copy deliver YAML files (which the generator reads at runtime) or Markdown design documents (which Tyre reads and encodes into Rust)? Either works — decide at sprint start. YAML is preferred if Tyre can define a schema upfront; Markdown if the profile needs to be free-form first and codified later.
## Sprint Completion Proof — Throwaway Render
**This is not a test suite. It is an eyeball test.**
The proof is a single standalone invocation that feeds the generator minimal parameters and inspects the output for shape and coherence.
**Input (the minimum the generator must accept):**
```
zone_type: "rural"
region: "outside Sova urban zone"
system: "Krenn"
seed: 42
```
Plus the Krenn culture profile (#610) and zone identity taxonomy (#609) — loaded from disk, not hardcoded.
**NO location-specific spec.** No "the village has a tavern." No bespoke social site list. The generator extrapolates entirely from zone type + culture.
**Command (to be written as part of #612):**
```bash
cargo run --bin generator-spike -- --zone rural --seed 42
```
**Expected output (printed to stdout):**
1. `DistrictSkeleton` summary: zone type, block count, social site placements
2. Generated NPC list: one line per NPC with name, role, 2-3 traits, one observable behavior
3. A sample relationship pair (NPC A knows NPC B as X)
**The pass condition (human judgment, not automated):**
- Does the output have *shape*? A rural area should feel different from an industrial one.
- Does it feel like it *belongs in the Krenn System*? Not generic space-village. Krenn-inflected.
- Can you read the NPC relationships from the output? Not infer — *read*.
**The fail condition:**
- Output could be from any game in any setting (culture profile not doing work)
- All rural areas produce identical outputs with different names (zone type not doing work)
- NPC traits are unreadable from text (legibility fails — D-129 gate not met)
**Why this framing matters (from the approval discussion):**
The sprint proof deliberately uses minimal input because the generator's entire value proposition is scaling beyond hand-authored content. If it only works with detailed per-location specs, it fails the brief — because the whole point is the player walking into an unspecified area and it still having shape. The "throwaway render" framing is intentional: this is a rough proof, not a polished demo. Pass/fail is a 5-minute eyeball by the team lead.
## Tickets by Team
| Team | # | Title |
|------|---|-------|
| copy | #609 | Zone identity spec |
| copy | #610 | Krenn culture profile |
| server | #611 | NpcBlueprint struct design |
| server | #612 | Template assembly generator |
| server | #613 | NPC generation pipeline |
## Dependency Chain
```
copy #609 (zone spec) ──┐
├──> server #611 (NpcBlueprint) ──> #612 (template gen) ──> #613 (NPC pipeline)
copy #610 (culture) ───┘
```
Copy (#609, #610) runs in parallel and completes first. Server (#611 → #612 → #613) runs sequentially after copy delivers.
## Open Questions
| ID | Question | Blocking |
|----|----------|---------|
| Q-WTF-033 | AI templating: Claude API, local ollama, or manual for v0.2? | #613, #623 |
| Q-WTF-039 | Character creation screen: portrait render or tile-scale preview? | Sprint 26+ |
| Q-WTF-040 | Do creation choices trace into the generated apartment? | Sprint 26+ |
Q-WTF-033 is the most relevant to this sprint. #613 does not need to implement AI templating — that is #623 (deferred). But the pipeline should be designed so AI templating slots in later without a rewrite. Discuss at sprint start.
## Deferred to Future Sprints
- Tycoon bookmark (#605, #614-617) — needs generator output proven first
- Character creation screen (#606, #618-620) — client work, post-generator
- NPC legibility systems (#607, #621-622) — downstream of generator
- AI content templating (#623) — Q-WTF-033 unresolved
- World feel systems (#608, #624-626) — downstream of everything
- Visual rendering of generated world — out of scope for this spike
## What This Sprint Does NOT Do
- No client work (no rendering of generated content)
- No new content authored beyond the zone spec and culture profile
- No AI templating implementation (design for it, don't build it)
- No playable session from the generated world
docs/sprints/sprint-25/server.md
+77
View File
@@ -0,0 +1,77 @@
# Sprint 25: Emerge — Server Tasks
**Goal:** Prove the generator can extrapolate from minimal input — a rural Krenn village from zone type and culture profile alone, no per-location spec.
**Branch:** `server`
**Agents:** Dudley (simulation dev), Tyre (architect)
## New Tickets
| # | Title | Blocked by |
|---|-------|------------|
| #611 | NpcBlueprint struct design | #609 (copy), #610 (copy) |
| #612 | Template assembly generator | #609, #610, #611 |
| #613 | NPC generation pipeline | #611, #612 |
Use `tooling/db/ticket show <id>` for full details.
## Key Decisions
- `decisions/scope.md` — D-114 (generator-first proof-of-life), D-119 (generator spike critical path), D-115 (skills + bookmark only for creation)
- `decisions/content.md` — D-122 (all NPCs generated), D-128 (culture implicit in location), D-129 (NPC personality: traits + behavior first), D-121 (voice culture-driven), D-123 (AI content templating via culture vectors)
- `decisions/architecture.md` — D-012 (chunk-based map, borderless generation future)
## What Exists
- **`server/src/simulation/generator.rs`** (576 lines) — `DistrictSkeleton` data model, `DistrictType`, `ZoningType`, `SocialSitePlacement`, `TriangleAssignment`, `BlockSkeleton`. This is the Phase 1 *data model* — struct definitions for what a generated district looks like. The *generator logic* that produces these structs from input parameters does not yet exist.
- **`server/src/npc/generate.rs`** — existing NPC generator taking a `RoleDefinition` (the 10-axis model: Want, Secret, Relationships, Tolerance, DailyRoutine, InformationInventory, Contentment, PersonalityTraits, TellSystem, SkillSet). Generates a fully-populated NPC entity via `SimRng` (deterministic, seeded). Sprint 25 work extends this pipeline, it does not replace it.
- **`server/src/npc/`** — full NPC component set: `awareness.rs`, `background.rs`, `disclosure.rs`, `generate.rs`, `interaction.rs`, `mod.rs`, `mood.rs`, `relationships.rs`, `routine.rs`, `tell_state.rs`, `tolerance.rs`, `trait_modifiers.rs`, `vision.rs`.
- **`server/src/content/`** — content loading: `entanglement.rs`, `hot_reload.rs`, `instantiation.rs`, `line_pool.rs`, `loader.rs`, `spawn.rs`, `template.rs`, `types.rs`.
## Notes
**#611 — NpcBlueprint struct design**
- Blocked by #609 and #610 (copy team delivers these first). Read those documents before writing the struct.
- This struct is the *interface* between the generator and all downstream systems: rendering, voice, AI templating, simulation.
- Must encode: trait set (from D-129), observable behavior surface (what a bystander can read), relationships (Sims + Rimworld style per D-129), role/occupation, cultural markers (feeds D-121 voice pipeline and D-123 AI templating), zone-type affiliation.
- The existing `RoleDefinition` in `npc/generate.rs` covers the 10-axis model. `NpcBlueprint` is a higher-level generator output that wraps role + cultural context + zone parameters. Think of `RoleDefinition` as "what the generator uses internally" and `NpcBlueprint` as "what the generator exports."
- Write the struct in `server/src/npc/blueprint.rs` (new file). Add a D-record reference in `decisions/architecture.md` or `decisions/content.md` when the struct is settled.
- Must be serializable (Serde) for inspection output (the sprint proof dumps the blueprint JSON to stdout).
**#612 — Template assembly generator**
- Blocked by #609, #610, #611.
- Input: zone type parameter (from zone identity spec), culture profile (from Krenn culture profile), seed (u64). No per-location spec. The whole point is extrapolating from minimal input.
- Output: a `DistrictSkeleton` (already defined in `server/src/simulation/generator.rs`) with `SocialSitePlacement` entries populated and `NpcBlueprint`s attached to each role slot.
- NOT procedural geography — template assembly. The generator picks a zone template from the zone identity taxonomy and fills it. The template provides the shape; the culture profile and seed provide the variety.
- Write generator logic in `server/src/simulation/generator.rs` (add below existing structs) or extract to `server/src/simulation/template_assembly.rs` — architect's call.
- The generator must be callable standalone (not as a bevy system) for the sprint proof (see joint.md).
- Determinism: use `SimRng` (ChaCha20, existing in `server/src/simulation/rng.rs`). Same seed + same zone type + same culture profile → same output.
**#613 — NPC generation pipeline**
- Blocked by #611 and #612.
- Wire the template generator output into actual NPC entity spawning.
- Input: `DistrictSkeleton` with `NpcBlueprint`s → spawn ECS entities using the existing `npc/generate.rs` pipeline, extended to accept cultural markers from the blueprint.
- The existing `RoleDefinition` in `npc/generate.rs` needs a cultural marker field (or the blueprint drives trait selection to match the culture profile).
- Proof-of-life test (in the sprint proof): print generated NPC trait sets and observable behaviors to stdout. A human reading the output should be able to say "yes, this NPC could plausibly exist in the Krenn System."
- D-129: traits + behavior first. The proof gate is not rendering — it is legibility from text output alone.
## Dependency Chain
```
copy #609 (zone spec) ──┐
├──> #611 (NpcBlueprint) ──> #612 (template gen) ──> #613 (NPC pipeline)
copy #610 (culture) ───┘
```
Server work begins when copy delivers #609 and #610. #611 must be complete before #612 starts. #613 follows #612.
## PR Workflow
When ready to submit, create a PR with `tea` CLI. All flags are required to avoid TTY prompts (see CLAUDE.md "Gitea access" section):
```bash
tea pr create --repo jpmschweitzer/settled-reach --login schweitz --title "feat(simulation): generator spike — NpcBlueprint, template assembly, NPC pipeline" --description "body" --base main --head server
```