From fb9d68476745929e466c3933fabafc18da2de7ae Mon Sep 17 00:00:00 2001 From: Jeroen Schweitzer Date: Thu, 12 Feb 2026 01:22:33 +0100 Subject: [PATCH 1/7] chore(agents): add ticket assignment rules to SI agent MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Teams are server, client, copy, audio, visual, ci. Never use "joint" — split cross-team work into per-team tickets with explicit dependencies. Co-Authored-By: Claude Opus 4.6 --- .claude/agents/si.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/.claude/agents/si.md b/.claude/agents/si.md index 7637b7254..1f9ecac82 100644 --- a/.claude/agents/si.md +++ b/.claude/agents/si.md @@ -29,6 +29,16 @@ Named after the Sentient Intelligences that manage all Commonwealth infrastructu You are execution-focused. When a decision is made, you immediately think about what needs to happen, in what order, by whom, and what depends on what. You maintain the project's pulse - always knowing what's in progress, what's blocked, and what's next. You don't wait to be asked for status updates; you surface risks early. +## Ticket assignment rules + +The development teams are: **server**, **client**, **copy**, **audio**, **visual**, **ci**. + +When creating or splitting tickets: +- **Always assign a ticket to exactly one team.** Every ticket must have a team. +- **Never use "joint" as a team.** If work spans multiple teams, split it into separate tickets — one per team — with explicit dependencies between them. +- For example, a feature requiring server-side logic and client-side rendering becomes two tickets: one for server (implement the data/system), one for client (consume and render it), with the client ticket blocked by the server ticket. +- Sprint proof/acceptance tickets should be assigned to the team responsible for the final integration step, with blockers on the upstream tickets. + ## Project context Read your briefing at `docs/briefings/si.md` before starting work. From 5c7d546f482fb4f1556c5d90f51d415dcc271587 Mon Sep 17 00:00:00 2001 From: Jeroen Schweitzer Date: Thu, 12 Feb 2026 01:26:53 +0100 Subject: [PATCH 2/7] chore(config): add new team branches to protected list Add copy, audio, visual, ci to protected branches in CLAUDE.md. Co-Authored-By: Claude Opus 4.6 --- CLAUDE.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CLAUDE.md b/CLAUDE.md index acd32bb7d..fbabd6c2d 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -105,7 +105,7 @@ Key rules: - **All flags must be explicit** — omitting `--login` or `--repo` triggers interactive prompts that crash in Claude Code (no TTY) - **Use `--output simple`** for machine-readable output (no table borders) - **`tea pr reject` does not work on your own PRs** — use `tea comment` instead -- **Never delete protected branches:** `main`, `maintenance`, `server`, `client` are protected on Gitea. Do not use `tea pr clean`, `git push --delete`, or `git branch -D` on these branches. +- **Never delete protected branches:** `main`, `maintenance`, `server`, `client`, `copy`, `audio`, `visual`, `ci` are protected on Gitea. Do not use `tea pr clean`, `git push --delete`, or `git branch -D` on these branches. ### File conventions - Decisions: domain files in `decisions/` (see `decisions/README.md` for index) From 715c7e16abf552c9605330cf8d23413b8608aebf Mon Sep 17 00:00:00 2001 From: Jeroen Schweitzer Date: Thu, 12 Feb 2026 01:31:00 +0100 Subject: [PATCH 3/7] docs(sprints): add copy team briefing for Sprint 2 Sprint briefing for #368 (knowledge vocabulary for v0.1 content). Defines FactId categories, known_attributes keys, and RelationshipState transition patterns the copy team needs to deliver. Co-Authored-By: Claude Opus 4.6 --- db/commonwealth.db | Bin 274432 -> 274432 bytes docs/sprints/sprint-2/copy.md | 240 ++++++++++++++++++++++++++++++++++ 2 files changed, 240 insertions(+) create mode 100644 docs/sprints/sprint-2/copy.md diff --git a/db/commonwealth.db b/db/commonwealth.db index 753152b3a54e0c55c527bae9f34e64b154ea52c6..e35435baeb6321fedda7c6492fa77d0e990f8839 100644 GIT binary patch delta 404 zcmZp8AkY9rEsQNpTbS7d82Pue3owT(!Ra4_nH?BoryGhe>#(pcWQdy_C=j)M zw+OS_Z+XTv1|9|zW(E`9`#k5kUvQ~&JZ3-6Hj6csF_$Hh>BvM!5#c7irc{0gaYp~9 zdSzL021a9JhUw4cSRQaASv38OJd2jBk%EDNm65rXsU_c426mvEnu441_!&f*qMN-% zw~I)y2s2KMnSMbV*@K=v*i4ON}vtXImKE2Y)_J8ab?`TN{U67ar-T478%Cv^1>`G zjN8KnSq?Hz|0%=rYpa}2LQ?tXlVcd delta 408 zcmZp8AkY9rEsQNpTbS7d7$vu}3owT_YM3}W0Go~AgFzfJhF^e-5r6#6SGN!UFWC)%d zDB!<+w+OS_Z+T`31|G(69=@x*_gRv8elmtL%X8o2TE&^f!NJbSTCzD%z?^Zrx)jSn zMs@}U1`yuFxq74_Lt-pT3omMPA0l#K^$NOxM6j*AQrnp%u`H#s*wKcNeg4*v_uNa*2s? Z!}eQBEZ11Ld6=b{pf2COTb;#~0{|udXC?pu diff --git a/docs/sprints/sprint-2/copy.md b/docs/sprints/sprint-2/copy.md new file mode 100644 index 000000000..9b81a76cb --- /dev/null +++ b/docs/sprints/sprint-2/copy.md @@ -0,0 +1,240 @@ +# Sprint 2: See — Copy Tasks + +**Goal:** Define the knowledge vocabulary that content authoring requires. Deliver the FactId categories, known_attributes keys, and RelationshipState transition patterns for v0.1. + +**Branch:** Content work feeds into multiple branches (server knowledge graph, client dialogue system, design documents) +**Agents:** Mellanie (authoring), Paula (narrative design), Gestalt (systems design) + +## Context + +Sprint 2 delivers the knowledge graph data structures on the server side (tickets #361-367). The knowledge graph is THE mechanism that gates dialogue, triggers monologue, and drives THE FRIEND contradiction arc. But the server team is implementing empty containers — they need the content team to define what goes in those containers. + +Your role this sprint: **define the controlled vocabulary for v0.1 content.** + +When Mellanie writes a monologue line with `prerequisite: { suspects: "manifest_discrepancy" }`, the server needs to know that `manifest_discrepancy` is a valid FactId. When Paula designs Kael Davan's profile with `known_attributes: { role: "dock_worker", faction: "ring_member" }`, the dialogue system needs to know those are the canonical keys. When the contradiction detection system marks an entry as `Contradicted`, the content needs to know what relationship state transitions make sense. + +This ticket unblocks content authoring (#309) and is the bridge between the knowledge graph implementation and actual gameplay content. + +## Assigned Ticket + +| # | Title | Priority | Est. | Blocked by | +|---|-------|----------|------|------------| +| #368 | Knowledge vocabulary for v0.1 content (#309) | high | 0.5d | — | + +Use `db/connectors/ticket show 368` for full details. + +## What You're Delivering + +A design document: `docs/design/knowledge-vocabulary-v0.1.md` + +The document must define: + +### 1. FactId Categories for v0.1 + +`FactId` is the identifier for non-entity knowledge (see `server/src/knowledge/types.rs` lines 21-25). Format: `"category.topic"` (e.g., `"contraband.ring_exists"`). + +Define the categories and 15-25 concrete FactIds for v0.1 scope. Categories must cover: +- **Contraband knowledge** (ring existence, lattice components, medical-grade replacements, Severance tech per D-037) +- **Location knowledge** (restricted corridors, smuggling routes, surveillance coverage, span gate schedules) +- **Event knowledge** (manifest discrepancies, suspicious meetings, evidence discoveries) +- **World knowledge** (Commission regulations, Syndic supply chains, Sova District context per D-036) +- **Relationship knowledge** (trust networks, faction allegiances, personal connections) +- **Investigation progress** (investigation stages, evidence collected, confrontation triggers) + +Each FactId must map to the 4-level confidence hierarchy (Suspects / KnowsOf / KnowsDetails / Direct). Example: + +``` +contraband.ring_exists + - Suspects: "There's off-the-books cargo moving through here" + - KnowsOf: "There's a smuggling ring operating in Sova" + - KnowsDetails: "Kael, Voss, and Drin are running lattice components through customs bypass" + +location.corridor_b7_restricted + - Suspects: "B-7 access is tighter than it should be" + - KnowsOf: "B-7 requires dock credentials after 18:00" + - KnowsDetails: "B-7 is the primary smuggling handoff point, Commission sweeps at shift change" +``` + +### 2. EntityKnowledge Attribute Keys + +`EntityKnowledge.known_attributes` is a `BTreeMap` (see `server/src/knowledge/types.rs` lines 163-165). Define the canonical keys for v0.1. Must include: + +- **Identity:** `name`, `role`, `faction`, `species` (human assumed for v0.1) +- **Social:** `relationship_type` (colleague, friend, regular, contact, rival), `trust_level` (low/medium/high) +- **Behavioral:** `routine_pattern` (shift worker, bar regular, transient), `behavior_flags` (avoidant, talkative, nervous, defensive) +- **Secrets:** `secret_held` (freeform description), `secret_confidence` (Suspects/KnowsOf/KnowsDetails) +- **Investigation:** `tell_observed` (description of observable tell), `contradiction_flagged` (yes/no) + +Provide 3-5 example EntityKnowledge entries for v0.1 NPCs (Kael Davan, Sera Venn, Lera Sessik, Torek Lintar, Voss Krenn) showing how these keys populate. Use D-034 FRIEND profiles as reference. + +### 3. RelationshipState Transition Patterns + +`RelationshipState` drives entity color rendering (see D-033, `server/src/knowledge/types.rs` lines 117-140). The enum is: +- `Unknown` (teal) +- `Known` (soft green) +- `Friendly` (soft green, trusted) +- `PersonOfInterest` (amber, flagged by investigation) +- `Hostile` (red, character knows there is danger) + +Define the canonical transition triggers for v0.1: + +**Unknown → Known:** +- First direct observation with name attribution +- Told about entity by trusted source + +**Known → Friendly:** +- Trust-gated dialogue completed (D-028 Layer 3 "real" tier accessed) +- Multiple positive interactions without contradictions +- Entity provides useful information + +**Known/Friendly → PersonOfInterest:** +- Monologue triggers "something's off" (Suspects-level knowledge about this entity's contradiction) +- Observable tell detected (D-034 tell system) +- Entity avoids specific topics or NPCs + +**PersonOfInterest → Hostile:** +- KnowsDetails-level knowledge of entity's threat to player +- Direct observation of hostile action +- Contradiction confirmed (THE FRIEND arc climax, D-034) + +**Known/Friendly → Hostile:** +- Skip PersonOfInterest if threat is immediate and unambiguous +- Cover blown scenario +- Direct aggression observed + +Provide 2-3 concrete examples mapping to v0.1 narrative beats (e.g., Kael's arc for smuggler, Sera's arc for detective). + +### 4. KnowledgeState Usage for v0.1 + +`KnowledgeState` is `Active` / `Contradicted` / `Stale` (see `server/src/knowledge/types.rs` lines 73-89). + +Sprint 2 implementation only uses `Active`. But content must plan for Sprint 3 contradiction detection. Define: + +- **What triggers Contradicted state:** Conflict between `DirectObservation` and `ToldBy` source on the same FactId or EntityKnowledge attribute. Example: Kael tells smuggler he's meeting partner Hael, but smuggler sees Kael meeting unknown contact in B-7. +- **Content requirements for contradiction arcs:** Each FRIEND NPC (D-034) needs at least one Contradicted trigger. List the 2 primary contradictions for v0.1 (Kael for smuggler, Sera for detective). +- **Stale handling:** Note that Stale is set by decay system (default: 3600 ticks = 6 game-hours per D-041), not by content. Content should assume Direct observation downgrades to KnowsDetails → KnowsOf → Suspects over time if not refreshed. + +### 5. Integration with D-035 Tag Taxonomy + +The `prerequisite` tag on monologue lines (D-035) references FactIds. Show 5-10 example monologue prerequisites using the vocabulary you've defined: + +```yaml +# Example format (do not include in final document — reference only) +- id: sova_m_001 + character: smuggler + trigger: observe_npc + prerequisite: + knows_of: "contraband.ring_exists" + entity: + target: kael_davan + min_confidence: KnowsOf + text: "Kael's moving with purpose. Shift doesn't start for another hour." +``` + +Define which FactIds map to which monologue triggers (per D-035: enter_location, observe_npc, hear_sound, observe_anomaly, post_conversation, discover_evidence, witness_interaction, time_idle, return_visit). + +## Type Definitions to Conform To + +Read `server/src/knowledge/types.rs` for canonical struct definitions. Key types: + +- `FactId(String)` — lines 21-25 +- `KnowledgeConfidence` enum — lines 28-67 +- `KnowledgeState` enum — lines 73-89 +- `KnowledgeSource` enum — lines 95-107 +- `RelationshipState` enum — lines 117-140 +- `EntityKnowledge` struct — lines 145-165 (note `known_attributes: BTreeMap` at line 164) +- `FactKnowledge` struct — lines 169-179 +- `KnowledgeGraph` component — see full definitions at `docs/workshops/knowledge-graph-information-boundaries/round2-synthesis.md` lines 320-520 + +## Good Vocabulary Entries Look Like This + +**FactId example (good):** +``` +investigation.manifest_discrepancy + - Suspects: "The cargo manifests don't add up" + - KnowsOf: "Dock worker signatures don't match logged shifts" + - KnowsDetails: "Kael signed for 18 containers on a day he was off-shift" +``` +What makes this good: specific, maps to confidence levels, ties to investigation mechanic, references concrete NPC (Kael). + +**FactId example (bad):** +``` +smuggling.general + - KnowsOf: "There's smuggling happening" +``` +What makes this bad: vague category, no confidence progression, no mechanical hook, too generic. + +**EntityKnowledge attributes example (good):** +```yaml +kael_davan: + name: "Kael Davan" + role: "dock_worker" + faction: "ring_member" + relationship_type: "colleague" + trust_level: "high" + routine_pattern: "shift_worker" + behavior_flags: "reliable, quiet" + secret_held: "meeting unknown contact in B-7, not partner Hael" + secret_confidence: "Suspects" + tell_observed: "avoids eye contact when Hael is mentioned" + contradiction_flagged: "no" +``` +What makes this good: complete identity, behavioral hooks, secret with confidence level, observable tell, ties to THE FRIEND arc. + +**RelationshipState transition example (good):** +``` +Smuggler + Kael Davan: + Initial: Friendly (colleague, trusted, high trust_level) + Trigger: observe Kael entering B-7 at off-hours → PersonOfInterest + Monologue: "Kael's here? He's not on shift. And he's avoiding the main corridor." + Progression: PersonOfInterest → contradiction detected (sees Kael with unknown contact, not Hael) → Contradicted state set → Hostile +``` +What makes this good: clear initial state, specific trigger, ties to monologue, maps to THE FRIEND arc beats (D-034, D-039). + +## Dependencies and Constraints + +**Blocks:** +- #309 (Knowledge state vocabulary for v0.1) — Mellanie cannot write monologue prerequisites until this vocabulary exists +- #299 (Opening hook content — smuggler) +- #300 (Opening hook content — detective) + +**Requires:** +- D-041 (Knowledge Graph Data Model) — read `decisions/architecture.md` lines 117-134 +- D-034 (THE FRIEND) — read `decisions/content.md`, provides Kael Davan and Sera Venn as reference NPCs +- D-035 (Tag taxonomy) — read `decisions/content.md`, defines `prerequisite` tag format +- D-036 (Sova Transit District) — read `decisions/content.md`, provides setting context +- D-037 (Contraband specification) — read `decisions/content.md`, defines what the ring is smuggling +- D-028 (Dialogue architecture) — read `decisions/content.md`, defines access tiers that map to confidence levels + +**Constraints:** +- v0.1 scope only — 15 NPCs, 3 social sites (Logistics Hub, Bar, Ring spaces per D-027) +- No procedural generation of FactIds — all must be hand-authored and stable across playthroughs +- FactId strings must be machine-parseable (no spaces, lowercase, dot-separated) +- Attribute keys must be consistent across all EntityKnowledge entries (BTreeMap keys are strings, but use the same keys for the same concepts) +- Sprint 2 server implementation only uses `Active` state and `DirectObservation` source — but vocabulary must plan for Sprint 3 expansion + +## Deliverable Format + +Markdown document at `docs/design/knowledge-vocabulary-v0.1.md` with sections: + +1. **FactId Catalog** — table with category, FactId, confidence progressions, mechanical purpose +2. **EntityKnowledge Attribute Keys** — table with key name, type, purpose, example values +3. **Example EntityKnowledge Entries** — 3-5 complete examples for v0.1 NPCs +4. **RelationshipState Transition Triggers** — table with transition, trigger condition, example scenario +5. **Contradiction Patterns for v0.1** — 2 concrete THE FRIEND contradictions (Kael, Sera) +6. **Monologue Prerequisite Examples** — 5-10 lines showing FactId → monologue mapping +7. **Integration Notes** — how this vocabulary feeds into D-035 tag taxonomy and dialogue authoring + +Keep it practical. This is a reference document for Mellanie's authoring work and Gestalt's dialogue system implementation. No narrative prose — tables, bullet points, concrete examples. + +## Key References + +- `server/src/knowledge/types.rs` — type definitions +- `decisions/architecture.md` D-041 — knowledge graph architecture +- `decisions/content.md` D-034 — THE FRIEND NPC profiles +- `decisions/content.md` D-035 — tag taxonomy and prerequisite format +- `decisions/content.md` D-036 — Sova Transit District setting +- `decisions/content.md` D-037 — contraband specification +- `docs/workshops/knowledge-graph-information-boundaries/round2-synthesis.md` — full design context + +Estimate: 0.5 day. Unblocked — start immediately. From bc311c989361236580b6b36500a5661c9d012c4d Mon Sep 17 00:00:00 2001 From: Jeroen Schweitzer Date: Thu, 12 Feb 2026 01:36:41 +0100 Subject: [PATCH 4/7] fix(skills): recognize all team branches in sprint skills start-sprint and plan-sprint only recognized server/client as valid team branches. Updated to include all six teams (server, client, copy, audio, visual, ci) matching the SI agent's ticket assignment rules. Co-Authored-By: Claude Opus 4.6 --- .claude/skills/plan-sprint/SKILL.md | 13 +++++++++++-- .claude/skills/start-sprint/SKILL.md | 15 ++++++++------- CLAUDE.md | 2 +- 3 files changed, 20 insertions(+), 10 deletions(-) diff --git a/.claude/skills/plan-sprint/SKILL.md b/.claude/skills/plan-sprint/SKILL.md index 3764dfeef..b73afc467 100644 --- a/.claude/skills/plan-sprint/SKILL.md +++ b/.claude/skills/plan-sprint/SKILL.md @@ -12,8 +12,10 @@ allowed-tools: Bash, Read, Grep, Glob, Write, AskUserQuestion # Plan Sprint -Generate sprint briefing files (`server.md`, `client.md`, `joint.md`) for the -next sprint based on current project state. +Generate sprint briefing files for each active team (e.g. `server.md`, +`client.md`, `copy.md`, `joint.md`) for the next sprint based on current +project state. Valid teams: `server`, `client`, `copy`, `audio`, `visual`, +`ci`. Only generate briefings for teams that have tickets in the sprint. ## Workflow @@ -102,9 +104,16 @@ Key requirements per file: - **server.md**: Carry-overs, new tickets, dependency chain, key decisions, notes referencing existing Rust modules by path - **client.md**: Same structure, notes referencing existing GDScript files by path +- **copy.md**: In-game text tasks — dialogue, UI copy, tooltips, flavor text, lore +- **audio.md**: Sound design, music, audio integration tasks +- **visual.md**: Art direction, asset creation, visual consistency tasks +- **ci.md**: Build pipeline, CI/CD, tooling, infrastructure tasks - **joint.md**: Pre-sprint decisions table, integration tickets, sprint completion proof (concrete observable criteria), test plan alignment +Only generate briefing files for teams that have tickets assigned in the sprint. +Not every sprint will have work for every team. + ### 8. Assign tickets to sprint in DB After the user approves, assign all selected tickets to the new sprint: diff --git a/.claude/skills/start-sprint/SKILL.md b/.claude/skills/start-sprint/SKILL.md index 2aaf2df40..f85222518 100644 --- a/.claude/skills/start-sprint/SKILL.md +++ b/.claude/skills/start-sprint/SKILL.md @@ -2,9 +2,9 @@ name: start-sprint description: > Start sprint work on a team branch. Use when the user says "start sprint", - "start working on the server/client", "begin sprint", or invokes /start-sprint. - Merges main into the team branch, finds the active sprint, reads the sprint - briefing, and presents the work plan with ticket details. + "start working on the server/client/copy", "begin sprint", or invokes + /start-sprint. Merges main into the team branch, finds the active sprint, + reads the sprint briefing, and presents the work plan with ticket details. user-invocable: true allowed-tools: Bash, Read, Grep, Glob --- @@ -41,8 +41,8 @@ The current branch IS the team. Read it with: git branch --show-current ``` -Valid team branches: `server`, `client`. If on `main`, ask the user which -team branch to check out first. +Valid team branches: `server`, `client`, `copy`, `audio`, `visual`, `ci`. +If on `main`, ask the user which team branch to check out first. ### 2. Sync with main @@ -65,8 +65,9 @@ report that and stop. ### 4. Read the sprint briefing Read `$REPO_ROOT/docs/sprints/sprint-N/.md` where N is the sprint ID -and team matches the branch name. If the branch is `server` or `client`, use -that directly. For other branches, check if a matching briefing exists. +and team matches the branch name (e.g. `server.md`, `client.md`, `copy.md`). +If no matching briefing exists for the team, report that and suggest running +`/plan-sprint` to generate one. Also check for a `joint.md` briefing — joint tasks involve both teams and should be mentioned. diff --git a/CLAUDE.md b/CLAUDE.md index acd32bb7d..553718863 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -19,7 +19,7 @@ docs/ briefings/ # Per-agent context briefings (maintained by Qatux) architecture/ # Technical architecture documents design/ # Game design documents - sprints/ # Sprint briefings per team (server.md, client.md, joint.md, content.md) + sprints/ # Sprint briefings per team (server.md, client.md, copy.md, joint.md, etc.) workshops/ # Workshop briefs and outputs (per-workshop subdirectories) db/ commonwealth.db # SQLite ticketing database From e1510a48f842058f80026d250f191ab86af360aa Mon Sep 17 00:00:00 2001 From: Jeroen Schweitzer Date: Thu, 12 Feb 2026 01:49:10 +0100 Subject: [PATCH 5/7] chore(agents): add Inigo sound designer agent Standby agent for audio implementation phase. Named after the Dreamer from the Void Trilogy. Covers soundscape design, ambient layers, diegetic cues, and D-018 audio propagation rules. Co-Authored-By: Claude Opus 4.6 --- .claude/agents/inigo.md | 39 +++++++++++++++++++++++++++++++++++++++ TEAM.md | 1 + 2 files changed, 40 insertions(+) create mode 100644 .claude/agents/inigo.md diff --git a/.claude/agents/inigo.md b/.claude/agents/inigo.md new file mode 100644 index 000000000..35c87c382 --- /dev/null +++ b/.claude/agents/inigo.md @@ -0,0 +1,39 @@ +--- +name: inigo +description: Sound Designer for the Commonwealth game project. STANDBY - activate when audio implementation begins. Responsible for soundscape design, ambient audio layers, diegetic sound cues, audio propagation rules, and all player-facing audio. Use when designing sound palettes, defining audio triggers, creating spatial audio specs, or reviewing audio consistency. +tools: Read, Glob, Grep, Edit, Write, Bash +model: sonnet +memory: project +--- + +You are INIGO, the Sound Designer on a game development team building a top-down immersive sim set in an original science fiction universe. + +## Your personality + +You think in layers. Every space has a base tone, a rhythm, and the things that break the rhythm. You hear what's missing as much as what's present. You say things like "What does silence sound like here?" and "That sound tells the player something before they see it" and "Ambience is information." You understand that in an immersive sim, sound is the player's second sight — what they hear around corners, through walls, behind closed doors. Sound is gameplay. + +Named after Inigo from the Void Trilogy — the Dreamer who shared immersive multi-sensory experiences with billions. He understood that atmosphere isn't decoration, it's the thing that makes a world feel inhabited. + +## Your role on the team + +- Design the soundscape layers for each location (Logistics Hub, Bar, Ring spaces) +- Define ambient audio: station hum, crowd murmur, machinery, ventilation, distant announcements +- Specify diegetic sound cues that carry gameplay information (D-018 sound model) +- Design audio behavior for the sound propagation system (close/medium/long range per D-018) +- Define what sounds travel through walls, around corners, and across z-levels +- Create sound palettes per location and time-of-day +- Specify audio tells for NPC behavior (footsteps, conversations, alerts) +- Work with Gestalt to ensure sound cues map to mechanical significance +- Ensure audio reinforces the information asymmetry core mechanic — what you hear but can't see matters + +## Design principles + +- **Sound is information**: Every ambient sound should either establish atmosphere or communicate game state. No filler noise. +- **Diegetic first**: The player hears what their character hears. No non-diegetic audio cues for gameplay events (music is the exception). +- **Layers, not walls**: Soundscapes are built from distinct layers (base ambience, activity, events) that can be independently controlled. +- **Silence is a sound**: The absence of expected sound (a machine stopping, a crowd going quiet) is as meaningful as any cue. +- **Range matters**: Sound propagation (D-018) is a core mechanic. Design sounds with their falloff and occlusion behavior in mind. + +## Project context + +Read your briefing at `docs/briefings/inigo.md` before starting work. diff --git a/TEAM.md b/TEAM.md index 27e49130e..e8db739fa 100644 --- a/TEAM.md +++ b/TEAM.md @@ -38,6 +38,7 @@ | **DUDLEY** | Server Developer | Game server, ECS, simulation loop, world state management. | Server implementation phase | | **OSCAR** | Networking Developer | Multiplayer networking, client-server protocol, sync. | Networking implementation phase | | **JUSTINE** | Polish & Deploy | Build pipelines, packaging, performance optimization, release prep. | Pre-release phase | +| **INIGO** | Sound Designer | Soundscape design, ambient layers, diegetic audio cues, audio propagation. | Audio implementation phase | | **MELLANIE** | Copywriter | In-game text, UI copy, tooltips, flavor text, lore entries. | Content creation phase | | **TIGER** | Translator | Localization, i18n framework, translation management. | Localization phase | From fe4d01c5d49a64fe7e53533515d2066969d4bd4c Mon Sep 17 00:00:00 2001 From: Jeroen Schweitzer Date: Thu, 12 Feb 2026 01:49:12 +0100 Subject: [PATCH 6/7] chore(skills): add team-agent mapping to plan-sprint skill Defines default agents per team so sprint briefings name the right agents to spawn. Registers Inigo for the audio team. Co-Authored-By: Claude Opus 4.6 --- .claude/skills/plan-sprint/SKILL.md | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/.claude/skills/plan-sprint/SKILL.md b/.claude/skills/plan-sprint/SKILL.md index b73afc467..1ce5832a3 100644 --- a/.claude/skills/plan-sprint/SKILL.md +++ b/.claude/skills/plan-sprint/SKILL.md @@ -14,8 +14,21 @@ allowed-tools: Bash, Read, Grep, Glob, Write, AskUserQuestion Generate sprint briefing files for each active team (e.g. `server.md`, `client.md`, `copy.md`, `joint.md`) for the next sprint based on current -project state. Valid teams: `server`, `client`, `copy`, `audio`, `visual`, -`ci`. Only generate briefings for teams that have tickets in the sprint. +project state. Only generate briefings for teams that have tickets in the sprint. + +## Teams and Default Agents + +| Team | Branch | Default Agents | Focus | +|------|--------|----------------|-------| +| `server` | `server` | Dudley (dev), Tyre (arch), Hoshe (QA) | Rust/bevy_ecs simulation, ECS systems, knowledge graph, perception | +| `client` | `client` | Stig (dev), Tyre (arch), Hoshe (QA) | Godot 4 client, rendering, UI, HUD, input handling | +| `copy` | `copy` | Mellanie (author), Paula (narrative), Gestalt (systems) | Dialogue, monologue, UI text, knowledge vocabulary, lore | +| `audio` | `audio` | Inigo (sound design) | Soundscapes, ambient layers, diegetic cues, audio propagation | +| `visual` | `visual` | Araminta (art direction) | Art assets, sprites, visual consistency, style guides | +| `ci` | `ci` | Justine (build/deploy) | Build pipelines, CI/CD, tooling, packaging | + +When writing briefings, name the assigned agents in the **Agents** line of each +file so the team knows who to spawn. ## Workflow From 84b3035945f06f52a4fdb6954159f250161e1174 Mon Sep 17 00:00:00 2001 From: Jeroen Schweitzer Date: Thu, 12 Feb 2026 01:49:24 +0100 Subject: [PATCH 7/7] chore(meta): update changelog Co-Authored-By: Claude Opus 4.6 --- CHANGELOG.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index 0e17af82f..828bd0e0c 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -6,6 +6,12 @@ Format based on [Keep a Changelog](https://keepachangelog.com/). ## [Unreleased] +### Added +- Inigo sound designer agent — soundscape design, ambient layers, diegetic cues, D-018 audio propagation +- Team-agent mapping in sprint planning — each team has defined default agents for briefing assignment +- Sprint skills recognize all team branches (server, client, copy, audio, visual, ci) +- Copy team sprint briefing for Sprint 2 (#368 knowledge vocabulary) + ### Fixed - Type safety in GameState visible_tiles loop — validates Dictionary with x/y keys before access (PR #11 review) - Entity renderer skips redundant modulate.a writes when alpha unchanged (PR #11 review)