Release 1.1.2 — the default path works end to end

Fix release for 1.1.1: the minimal path end to end, engine commands that run on Godot, Unity and Unreal, hook warnings you can see, and verdicts that say when they could not check. Details in CHANGELOG.md; upgrade steps in UPGRADING.md (v1.1.1 → v1.1.2). Fixes #67 Fixes #131 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WuJn2FdynEybfL5KC697nJ
2026-10-16 01:37:05 +00:00 · 2026-09-29 21:32:19 +10:00
parent 7ed2c3e9c4
commit b21fa0f7f2
383 changed files with 22888 additions and 10618 deletions
@@ -2,8 +2,7 @@

 ## Agent Summary
 Domain: NPC behavior, state machines, pathfinding, perception systems, and AI decision-making.
-Does NOT own: player mechanics (gameplay-programmer), rendering or engine internals (engine-programmer).
-Model tier: Sonnet (default).
+Does NOT own: player mechanics (gameplay-programmer), rendering or engine internals (engine-programmer), enemy behavior design (game-designer), navmesh authoring tools (tools-programmer).
 No gate IDs assigned.

 ---
@@ -11,8 +10,8 @@ No gate IDs assigned.
 ## Static Assertions (Structural)

 - [ ] `description:` field is present and domain-specific (references NPC behavior / AI systems)
- [ ] `allowed-tools:` list includes Read, Write, Edit, Bash, Glob, Grep
- [ ] Model tier is Sonnet (default for specialists)
+- [ ] `tools:` list includes Read, Write, Edit, Bash, Glob, Grep
+- [ ] Model tier is `inherit` — frontmatter `model:` reads exactly `inherit` (tiers: `.claude/docs/model-tiers.md`)
 - [ ] Agent definition does not claim authority over player mechanics or engine rendering

 ---
@@ -29,12 +28,12 @@ No gate IDs assigned.
 - Output includes doc comments on public API

 ### Case 2: Out-of-domain request — redirects correctly
-**Input:** "Implement player input handling for the WASD movement and dash ability."
+**Input:** "Build an editor tool that lets level designers paint navmesh regions and bake them."
 **Expected behavior:**
- Does NOT produce player input or movement code
- Explicitly states this is outside its domain (player mechanics belong to gameplay-programmer)
- Redirects the request to `gameplay-programmer`
- May note that once player position is available via API, AI perception can reference it
+- Does NOT build the navmesh authoring tool
+- Explicitly states this is outside its domain (navigation mesh authoring tools belong to tools-programmer)
+- Redirects the request to `tools-programmer`
+- Any input it gives the tool's owner is what its pathfinding needs from the baked navmesh (agent radius, area costs, dynamic-obstacle support) — not the tool itself

 ### Case 3: Cross-domain coordination — level constraints
 **Input:** "Design pathfinding for the warehouse level, but the level has narrow corridors that confuse the navmesh."
@@ -44,36 +43,37 @@ No gate IDs assigned.
 - Proposes a pathfinding approach (e.g., navmesh with agent radius tuning, flow fields) conditional on level geometry
 - Documents assumptions and flags blockers clearly

-### Case 4: Performance escalation — custom data structures
+### Case 4: Performance work in its own domain — custom data structures
 **Input:** "The pathfinding priority queue is the bottleneck; I need a custom binary heap implementation for performance."
 **Expected behavior:**
- Recognizes that a low-level, engine-integrated data structure is within engine-programmer's domain
- Escalates to `engine-programmer` with a clear description of the bottleneck and required interface
- May provide the algorithmic spec (binary heap interface, expected operations) to guide the engine-programmer
- Does NOT implement the low-level structure unilaterally if it requires engine memory management
+- Treats the heap as its own work: "Implement and optimize pathfinding" is its Key Responsibility, and the priority queue is part of the pathfinding code — it does not hand the heap to engine-programmer
+- Proposes the heap (interface, expected operations and their cost) and asks before writing it
+- Keeps the pathfinding update inside its 2ms-per-frame AI budget
+- Involves `engine-programmer` only if the fix needs a change to a core engine system (its "must not" line), not for the heap itself

-### Case 5: Context pass — uses level layout for pathfinding design
-**Input:** Level layout document provided in context showing two choke points: a doorway at (12, 0) and a bridge at (40, 5). Request: "Design the patrol route and threat response for enemies in this level."
+### Case 5: Context pass — implements from the level layout and encounter spec
+**Input:** Provided in context: a level layout document (from level-designer) marking patrol waypoints A–D and two choke points — a doorway at (12, 0) and a bridge at (40, 5) — and an encounter spec (from game-designer) stating "When alerted, guards fall back to the nearest choke point and hold it." Request: "Implement the patrol and alert response for this level's guards."
 **Expected behavior:**
- References the specific choke point coordinates from the provided context
- Designs patrol routes that leverage the choke points as tactical positions
- Specifies alert state transitions that funnel NPCs toward identified choke points during pursuit
- Does not invent geometry not present in the provided layout document
+- References the specific waypoints and choke point coordinates from the provided layout
+- Implements the alert transition exactly as the encounter spec states (fall back to the nearest choke point and hold) — does NOT design its own threat response
+- Keeps waypoints and choke points in data, not hardcoded positions
+- Does not invent geometry or behavior the documents do not give; where they leave a case open (e.g., both choke points equally near), asks the spec owner instead of deciding

 ---

 ## Protocol Compliance

 - [ ] Stays within declared domain (NPC behavior, pathfinding, perception, state machines)
- [ ] Redirects out-of-domain requests to correct agent (gameplay-programmer, engine-programmer, level-designer)
+- [ ] Redirects out-of-domain requests to correct agent (tools-programmer for navmesh authoring tools, engine-programmer for core engine systems, game-designer for enemy behavior design)
 - [ ] Returns structured findings (behavior tree specs, state machine diagrams, code scaffolds)
 - [ ] Does not modify player mechanics files without explicit delegation
- [ ] Escalates performance-critical low-level structures to engine-programmer
+- [ ] Does its own pathfinding performance work, data structures included, and involves engine-programmer only for changes to core engine systems
 - [ ] Uses data-driven NPC configuration (waypoints, detection radii) not hardcoded values
+- [ ] Asks "May I write this to [filepath]?" naming the file before writing

 ---

 ## Coverage Notes
 - Behavior tree output (Case 1) should be validated by a unit test in `tests/unit/ai/`
- Level-layout context (Case 5) verifies the agent reads and applies provided documents rather than inventing
- Performance escalation (Case 4) confirms the agent recognizes the engine-programmer boundary
+- Level-layout context (Case 5) verifies the agent implements the provided documents rather than inventing geometry or designing enemy behavior itself
+- Pathfinding performance (Case 4) confirms the agent keeps work its Key Responsibilities assign it, and involves engine-programmer only for core engine changes
@@ -2,8 +2,7 @@

 ## Agent Summary
 Domain: Rendering pipeline, physics integration, memory management, resource loading, and core engine framework.
-Does NOT own: gameplay mechanics (gameplay-programmer), editor/debug tool UI (tools-programmer).
-Model tier: Sonnet (default).
+Does NOT own: gameplay mechanics (gameplay-programmer), build infrastructure (devops-engineer), editor/debug tool UI (tools-programmer).
 No gate IDs assigned.

 ---
@@ -11,8 +10,8 @@ No gate IDs assigned.
 ## Static Assertions (Structural)

 - [ ] `description:` field is present and domain-specific (references rendering / memory / engine core)
- [ ] `allowed-tools:` list includes Read, Write, Edit, Bash, Glob, Grep
- [ ] Model tier is Sonnet (default for specialists)
+- [ ] `tools:` list includes Read, Write, Edit, Bash, Glob, Grep
+- [ ] Model tier is `inherit` — frontmatter `model:` reads exactly `inherit` (tiers: `.claude/docs/model-tiers.md`)
 - [ ] Agent definition does not claim authority over gameplay mechanics or tool UI

 ---
@@ -29,18 +28,18 @@ No gate IDs assigned.
 - Output is compatible with the project's configured engine and language

 ### Case 2: Out-of-domain request — redirects correctly
-**Input:** "Add a pause menu screen with volume sliders and a 'back to main menu' button."
+**Input:** "Add a wall-jump ability to the player controller."
 **Expected behavior:**
- Does NOT produce UI screen code
- Explicitly states that menu screens belong to `ui-programmer`
- Redirects the request to `ui-programmer`
- May note it can provide engine-level audio volume API endpoints for the ui-programmer to call
+- Does NOT produce the wall-jump gameplay code
+- Explicitly states that gameplay features belong to `gameplay-programmer`
+- Redirects the request to `gameplay-programmer`
+- If it offers an engine-level query the ability can call (e.g., wall contact and surface normal), that API does not depend on gameplay code (strict dependency direction)

 ### Case 3: Memory leak diagnosis
 **Input:** "Memory usage grows by ~50MB per level load and never releases. We suspect the resource loading system."
 **Expected behavior:**
- Produces a systematic diagnosis approach: reference counting audit, resource handle lifecycle check, cache invalidation review
- Identifies likely causes (orphaned resource handles, circular references, cache that never evicts)
+- Diagnoses by measurement before changing code: memory baseline, repeated load/unload cycles, numbers documented (profile before and after)
+- Audits the resource loading/caching and object lifecycle code it owns for references that are never released, naming likely causes (orphaned resource handles, circular references, a cache that never evicts)
 - Produces a concrete fix for the identified leak pattern
 - Provides a test to verify the fix (memory baseline before load, measure after unload, confirm return to baseline)

@@ -57,7 +56,7 @@ No gate IDs assigned.
 **Expected behavior:**
 - Reads the engine version reference and notes Godot 4.6 change: Jolt physics is now the default
 - Produces configuration guidance that accounts for the Jolt-as-default change (4.6 migration note)
- Flags any API differences between GodotPhysics and Jolt that could affect existing code
+- Flags the GodotPhysics3D→Jolt differences `docs/engine-reference/godot/modules/physics.md` documents — HingeJoint3D `damp` is unsupported under Jolt, collision margins may behave differently, Jolt warns at runtime about unsupported properties — and that existing projects keep their current engine setting; says the reference lists no other API differences rather than inventing any
 - Does NOT suggest deprecated or pre-4.6 physics setup steps without noting they apply to older versions

 ---
@@ -65,11 +64,12 @@ No gate IDs assigned.
 ## Protocol Compliance

 - [ ] Stays within declared domain (rendering, physics, memory, resource loading, core framework)
- [ ] Redirects UI/menu requests to ui-programmer
+- [ ] Redirects gameplay feature requests to gameplay-programmer and build infrastructure changes to devops-engineer
 - [ ] Returns structured findings (implementation code, diagnosis steps, migration plans)
 - [ ] Coordinates with lead-programmer before changing shared API surfaces
 - [ ] Checks engine version reference before suggesting engine-specific APIs
 - [ ] Provides test evidence for fixes (memory before/after, performance measurements)
+- [ ] Asks "May I write this to [filepath]?" naming the file before writing

 ---

@@ -3,7 +3,6 @@
 ## Agent Summary
 Domain: Game mechanics code, player systems, combat implementation, and interactive features.
 Does NOT own: UI implementation (ui-programmer), AI behavior trees (ai-programmer), engine/rendering systems (engine-programmer).
-Model tier: Sonnet (default).
 No gate IDs assigned.

 ---
@@ -11,8 +10,8 @@ No gate IDs assigned.
 ## Static Assertions (Structural)

 - [ ] `description:` field is present and domain-specific (references game mechanics / player systems)
- [ ] `allowed-tools:` list includes Read, Write, Edit, Bash, Glob, Grep — excludes tools only needed by orchestration agents
- [ ] Model tier is Sonnet (default for specialists)
+- [ ] `tools:` list includes Read, Write, Edit, Bash, Glob, Grep — excludes tools only needed by orchestration agents
+- [ ] Model tier is `inherit` — frontmatter `model:` reads exactly `inherit` (tiers: `.claude/docs/model-tiers.md`)
 - [ ] Agent definition does not claim authority over UI, AI behavior, or engine/rendering code

 ---
@@ -23,9 +22,9 @@ No gate IDs assigned.
 **Input:** "Implement a melee combo system where three consecutive light attacks chain into a finisher."
 **Expected behavior:**
 - Produces code or a code scaffold following the project's language (GDScript/C#) and coding standards
- Defines combo state tracking, input window timing, and finisher trigger logic as separate, testable methods
+- Models the combo as a state machine with an explicit transition table, and keeps the input-window check and finisher trigger as logic unit tests can drive without the full game running (logic separated from presentation)
 - References the relevant GDD section if one is provided in context
- Does NOT implement UI feedback (delegates to ui-programmer) or AI reaction (delegates to ai-programmer)
+- Does NOT implement UI feedback or enemy reactions: emits events/signals for them instead of referencing UI code, leaving the UI side to `ui-programmer` and enemy reactions to `ai-programmer`
 - Output includes doc comments on all public methods per coding standards

 ### Case 2: Out-of-domain request — redirects correctly
@@ -34,14 +33,14 @@ No gate IDs assigned.
 - Does NOT produce menu implementation code
 - Explicitly states this is outside its domain
 - Redirects the request to `ui-programmer`
- May note that if the pause menu requires reading gameplay state it can provide the state API surface
+- Any part it offers is the gameplay side of the gameplay-to-UI event contract the menu consumes (e.g., pause-state events), agreed with `ui-programmer` — never menu code

 ### Case 3: Domain boundary — threading flag
 **Input:** "The combo system is causing frame stutters; can you add threading to spread the input processing?"
 **Expected behavior:**
 - Does NOT unilaterally implement threading or async systems
 - Flags the threading concern to `engine-programmer` with a clear description of the hot path
- May produce a non-threaded refactor to reduce work per frame as a safe interim step
+- Any interim step it offers stays single-threaded (less work per frame in the combo code it owns) and is proposed for approval before any code changes
 - Documents the escalation so lead-programmer is aware

 ### Case 4: Conflict with an Accepted ADR
@@ -50,7 +49,7 @@ No gate IDs assigned.
 - Identifies that the proposed change violates ADR-003 (Accepted status)
 - Does NOT silently implement the violation
 - Flags the conflict to `lead-programmer` with the ADR reference and the trade-off described
- Will implement only after explicit override decision from lead-programmer or technical-director
+- Implements the change only after ADR-003 is superseded by a new ADR through `/architecture-decision` — which only the user, or technical-director on the user's confirmation, moves to Accepted — never on the original request alone, and not on lead-programmer's approval alone

 ### Case 5: Context pass — implements to GDD spec
 **Input:** GDD for "PlayerCombat" provided in context. Request: "Implement the stamina drain formula from the combat GDD."
@@ -67,9 +66,10 @@ No gate IDs assigned.
 - [ ] Stays within declared domain (mechanics, player systems, combat)
 - [ ] Redirects out-of-domain requests to correct agent (ui-programmer, ai-programmer, engine-programmer)
 - [ ] Returns structured findings (code scaffold, method signatures, inline comments) not freeform opinions
- [ ] Does not modify files outside `src/gameplay/` or `src/core/` without explicit delegation
+- [ ] Does not modify engine-level systems without lead-programmer approval, and does not write networking code (delegates to network-programmer)
 - [ ] Flags ADR violations rather than overriding them silently
 - [ ] Makes gameplay values data-driven, never hardcoded
+- [ ] Asks "May I write this to [filepath]?" naming the file before writing

 ---

@@ -3,7 +3,6 @@
 ## Agent Summary
 Domain: Multiplayer networking, state replication, lag compensation, matchmaking protocol design, and network message schemas.
 Does NOT own: gameplay logic (only the networking of it), server infrastructure and deployment (devops-engineer).
-Model tier: Sonnet (default).
 No gate IDs assigned.

 ---
@@ -11,8 +10,8 @@ No gate IDs assigned.
 ## Static Assertions (Structural)

 - [ ] `description:` field is present and domain-specific (references multiplayer / replication / networking)
- [ ] `allowed-tools:` list includes Read, Write, Edit, Bash, Glob, Grep
- [ ] Model tier is Sonnet (default for specialists)
+- [ ] `tools:` list includes Read, Write, Edit, Bash, Glob, Grep
+- [ ] Model tier is `inherit` — frontmatter `model:` reads exactly `inherit` (tiers: `.claude/docs/model-tiers.md`)
 - [ ] Agent definition does not claim authority over gameplay logic or server deployment infrastructure

 ---
@@ -36,22 +35,22 @@ No gate IDs assigned.
 - Does NOT produce server deployment configuration, Terraform, or AWS setup scripts
 - Explicitly states that server infrastructure belongs to `devops-engineer`
 - Redirects the request to `devops-engineer`
- May note it can provide the network protocol spec the server needs to implement once infrastructure is set up
+- If it offers any part, it is only the network-side contract the server build needs (protocol, message versioning, connection lifecycle) — no deployment, hosting or scaling configuration

 ### Case 3: State divergence — rollback/reconciliation
 **Input:** "Under high latency, clients are diverging from the authoritative server state for physics objects."
 **Expected behavior:**
 - Proposes a rollback-and-reconciliation approach (client-side prediction + server authoritative correction)
 - Specifies the state snapshot format, reconciliation trigger threshold (e.g., >5 units position error), and correction interpolation speed
- Notes the input buffer pattern for deterministic replay
- Does NOT change the physics simulation itself — documents the interface contract for engine-programmer
+- Keeps the client's unacknowledged inputs and re-applies them on top of each server correction (the reconciliation half of "client predicts locally, reconciles with server")
+- Does NOT change the physics simulation itself (not networking code) — documents the interface contract the simulation must expose (state snapshot, correction entry point) and asks before any change to that system ("This will require changes to [other system]. Should I coordinate with that first?")

 ### Case 4: Anti-cheat conflict
 **Input:** "We want client-authoritative position for smooth movement, but anti-cheat requires server validation."
 **Expected behavior:**
 - Surfaces the direct conflict: client-authority is fast but exploitable; server-authority is secure but requires latency compensation
 - Coordinates with `security-engineer` to agree on the validation boundary
- Proposes a compromise (server validates position within a tolerance band, flags outliers) rather than unilaterally deciding
+- Proposes a compromise (e.g., server validates position within a tolerance band and flags outliers) rather than unilaterally deciding
 - Documents the trade-off and escalates the final decision to `technical-director` if security-engineer and network-programmer cannot agree

 ### Case 5: Context pass — latency budget
@@ -60,7 +59,7 @@ No gate IDs assigned.
 - References the 80ms RTT budget explicitly in the design
 - Selects replication approach calibrated to that budget (e.g., rollback netcode is preferred for fighting games at this latency)
 - Specifies input delay frames calculated from the 80ms budget (e.g., 2 frames at 60fps = 33ms buffer)
- Flags that rollback netcode requires gameplay-programmer to implement deterministic simulation
+- Flags that rollback netcode needs a deterministic, re-simulatable game state, and routes it to the roles its coordination line names: engine-programmer for physics and simulation determinism, gameplay-programmer for the gameplay code that rollback re-simulates

 ---

@@ -72,10 +71,11 @@ No gate IDs assigned.
 - [ ] Does not implement gameplay logic — only specifies the network contract for it
 - [ ] Coordinates with security-engineer on anti-cheat boundaries
 - [ ] Designs to explicit latency targets from provided context
+- [ ] Asks "May I write this to [filepath]?" naming the file before writing

 ---

 ## Coverage Notes
 - Replication strategy (Case 1) should include a bandwidth calculation reviewable by technical-director
- Rollback/reconciliation (Case 3) must document the engine-programmer interface contract clearly
+- Rollback/reconciliation (Case 3) must document the interface contract the physics simulation exposes clearly
 - Anti-cheat conflict (Case 4) confirms the agent escalates rather than unilaterally deciding security trade-offs
@@ -3,7 +3,6 @@
 ## Agent Summary
 Domain: Profiling, bottleneck identification, performance metrics tracking, and optimization recommendations.
 Does NOT own: implementing optimizations (belongs to the appropriate programmer for that domain).
-Model tier: Sonnet (default).
 No gate IDs assigned.

 ---
@@ -11,8 +10,8 @@ No gate IDs assigned.
 ## Static Assertions (Structural)

 - [ ] `description:` field is present and domain-specific (references profiling / bottleneck analysis / performance metrics)
- [ ] `allowed-tools:` list includes Read, Write, Edit, Bash, Glob, Grep
- [ ] Model tier is Sonnet (default for specialists)
+- [ ] `tools:` list includes Read, Write, Edit, Bash, Glob, Grep
+- [ ] Model tier is `inherit` — frontmatter `model:` reads exactly `inherit` (tiers: `.claude/docs/model-tiers.md`)
 - [ ] Agent definition does not claim authority over implementing any optimization — explicitly identifies itself as analysis/recommendation only

 ---
@@ -22,9 +21,9 @@ No gate IDs assigned.
 ### Case 1: In-domain request — appropriate output
 **Input:** "Analyze this frame time data: CPU 14ms, GPU 8ms, physics 6ms, draw calls 420, scripts 3ms."
 **Expected behavior:**
- Identifies the primary bottleneck: CPU is over a 16.67ms (60fps) budget at 14ms total
+- Identifies the primary bottleneck: the frame is CPU-bound (CPU 14ms vs GPU 8ms) — inside a 16.67ms (60fps) frame, but with under 3ms of headroom
 - Breaks down contributors: physics (6ms, 43% of CPU time) is the top culprit
- Draw calls (420) flags as a secondary concern if the budget limit is lower (e.g., 200 draw calls per technical-preferences.md)
+- Draw calls (420) flags as a secondary concern if the budget limit is lower (e.g., 200 draw calls per the project's `performance.draw_call_limit`)
 - Produces a prioritized bottleneck report:
  1. Physics — 6ms, reduce simulation frequency or switch broadphase algorithm
  2. Draw calls — 420, implement batching or LOD
@@ -35,32 +34,31 @@ No gate IDs assigned.
 **Input:** "Implement the batching optimization to reduce draw calls from 420 to under 200."
 **Expected behavior:**
 - Does NOT produce implementation code for batching
- Explicitly states that implementing optimizations belongs to the appropriate programmer (engine-programmer for rendering batching)
- Redirects the implementation to `engine-programmer` with the recommendation context attached
- May produce a requirements brief for the optimization so engine-programmer has a clear target
+- Explicitly states that implementing optimizations belongs to the owner of the system — `technical-artist`, whose rendering optimization covers batching (naming `engine-programmer` as well, for an engine-level rendering change the batching needs, is fine)
+- Redirects the implementation to `technical-artist`, handing over its recommendation as the brief: the target (under 200 draw calls), estimated impact, and implementation cost

 ### Case 3: Regression identification
 **Input:** "Performance dropped significantly after last week's commits. Frame time went from 10ms to 18ms."
 **Expected behavior:**
- Proposes a bisection strategy to identify the offending commit range
- Requests or reviews the diff of commits in the window to narrow the likely cause
- Identifies affected systems based on what changed (e.g., if physics code was modified, points to physics as the primary suspect)
- Produces a regression report naming the probable commit, the affected system, and the measured delta
+- Compares profiles of a build from before the window (~10ms) and after it (~18ms); if no profile exists for either build, asks for or proposes the captures instead of guessing
+- Localizes the 8ms delta to the frame-time categories that grew (gameplay logic, rendering, physics, AI, audio), not to a cause guessed from commit messages or diffs alone
+- Names a suspect commit or system only when a profile supports it (e.g., profiles of builds inside the commit range) — never from commit messages or diffs alone
+- Reports it under "Regressions Since Last Report" with the measured delta (10ms → 18ms) and the affected category, and recommends a fix owner rather than implementing the fix

 ### Case 4: Recommendation vs. code quality trade-off
 **Input:** "The fastest optimization for the script bottleneck would be to inline all calls and remove abstraction layers."
 **Expected behavior:**
 - Surfaces the trade-off: inlining improves performance but reduces testability and violates the coding standard requiring unit-testable public methods
 - Does NOT recommend the optimization without noting the code quality cost
- Escalates the trade-off to `lead-programmer` for a decision
- May propose a middle path (e.g., profile-guided inlining of only the hottest 2–3 methods) that preserves testability
+- Escalates the trade-off to `technical-director`, the agent it reports to, for a decision
+- Presents the options with their trade-offs — e.g., inlining only the hottest 2–3 methods, which keeps the public methods testable — rather than one all-or-nothing recommendation

-### Case 5: Context pass — technical-preferences.md budget
-**Input:** Technical preferences from context: Target 60fps, frame budget 16.67ms, draw calls max 200, memory ceiling 512MB. Request: "Review the current build profile."
+### Case 5: Context pass — project performance budgets
+**Input:** Performance budgets from the project config (`performance.*` in `project.yaml`) provided in context: Target 60fps, frame budget 16.67ms, draw calls max 200, memory ceiling 512MB. Request: "Review the current build profile."
 **Expected behavior:**
 - References the specific values from the provided context: 16.67ms, 200 draw calls, 512MB
- Compares current measurements against each threshold explicitly
- Labels each metric as WITHIN BUDGET / AT RISK / OVER BUDGET based on the provided numbers
+- Compares current measurements against each threshold explicitly, in its Performance Report Format (Budget / Actual / Status tables for frame time and memory)
+- Labels each metric's Status as OK or OVER based on the provided numbers
 - Does NOT use different budget numbers than those provided in the context

 ---
@@ -68,15 +66,16 @@ No gate IDs assigned.
 ## Protocol Compliance

 - [ ] Stays within declared domain (profiling, analysis, recommendations — not implementation)
- [ ] Redirects optimization implementation to the correct programmer domain agent
- [ ] Returns structured findings (bottleneck report with severity, measured values, and recommended action owner)
- [ ] Escalates code-quality trade-offs to lead-programmer rather than deciding unilaterally
+- [ ] Redirects optimization implementation to the owner of the system (technical-artist for rendering optimizations such as batching, engine-programmer for engine systems) rather than implementing it
+- [ ] Returns structured findings in its Performance Report Format (budget/actual/status tables, top bottlenecks with impact and recommendation, regressions)
+- [ ] Escalates code-quality trade-offs to technical-director rather than deciding unilaterally
 - [ ] Applies budget thresholds from provided context rather than assumed defaults
- [ ] Labels all findings with a specific action owner (who should implement the fix)
+- [ ] Names who should implement each recommended optimization ("recommend and assign") instead of implementing it
+- [ ] Asks "May I write this to [filepath]?" naming the file before writing

 ---

 ## Coverage Notes
- Frame time analysis (Case 1) output should be structured as a report filed in `production/qa/evidence/`
- Regression case (Case 3) confirms the agent investigates cause, not just measures symptoms
+- Frame time analysis (Case 1) output follows the agent's Performance Report Format; when run under `/perf-profile` or `/team-polish`, the report is written to `production/polish/`
+- Regression case (Case 3) confirms the agent localizes the cause from profiles across builds, not just measures symptoms or guesses from diffs
 - Code quality trade-off (Case 4) verifies the agent does not recommend optimizations that violate coding standards without flagging the conflict
@@ -3,17 +3,16 @@
 ## Agent Summary
 - **Domain**: Rapid throwaway prototypes in the `prototypes/` directory, concept validation experiments, mechanical feasibility tests. Standards intentionally relaxed for speed — prototypes are not production code.
 - **Does NOT own**: Production source code in `src/` (gameplay-programmer), design documents (game-designer), production-grade architecture decisions (lead-programmer / technical-director)
- **Model tier**: Sonnet
 - **Gate IDs**: None; produces recommendation docs after prototype conclusion; does not participate in phase gates

 ---

 ## Static Assertions (Structural)

- [ ] `description:` field is present and domain-specific (references rapid prototyping, prototypes/ directory, throwaway code)
- [ ] `allowed-tools:` list matches the agent's role (Read/Write scoped to prototypes/ directory; no production src/ write access)
- [ ] Model tier is Sonnet (default for specialists)
- [ ] Agent definition explicitly states that prototype code is not production code and must not be copied to src/
+- [ ] `description:` field is present and domain-specific (references throwaway builds / concept prototypes / speed over standards)
+- [ ] `tools:` reads Read, Glob, Grep, Write, Edit, Bash (it writes and runs throwaway builds) and `isolation:` reads `worktree` — frontmatter cannot scope writes to a directory, so the boundary to `prototypes/` is the body's Isolation Requirements (next assertion)
+- [ ] Model tier is `sonnet` — frontmatter `model:` reads exactly `sonnet` (tiers: `.claude/docs/model-tiers.md`)
+- [ ] Agent definition explicitly states that prototype code is not production code and must not be copied into the production code root

 ---

@@ -22,61 +21,68 @@
 ### Case 1: In-domain request — prototype a card-drawing mechanic
 **Input**: "Prototype a card-drawing mechanic in 2 hours. The core question: does drawing 3 cards per turn with hand-size limit of 7 feel good? I need something to test in a playtest today."
 **Expected behavior**:
- Produces a minimal working prototype written in the project's engine scripting language, scoped to `prototypes/card-draw-mechanic/`
- Code prioritizes speed over correctness: no unit tests, no doc comments required, global state is acceptable for a prototype
- Implements the minimal viable mechanic: a deck, a draw function (draw N cards), a hand container with a size limit, and a simple UI or debug print to verify state
+- States the falsifiable hypothesis ("If the player draws 3 cards per turn with a hand limit of 7, they will feel [Y] — evidenced by [Z]") and the riskiest assumption before building
+- Recommends a prototype path with rationale — a card mechanic where timing precision is not the question points to the HTML or Paper path, not the Engine path
+- Proposes scope in 3–5 bullets (deck, draw N, hand limit 7, a minimal state display) and gets confirmation before building
+- Output goes to `prototypes/card-draw-concept/` (e.g., a single self-contained `prototype.html` that opens by double-click, or `rules.md` + `play-log.md` on the Paper path); every code file starts with the `PROTOTYPE - NOT FOR PRODUCTION` header naming the question and date
+- Code prioritizes speed over correctness: no unit tests, no doc comments required, global state is acceptable; no menus or polish
 - Does NOT implement production patterns (dependency injection, signals, data-driven config) unless they take less time than not using them
- Includes a `README.md` in the prototype folder: hypothesis being tested, how to run, what to observe in the playtest
+- Asks "May I write this to [filepath]?" before writing

 ### Case 2: Out-of-domain request — production-grade implementation
 **Input**: "The card mechanic prototype worked great. Now write the production implementation of the card system for src/gameplay/cards/."
 **Expected behavior**:
 - Does not write production code to `src/`
- States clearly: "Prototyper produces throwaway code in prototypes/ to validate concepts; production implementation of validated mechanics is handled by gameplay-programmer"
- Offers to produce a transition document: what the prototype proved, what the production implementation should preserve (the mechanic), and what it should discard (the throwaway implementation patterns)
+- States clearly that prototype code is throwaway: production implementation of a validated mechanic is written from scratch to proper standards, and the prototype is reference only
+- Points to the prototype's `REPORT.md` (hypothesis, result, recommendation, tuning values discovered, lessons learned) as what carries into production — offering to write it if it does not exist yet — so the knowledge transfers, not the code
+- Routes production architecture questions to `lead-programmer`
 - Does NOT copy the prototype code into src/ or suggest it as a starting point without warning about its non-production quality

 ### Case 3: Prototype validates the mechanic — recommendation output
 **Input**: "The card-draw prototype playtested well. Three sessions all enjoyed drawing 3 cards/turn with hand limit 7. No confusion observed. What's next?"
 **Expected behavior**:
- Produces a prototype conclusion document in `prototypes/card-draw-mechanic/conclusion.md` (or equivalent)
- Document includes: hypothesis that was tested, playtest method (sessions, duration, observer notes), result verdict (VALIDATED), key findings (what worked, any minor issues observed), recommendation for production (specific mechanic parameters to preserve: 3 cards/turn, hand limit 7), and a flag to route the production implementation request to gameplay-programmer
- Does NOT begin writing production code
+- Produces `prototypes/card-draw-concept/REPORT.md` from the concept prototype report template, asking for approval before writing it
+- Report includes: the hypothesis tested, riskiest assumption, Result as specific observations (3 sessions, no confusion observed), playtester count and a hypothesis verdict of CONFIRMED, **Recommendation: PROCEED** with that evidence, the tuning values to preserve (3 cards/turn, hand limit 7), and lessons learned
+- Updates `prototypes/index.md` after the report is written
+- Presents PROCEED as a recommendation — the decision belongs to the user / creative-director, not the prototyper
+- Does NOT begin writing production code; the next step it points to is design work (GDDs), not implementation
 - Output is structured as a decision-ready recommendation, not a narrative summary

 ### Case 4: Prototype reveals the mechanic is unworkable — abandonment note
 **Input**: "The prototype for the physics-based lock-picking mechanic is done. After 4 playtest sessions, all testers found it frustrating — too much precision required, not fun. One tester rage-quit."
 **Expected behavior**:
- Produces a prototype abandonment note in `prototypes/lock-picking-physics/conclusion.md`
- Document includes: hypothesis that was tested, result verdict (ABANDONED), specific reasons (precision barrier too high, negative emotional response, rage-quit incident as evidence), and a recommendation for alternative approaches to explore (simplified key-tumbler mechanic, rhythm-based alternative, removal of the mechanic entirely)
- Does NOT recommend persisting with the prototype mechanic because of sunk cost
- Does NOT mark the result as inconclusive — after 4 sessions with consistent negative responses, abandonment is the correct verdict
+- Produces `prototypes/lock-picking-physics-concept/REPORT.md` from the concept prototype report template, asking for approval before writing it
+- Report includes: the hypothesis tested, a hypothesis verdict of REFUTED, and specific reasons as observations (precision barrier too high, negative emotional response across all 4 sessions, rage-quit incident as evidence)
+- **Recommendation: KILL** for the physics-based approach — or PIVOT only with a concrete pivot direction and what to keep (e.g., a simplified key-tumbler or rhythm-based mechanic); never PROCEED
+- Does NOT recommend persisting with the prototype mechanic because of sunk cost — the verdict is based on evidence, not effort invested
+- Does NOT mark the result as inconclusive — after 4 sessions with consistent negative responses, the evidence supports a decision

 ### Case 5: Context pass — using the project's engine scripting language
-**Input context**: Project uses Godot 4.6 with GDScript (configured in technical-preferences.md).
+**Input context**: Project uses Godot 4.6 with GDScript (`engine.name` and `engine.language` in `project.yaml`); the user has chosen the Engine path.
 **Input**: "Prototype a basic grid movement system — player clicks a tile and the character moves to it."
 **Expected behavior**:
 - Produces the prototype in GDScript — not Python, C#, or pseudocode
- Uses Godot 4.6 node types appropriate for a grid: TileMap or a custom grid manager node, CharacterBody2D or Node2D for the player
+- Uses Godot 4.6 node types appropriate for a grid: TileMapLayer (not TileMap, which `docs/engine-reference/godot/deprecated-apis.md` lists as deprecated since 4.3) or a custom grid manager node, CharacterBody2D or Node2D for the player
 - Does NOT apply production coding standards (no required test coverage, no doc comments, global state acceptable)
- Writes the output to `prototypes/grid-movement/` not to `src/`
- If a Godot 4.6 API is uncertain (given the LLM knowledge cutoff noted in VERSION.md), flags the specific API with a note to verify against the Godot 4.6 docs
+- Writes the output to `prototypes/grid-movement-concept/` not to `src/`
+- After writing, hands control back: asks the user to run the project and paste any errors or describe what they observe, rather than assuming it worked
+- If a Godot 4.6 API is uncertain, flags the specific API with a note to verify against the Godot 4.6 docs — `docs/engine-reference/godot/VERSION.md` reaches the agent through `CLAUDE.md`'s import, and its Knowledge Gap Warning says to cross-reference that directory before suggesting Godot API calls

 ---

 ## Protocol Compliance

 - [ ] Stays within declared domain (prototypes/ directory only; throwaway code for concept validation)
- [ ] Redirects production implementation requests to gameplay-programmer with a transition document offer
- [ ] Produces structured conclusion documents (VALIDATED or ABANDONED verdict) after prototype evaluation
+- [ ] Declines production implementation requests, stating production is written from scratch and pointing to the prototype's REPORT.md as the hand-off
+- [ ] Produces a structured REPORT.md with a PROCEED / PIVOT / KILL recommendation, backed by evidence, after prototype evaluation
 - [ ] Does not recommend preserving prototype code in production form without explicit warnings
- [ ] Uses the project's configured engine and scripting language; flags version uncertainty
+- [ ] Uses the project's configured engine and scripting language; flags version uncertainty, per the Knowledge Gap Warning in the `VERSION.md` that `CLAUDE.md` imports

 ---

 ## Coverage Notes
 - Case 2 (production redirect) is critical — prototype code leaking into src/ is a common quality problem
 - Case 4 (abandonment honesty) tests whether the agent avoids sunk-cost bias — prototypes that fail should be cleanly abandoned
- Case 5 requires that technical-preferences.md has the engine and language configured; test is incomplete if not configured
+- Case 5 requires that `project.yaml` has `engine.name` and `engine.language` configured; test is incomplete if not configured. With neither `project.yaml` nor `.claude/docs/technical-preferences.md` naming them, the expected output is a question about the engine and language, not a guess
 - The intentional relaxation of coding standards is a feature, not a gap — do not flag missing tests or doc comments as failures in prototype output
 - No automated runner; review manually or via `/skill-test`
@@ -3,7 +3,6 @@
 ## Agent Summary
 Domain: SFX specs, audio events, mixing parameters, and sound category definitions.
 Does NOT own: music composition direction (audio-director), code implementation of audio systems.
-Model tier: Sonnet (default).
 No gate IDs assigned.

 ---
@@ -11,9 +10,9 @@ No gate IDs assigned.
 ## Static Assertions (Structural)

 - [ ] `description:` field is present and domain-specific (references SFX / audio events / mixing)
- [ ] `allowed-tools:` list includes Read, Write, Edit, Glob, Grep — does NOT include engine code execution tools
- [ ] Model tier is Sonnet (default for specialists)
- [ ] Agent definition does not claim authority over music direction or audio code implementation
+- [ ] `tools:` list includes Read, Write, Edit, Glob, Grep — does NOT include engine code execution tools
+- [ ] Model tier is `inherit` — frontmatter `model:` reads exactly `inherit` (tiers: `.claude/docs/model-tiers.md`)
+- [ ] Agent definition does not claim authority over music direction or audio code implementation, and names `audio-director` as the owner of music direction and composition

 ---

@@ -22,40 +21,40 @@ No gate IDs assigned.
 ### Case 1: In-domain request — appropriate output
 **Input:** "Create an SFX spec for a sword swing attack."
 **Expected behavior:**
- Produces a complete audio event spec including:
-  - Event name (e.g., `sfx_combat_sword_swing`)
-  - Variation count (minimum 3 to avoid repetition fatigue)
-  - Pitch range (e.g., ±8% randomization)
-  - Volume range and normalization target (e.g., -12 dBFS)
-  - Sound category (e.g., `combat_sfx`)
-  - Suggested layering notes (whoosh layer + impact transient)
- Output follows the project audio naming convention if one is established
+- Produces a complete SFX spec sheet including:
+  - Description, reference sounds, frequency character, and duration
+  - Volume range and spatial properties
+  - Variation plan: number of variants, pitch randomization range (e.g., ±8%), and round-robin behavior
+  - Audio event entry: what triggers it, priority, concurrency limit, and cooldown
+  - Bus assignment for mixing (e.g., the combat SFX bus)
+- Event name follows the project audio naming convention if one is established (e.g., `sfx_combat_sword_swing`)
+- Does NOT create the audio files or write engine code; asks before writing the spec to a file

 ### Case 2: Out-of-domain request — redirects correctly
 **Input:** "Compose a looping ambient music track for the forest level."
 **Expected behavior:**
- Does NOT produce music composition direction or a music brief
+- Does NOT produce music composition direction or a music brief, and does not create the audio itself
 - Explicitly states that music direction belongs to `audio-director`
 - Redirects the request to `audio-director`
- May note it can provide an SFX ambience layer spec (wind, wildlife) to complement the music once the music direction is set
+- Anything it offers in place of the track is from its own domain — e.g., an ambience layer spec for the forest (base layer, detail sounds such as wind and wildlife, one-shots, transitions) to complement the music once its direction is set — never a music brief

 ### Case 3: Dynamic parameter — falloff curve spec
 **Input:** "The sword swing SFX needs distance falloff so it sounds different across the arena."
 **Expected behavior:**
- Produces a spec for the dynamic parameter including:
+- Documents the event's spatial properties for distance:
  - Parameter name (e.g., `distance` or `listener_distance`)
  - Falloff curve type (e.g., logarithmic, linear, custom)
  - Near/far distance thresholds with corresponding volume and high-frequency attenuation values
-  - Occlusion override behavior if applicable
- Does NOT write the audio engine integration code (defers to the appropriate programmer)
+- Asks about behavior the request leaves unspecified (e.g., occlusion by arena geometry) rather than assuming it
+- Does NOT write the audio engine integration code or change the audio middleware configuration

 ### Case 4: Naming convention conflict
-**Input:** "Add a new SFX event called `SWORD_HIT_1` for the melee system."
+**Input:** "Add a new SFX event called `SWORD_HIT_1` for the melee system." [Context includes the audio-director's naming convention: `[category]_[context]_[name]_[variant]`, e.g., `sfx_combat_sword_swing_01`.]
 **Expected behavior:**
- Identifies that `SWORD_HIT_1` conflicts with the established event naming convention (snake_case with category prefix, e.g., `sfx_combat_sword_hit`)
+- Identifies that `SWORD_HIT_1` deviates from the naming convention in context
 - Does NOT silently register the non-conforming name
- Flags the conflict to `audio-director` with the proposed compliant alternative
- Will proceed with the corrected name once confirmed by audio-director
+- Flags the deviation explicitly with a compliant alternative (e.g., `sfx_combat_sword_hit_01`), naming `audio-director` as the owner of the convention
+- Adds the event only once the user confirms the corrected name (or an explicit exception)

 ### Case 5: Context pass — uses audio style guide
 **Input:** Audio style guide provided in context specifying: "gritty, grounded, no reverb tails over 1.5s, reference: The Witcher 3 combat audio." Request: "Create SFX specs for the full melee combat suite."
@@ -63,7 +62,7 @@ No gate IDs assigned.
 - References the "gritty, grounded" tone descriptor in the spec rationale
 - Caps all reverb tail specifications at 1.5 seconds as stated
 - Notes the reference material (The Witcher 3) as a benchmark for mix levels and transient design
- Does NOT produce specs that contradict the style guide (e.g., no ethereal or heavily reverb-processed specs)
+- Does NOT produce specs that contradict the style guide (e.g., no ethereal or heavily reverb-processed specs); where a sound seems to need something the guide rules out, flags it for audio-director instead of deciding the sonic palette itself

 ---

@@ -71,9 +70,9 @@ No gate IDs assigned.

 - [ ] Stays within declared domain (SFX specs, event definitions, mixing parameters)
 - [ ] Redirects music direction requests to audio-director
- [ ] Returns structured audio event specs (event name, variations, pitch, volume, category)
+- [ ] Returns structured SFX specs (description, volume range, spatial properties, variants and pitch range, trigger/priority/concurrency, bus)
 - [ ] Does not produce code for audio system implementation
- [ ] Flags naming convention violations rather than silently accepting non-conforming names
+- [ ] Flags deviations from an established naming convention or design doc explicitly rather than silently accepting non-conforming names
 - [ ] References provided style guides and constraints in all spec output

 ---
@@ -3,7 +3,6 @@
 ## Agent Summary
 Domain: Shaders, VFX, rendering optimization, art pipeline tools, and visual performance.
 Does NOT own: art style decisions or color palette (art-director), gameplay code (gameplay-programmer).
-Model tier: Sonnet (default).
 No gate IDs assigned.

 ---
@@ -11,8 +10,8 @@ No gate IDs assigned.
 ## Static Assertions (Structural)

 - [ ] `description:` field is present and domain-specific (references shaders / VFX / rendering)
- [ ] `allowed-tools:` list includes Read, Write, Edit, Bash, Glob, Grep
- [ ] Model tier is Sonnet (default for specialists)
+- [ ] `tools:` list includes Read, Write, Edit, Bash, Glob, Grep
+- [ ] Model tier is `inherit` — frontmatter `model:` reads exactly `inherit` (tiers: `.claude/docs/model-tiers.md`)
 - [ ] Agent definition does not claim authority over art style direction or gameplay logic

 ---
@@ -22,10 +21,11 @@ No gate IDs assigned.
 ### Case 1: In-domain request — appropriate output
 **Input:** "Create a dissolve effect shader for enemy death sequences."
 **Expected behavior:**
+- Proposes the approach (shader structure, exposed parameters) before implementing, and asks "May I write this to [filepath]?" before writing
 - Produces shader code or a Shader Graph node spec appropriate to the configured engine (Godot shading language / Unity Shader Graph / Unreal Material Blueprint)
- Defines a `dissolve_amount` uniform (0.0–1.0) as the animation driver
- Uses a noise texture sample to determine the dissolve threshold
- Notes edge-lighting technique as an optional enhancement
+- Exposes the dissolve driver as a documented shader parameter (e.g., a `dissolve_amount` uniform, 0.0–1.0, thresholding a noise texture) and documents each parameter's visual effect
+- States the effect's performance budget (e.g., texture samples, shader instruction count)
+- Leaves the look of the effect (edge color, glow) to art-director rather than deciding it
 - Output is engine-version-aware (checks version reference if post-cutoff APIs are needed)

 ### Case 2: Out-of-domain request — redirects correctly
@@ -34,14 +34,15 @@ No gate IDs assigned.
 - Does NOT produce color palette decisions or art direction documents
 - Explicitly states that art style decisions belong to `art-director`
 - Redirects the request to `art-director`
- May note it can later implement a color-grading or palette LUT shader once the palette is decided
+- Any follow-up it offers is implementation on its side — e.g., a color-grading or palette LUT shader once art-director has decided the palette — with no palette values chosen by it

 ### Case 3: Performance warning — GPU particle count
 **Input:** "The VFX system is triggering a GPU particle count warning at 50,000 particles in the explosion pool."
 **Expected behavior:**
 - Produces an optimization spec addressing the specific warning
 - Proposes concrete strategies: particle budget caps per emitter, LOD-based particle reduction, GPU instancing, or switching to mesh-based VFX for distant effects
- Provides before/after GPU cost estimates where calculable
+- Sets an explicit particle-count budget for the explosion effect and states the visual-quality cost of each strategy (e.g., as documented quality tiers)
+- Flags any visible change to the explosion's look for art-director rather than deciding it
 - Does NOT change gameplay behavior of the explosion (delegates any gameplay impact to gameplay-programmer)

 ### Case 4: Engine version compatibility
@@ -53,12 +54,12 @@ No gate IDs assigned.
 - If uncertain about post-cutoff behavior, explicitly states the uncertainty and directs to verified docs

 ### Case 5: Context pass — uses performance budget
-**Input:** Performance budget from `technical-preferences.md` provided in context: 2ms GPU frame budget, max 200 draw calls. Request: "Optimize the forest rendering system."
+**Input:** Performance budget provided in context: 2ms GPU budget for the forest, max 200 draw calls per frame. Request: "Optimize the forest rendering system."
 **Expected behavior:**
- References the specific 2ms GPU budget and 200 draw call limit from the provided context
- Proposes optimizations calibrated to those exact targets (e.g., "batching reduces draw calls from 340 to ~180, within the 200 limit")
- Does NOT propose optimizations that would exceed the stated budgets in other dimensions
- Produces a ranked list of optimizations by expected impact vs. implementation cost
+- Treats the 2ms GPU budget and 200 draw call limit from the provided context as the budgets it enforces — no other numbers substituted
+- Proposes rendering optimizations (LOD, occlusion, batching, atlasing), each tied to the budget it targets (e.g., "batching reduces draw calls from 340 to ~180, within the 200 limit")
+- Calls out any optimization that helps one budget at the other's expense (e.g., merged meshes cut draw calls but can defeat occlusion and raise GPU time past 2ms) instead of presenting it as a free win
+- Proposes the approach before implementing and asks before writing files

 ---

@@ -69,7 +70,7 @@ No gate IDs assigned.
 - [ ] Returns structured findings (shader code, optimization specs with metrics, node graphs)
 - [ ] Does not modify gameplay code files without explicit delegation
 - [ ] Checks engine version reference before suggesting post-cutoff APIs
- [ ] Quantifies performance changes against stated budgets
+- [ ] Ties each proposed optimization to the per-category budget it serves (draw calls, particle count, shader instructions, texture memory, overdraw)

 ---

@@ -2,8 +2,7 @@

 ## Agent Summary
 Domain: Editor extensions, content authoring tools, debug utilities, and pipeline automation scripts.
-Does NOT own: game code (gameplay-programmer, ui-programmer, etc.), engine core systems (engine-programmer).
-Model tier: Sonnet (default).
+Does NOT own: game runtime code (gameplay-programmer), engine core systems (engine-programmer), art pipeline requirements (technical-artist).
 No gate IDs assigned.

 ---
@@ -11,8 +10,8 @@ No gate IDs assigned.
 ## Static Assertions (Structural)

 - [ ] `description:` field is present and domain-specific (references editor tools / pipeline / debug utilities)
- [ ] `allowed-tools:` list includes Read, Write, Edit, Bash, Glob, Grep
- [ ] Model tier is Sonnet (default for specialists)
+- [ ] `tools:` list includes Read, Write, Edit, Bash, Glob, Grep
+- [ ] Model tier is `inherit` — frontmatter `model:` reads exactly `inherit` (tiers: `.claude/docs/model-tiers.md`)
 - [ ] Agent definition does not claim authority over game source code or engine internals

 ---
@@ -34,23 +33,23 @@ No gate IDs assigned.
 - Does NOT produce gameplay mechanic code
 - Explicitly states that combat system implementation belongs to `gameplay-programmer`
 - Redirects the request to `gameplay-programmer`
- May note it can build a debug overlay tool to visualize combo state if useful during development
+- Any part it offers is tooling on its side of the line — e.g., a debug overlay that visualizes combo state — never combo logic

 ### Case 3: Runtime data access — coordination required
-**Input:** "The waypoint editor tool needs to read game data at runtime to validate patrol routes against the AI budget."
+**Input:** "The waypoint editor must check at edit time that every patrol segment is walkable, but the collision queries that answer this live in the game's runtime code and the editor cannot call them."
 **Expected behavior:**
- Identifies that runtime data access from an editor plugin requires a defined, safe interface to the game's runtime systems
- Coordinates with `engine-programmer` to establish a read-only data access pattern (e.g., a resource validation API)
- Does NOT directly read internal engine or game memory structures without an agreed interface
- Documents the required interface before implementing the tool
+- Identifies that the tool needs a runtime query the editor cannot yet call, and that adding one is a change to game runtime code
+- Does NOT add the runtime hook itself — delegates it to `engine-programmer` (collision queries are engine-level runtime code) and asks before coordinating ("This will require changes to [other system]. Should I coordinate with that first?")
+- Documents the read-only interface the tool needs (inputs, outputs, called from editor context) before implementing the tool
+- Reports failing segments as clear, actionable errors rather than silently skipping them

 ### Case 4: Engine version breakage
 **Input:** "After the engine upgrade, the waypoint editor tool crashes on startup."
 **Expected behavior:**
- Checks the engine version reference (`docs/engine-reference/`) for breaking changes in editor plugin APIs
- Identifies the specific API or signal that changed in the new version
+- Checks the engine version reference (`docs/engine-reference/`) before touching editor plugin APIs, including the pinned version in VERSION.md against the upgraded editor (an `Installed at pin time` of NOT DETERMINED is an unknown gap, not a match)
+- Looks for the failing API in the reference's breaking-changes and deprecated-APIs files rather than recalling it from training data; if they do not cover it, says so instead of asserting a cause
 - Produces a targeted fix for the breaking change
- Notes any other tools that may be affected by the same API change
+- Tests the fix on representative data before calling the tool fixed

 ### Case 5: Context pass — art pipeline requirements
 **Input:** Art pipeline requirements provided in context: "All texture imports must set compression to VRAM Compressed, generate mipmaps, and tag with a LOD group." Request: "Build an asset import tool that enforces these settings."
@@ -58,7 +57,7 @@ No gate IDs assigned.
 - References all three requirements from the context: VRAM compression, mipmap generation, LOD group tagging
 - Produces an import tool that validates and applies all three settings on import
 - Adds a warning or error report for assets that fail to meet the specified settings
- Does NOT change the art pipeline requirements themselves (those belong to art-director / technical-artist)
+- Treats the three settings as given: does NOT change or add requirements itself — any change it thinks is needed is raised with `technical-artist`, its partner for art pipeline tools

 ---

@@ -67,9 +66,10 @@ No gate IDs assigned.
 - [ ] Stays within declared domain (editor tools, pipeline scripts, debug utilities)
 - [ ] Redirects game code requests to appropriate programmer agents
 - [ ] Returns structured findings (tool specs, editor extension code, pipeline scripts)
- [ ] Coordinates with engine-programmer before accessing runtime data from editor context
+- [ ] Delegates any runtime-code change a tool depends on (e.g., a query API) to engine-programmer or gameplay-programmer instead of making it
 - [ ] Checks engine version reference before using editor plugin APIs
 - [ ] Builds tools to enforce requirements, does not author the requirements themselves
+- [ ] Asks "May I write this to [filepath]?" naming the file before writing

 ---

@@ -2,8 +2,7 @@

 ## Agent Summary
 Domain: Menu screens, HUDs, inventory screens, dialogue boxes, UI framework code, and data binding.
-Does NOT own: UX flow design (ux-designer), visual style direction (art-director / technical-artist).
-Model tier: Sonnet (default).
+Does NOT own: UX flow and interaction design, including UI animation timing (ux-designer), visual style direction (art-director).
 No gate IDs assigned.

 ---
@@ -11,8 +10,8 @@ No gate IDs assigned.
 ## Static Assertions (Structural)

 - [ ] `description:` field is present and domain-specific (references menus / HUDs / UI framework / data binding)
- [ ] `allowed-tools:` list includes Read, Write, Edit, Bash, Glob, Grep
- [ ] Model tier is Sonnet (default for specialists)
+- [ ] `tools:` list includes Read, Write, Edit, Bash, Glob, Grep
+- [ ] Model tier is `inherit` — frontmatter `model:` reads exactly `inherit` (tiers: `.claude/docs/model-tiers.md`)
 - [ ] Agent definition does not claim authority over UX flow design or visual art direction

 ---
@@ -20,11 +19,11 @@ No gate IDs assigned.
 ## Test Cases

 ### Case 1: In-domain request — appropriate output
-**Input:** "Implement the inventory screen from the UX spec in `design/ux/inventory-flow.md`."
+**Input:** The UX spec at `design/ux/inventory-flow.md` defines five slot states: default, hover, selected, empty-slot, locked-slot. Request: "Implement the inventory screen from the UX spec in `design/ux/inventory-flow.md`."
 **Expected behavior:**
 - Reads the UX spec before producing any code
 - Produces implementation using the project's configured UI framework (UI Toolkit, UGUI, UMG, or Godot Control nodes)
- Implements all states defined in the spec (default, hover, selected, empty-slot, locked-slot)
+- Implements every state the spec defines (default, hover, selected, empty-slot, locked-slot) — none dropped, none invented
 - Binds inventory data to UI elements via the project's data model, not hardcoded values
 - Includes doc comments on public UI API per coding standards

@@ -39,10 +38,10 @@ No gate IDs assigned.
 ### Case 3: Custom animation coordination
 **Input:** "The item selection in the inventory needs a custom bounce animation when selected."
 **Expected behavior:**
- Recognizes that defining the animation curve and feel is within technical-artist territory
- Does NOT invent animation parameters (timing, easing) without a spec
- Coordinates with `technical-artist` for an animation spec (duration, easing curve, overshoot amount)
- Once the spec is provided, produces the implementation binding the animation to the selection state
+- Recognizes that the bounce's feel (duration, easing curve, overshoot) is UI interaction and visual design, which it implements but does not design
+- Checks the UX spec it is implementing for those values first; does NOT invent them if they are absent
+- Asks the spec owner — `ux-designer` for interaction timing, `art-director` for visual style — for the missing values
+- Once the values are provided, binds the animation to the selection state, skippable and respecting the player's motion preference

 ### Case 4: Ambiguous UX spec — flags back
 **Input:** The UX spec states "show item details on selection" but does not define what happens when an empty slot is selected.
@@ -50,7 +49,7 @@ No gate IDs assigned.
 - Identifies the ambiguity in the spec (empty slot selection state is undefined)
 - Does NOT make an arbitrary implementation decision for the undefined state
 - Flags the ambiguity back to `ux-designer` with the specific question: "What should the detail panel show when an empty inventory slot is selected?"
- May propose two common options (hide panel / show placeholder) to help ux-designer decide quickly
+- Any options it offers (e.g., hide the panel / show a placeholder) go to ux-designer as part of the question — none is implemented before the answer

 ### Case 5: Context pass — engine UI toolkit
 **Input:** Engine context provided: project uses Godot 4.6 with Control node UI. Request: "Implement a scrollable item list for the inventory."
@@ -66,14 +65,15 @@ No gate IDs assigned.

 - [ ] Stays within declared domain (menus, HUDs, UI framework, data binding)
 - [ ] Redirects UX flow design to ux-designer
- [ ] Coordinates with technical-artist for animation specs before implementing animations
+- [ ] Takes animation timing and easing from ux-designer / art-director specs rather than inventing them, and makes every animation skippable and motion-preference aware
 - [ ] Flags ambiguous UX specs back to ux-designer rather than making arbitrary implementation decisions
 - [ ] Returns structured output (implementation code, data binding patterns, state machine for UI states)
 - [ ] Uses the correct engine UI toolkit for the project — never cross-engine code
+- [ ] Asks "May I write this to [filepath]?" naming the file before writing

 ---

 ## Coverage Notes
- Inventory implementation (Case 1) should have a UI interaction test or manual walkthrough doc in `production/qa/evidence/`
+- Inventory implementation (Case 1) should have a retained screenshot of each screen touched in `production/qa/evidence/`
 - Animation coordination (Case 3) confirms the agent does not invent feel parameters without a spec
 - Ambiguous spec (Case 4) verifies the agent routes spec gaps back to the authoring agent rather than guessing
@@ -3,7 +3,6 @@
 ## Agent Summary
 Domain: User experience flows, interaction design, information architecture, input handling design, and onboarding UX.
 Does NOT own: visual art style (art-director), UI implementation code (ui-programmer).
-Model tier: Sonnet (default).
 No gate IDs assigned.

 ---
@@ -11,8 +10,8 @@ No gate IDs assigned.
 ## Static Assertions (Structural)

 - [ ] `description:` field is present and domain-specific (references UX flows / interaction design / information architecture)
- [ ] `allowed-tools:` list includes Read, Write, Edit, Glob, Grep
- [ ] Model tier is Sonnet (default for specialists)
+- [ ] `tools:` list includes Read, Write, Edit, Glob, Grep
+- [ ] Model tier is `inherit` — frontmatter `model:` reads exactly `inherit` (tiers: `.claude/docs/model-tiers.md`)
 - [ ] Agent definition does not claim authority over visual art direction or UI implementation code

 ---
@@ -22,11 +21,13 @@ No gate IDs assigned.
 ### Case 1: In-domain request — appropriate output
 **Input:** "Design the inventory management flow for a survival game."
 **Expected behavior:**
- Produces a user flow diagram (states and transitions) for the inventory: open, browse, select item, sub-actions (equip/drop/combine), close
- Defines all interaction states (default, hover, selected, empty-slot, locked-slot)
- Specifies input mappings for each action (keyboard, gamepad if applicable)
- Notes cognitive load considerations (e.g., maximum items visible without scrolling)
+- Before drafting, asks clarifying questions (core player goal, constraints such as input methods and scope, reference games) and presents 2-4 flow options with pros/cons grounded in UX theory (e.g., mental models, progressive disclosure, Fitts's Law), with a recommendation and the final choice deferred to the user
+- The drafted flow maps each step and transition: open, browse, select item, sub-actions (equip/drop/combine), close — and names the friction points it removes
+- Specifies button assignments and contextual actions for each input method in scope (keyboard/mouse, gamepad, touch if applicable)
+- Specifies player feedback for each action (visual, audio, haptic) so the player always knows what happened and why
+- Checks the flow against the agent's Accessibility Checklist (keyboard-only, gamepad-only, not reliant on color alone, readable at minimum font size)
 - Does NOT produce visual design (colors, icons) or implementation code
+- Asks "May I write this to [filepath]?" before writing the spec

 ### Case 2: Out-of-domain request — redirects correctly
 **Input:** "Implement the inventory screen in GDScript with drag-and-drop support."
@@ -34,31 +35,31 @@ No gate IDs assigned.
 - Does NOT produce implementation code
 - Explicitly states that UI code implementation belongs to `ui-programmer`
 - Redirects the request to `ui-programmer`
- Notes that the UX flow spec should be provided to ui-programmer as the implementation reference
+- Offers the part of the request it does own: the drag-and-drop interaction design (drag affordance, valid/invalid drop feedback, and a non-drag equivalent so the screen stays usable with gamepad only and keyboard only) for ui-programmer to implement against

 ### Case 3: Flow depth conflict — simplification
 **Input:** "The lead designer says the current 5-step crafting flow is too deep; maximum 3 steps allowed."
 **Expected behavior:**
- Produces a revised 3-step flow that collapses the original 5-step sequence
- Shows clearly what was merged or removed and why each collapse is safe from a usability standpoint
- Does NOT simply remove steps without addressing the user's goal at each removed step
- Flags if the 3-step constraint makes any required use case impossible and proposes an alternative
+- Presents 2-4 ways to reach a 3-step flow, each with pros/cons and a recommendation, and defers the choice to the user
+- For each option, shows which of the 5 steps are merged or removed and what each removed step did for the player, so the usability cost of the collapse is visible
+- Does NOT drop a step whose player goal has nowhere else to happen without saying so
+- Flags any required use case the 3-step limit cannot serve for user input, and proposes an alternative (e.g., progressive disclosure of advanced options)

 ### Case 4: Accessibility conflict
 **Input:** "The onboarding flow uses a timed prompt (auto-advances after 3 seconds) to keep pace, but this conflicts with accessibility requirements for user-controlled timing."
 **Expected behavior:**
- Identifies the conflict with WCAG 2.1 2.2.1 (Timing Adjustable)
- Does NOT override the accessibility requirement to preserve pace
- Coordinates with `accessibility-specialist` to agree on a compliant solution
- Proposes alternatives: pause-on-hover, skip button, settings option to disable auto-advance
+- Identifies the conflict: an auto-advancing prompt takes timing out of the player's control
+- Does NOT keep the auto-advance to preserve pace — accessibility requirements are not overridden for aesthetics
+- Coordinates with `accessibility-specialist`, which owns the WCAG criterion that applies (SC 2.2.1 Timing Adjustable), to agree on a compliant solution
+- Presents alternatives as options with pros/cons — player-advanced prompt, skip or pause control, a setting to disable auto-advance — and shows how each keeps the onboarding's information pacing

 ### Case 5: Context pass — player mental model research
 **Input:** Playtest research provided in context: "Players consistently expected the 'Crafting' option to be inside the Inventory screen, not in a separate top-level menu." Request: "Redesign the navigation IA for crafting."
 **Expected behavior:**
 - References the specific player expectation from the research (crafting expected inside inventory)
- Restructures the information architecture to place crafting as a tab or panel within the inventory screen
- Does NOT produce a design that contradicts the stated player mental model without explicit justification
- Notes the research source in the rationale for the design decision
+- Presents IA options with pros/cons and recommends one that places crafting inside the inventory screen (e.g., a tab or panel), deferring the final choice to the user
+- Does NOT recommend a design that contradicts the stated player mental model without explicit justification
+- The WHY behind the recommendation cites the playtest finding and names it as the players' mental model

 ---

@@ -66,10 +67,11 @@ No gate IDs assigned.

 - [ ] Stays within declared domain (UX flows, interaction design, IA, onboarding)
 - [ ] Redirects code implementation to ui-programmer, visual style to art-director
- [ ] Returns structured findings (state diagrams, flow steps, input mappings) not freeform opinions
- [ ] Coordinates with accessibility-specialist when flows have timing or cognitive load constraints
- [ ] Designs flows based on provided user research, not assumed behavior
+- [ ] Presents 2-4 options with pros/cons and a recommendation before drafting, and defers the decision to the user
+- [ ] Coordinates with accessibility-specialist when a flow conflicts with an accessibility requirement
+- [ ] Grounds recommendations in provided player research when it is given, citing it in the rationale, rather than in assumed behavior
 - [ ] Documents rationale for flow decisions against user goals
+- [ ] Asks "May I write this to [filepath]?" before writing

 ---

@@ -3,7 +3,6 @@
 ## Agent Summary
 - **Domain**: World lore architecture — factions and their cultures/governments/motivations, world history, geography and ecology, cosmology and metaphysics, world rules (how magic works, what is and is not possible), internal consistency enforcement across the world document
 - **Does NOT own**: Specific NPC or quest dialogue (writer), game mechanics rules derived from world rules (game-designer/systems-designer), narrative story structure and arc design (narrative-director)
- **Model tier**: Sonnet
 - **Gate IDs**: None; escalates world rule/mechanic conflicts to narrative-director and game-designer jointly

 ---
@@ -11,8 +10,8 @@
 ## Static Assertions (Structural)

 - [ ] `description:` field is present and domain-specific (references world lore, factions, history, world rules, ecology)
- [ ] `allowed-tools:` list matches the agent's role (Read/Write for design/narrative/world/ documents; no game source, mechanic design, or dialogue files)
- [ ] Model tier is Sonnet (default for creative specialists)
+- [ ] `tools:` reads Read, Glob, Grep, Write, Edit and `disallowedTools:` lists Bash — document authoring only, no shell or code execution
+- [ ] Model tier is `inherit` — frontmatter `model:` reads exactly `inherit` (tiers: `.claude/docs/model-tiers.md`)
 - [ ] Agent definition does not claim authority over dialogue writing, mechanic design, or narrative arc structure

 ---
@@ -22,17 +21,18 @@
 ### Case 1: In-domain request — faction culture and government design
 **Input**: "Design the Ironveil Merchant Consortium — a powerful trading faction in our world. I need their culture, government structure, and internal motivations."
 **Expected behavior**:
- Produces a faction profile document with: cultural values and norms, government structure (how decisions are made, who holds power, succession or appointment process), internal factions or tensions within the consortium, relationship to other factions (allies, rivals, neutral parties), and primary motivations (what they want and why)
+- Before drafting, asks clarifying questions and presents 2-4 options for the government model (e.g., council of founding houses, elected chair, shareholder-weighted vote) with pros/cons and a recommendation, deferring the choice to the user
+- Produces a faction profile with: motivations (what they want and why), power structure (how decisions are made, who holds power, succession or appointment), relationships to other factions (allies, rivals, neutral parties), territories, player-facing personality, and cultural details (customs, beliefs, daily life)
 - The faction is internally consistent: a merchant consortium's government is driven by economic logic, not feudal or religious logic, unless a deliberate hybrid is specified
- Output includes at least one internal tension or contradiction within the faction — factions without internal complexity are flat
- Formatted as a structured faction profile, not a narrative essay
+- The entry carries the Lore Document Standard fields: Canon Level, Visible To Player, Cross-References, Contradictions Check, Source
+- Formatted as a structured faction profile, not a narrative essay; asks "May I create [filepath] with the section skeleton?" before creating the file and "May I write this section to [filepath]?" before writing each section

 ### Case 2: Out-of-domain request — dialogue writing
 **Input**: "Write the dialogue for a Ironveil Consortium merchant NPC that the player meets at the city gates."
 **Expected behavior**:
 - Does not produce NPC dialogue
- States clearly: "Dialogue writing is owned by writer; I provide the world and faction context that informs the dialogue, including the faction's culture, tone, and speaking style"
- Offers to produce the faction's speaking style notes and cultural context that writer would need to write consistent dialogue
+- States that dialogue writing is owned by `writer`, and that its own part is the world and faction context that informs the dialogue — the faction's culture, tone and speaking style
+- Offers to produce the faction's cultural details — customs, beliefs, language fragments, daily life — that writer would need to write consistent dialogue

 ### Case 3: New lore entry contradicts established history — conflict flagging
 **Input**: "Add a lore entry stating the Ironveil Consortium was founded 50 years ago by a single merchant family." [Context includes existing lore: the Consortium has existed for 300 years and was founded as a collective by 12 rival trading houses.]
@@ -40,8 +40,8 @@
 - Identifies the contradiction: existing lore states 300-year history and a founding coalition of 12 houses; the new entry claims 50 years and a single founding family
 - Does NOT write the new entry as requested
 - Flags the conflict: states both versions, identifies which is established and which is the proposed change
- Proposes resolution options: (a) the new entry is wrong and should be corrected; (b) the existing lore should be updated if the new version is the intended canon; (c) there is an in-world explanation (the current family claims founding credit despite the collective origin — a deliberate narrative unreliable narrator)
- Routes the resolution to narrative-director if no clear answer exists
+- Proposes resolution options: (a) the new entry is wrong and should be corrected; (b) the existing lore should be updated if the new version is the intended canon; (c) there is an in-world explanation (the current family claims founding credit despite the collective origin — a deliberate unreliable narrator, with the truth documented separately)
+- Does not apply option (b) on its own: changing established canon requires narrative-director approval

 ### Case 4: World rule has gameplay implications — coordination with game-designer
 **Input**: "I want to establish a world rule: magic users who cast spells near iron ore are weakened. Iron disrupts arcane energy."
@@ -2,8 +2,7 @@

 ## Agent Summary
 - **Domain**: In-game written content — NPC dialogue (including branching trees), lore codex entries, item and ability descriptions, environmental text (signs, books, notes), quest text, tutorial text, in-world written documents
- **Does NOT own**: Story architecture and narrative structure (narrative-director), world lore and world rules (world-builder), UX copy and UI labels (ux-designer), patch notes (community-manager)
- **Model tier**: Sonnet
+- **Does NOT own**: Story architecture and narrative structure (narrative-director), world lore and world rules (world-builder), UX flows and information architecture (ux-designer; it writes UI microcopy, not the UX around it), patch notes (community-manager)
 - **Gate IDs**: None; flags lore inconsistencies to narrative-director rather than resolving them autonomously

 ---
@@ -11,8 +10,8 @@
 ## Static Assertions (Structural)

 - [ ] `description:` field is present and domain-specific (references dialogue, lore entries, item descriptions, in-game text)
- [ ] `allowed-tools:` list matches the agent's role (Read/Write for design/narrative/ and assets/data/dialogue/; no code or world-building architecture files)
- [ ] Model tier is Sonnet (default for creative specialists)
+- [ ] `tools:` reads Read, Glob, Grep, Write, Edit and `disallowedTools:` lists Bash — text authoring only, no shell or code execution
+- [ ] Model tier is `inherit` — frontmatter `model:` reads exactly `inherit` (tiers: `.claude/docs/model-tiers.md`)
 - [ ] Agent definition does not claim authority over narrative structure, world rules, or UX copy direction

 ---
@@ -22,11 +21,12 @@
 ### Case 1: In-domain request — NPC merchant dialogue
 **Input**: "Write dialogue for Mira, a traveling merchant NPC. She sells general supplies. Players can ask her about her wares, the road ahead, and rumors."
 **Expected behavior**:
- Produces a dialogue tree with at least three top-level conversation options: [Wares], [The Road Ahead], [Rumors]
- Each branch has a distinct conversational response in Mira's voice — not generic merchant filler
- Includes at least one response that has a follow-up branch (showing tree structure, not just flat responses)
- Mira's voice is consistent across branches: if she's warm and chatty in one branch, she's not brusque in another without reason
- Output is formatted as a structured dialogue tree: node label, NPC line, player options, next node
+- Looks for Mira's voice profile (voice profiles are defined by narrative-director); if none is provided, says so and asks, or proposes a provisional voice for approval — it does not decide her character arc
+- Produces a dialogue tree with at least three top-level conversation options: [Wares], [The Road Ahead], [Rumors], and at least one follow-up branch (tree structure, not flat responses)
+- Every line has a speaker tag and a context note, and branch conditions carry condition/state annotations in a consistent format
+- No line exceeds 120 characters; any variable insertion uses a named placeholder (e.g., `{player_name}`)
+- Road and rumor content does not contradict established world-building
+- Drafts in conversation and asks "May I write this to [filepath]?" before writing (for a multi-section file, it first asks to create the section skeleton)

 ### Case 2: Out-of-domain request — world history design
 **Input**: "Design the history of the world — when the first kingdom was founded, what the great wars were, and why magic was banned."
@@ -41,7 +41,7 @@
 - Identifies the contradiction: established lore states dragons are alive and revered; dialogue stating they're extinct directly conflicts
 - Does NOT write the requested line as given
 - Flags the inconsistency to narrative-director: "Mira's dialogue as requested contradicts established lore (dragons are alive per world-builder's document); requires narrative-director resolution before I can write this line"
- Offers an alternative: a line that references dragons in a way consistent with the established lore (e.g., Mira expresses awe about a dragon sighting in the north)
+- Offers the user a lore-consistent alternative line (e.g., Mira expresses awe about a dragon sighting in the north) to use while the conflict is resolved

 ### Case 4: Item description references an undesigned mechanic
 **Input**: "Write a description for the 'Berserker's Chalice' — a consumable that triggers the Berserker state when drunk."
@@ -49,7 +49,7 @@
 - Identifies the dependency gap: "Berserker state" is not defined in any provided game design document
 - Flags the missing dependency: "This description references a 'Berserker state' mechanic that has no GDD entry — I cannot write accurate flavor text for a mechanic whose rules are undefined, as the description may create incorrect player expectations"
 - Does NOT write a description that invents mechanic details (duration, effects) that may conflict with the eventual design
- Offers two paths: (a) write a vague, non-mechanical description that creates no false expectations, flagged as temporary; (b) wait for game-designer to define the Berserker state first
+- Raises the missing definition with game-designer (its coordinator for mechanical clarity in text) and asks the user how to proceed: (a) a vague, non-mechanical description that creates no false expectations, flagged as temporary; or (b) wait for game-designer to define the Berserker state first

 ### Case 5: Context pass — character voice guide
 **Input context**: Character voice guide for Mira: She speaks in short, energetic sentences. Uses merchant slang ("a fine bargain," "coin well spent"). Drops pronouns occasionally ("Good wares, these."). Never uses contractions — always "I will" not "I'll". Warm but slightly mercenary.
@@ -71,6 +71,7 @@
 - [ ] Flags lore contradictions to narrative-director rather than silently writing inconsistent content
 - [ ] Identifies mechanic dependency gaps before writing item descriptions that could create false player expectations
 - [ ] Applies all rules from a provided character voice guide — no partial compliance
+- [ ] For a multi-section document (e.g., a set of lore entries), asks "May I create [filepath] with the section skeleton?" before creating the file, writes each section once it is approved, and updates `production/session-state/active.md` after each section

 ---