docs(sprints): regenerate sprint 3 briefings from database
Previous briefings referenced tickets not assigned to sprint 3. Rewrote all four team briefings (server, client, joint, copy) to match actual sprint 3 ticket assignments in the database. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
@@ -1,56 +1,65 @@
|
||||
# Sprint 3: Know — Server Tasks
|
||||
# Sprint 3: Content Foundation — Server Tasks
|
||||
|
||||
**Goal:** Player character can observe NPCs, track their knowledge, and interact with the environment through a working observation event pipeline.
|
||||
**Goal:** Build the content infrastructure for v0.1 — directory structure, schema validation, and interaction mechanics.
|
||||
|
||||
**Branch:** `server`
|
||||
**Agents:** Dudley (simulation), Tyre (architecture), Hoshe (QA)
|
||||
|
||||
## Tickets
|
||||
|
||||
| # | Title | Blocked by |
|
||||
|---|-------|------------|
|
||||
| #86 | Core NPC components | — |
|
||||
| #87 | Relationship system | — |
|
||||
| #88 | Daily routine system | #25 (done) |
|
||||
| #237 | Tile-based A* pathfinding | #236 (done) |
|
||||
| #238 | NPC path following and movement | #237 |
|
||||
| #239 | Observation event generator | — |
|
||||
| # | Title | Priority | Blocked by |
|
||||
|---|-------|----------|------------|
|
||||
| #385 | Create content/ directory skeleton | high | #384 |
|
||||
| #386 | Content schema definitions (YAML Schema files) | high | #384 |
|
||||
| #392 | Implement make validate-content CLI | high | #386 |
|
||||
| #404 | Proximity detection + multi-verb InteractionOptions (verbs[]) | high | — |
|
||||
| #406 | Pause system — server tick rate scaling | medium | — |
|
||||
|
||||
Use `db/connectors/ticket show <id>` for full details.
|
||||
|
||||
## Key Decisions
|
||||
|
||||
- `decisions/content.md` — D-024 (10-axis NPC model), D-034 (THE FRIEND pattern), D-035 (dialogue tag taxonomy)
|
||||
- `decisions/architecture.md` — D-041 (Knowledge Graph), D-026 (simulation tiers), D-030 (testability), D-031 (time system)
|
||||
- `decisions/perception.md` — D-011 (fog/perception), D-016 (internal monologue), D-017 (perception modes)
|
||||
- `decisions/architecture.md` — D-020 (IPC protocol), D-026 (simulation tiers), D-030 (testability)
|
||||
- `decisions/content.md` — D-024 (10-axis NPC model), D-035 (dialogue tag taxonomy)
|
||||
- Content scoping: v0.1 Content Scoping Workshop outputs (parent epic #369)
|
||||
|
||||
## Notes
|
||||
|
||||
**NPC foundation tickets (#86, #87, #88):**
|
||||
- **#86 (Core NPC components):** The `Npc` marker component and basic axes already exist in `server/src/npc/mod.rs` (Want, Secret, Relationships, ToleranceThreshold, DailyRoutine, InformationInventory, Contentment, plus supporting axes). This ticket extends those component definitions to match the full D-024 10-axis model with proper field types. DailyRoutine needs to become a structured schedule with time-based location transitions.
|
||||
- **#87 (Relationship system):** The `Relationships` component exists as a stub. Implement the RelationshipGraph resource (per D-024) for NPC-to-NPC connections with trust/history metadata. Keep per-NPC relationship slots (3 key relationships) for Active-tier NPCs. This is separate from the KnowledgeGraph (what entities *know*) — this is what entities *feel*.
|
||||
- **#88 (Daily routine system):** Build on SimulationTime (done in #25, `server/src/simulation/time.rs`). DailyRoutine component stores location schedule with day-phase transitions (Morning/Afternoon/Evening/Night per D-031). NPCs transition between locations at phase boundaries. Foundation for routine deviation detection (#243, Sprint 4+).
|
||||
**Content infrastructure (#385, #386, #392):**
|
||||
|
||||
**Pathfinding tickets (#237, #238):**
|
||||
- **#237 (Pathfinding):** A* pathfinding over the WalkabilityMap (done in #236, `server/src/simulation/movement.rs`). Use the `pathfinding` crate. NPCs request paths between positions; system returns tile sequences. Output: `PathRequest` event + `ComputedPath` component. This blocks routine execution — NPCs can't move between routine locations without pathfinding.
|
||||
- **#238 (Path following):** Per-tick NPC position updates along computed paths. Separate from pathfinding computation. Smooth interpolation between tiles (fractional TilePosition or separate VisualPosition component). Movement speed parameter. This is the execution system that makes NPCs actually walk.
|
||||
These three tickets form a pipeline: directory structure → schema definitions → validation tooling.
|
||||
|
||||
**Observation pipeline (#239):**
|
||||
- **#239 (Observation event generator):** The mechanical heart of the game per Gestalt. Compares ObserverSnapshot against character KnowledgeGraph to generate ObservationEvents. Trigger types: routine deviation, absence detection, social anomaly, new information, contradiction. Character-specific — same NPC behavior generates different events for smuggler vs detective. Foundation for monologue generation (#119, Sprint 4+).
|
||||
- Existing foundation: `server/src/perception/observation.rs` already emits DirectObservation and LeftLOS events. This ticket adds the *interpretation* layer — detecting *meaningful* observations like routine deviations, not just visibility changes.
|
||||
- Integration points: Reads KnowledgeGraph (Sprint 2, done), reads DailyRoutine (this sprint, #88), emits to a new ObservationEventQueue resource.
|
||||
- **#385 (Directory skeleton):** Create the converged `content/` directory structure from workshop outputs. Canonical layout: `_meta/`, `_schema/` (infrastructure, underscore prefix), `global/` (factions, technology, contraband, knowledge, enums, regions), `districts/sova-transit/` (district.yaml, npcs/, locations/, templates/, triangles/, lines/). Empty YAML stubs for all major files. This establishes the physical structure that all content authoring depends on. **Blocked by #384** (design doc, copy team).
|
||||
- **#386 (Schema files):** Write YAML Schema validation files in `_schema/`: npc.schema.yaml (with tier-conditional rules — Tier 1 vs Tier 2 NPC requirements differ), location.schema.yaml, faction.schema.yaml, template.schema.yaml, fact.schema.yaml, dialogue.schema.yaml, monologue.schema.yaml, district.schema.yaml, pool.schema.yaml. These define the contract for all content files. **Blocked by #384** (design doc).
|
||||
- **#392 (Validation CLI):** Implement `make validate-content` CLI tool. Reads `_schema/` definitions, validates all YAML in `content/`. v0.1 scope: structural validation (required fields, type checks, enum matching) + tier-conditional rules (Tier 1 NPCs need 50-70 lines, Tier 2 need 10-axis profiles). v0.2 scope (future): cross-reference validation (FactId existence checks, NPC slug resolution). This is the same crate as C3 schemas. **Blocked by #386** (schemas must exist first).
|
||||
|
||||
These tickets lay the foundation for all content work. Without them, content authors write into the void with no validation feedback.
|
||||
|
||||
**Interaction mechanics (#404):**
|
||||
|
||||
- **#404 (Proximity + InteractionOptions):** Two deliverables: (1) proximity detection system (determines when player is close enough to interact with an entity), (2) server-side `InteractionOptions` component modeling N available actions per entity via `verbs[]` array. Without proximity, `InteractionOptions` has no trigger. v0.1 client behavior: pick first/best verb automatically. v0.2 client behavior: show context menu with all available verbs. **Architecture requirement:** This must not be throwaway work — the system must support the v0.2 multi-verb menu natively from day one. Includes ObserverSnapshot v2 → v3 protocol extension to send interaction data to client. See ticket #402 (copy team) for verb taxonomy (Move, Look, Monologue, Examine Object, Examine NPC, Talk, Overhear). **Blocks #405** (client interaction prompt, client team).
|
||||
- **Files:** `server/src/simulation/interaction.rs` (new module), `server/src/bridge/types.rs` (ObserverSnapshot v3 extension)
|
||||
- **Integration:** Works with existing proximity/spatial queries. The observation system already tracks entity visibility — this extends it to track interaction range (closer threshold than LOS).
|
||||
|
||||
**Pause system (#406):**
|
||||
|
||||
- **#406 (Tick rate scaling):** Three tick rate states: (1) full speed (normal gameplay), (2) 50% speed (UI overlay open — knowledge panel, dialogue tree — player is reading), (3) 0% (spacebar pause). Server receives pause/speed commands from client via IPC. Medium priority — nice-to-have for v0.1 but not critical path. Improves player experience when reading dialogue or checking knowledge graph.
|
||||
- **Files:** `server/src/simulation/time.rs` (extend existing SimulationTime with speed scaling)
|
||||
|
||||
## Dependency Chain
|
||||
|
||||
```
|
||||
#86 (NPC components) → #239 (needs NPC profiles to compare against)
|
||||
#87 (relationships) → standalone, feeds NPC generation pipeline (#92, Sprint 4+)
|
||||
#88 (routines) → #239 (routine deviation requires routine data)
|
||||
#237 (pathfinding) → #238 (path following) → #101 (routine execution, Sprint 4+)
|
||||
#239 (observation) → #119 (monologue generation, Sprint 4+)
|
||||
#384 (design doc, copy) → #385 (directory skeleton) → content authoring
|
||||
→ #386 (schemas) → #392 (validation CLI) → content authoring
|
||||
|
||||
#404 (proximity + verbs[]) → #405 (interaction prompt, client)
|
||||
|
||||
#406 (pause) → standalone
|
||||
```
|
||||
|
||||
#86, #87, #237 can start immediately. #88 and #239 depend on completions but not each other.
|
||||
**Critical path:** #384 → #385 → #386 → #392. All content work is blocked until these complete.
|
||||
|
||||
**Parallel work:** #404 and #406 are independent and can start immediately.
|
||||
|
||||
## PR Workflow
|
||||
|
||||
|
||||
Reference in New Issue
Block a user