bmad-method 4.42.1 → 4.43.1

package/expansion-packs/bmad-godot-game-dev/checklists/game-architect-checklist.md

@@ -0,0 +1,377 @@
+# Game Architect Solution Validation Checklist (Godot)
+
+This checklist serves as a comprehensive framework for the Game Architect to validate the technical design and architecture for Godot game development. The Game Architect should systematically work through each item, ensuring the game architecture is robust, scalable, performant, and aligned with the Game Design Document requirements while leveraging Godot's strengths.
+
+[[LLM: INITIALIZATION INSTRUCTIONS - REQUIRED ARTIFACTS
+
+Before proceeding with this checklist, ensure you have access to:
+
+1. architecture.md - The primary game architecture document (check docs/architecture.md)
+2. game-design-doc.md - Game Design Document for game requirements alignment (check docs/game-design-doc.md)
+3. Any system diagrams referenced in the architecture
+4. Godot project structure documentation
+5. Game balance and configuration specifications
+6. Platform target specifications
+7. Performance profiling data if available
+
+IMPORTANT: If any required documents are missing or inaccessible, immediately ask the user for their location or content before proceeding.
+
+GAME PROJECT TYPE DETECTION:
+First, determine the game project type by checking:
+
+- Is this a 2D or 3D Godot game project?
+- What platforms are targeted (mobile, desktop, web, console)?
+- What are the core game mechanics from the GDD?
+- Are there specific performance requirements (60 FPS, mobile constraints)?
+- Will the project use GDScript, C#, or both?
+
+VALIDATION APPROACH:
+For each section, you must:
+
+1. Deep Analysis - Don't just check boxes, thoroughly analyze each item against the provided documentation
+2. Evidence-Based - Cite specific sections or quotes from the documents when validating
+3. Critical Thinking - Question assumptions and identify gaps, not just confirm what's present
+4. Performance Focus - Consider frame rate impact, draw calls, and memory usage for every architectural decision
+5. Language Balance - Evaluate whether GDScript vs C# choices are appropriate for each system
+
+EXECUTION MODE:
+Ask the user if they want to work through the checklist:
+
+- Section by section (interactive mode) - Review each section, present findings, get confirmation before proceeding
+- All at once (comprehensive mode) - Complete full analysis and present comprehensive report at end]]
+
+## 1. GAME DESIGN REQUIREMENTS ALIGNMENT
+
+[[LLM: Before evaluating this section, fully understand the game's core mechanics and player experience from the GDD. What type of gameplay is this? What are the player's primary actions? What must feel responsive and smooth? Consider Godot's node-based architecture and how it serves these requirements.]]
+
+### 1.1 Core Mechanics Coverage
+
+- [ ] Architecture supports all core game mechanics from GDD
+- [ ] Node hierarchy properly represents game entities and systems
+- [ ] Player controls and input handling leverage Godot's Input system
+- [ ] Game state management uses Godot's scene tree effectively
+- [ ] All gameplay features map to appropriate Godot nodes and scenes
+
+### 1.2 Performance & Platform Requirements
+
+- [ ] Target frame rate requirements (60+ FPS) with specific solutions
+- [ ] Mobile platform constraints addressed (draw calls, texture memory)
+- [ ] Memory usage optimization strategies using Godot's monitoring tools
+- [ ] Battery life considerations for mobile platforms
+- [ ] Cross-platform compatibility leveraging Godot's export system
+
+### 1.3 Godot-Specific Requirements Adherence
+
+- [ ] Godot version (4.x or 3.x) is specified with justification
+- [ ] .NET/Mono version requirements for C# projects defined
+- [ ] Target platform export templates identified
+- [ ] Asset import pipeline configuration specified
+- [ ] Node lifecycle usage (\_ready, \_process, \_physics_process) planned
+
+## 2. GAME ARCHITECTURE FUNDAMENTALS
+
+[[LLM: Godot's node-based architecture requires different thinking than component systems. As you review, consider: Are scenes properly composed? Is the node tree structure optimal? Are signals used effectively for decoupling? Is the architecture leveraging Godot's strengths?]]
+
+### 2.1 Game Systems Clarity
+
+- [ ] Game architecture documented with node tree diagrams
+- [ ] Major scenes and their responsibilities defined
+- [ ] Signal connections and event flows mapped
+- [ ] Resource data flows clearly illustrated
+- [ ] Scene inheritance and composition patterns specified
+
+### 2.2 Godot Node Architecture
+
+- [ ] Clear separation between scenes, nodes, and resources
+- [ ] Node lifecycle methods used appropriately
+- [ ] Scene instantiation and queue_free patterns defined
+- [ ] Scene transition and management strategies clear
+- [ ] Autoload/singleton usage justified and documented
+
+### 2.3 Game Design Patterns & Practices
+
+- [ ] Appropriate patterns for Godot (signals, groups, autoloads)
+- [ ] GDScript and C# patterns used consistently
+- [ ] Common Godot anti-patterns avoided (deep node paths, circular deps)
+- [ ] Consistent architectural style across game systems
+- [ ] Pattern usage documented with Godot-specific examples
+
+### 2.4 Scalability & Performance Optimization
+
+- [ ] Object pooling implemented for frequently spawned entities
+- [ ] Draw call batching strategies defined
+- [ ] LOD systems planned for complex scenes
+- [ ] Occlusion culling configured appropriately
+- [ ] Memory management patterns established
+
+## 3. GODOT TECHNOLOGY STACK & LANGUAGE DECISIONS
+
+[[LLM: Language choice (GDScript vs C#) impacts performance and development speed. For each system, verify the language choice is justified. GDScript for rapid iteration and Godot-native features, C# for compute-intensive operations and complex algorithms.]]
+
+### 3.1 Language Strategy
+
+- [ ] GDScript vs C# decision matrix for each system
+- [ ] Performance-critical systems identified for C# implementation
+- [ ] Rapid iteration systems appropriate for GDScript
+- [ ] Interop boundaries between languages minimized
+- [ ] Language-specific best practices documented
+
+### 3.2 Godot Technology Selection
+
+- [ ] Godot version with specific features needed
+- [ ] Rendering backend choice (Vulkan/OpenGL) justified
+- [ ] Physics engine (2D/3D) configuration specified
+- [ ] Navigation system usage planned
+- [ ] Third-party plugins justified and version-locked
+
+### 3.3 Game Systems Architecture
+
+- [ ] Game Manager using autoload pattern defined
+- [ ] Audio system using AudioStreamPlayers and buses specified
+- [ ] Input system with InputMap configuration outlined
+- [ ] UI system using Control nodes or immediate mode determined
+- [ ] Scene management and loading architecture clear
+- [ ] Save/load system using Godot's serialization defined
+- [ ] Multiplayer architecture using RPCs detailed (if applicable)
+- [ ] Rendering optimization strategies documented
+- [ ] Shader usage guidelines and performance limits
+- [ ] Particle system budgets and pooling strategies
+- [ ] Animation system using AnimationPlayer/AnimationTree
+
+### 3.4 Data Architecture & Resources
+
+- [ ] Resource usage for game data properly planned
+- [ ] Custom Resource classes for game configuration
+- [ ] Save game serialization approach specified
+- [ ] Data validation and versioning handled
+- [ ] Hot-reload support for development iteration
+
+## 4. PERFORMANCE OPTIMIZATION & PROFILING
+
+[[LLM: Performance is critical. Focus on Godot-specific optimizations: draw calls, physics bodies, node count, signal connections. Consider both GDScript and C# performance characteristics. Look for specific profiling strategies using Godot's built-in tools.]]
+
+### 4.1 Rendering Performance
+
+- [ ] Draw call optimization through batching
+- [ ] Texture atlasing strategy defined
+- [ ] Viewport usage and render targets optimized
+- [ ] Shader complexity budgets established
+- [ ] Culling and LOD systems configured
+
+### 4.2 Memory Management
+
+- [ ] Object pooling for bullets, particles, enemies
+- [ ] Resource preloading vs lazy loading strategy
+- [ ] Scene instance caching approach
+- [ ] Reference cleanup patterns defined
+- [ ] C# garbage collection mitigation (if using C#)
+
+### 4.3 CPU Optimization
+
+- [ ] Process vs physics_process usage optimized
+- [ ] Signal connection overhead minimized
+- [ ] Node tree depth optimization
+- [ ] GDScript static typing for performance
+- [ ] C# for compute-intensive operations
+
+### 4.4 Profiling & Monitoring
+
+- [ ] Godot profiler usage documented
+- [ ] Performance metrics and budgets defined
+- [ ] Frame time analysis approach
+- [ ] Memory leak detection strategy
+- [ ] Platform-specific profiling planned
+
+## 5. TESTING & QUALITY ASSURANCE
+
+[[LLM: Testing in Godot requires specific approaches. GUT for GDScript, GoDotTest for C#. Consider how TDD will be enforced, how performance will be validated, and how gameplay will be tested.]]
+
+### 5.1 Test Framework Strategy
+
+- [ ] GUT framework setup for GDScript testing
+- [ ] GoDotTest/GodotTestDriver configuration for C# testing
+- [ ] Test scene organization defined
+- [ ] CI/CD pipeline with test automation
+- [ ] Performance benchmark tests specified
+
+### 5.2 Test Coverage Requirements
+
+- [ ] Unit test coverage targets (80%+)
+- [ ] Integration test scenarios defined
+- [ ] Performance test baselines established
+- [ ] Platform-specific test plans
+- [ ] Gameplay experience validation tests
+
+### 5.3 TDD Enforcement
+
+- [ ] Red-Green-Refactor cycle mandated
+- [ ] Test-first development workflow documented
+- [ ] Code review includes test verification
+- [ ] Performance tests before optimization
+- [ ] Regression test automation
+
+## 6. GAME DEVELOPMENT WORKFLOW
+
+[[LLM: Efficient Godot development requires clear workflows. Consider scene organization, asset pipelines, version control with .tscn/.tres files, and collaboration patterns.]]
+
+### 6.1 Godot Project Organization
+
+- [ ] Project folder structure clearly defined
+- [ ] Scene and resource naming conventions
+- [ ] Asset organization (sprites, audio, scenes)
+- [ ] Script attachment patterns documented
+- [ ] Version control strategy for Godot files
+
+### 6.2 Asset Pipeline
+
+- [ ] Texture import settings standardized
+- [ ] Audio import configuration defined
+- [ ] 3D model pipeline established (if 3D)
+- [ ] Font and UI asset management
+- [ ] Asset compression strategies
+
+### 6.3 Build & Deployment
+
+- [ ] Export preset configuration documented
+- [ ] Platform-specific export settings
+- [ ] Build automation using Godot headless
+- [ ] Debug vs release build optimization
+- [ ] Distribution pipeline defined
+
+## 7. GODOT-SPECIFIC IMPLEMENTATION GUIDANCE
+
+[[LLM: Clear Godot patterns prevent common mistakes. Consider node lifecycle, signal patterns, resource management, and language-specific idioms.]]
+
+### 7.1 GDScript Best Practices
+
+- [ ] Static typing usage enforced
+- [ ] Signal naming conventions defined
+- [ ] Export variable usage guidelines
+- [ ] Coroutine patterns documented
+- [ ] Performance idioms specified
+
+### 7.2 C# Integration Patterns
+
+- [ ] C# coding standards for Godot
+- [ ] Marshalling optimization patterns
+- [ ] Dispose patterns for Godot objects
+- [ ] Collection usage guidelines
+- [ ] Async/await patterns in Godot
+
+### 7.3 Node & Scene Patterns
+
+- [ ] Scene composition strategies
+- [ ] Node group usage patterns
+- [ ] Signal vs method call guidelines
+- [ ] Tool scripts usage defined
+- [ ] Custom node development patterns
+
+## 8. MULTIPLAYER & NETWORKING (if applicable)
+
+[[LLM: Godot's high-level multiplayer API has specific patterns. If multiplayer is required, validate the architecture leverages Godot's networking strengths.]]
+
+### 8.1 Network Architecture
+
+- [ ] Client-server vs peer-to-peer decision
+- [ ] RPC usage patterns defined
+- [ ] State synchronization approach
+- [ ] Lag compensation strategies
+- [ ] Security considerations addressed
+
+### 8.2 Multiplayer Implementation
+
+- [ ] Network node ownership clear
+- [ ] Reliable vs unreliable RPC usage
+- [ ] Bandwidth optimization strategies
+- [ ] Connection handling robust
+- [ ] Testing approach for various latencies
+
+## 9. AI AGENT IMPLEMENTATION SUITABILITY
+
+[[LLM: This architecture may be implemented by AI agents. Review for clarity: Are Godot patterns consistent? Is the node hierarchy logical? Are GDScript/C# responsibilities clear? Would an AI understand the signal flows?]]
+
+### 9.1 Implementation Clarity
+
+- [ ] Node responsibilities singular and clear
+- [ ] Signal connections documented explicitly
+- [ ] Resource usage patterns consistent
+- [ ] Scene composition rules defined
+- [ ] Language choice per system justified
+
+### 9.2 Development Patterns
+
+- [ ] Common Godot patterns documented
+- [ ] Anti-patterns explicitly called out
+- [ ] Performance pitfalls identified
+- [ ] Testing patterns clearly defined
+- [ ] Debugging approaches specified
+
+### 9.3 AI Implementation Support
+
+- [ ] Template scenes provided
+- [ ] Code snippets for common patterns
+- [ ] Performance profiling examples
+- [ ] Test case templates included
+- [ ] Build automation scripts ready
+
+## 10. PLATFORM & PERFORMANCE TARGETS
+
+[[LLM: Different platforms have different constraints in Godot. Mobile needs special attention for performance, web has size constraints, desktop can leverage more features.]]
+
+### 10.1 Platform-Specific Optimization
+
+- [ ] Mobile performance targets achieved (60 FPS)
+- [ ] Desktop feature utilization maximized
+- [ ] Web build size optimization planned
+- [ ] Console certification requirements met
+- [ ] Platform input handling comprehensive
+
+### 10.2 Performance Validation
+
+- [ ] Frame time budgets per system defined
+- [ ] Memory usage limits established
+- [ ] Load time targets specified
+- [ ] Battery usage goals for mobile
+- [ ] Network bandwidth limits defined
+
+[[LLM: FINAL GODOT ARCHITECTURE VALIDATION REPORT
+
+Generate a comprehensive validation report that includes:
+
+1. Executive Summary
+   - Overall architecture readiness (High/Medium/Low)
+   - Critical performance risks
+   - Key architectural strengths
+   - Language strategy assessment (GDScript/C#)
+
+2. Godot Systems Analysis
+   - Pass rate for each major section
+   - Node architecture completeness
+   - Signal system usage effectiveness
+   - Resource management approach
+
+3. Performance Risk Assessment
+   - Top 5 performance bottlenecks
+   - Platform-specific concerns
+   - Memory management risks
+   - Draw call and rendering concerns
+
+4. Implementation Recommendations
+   - Must-fix items before development
+   - Godot-specific improvements needed
+   - Language choice optimizations
+   - Testing strategy gaps
+
+5. Development Workflow Assessment
+   - Asset pipeline completeness
+   - Build system readiness
+   - Testing framework setup
+   - Version control preparedness
+
+6. AI Agent Implementation Readiness
+   - Clarity of Godot patterns
+   - Complexity assessment
+   - Areas needing clarification
+   - Template completeness
+
+After presenting the report, ask the user if they would like detailed analysis of any specific system, performance concern, or language consideration.]]

package/expansion-packs/bmad-godot-game-dev/checklists/game-change-checklist.md

@@ -0,0 +1,250 @@
+# Game Development Change Navigation Checklist (Godot)
+
+**Purpose:** To systematically guide the Game SM agent and user through analysis and planning when a significant change (performance issue, platform constraint, technical blocker, gameplay feedback) is identified during Godot game development.
+
+**Instructions:** Review each item with the user. Mark `[x]` for completed/confirmed, `[N/A]` if not applicable, or add notes for discussion points.
+
+[[LLM: INITIALIZATION INSTRUCTIONS - GAME CHANGE NAVIGATION
+
+Changes during game development are common - performance issues, platform constraints, gameplay feedback, and technical limitations are part of the process.
+
+Before proceeding, understand:
+
+1. This checklist is for SIGNIFICANT changes affecting game architecture or features
+2. Minor tweaks (shader adjustments, UI positioning) don't require this process
+3. The goal is to maintain playability while adapting to technical realities
+4. Performance (60+ FPS) and player experience are paramount
+5. Consider both GDScript and C# implementation options
+
+Required context:
+
+- The triggering issue (performance metrics, crash logs, feedback)
+- Current development state (implemented features, current sprint)
+- Access to GDD, technical specs, and performance budgets
+- Understanding of remaining features and milestones
+- Current language usage (GDScript vs C#) per system
+
+APPROACH:
+This is an interactive process. Discuss performance implications, platform constraints, and player impact. The user makes final decisions, but provide expert Godot/game dev guidance.
+
+REMEMBER: Game development is iterative. Changes often lead to better gameplay and performance.]]
+
+---
+
+## 1. Understand the Trigger & Context
+
+[[LLM: Start by understanding the game-specific issue. Ask technical questions:
+
+- What performance metrics triggered this? (FPS, frame time, memory)
+- Is this platform-specific or universal?
+- Can we reproduce it consistently?
+- What Godot profiler data do we have?
+- Is this a GDScript performance issue that C# could solve?
+- Are we hitting Godot engine limits?
+
+Focus on measurable impacts and technical specifics.]]
+
+- [ ] **Identify Triggering Element:** Clearly identify the game feature/system revealing the issue.
+- [ ] **Define the Issue:** Articulate the core problem precisely.
+  - [ ] Performance bottleneck (CPU/GPU/Memory)?
+  - [ ] Draw call or batching issue?
+  - [ ] Platform-specific limitation?
+  - [ ] Godot engine constraint?
+  - [ ] GDScript vs C# performance difference?
+  - [ ] Node tree complexity issue?
+  - [ ] Signal overhead problem?
+  - [ ] Physics engine bottleneck?
+  - [ ] Gameplay/balance issue from playtesting?
+  - [ ] Asset import or resource loading problem?
+  - [ ] Export template or platform issue?
+- [ ] **Assess Performance Impact:** Document specific metrics (current FPS, target 60+ FPS, frame time ms, draw calls, memory usage).
+- [ ] **Gather Technical Evidence:** Note Godot profiler data, performance monitor stats, platform test results, player feedback.
+
+## 2. Game Feature Impact Assessment
+
+[[LLM: Game features are interconnected in Godot's node system. Evaluate systematically:
+
+1. Can we optimize the current feature without changing gameplay?
+2. Should this system move from GDScript to C#?
+3. Do dependent scenes/nodes need adjustment?
+4. Are there Godot-specific optimizations available?
+5. Does this affect our performance budget allocation?
+
+Consider both technical and gameplay impacts.]]
+
+- [ ] **Analyze Current Sprint Features:**
+  - [ ] Can the current feature be optimized?
+    - [ ] Object pooling for frequently instantiated nodes?
+    - [ ] LOD system implementation?
+    - [ ] Draw call batching improvements?
+    - [ ] Move hot code from GDScript to C#?
+    - [ ] Static typing in GDScript for performance?
+  - [ ] Does it need gameplay simplification?
+  - [ ] Should it be platform-specific (high-end only)?
+- [ ] **Analyze Dependent Systems:**
+  - [ ] Review all scenes and nodes interacting with the affected feature.
+  - [ ] Do physics bodies need optimization?
+  - [ ] Are Control nodes/UI systems impacted?
+  - [ ] Do Resource save/load systems require changes?
+  - [ ] Are multiplayer RPCs affected?
+  - [ ] Do signal connections need optimization?
+- [ ] **Language Migration Assessment:**
+  - [ ] Would moving this system to C# improve performance?
+  - [ ] What's the interop overhead if we split languages?
+  - [ ] Can we maintain rapid iteration with C#?
+- [ ] **Summarize Feature Impact:** Document effects on node hierarchy, scene structure, and technical architecture.
+
+## 3. Game Artifact Conflict & Impact Analysis
+
+[[LLM: Game documentation drives development. Check each artifact:
+
+1. Does this invalidate GDD mechanics?
+2. Are technical architecture assumptions still valid?
+3. Do performance budgets need reallocation?
+4. Are platform requirements still achievable?
+5. Does our language strategy (GDScript/C#) need revision?
+
+Missing conflicts cause performance issues later.]]
+
+- [ ] **Review GDD:**
+  - [ ] Does the issue conflict with core gameplay mechanics?
+  - [ ] Do game features need scaling for performance?
+  - [ ] Are progression systems affected?
+  - [ ] Do balance parameters need adjustment?
+- [ ] **Review Technical Architecture:**
+  - [ ] Does the issue conflict with Godot architecture (scene structure, node hierarchy)?
+  - [ ] Are autoload/singleton systems impacted?
+  - [ ] Do shader/rendering approaches need revision?
+  - [ ] Are Resource structures optimal for the scale?
+  - [ ] Is the GDScript/C# split still appropriate?
+- [ ] **Review Performance Specifications:**
+  - [ ] Are target framerates (60+ FPS) still achievable?
+  - [ ] Do memory budgets need reallocation?
+  - [ ] Are load time targets realistic?
+  - [ ] Do we need platform-specific targets?
+  - [ ] Are draw call budgets exceeded?
+- [ ] **Review Asset Specifications:**
+  - [ ] Do texture import settings need adjustment?
+  - [ ] Are mesh instance counts appropriate?
+  - [ ] Do audio bus configurations need changes?
+  - [ ] Is the animation tree complexity sustainable?
+  - [ ] Are particle system limits appropriate?
+- [ ] **Summarize Artifact Impact:** List all game documents requiring updates.
+
+## 4. Path Forward Evaluation
+
+[[LLM: Present Godot-specific solutions with technical trade-offs:
+
+1. What's the performance gain (FPS improvement)?
+2. How much rework is required?
+3. What's the player experience impact?
+4. Are there platform-specific solutions?
+5. Should we migrate systems from GDScript to C#?
+6. Can we leverage Godot 4.x features if on 3.x?
+
+Be specific about Godot implementation details.]]
+
+- [ ] **Option 1: Optimization Within Current Design:**
+  - [ ] Can performance be improved through Godot optimizations?
+    - [ ] Object pooling with node reuse?
+    - [ ] MultiMesh for instancing?
+    - [ ] Viewport optimization?
+    - [ ] Occlusion culling setup?
+    - [ ] Static typing in GDScript?
+    - [ ] Batch draw calls with CanvasItem?
+    - [ ] Optimize signal connections?
+    - [ ] Reduce node tree depth?
+  - [ ] Define specific optimization techniques.
+  - [ ] Estimate performance improvement potential.
+- [ ] **Option 2: Language Migration:**
+  - [ ] Would moving to C# provide needed performance?
+  - [ ] Identify hot paths for C# conversion.
+  - [ ] Define interop boundaries.
+  - [ ] Assess development velocity impact.
+- [ ] **Option 3: Feature Scaling/Simplification:**
+  - [ ] Can the feature be simplified while maintaining fun?
+  - [ ] Identify specific elements to scale down.
+  - [ ] Define platform-specific variations.
+  - [ ] Assess player experience impact.
+- [ ] **Option 4: Architecture Refactor:**
+  - [ ] Would restructuring improve performance significantly?
+  - [ ] Identify Godot-specific refactoring needs:
+    - [ ] Scene composition changes?
+    - [ ] Node hierarchy optimization?
+    - [ ] Signal system redesign?
+    - [ ] Autoload restructuring?
+    - [ ] Resource management improvements?
+  - [ ] Estimate development effort.
+- [ ] **Option 5: Scope Adjustment:**
+  - [ ] Can we defer features to post-launch?
+  - [ ] Should certain features be platform-exclusive?
+  - [ ] Do we need to adjust milestone deliverables?
+- [ ] **Select Recommended Path:** Choose based on performance gain vs. effort.
+
+## 5. Game Development Change Proposal Components
+
+[[LLM: The proposal must include technical specifics:
+
+1. Performance metrics (before/after projections with FPS targets)
+2. Godot implementation details (nodes, scenes, scripts)
+3. Language strategy (GDScript vs C# per system)
+4. Platform-specific considerations
+5. Testing requirements (GUT for GDScript, GoDotTest for C#)
+6. Risk mitigation strategies
+
+Make it actionable for game developers.]]
+
+(Ensure all points from previous sections are captured)
+
+- [ ] **Technical Issue Summary:** Performance/technical problem with metrics.
+- [ ] **Feature Impact Summary:** Affected nodes, scenes, and systems.
+- [ ] **Performance Projections:** Expected improvements from chosen solution (target 60+ FPS).
+- [ ] **Implementation Plan:** Godot-specific technical approach.
+  - [ ] Node hierarchy changes
+  - [ ] Scene restructuring needs
+  - [ ] Script migration (GDScript to C#)
+  - [ ] Resource optimization
+  - [ ] Signal flow improvements
+- [ ] **Platform Considerations:** Any platform-specific implementations.
+- [ ] **Testing Strategy:**
+  - [ ] GUT tests for GDScript changes
+  - [ ] GoDotTest for C# changes
+  - [ ] Performance benchmarks
+  - [ ] Platform validation approach
+- [ ] **Risk Assessment:** Technical risks and mitigation plans.
+- [ ] **Updated Game Stories:** Revised stories with technical constraints.
+
+## 6. Final Review & Handoff
+
+[[LLM: Game changes require technical validation. Before concluding:
+
+1. Are performance targets (60+ FPS) clearly defined?
+2. Is the Godot implementation approach clear?
+3. Is the language strategy (GDScript/C#) documented?
+4. Do we have rollback strategies?
+5. Are test scenarios defined for both languages?
+6. Is platform testing covered?
+
+Get explicit approval on technical approach.
+
+FINAL REPORT:
+Provide a technical summary:
+
+- Performance issue and root cause
+- Chosen solution with expected FPS gains
+- Implementation approach in Godot (nodes, scenes, languages)
+- GDScript vs C# decisions and rationale
+- Testing and validation plan (GUT/GoDotTest)
+- Timeline and milestone impacts
+
+Keep it technically precise and actionable.]]
+
+- [ ] **Review Checklist:** Confirm all technical aspects discussed.
+- [ ] **Review Change Proposal:** Ensure Godot implementation details are clear.
+- [ ] **Language Strategy:** Confirm GDScript vs C# decisions documented.
+- [ ] **Performance Validation:** Define how we'll measure success (profiler metrics).
+- [ ] **Test Coverage:** Ensure both GUT and GoDotTest coverage planned.
+- [ ] **User Approval:** Obtain approval for technical approach.
+- [ ] **Developer Handoff:** Ensure game-dev agent has all technical details needed.
+
+---