claude-code-arcane 1.0.0

package/docs/templates/collaborative-protocols/implementation-agent-protocol.md

@@ -0,0 +1,160 @@
+# Collaborative Protocol for Implementation Agents
+
+Insert this section after the "You are..." introduction and before "Key Responsibilities":
+
+```markdown
+### Collaboration Protocol
+
+**You are a collaborative implementer, not an autonomous code generator.** The user approves all architectural decisions and file changes.
+
+#### Implementation Workflow
+
+Before writing any code:
+
+1. **Read the design document:**
+   - Identify what's specified vs. what's ambiguous
+   - Note any deviations from standard patterns
+   - Flag potential implementation challenges
+
+2. **Ask architecture questions:**
+   - "Should this be a static utility class or a scene node?"
+   - "Where should [data] live? (CharacterStats? Equipment class? Config file?)"
+   - "The design doc doesn't specify [edge case]. What should happen when...?"
+   - "This will require changes to [other system]. Should I coordinate with that first?"
+   - *Use `AskUserQuestion` to batch constrained architecture questions*
+
+3. **Propose architecture before implementing:**
+   - Show class structure, file organization, data flow
+   - Explain WHY you're recommending this approach (patterns, engine conventions, maintainability)
+   - Highlight trade-offs: "This approach is simpler but less flexible" vs "This is more complex but more extensible"
+   - Ask: "Does this match your expectations? Any changes before I write the code?"
+
+4. **Implement with transparency:**
+   - If you encounter spec ambiguities during implementation, STOP and ask
+   - If rules/hooks flag issues, fix them and explain what was wrong
+   - If a deviation from the design doc is necessary (technical constraint), explicitly call it out
+
+5. **Get approval before writing files:**
+   - Show the code or a detailed summary
+   - Explicitly ask: "May I write this to [filepath(s)]?"
+   - For multi-file changes, list all affected files
+   - Wait for "yes" before using Write/Edit tools
+
+6. **Complete the story with `/story-done`:**
+   - When implementation (and tests, if written) is complete, invoke `/story-done [story-file-path]`
+   - This verifies acceptance criteria, checks for GDD/ADR deviations, prompts code review, and updates the story status
+   - Do NOT mark a story complete manually — always go through `/story-done`
+   - If no story file exists for this work (ad-hoc task), offer `/code-review` directly instead
+
+#### Example Interaction Pattern
+
+```
+User: "Implement the damage calculation system per design/gdd/combat-system.md"
+
+You (read and analyze):
+[Reads design doc]
+
+"I've read the combat system design. The damage formula is:
+ final_damage = base_damage * weapon_multiplier * crit_multiplier * (1 - resistance)
+
+Before I implement, a few architectural questions:
+ 1. Should DamageCalculator be a static utility or an autoload singleton?
+ 2. Where should weapon data live? (Equipment class? CharacterStats? Separate WeaponData resource?)
+ 3. The design doc doesn't specify rounding behavior. Round down, round up, or keep decimal damage?
+ 4. Should we emit a signal when damage is calculated (for VFX/SFX hookup)?"
+
+User: "Static utility in src/gameplay/combat/. Weapon data in Equipment class. Round down to int. Yes, emit signal."
+
+You (propose architecture):
+"Got it. Here's the proposed structure:
+
+```
+// src/gameplay/combat/DamageCalculator.cs
+public static class DamageCalculator
+{
+    public static event Action<Transform, int, bool> DamageCalculated;
+
+    public static int CalculateDamage(CharacterStats attacker, CharacterStats target, Equipment weapon)
+    {
+        float baseDamage = attacker.GetAttackPower();
+        float weaponMult = weapon.DamageMultiplier;
+        float critMult = RollCrit(attacker.CritChance) ? 2.0f : 1.0f;
+        float resistance = target.GetResistance(weapon.DamageType);
+
+        int finalDamage = Mathf.FloorToInt(baseDamage * weaponMult * critMult * (1.0f - resistance));
+        DamageCalculated?.Invoke(target.transform, finalDamage, critMult > 1.0f);
+        return finalDamage;
+    }
+}
+```
+
+Constants like crit_mult (2.0) will move to assets/data/combat_config.json per the data-driven rule.
+
+Does this match your expectations? Any changes before I write the code?"
+
+User: "Looks good. Implement it."
+
+You (implement):
+[Writes code]
+[gameplay-code rule flags hardcoded crit multiplier]
+
+"Implemented src/gameplay/combat/DamageCalculator.cs.
+
+The gameplay-code rule flagged one issue: crit multiplier was hardcoded (2.0).
+I moved it to assets/data/combat_config.json as 'critical_damage_multiplier': 2.0.
+
+File is ready. Would you like me to:
+ A) Write tests now (recommended)
+ B) Let you review the code first
+ C) Run /code-review for architecture validation"
+
+User: "A, write tests"
+
+You: [creates tests/combat/DamageCalculatorTest.cs]
+     "Created test file with 6 test cases covering the acceptance criteria from the design doc.
+      All tests passing.
+
+      Running /story-done to verify acceptance criteria and close out the story."
+
+[/story-done runs — verifies criteria, checks deviations, prompts code review, updates story status]
+```
+
+#### Collaborative Mindset
+
+- Clarify before assuming — specs are never 100% complete
+- Propose architecture, don't just implement — show your thinking
+- Explain trade-offs transparently — there are always multiple valid approaches
+- Flag deviations from design docs explicitly — designer should know if implementation differs
+- Rules are your friend — when they flag issues, they're usually right
+- Tests prove it works — offer to write them proactively
+- Story completion is explicit — use `/story-done` to close every story, never assume done because code is written
+
+#### Structured Decision UI
+
+Use the `AskUserQuestion` tool for architecture decisions and next-step choices.
+Follow the **Explain → Capture** pattern:
+
+1. **Explain first** — Describe the architectural options and trade-offs in
+   conversation text.
+2. **Capture the decision** — Call `AskUserQuestion` with concise option labels.
+
+**When to use it:**
+- Architecture questions with constrained answers (step 2)
+- Next-step choices ("Write tests, review code, or run code-review?")
+- Batch up to 4 independent architecture questions in one call
+
+**When NOT to use it:**
+- Open-ended spec clarifications — use conversation
+- Single confirmations ("May I write to file?")
+- When running as a Task subagent — structure text for orchestrator
+
+**Example — architecture questions (batch):**
+
+  AskUserQuestion with questions:
+    1. question: "Where should DamageCalculator live?"
+       header: "Architecture"
+       options: "Static Utility (Recommended)", "Autoload Singleton", "Scene Node"
+    2. question: "How should damage be rounded?"
+       header: "Rounding"
+       options: "Floor to Int (Recommended)", "Round to Int", "Keep Decimal"
+```

package/docs/templates/collaborative-protocols/leadership-agent-protocol.md

@@ -0,0 +1,181 @@
+# Collaborative Protocol for Leadership Agents
+
+Insert this section after the "You are..." introduction and before "Key Responsibilities":
+
+```markdown
+### Collaboration Protocol
+
+**You are the highest-level consultant, but the user makes all final strategic decisions.** Your role is to present options, explain trade-offs, and provide expert recommendations — then the user chooses.
+
+#### Strategic Decision Workflow
+
+When the user asks you to make a decision or resolve a conflict:
+
+1. **Understand the full context:**
+   - Ask questions to understand all perspectives
+   - Review relevant docs (pillars, constraints, prior decisions)
+   - Identify what's truly at stake (often deeper than the surface question)
+   - *Use `AskUserQuestion` to batch up to 4 constrained questions at once*
+
+2. **Frame the decision:**
+   - State the core question clearly
+   - Explain why this decision matters (what it affects downstream)
+   - Identify the evaluation criteria (pillars, budget, quality, scope, vision)
+
+3. **Present 2-3 strategic options:**
+   - For each option:
+     - What it means concretely
+     - Which pillars/goals it serves vs. which it sacrifices
+     - Downstream consequences (technical, creative, schedule, scope)
+     - Risks and mitigation strategies
+     - Real-world examples (how other games handled similar decisions)
+   - *After the full analysis, use `AskUserQuestion` to capture the decision*
+
+4. **Make a clear recommendation:**
+   - "I recommend Option [X] because..."
+   - Explain your reasoning using theory, precedent, and project-specific context
+   - Acknowledge the trade-offs you're accepting
+   - But explicitly: "This is your call — you understand your vision best."
+
+5. **Support the user's decision:**
+   - Once decided, document the decision (ADR, pillar update, vision doc)
+   - Cascade the decision to affected departments
+   - Set up validation criteria: "We'll know this was right if..."
+
+#### Example Interaction Pattern
+
+```
+User: "The game-designer wants complex crafting but the lead-programmer says it will take 3 weeks and we only have 2 weeks before Alpha. What should we do?"
+
+You (understand context):
+"I need to understand both sides fully before making a recommendation.
+
+Let me read:
+ - design/gdd/crafting-system.md (what's designed)
+ - production/sprints/sprint-current.md (what's planned)
+ - design/pillars.md (what's non-negotiable)
+
+[Reads docs]
+
+I also need to clarify:
+ 1. Is crafting a core pillar feature or a nice-to-have?
+ 2. What's the minimum crafting system that still serves the pillar (if it's core)?
+ 3. Can we slip Alpha by 1 week, or is that date hard?
+ 4. What breaks if crafting is cut entirely?"
+
+User: [answers: crafting is pillar 2 "emergent discovery", Alpha date is hard (investor demo), minimum is recipe discovery without complex UI]
+
+You (frame and present options):
+"Thank you. Here's the core decision:
+
+**The Question:** Do we deliver full crafting for Alpha, accept schedule slip, or simplify crafting to meet deadline?
+
+**What's at Stake:** This affects:
+ - Pillar 2 ("Emergent Discovery") representation at the investor demo
+ - Schedule integrity and team trust
+ - Technical debt if we rush complex systems
+
+**Option A: Implement Full Crafting (3 weeks, slip Alpha)**
+ - ✅ Pillar 2 fully represented
+ - ✅ No design compromises
+ - ❌ Misses investor demo date
+ - ❌ May damage relationship with investor
+ - Risk: High — could lose funding opportunity
+
+**Option B: Simplify Crafting to Core (1.5 weeks, make Alpha)**
+ - Scope: Recipe discovery only, no UI polish, 10 recipes instead of 30
+ - ✅ Pillar 2 still represented (core mechanic intact)
+ - ✅ Makes investor demo
+ - ✅ Can polish post-Alpha
+ - ❌ First impression is "rough"
+ - Risk: Medium — demo may not wow, but pillar is visible
+
+**Option C: Cut Crafting Entirely (0 weeks, make Alpha)**
+ - ✅ Makes deadline with polish
+ - ✅ Team focuses on core combat (Pillar 1)
+ - ❌ Pillar 2 not represented
+ - ❌ Game identity incomplete
+ - Risk: High — investor won't see 50% of the vision
+
+**My Recommendation: Option B (Simplify to Core)**
+
+Reasoning:
+ 1. The investor demo needs to show ALL pillars, even if rough. A polished half-game is worse than a playable full-game.
+ 2. Recipe discovery is the SOUL of the crafting pillar — the UI is just presentation. Core > polish for a vertical slice.
+ 3. This protects schedule (team morale) and pillar integrity (investor confidence).
+ 4. We can polish post-Alpha and show progression: "Here's Alpha vs. Beta" is a compelling narrative.
+
+References: Hades showed rough vertical slices in Early Access and iterated — investors loved the pillar demonstration over polish.
+
+Trade-offs I'm accepting: The demo won't look AAA-polished, but it will feel complete.
+
+**But this is your call.** You know the investor relationship better than I do. If they value polish over completeness, Option C might be right. If they're technical and want to see systems depth, Option A might be worth the risk.
+
+What's your decision?"
+
+User: "Option B. Let's simplify the scope."
+
+You (support decision):
+"Excellent. I'll document this decision and cascade it:
+
+1. Creating ADR: docs/architecture/adr-005-alpha-crafting-scope-reduction.md
+2. Updating design/gdd/crafting-system.md with Alpha scope markers
+3. Notifying game-designer and lead-programmer to align on new 1.5-week plan
+4. Adding to production/milestones/alpha.md as success criteria: 'Crafting pillar demonstrated via core discovery mechanic'
+
+Validation criteria: We'll know this was right if:
+ - Investor demo shows both Pillar 1 (combat) and Pillar 2 (discovery) in playable form
+ - Team hits Alpha deadline without crunch
+ - Post-Alpha sprint can polish crafting without rework
+
+May I proceed with documentation?"
+
+User: "Yes"
+
+You: [Creates ADR, updates docs, notifies relevant agents]
+```
+
+#### Collaborative Mindset
+
+- You provide strategic analysis, the user provides final judgment
+- Present options clearly — don't make the user drag it out of you
+- Explain trade-offs honestly — acknowledge what each option sacrifices
+- Use theory and precedent, but defer to user's contextual knowledge
+- Once decided, commit fully — document and cascade the decision
+- Set up success metrics — "we'll know this was right if..."
+
+#### Structured Decision UI
+
+Use the `AskUserQuestion` tool to present strategic decisions as a selectable UI.
+Follow the **Explain → Capture** pattern:
+
+1. **Explain first** — Write full strategic analysis in conversation: options with
+   pillar alignment, downstream consequences, risk assessment, recommendation.
+
+2. **Capture the decision** — Call `AskUserQuestion` with concise option labels.
+
+**When to use it:**
+- Every strategic decision point (options in step 3, context questions in step 1)
+- Batch up to 4 independent questions in one call
+- Next-step choices after a decision is made
+
+**When NOT to use it:**
+- Open-ended context gathering ("Tell me about the investor relationship")
+- Single confirmations ("May I document this decision?")
+- When running as a Task subagent — structure text for orchestrator
+
+**Format guidelines:**
+- Labels: 1-5 words. Descriptions: 1 sentence with key trade-off.
+- Add "(Recommended)" to your preferred option's label
+- Use `markdown` previews for comparing architectural approaches
+
+**Example — strategic decision (after full analysis in conversation):**
+
+  AskUserQuestion with questions:
+    1. question: "How should we handle crafting scope for Alpha?"
+       header: "Scope"
+       options:
+         "Simplify to Core (Recommended)" — makes deadline, pillar visible
+         "Full Implementation" — slips Alpha by 1 week
+         "Cut Entirely" — deadline met, pillar missing
+```

package/docs/templates/design-doc-from-implementation.md

@@ -0,0 +1,204 @@
+# [System Name] — Design Document
+
+---
+**Status**: Reverse-Documented
+**Source**: `[path to implementation code]`
+**Date**: [YYYY-MM-DD]
+**Verified By**: [User name or "pending review"]
+**Implementation Status**: [Fully implemented | Partially implemented | Needs extension]
+---
+
+> **⚠️ Reverse-Documentation Notice**
+>
+> This design document was created **after** the implementation already existed.
+> It captures current behavior and clarified design intent based on code analysis
+> and user consultation. Some sections may be incomplete where implementation is
+> partial or design intent was unclear during reverse-engineering.
+
+---
+
+## 1. Overview
+
+**Purpose**: [What problem does this system solve?]
+
+**Scope**: [What is included/excluded from this system?]
+
+**Current Implementation**: [Brief description of what exists in code]
+
+**Design Intent** (clarified):
+- [Intent 1 — why this feature exists]
+- [Intent 2 — what player experience it creates]
+- [Intent 3 — how it fits into overall game pillars]
+
+---
+
+## 2. Detailed Design
+
+### 2.1 Core Mechanics
+
+[Describe the mechanics as implemented, organized clearly]
+
+**[Mechanic 1 Name]**:
+- **Description**: [What it does]
+- **Implementation**: [How it works in code]
+- **Design Rationale**: [Why it exists — from user clarification]
+- **Player-Facing**: [How players experience this]
+
+**[Mechanic 2 Name]**:
+- **Description**: [What it does]
+- **Implementation**: [How it works]
+- **Design Rationale**: [Why it exists]
+- **Player-Facing**: [Player experience]
+
+### 2.2 Rules and Formulas
+
+**Formulas Discovered in Code**:
+
+| Formula | Expression | Purpose | Verified? |
+|---------|-----------|---------|-----------|
+| [Formula 1] | `[mathematical expression]` | [What it calculates] | ✅ / ⚠️ needs tuning |
+| [Formula 2] | `[expression]` | [Purpose] | ✅ / ⚠️ needs tuning |
+
+**Clarifications**:
+- [Formula X]: Originally [value/approach], user clarified intent is [corrected intent]
+- [Formula Y]: Implemented as [X], but should be [Y] — flagged for update
+
+### 2.3 State and Data
+
+**Data Structures** (from code):
+- [Data structure 1]: `[fields/properties]`
+- [Data structure 2]: `[fields/properties]`
+
+**State Machines** (if applicable):
+```
+[State diagram or list of states and transitions]
+```
+
+**Persistence**:
+- Saved: [What is saved to player save file]
+- Not saved: [What is session-only or recalculated]
+
+### 2.4 Integration Points
+
+**Dependencies** (systems this depends on):
+- [System 1]: [What it provides]
+- [System 2]: [What it provides]
+
+**Dependents** (systems that depend on this):
+- [System 3]: [How it uses this system]
+- [System 4]: [How it uses this system]
+
+**API Surface** (public interface):
+- [Method/Function 1]: [Purpose]
+- [Method/Function 2]: [Purpose]
+
+---
+
+## 3. Edge Cases
+
+**Handled in Code**:
+- ✅ [Edge case 1]: [How it's handled]
+- ✅ [Edge case 2]: [How it's handled]
+
+**Not Yet Handled** (discovered during analysis):
+- ⚠️ [Edge case 3]: [What happens? Needs implementation]
+- ⚠️ [Edge case 4]: [What happens? Needs implementation]
+
+**Unclear** (need user clarification):
+- ❓ [Edge case 5]: [What should happen? Pending decision]
+
+---
+
+## 4. Dependencies
+
+**Technical Dependencies**:
+- [Dependency 1]: [Why needed]
+- [Dependency 2]: [Why needed]
+
+**Design Dependencies** (other design docs):
+- [System X Design]: [How they interact]
+- [System Y Design]: [How they interact]
+
+**Content Dependencies**:
+- [Asset type]: [What's needed]
+- [Data files]: [Required config/balance data]
+
+---
+
+## 5. Balance and Tuning
+
+**Current Values** (as implemented):
+
+| Parameter | Current Value | Rationale | Needs Tuning? |
+|-----------|--------------|-----------|---------------|
+| [Param 1] | [value] | [Why this value] | ✅ / ⚠️ / ❌ |
+| [Param 2] | [value] | [Why this value] | ✅ / ⚠️ / ❌ |
+
+**Balance Concerns Identified**:
+- ⚠️ [Concern 1]: [What's wrong, suggested fix]
+- ⚠️ [Concern 2]: [What's wrong, suggested fix]
+
+**Recommended Balance Pass**:
+- Run `/balance-check` on [specific aspect]
+- Playtest with focus on [specific scenario]
+
+---
+
+## 6. Acceptance Criteria
+
+**What Exists** (implemented):
+- ✅ [Criterion 1]
+- ✅ [Criterion 2]
+- ⚠️ [Criterion 3] — partially implemented
+
+**What's Missing** (not yet implemented):
+- ❌ [Criterion 4] — flagged for future work
+- ❌ [Criterion 5] — flagged for future work
+
+**Definition of Done** (when is this system "complete"?):
+- [ ] [Requirement 1]
+- [ ] [Requirement 2]
+- [ ] [Requirement 3]
+
+---
+
+## 7. Open Questions and Follow-Up Work
+
+### Questions Needing User Decision
+1. **[Question 1]**: [What needs to be decided?]
+   - Option A: [Approach A]
+   - Option B: [Approach B]
+
+2. **[Question 2]**: [What needs to be decided?]
+
+### Flagged Follow-Up Work
+- [ ] **Update [Formula X]**: Change from exponential to linear (per user clarification)
+- [ ] **Implement [Edge Case Y]**: Handle scenario not in current code
+- [ ] **Create ADR**: Document why [architectural decision] was chosen
+- [ ] **Balance pass**: Run `/balance-check` on progression curve
+- [ ] **Extend design doc**: When [related feature] is implemented, update this doc
+
+---
+
+## 8. Version History
+
+| Date | Author | Changes |
+|------|--------|---------|
+| [Date] | Claude (reverse-doc) | Initial reverse-documentation from `[source path]` |
+| [Date] | [User] | Clarified design intent, corrected [X] |
+
+---
+
+**Next Steps**:
+1. [Priority 1 task based on gaps identified]
+2. [Priority 2 task]
+3. [Priority 3 task]
+
+**Related Skills**:
+- `/balance-check` — Validate formulas and progression
+- `/architecture-decision` — Document technical decisions
+- `/code-review` — Ensure code matches clarified design
+
+---
+
+*This document was generated by `/reverse-document design [path]`*

package/docs/templates/incident-response.md

@@ -0,0 +1,135 @@
+# Incident Response: [Incident Title]
+
+**Severity**: [S1-Critical / S2-Major / S3-Moderate / S4-Minor]
+**Status**: [Active / Mitigated / Resolved / Post-Mortem Complete]
+**Detected**: [Date Time UTC]
+**Resolved**: [Date Time UTC or ONGOING]
+**Duration**: [Total time from detection to resolution]
+**Incident Commander**: [Name/Role]
+
+---
+
+## Impact Summary
+
+[2-3 sentences describing what players experienced. Write from the player
+perspective, not the technical perspective.]
+
+- **Players affected**: [estimated count or percentage]
+- **Platforms affected**: [PC / Console / Mobile / All]
+- **Regions affected**: [All / specific regions]
+- **Revenue impact**: [estimated if applicable]
+
+---
+
+## Timeline
+
+| Time (UTC) | Event | Action Taken |
+| ---- | ---- | ---- |
+| [HH:MM] | Incident detected via [monitoring/player report/etc.] | Incident commander assigned |
+| [HH:MM] | Root cause identified | [Brief description of cause] |
+| [HH:MM] | Mitigation deployed | [What was done] |
+| [HH:MM] | Service restored / Fix confirmed | Monitoring for recurrence |
+| [HH:MM] | All-clear declared | Post-mortem scheduled |
+
+---
+
+## Root Cause
+
+### What Happened
+[Technical description of the root cause. Be specific about the chain of events
+that led to the incident.]
+
+### Why It Happened
+[Systemic cause — why did existing processes, tests, or safeguards fail to
+prevent this? This is more important than the technical cause.]
+
+### Contributing Factors
+- [Factor 1 — e.g., "Insufficient load testing for the new matchmaking system"]
+- [Factor 2 — e.g., "Monitoring alert threshold was set too high"]
+- [Factor 3]
+
+---
+
+## Mitigation and Resolution
+
+### Immediate Actions (during incident)
+1. [Action taken to stop the bleeding]
+2. [Action taken to restore service]
+3. [Action taken to verify resolution]
+
+### Follow-Up Actions (after resolution)
+1. [Permanent fix if immediate action was a workaround]
+2. [Additional testing or monitoring added]
+3. [Process changes to prevent recurrence]
+
+---
+
+## Player Communication
+
+### Initial Acknowledgment
+*Sent: [Time] via [channel]*
+> [Exact text of the first public message acknowledging the issue]
+
+### Status Updates
+*Sent: [Time] via [channel]*
+> [Text of each subsequent update]
+
+### Resolution Notice
+*Sent: [Time] via [channel]*
+> [Text announcing the fix and any compensation]
+
+### Compensation (if applicable)
+- **What**: [description of compensation — e.g., "500 premium currency + 24-hour XP boost"]
+- **Who**: [all players / affected players only / players who logged in during incident]
+- **When**: [delivery date and method]
+- **Rationale**: [why this compensation is appropriate for the impact]
+
+---
+
+## Prevention
+
+### What We Are Changing
+
+| Action Item | Owner | Deadline | Status |
+| ---- | ---- | ---- | ---- |
+| [Specific preventive measure] | [Role] | [Date] | [TODO/Done] |
+| [Add monitoring for X] | [Role] | [Date] | [TODO/Done] |
+| [Add test coverage for Y] | [Role] | [Date] | [TODO/Done] |
+| [Update runbook for Z] | [Role] | [Date] | [TODO/Done] |
+
+### Process Improvements
+- [Process change to prevent similar incidents]
+- [Monitoring/alerting improvement]
+- [Testing improvement]
+
+---
+
+## Lessons Learned
+
+### What Went Well
+- [Positive aspect of incident response — e.g., "Detection was fast due to
+  monitoring alerts"]
+- [Positive aspect]
+
+### What Went Poorly
+- [Problem with response — e.g., "Took 20 minutes to identify the correct
+  on-call person"]
+- [Problem]
+
+### Where We Got Lucky
+- [Factor that reduced impact by chance rather than design — these are hidden
+  risks to address]
+
+---
+
+## Sign-Offs
+
+- [ ] Technical Director — Root cause accurate, prevention plan sufficient
+- [ ] QA Lead — Test coverage gaps addressed
+- [ ] Producer — Timeline and communication reviewed
+- [ ] Community Manager — Player communication reviewed
+
+---
+
+*This document is filed in `production/hotfixes/` and linked from the
+release notes for the fix version.*