- Created a comprehensive document detailing various SecGen lab scenarios, including setup, user accounts, vulnerabilities, and CTF steps.
- Each scenario provides insights into player experiences and objectives, aiding mission designers in understanding gameplay dynamics.
- Scenarios cover a range of topics, including Linux and Windows security labs, malware exploitation, information gathering, and post-exploitation techniques.
- Updated `GamesController` to support XML flag hints for standalone mode, improving backward compatibility with legacy flag input.
- Introduced `parse_flag_hints_xml` method in `Mission` model to extract flags from XML content.
- Enhanced `Game` model to incorporate `flags_by_vm` from player state for better flag management.
- Modified `new.html.erb` to update UI for flag hints input, replacing the previous comma-separated flags format.
- Improved `FlagStationMinigame` to display accepted VM flags and handle flag submissions more effectively.
- Adjusted scenario JSON to include flag stations with VM-specific flag handling.
- Updated last modified date and added new review document reference.
- Added policy methods for `GamePolicy#submit_flag?` and `MissionPolicy#create_game?`.
- Fixed authorization in `games#create` to use `:create_game?` and removed redundant `VmSet` authorization.
- Clarified loading of `hacktivity-cable.js` with CSP nonce.
- Included fallback for non-Hacktivity mode in VM set validation.
- Documented minor amendments and verification checklist for implementation readiness.
- Added detailed review documentation for Hacktivity compatibility.
- Addressed critical issue: implemented missing `games#create` action in GamesController.
- Updated `MissionsController#show` to handle VM-required missions differently.
- Clarified deployment order for migration to remove unique index.
- Added recommendations for strong parameters in `games#create`.
- Documented necessary changes for flag submission and VM set display.
- Verified compatibility of model structures and updated flag submission logic.
- Added ObjectivesManager to track mission objectives and tasks.
- Created ObjectivesPanel for displaying objectives in a collapsible HUD.
- Integrated objectives state restoration from the server during game initialization.
- Implemented task completion and unlocking mechanisms via game actions.
- Added CSS styles for the objectives panel with a pixel-art aesthetic.
- Developed a test scenario to validate the objectives system functionality.
- Updated database schema to include fields for tracking completed objectives and tasks.
- Created an updated TODO checklist outlining phases and tasks for the objectives system implementation.
- Added corrected code snippets for critical fixes, including door unlock event emission and key pickup event handling.
- Documented necessary changes to ensure proper event emissions for objectives tracking.
- Reviewed and approved the implementation plan with minor corrections regarding door unlock events.
- Added `Cybok` model to manage CyBOK entries associated with missions.
- Implemented `by_collection` scope in `Mission` model for filtering missions by collection.
- Updated `missions_controller` to filter missions based on the selected collection.
- Introduced `CybokSyncService` for syncing CyBOK data from mission metadata to the database.
- Created new views and partials for displaying CyBOK information with tooltips using Tippy.js.
- Added metadata fields to `break_escape_missions` for `secgen_scenario` and `collection`.
- Enhanced mission seeding logic to support new metadata and CyBOK entries.
- Added multiple new mission scenarios with associated metadata.
- Implemented a global character registry to manage player and NPC data.
- Added methods for setting the player, registering NPCs, and retrieving character information.
- Integrated character registry updates into the NPC manager for seamless NPC registration.
- Created test scenarios for line prefix speaker format, including narrator modes and background changes.
- Developed comprehensive NPC sprite test scenario with various NPC interactions and items.
- Created COMPREHENSIVE_REVIEW.md detailing architecture, risk assessment, and recommendations for the line prefix speaker format implementation.
- Developed README.md summarizing the implementation plan assessment, key findings, and integration of the Background[] feature.
- Included detailed risk assessment, updated timeline estimates, and success criteria for the implementation.
- Recommended enhancements for security, performance, reliability, and deployment strategies.
- Established a phased approach for implementation with clear priorities and next steps for the team and content creators.
- Implemented narrator syntax to display character portraits during narration.
- Changed default speaker behavior to default to the main NPC for unprefixed lines.
- Enhanced NPC behavior tags to support no parameters, comma-separated lists, wildcard patterns, and an "all" keyword.
- Added comprehensive testing requirements for narrator, default speaker, and NPC behavior tags.
- Updated documentation to reflect new features and usage examples.
- Addressed critical and high-priority issues from REVIEW1, including function naming conflicts, regex security, and empty dialogue validation.
- Improved code organization and backward compatibility.
- Added server-side validation for inventory actions, ensuring items are validated before being added to the player's inventory.
- Updated client-side `addToInventory()` function to include server validation and error handling for inventory actions.
- Implemented container loading logic to fetch contents from the server, handling locked containers appropriately.
- Enhanced player state initialization to ensure starting items are correctly added to the inventory.
- Clarified NPC `itemsHeld` structure and updated validation logic to match the expected item format.
- Improved error handling for room access and container interactions, including transaction safety for state mutations.
- Introduced new endpoints for scenario mapping and bulk inventory synchronization.
- Added performance optimizations, including caching filtered room data and implementing JSON schema validation for item structures.
- Established a detailed implementation plan with phased priorities and testing gaps identified for future work.
User correctly pointed out the loading UI was over-engineered.
## Simplifications:
### Before (over-complicated):
- Complex timeline management
- Success/failure flash effects (green/red)
- Spinner alternatives
- Stored references on sprites
- Timeline cleanup logic
- ~150 lines of code
### After (simple):
- startThrob(sprite) - Blue tint + pulsing alpha
- stopThrob(sprite) - Kill tweens, reset
- ~20 lines of code
## Why This Works:
1. **Door sprites get removed anyway** when they open
2. **Container items transition** to next state automatically
3. **Game already shows alerts** for success/error
4. **Only need feedback** during the ~100-300ms API call
## API Changes:
- showUnlockLoading() → startThrob()
- clearUnlockLoading() → stopThrob()
- No success/failure parameter needed
- No stored references to clean up
## Result:
From 150+ lines down to ~30 lines total.
Same UX, much simpler implementation.
User feedback: "Just set the door or item to throb, and remove when
the loading finishes (the door sprite is removed anyway), and if it's
a container, just follow the unlock with a removal of the animation."
User correctly noted that Hacktivity's application layout already includes
csrf_meta_tags, so we don't need to add them again.
## Changes:
### Section 9.3.1: Layout Strategy
- Split into Option A (Hacktivity layout - recommended) and Option B (standalone)
- **Option A (Recommended):** Read from existing meta tag
- Uses Hacktivity's csrf_meta_tags (already present in layout)
- No duplicate meta tags needed
- Reads via: document.querySelector('meta[name="csrf-token"]')?.content
- **Option B:** Standalone layout
- For when engine needs separate layout
- Must add <%= csrf_meta_tags %> to engine layout
- Can use <%= form_authenticity_token %> directly
### Section 9.3.3: Token Reading Logic
- Updated config.js to try multiple sources:
1. window.breakEscapeConfig.csrfToken (if explicitly set)
2. meta[name="csrf-token"] tag (from Hacktivity layout)
- Better error messages showing all sources checked
- Logs which source provided the token
### Section 9.3.5: Issue #2 Solution
- Updated to reference the fallback logic in 9.3.3
- Added debugging console commands
- Shows how to check all meta tags
## Key Points:
- ✅ Hacktivity layout csrf_meta_tags are reused (don't duplicate)
- ✅ Fallback chain ensures token found from either source
- ✅ Clear guidance for both integration scenarios
- ✅ Better debugging when token is missing
This aligns with Rails best practices and Hacktivity's existing setup.
Based on comprehensive codebase review, enhanced implementation plans with:
## Phase 3 Updates (Scenario Conversion):
- Complete bash script to convert all 26 scenarios to ERB structure
- Explicit list of 3 main scenarios (ceo_exfil, cybok_heist, biometric_breach)
- List of 23 test/demo scenarios for development
- Instructions to rename .json to .erb (actual ERB code added later in Phase 4)
- Preserves git history with mv commands
- Both automated script and manual alternatives provided
## Phase 9 Updates (CSRF Token Handling):
NEW Section 9.3: "Setup CSRF Token Injection"
- Critical security implementation for Rails CSRF protection
- Complete view template with <%= form_authenticity_token %>
- JavaScript config injection via window.breakEscapeConfig
- CSRF token validation and error handling
- Browser console testing procedures
- 5 common CSRF issues with solutions
- Fallback to meta tag if config missing
- Development vs production considerations
## Phase 9 Updates (Async Unlock with Loading UI):
ENHANCED Section 9.5: "Update Unlock Validation with Loading UI"
- New file: unlock-loading-ui.js with Phaser.js throbbing tint effect
- showUnlockLoading(): Blue pulsing animation during server validation
- clearUnlockLoading(): Green flash on success, red flash on failure
- Alternative spinner implementation provided
- Complete unlockTarget() rewrite with async/await server validation
- Loading UI shows during API call (~100-300ms)
- Graceful error handling with user feedback
- Updates for ALL lock types: pin, password, key, lockpick, biometric, bluetooth, RFID
- Minigame callback updates to pass attempt and method to server
- Testing mode fallback (DISABLE_SERVER_VALIDATION)
- Preserves all existing unlock logic after server validation
## Key Features:
- Addresses 2 critical risks from review (CSRF tokens, async validation)
- Solves scenario conversion gap (26 files → ERB structure)
- Maintains backward compatibility during migration
- Comprehensive troubleshooting guidance
- Production-ready security implementation
Total additions: ~600 lines of detailed implementation guidance
Complete documentation for:
- 04_API_REFERENCE.md: All 9 API endpoints with examples
- 05_TESTING_GUIDE.md: Minitest strategy with fixtures and tests
These complete the documentation set along with the Hacktivity integration guide.
Major simplification to migration plan:
- Remove NpcScript model entirely
- Reduce to 2 tables: missions (metadata) + games (state + scenario snapshot)
- Serve ink files directly from filesystem via game endpoints
- Move scenario_data to game instances (enables per-instance randomization)
- Eliminates Issue #2 (NPC schema complexity)
- Reduces P0 fixes from 10 hours to 2-3 hours
- Much simpler seed process (metadata only)
- Identify 5 critical issues requiring fixes before implementation
- Validate architecture decisions (mostly solid)
- Provide corrected database schema for shared NPCs
- Document P0 fixes needed: Ink compilation, file structure, NPC schema
- Recommend 1.5 days of prep work to save 3-5 days of rework
- Total review: 6 documents covering issues, architecture, and solutions
Updated migration plans to reflect significant codebase evolution:
NEW SYSTEMS DOCUMENTED:
- NPC system (fully implemented with NPCManager, conversation state, events)
- Event system (80+ events across codebase)
- Global game state management (window.gameState.globalVariables)
- Multiple scenarios (24 total, up from 1 originally planned)
KEY UPDATES:
- UPDATED_MIGRATION_STATUS.md: Comprehensive status of what's changed
- What's implemented vs what still needs server-side integration
- Updated timeline: 22 weeks (was 18 weeks)
- New database schema requirements
- Updated risk assessment
- CLIENT_SERVER_SEPARATION_PLAN.md: Added 3 new systems
- System 5: NPC System (hybrid approach confirmed)
- System 6: Event System (selective logging)
- System 7: Global Game State (server as source of truth)
- Updated migration checklist: 9 phases (was 7)
- Updated timeline: 18-22 weeks
- README_UPDATED.md: New master index document
- Quick start guide
- Document index
- What's changed summary
- Timeline breakdown
- Architecture decisions
- Success metrics
MIGRATION APPROACH:
- Hybrid NPC approach: Scripts client-side, validation server-side
- Selective event logging: Critical events only
- State sync: Server as source of truth, client cache for performance
- Incremental rollout with dual-mode support
TIMELINE: 22 weeks (~5.5 months)
- Added 4 weeks for NPC, Event, State integration
- Original: 18 weeks → Updated: 22 weeks (+22%)
All plans are complete, self-contained, actionable, and feature-focused.
Ready for team review and implementation.
Added three review documents analyzing the completed RFID system:
- POST_IMPLEMENTATION_REVIEW.md: Full technical analysis of implementation
- Reviewed 4 core files, 6 integration points, CSS, and test scenario
- Found 0 critical issues, 2 medium priority improvements (optional)
- Confirmed production-ready status
- Verified correct conversation return pattern
- Validated EM4100 protocol implementation
- ISSUES_SUMMARY.md: Quick reference for identified issues
- 7 total issues (all minor/optional)
- Action items with code examples
- Testing checklist
- README.md: Review overview and quick status
Key findings:
✅ Clean modular architecture following established patterns
✅ Authentic Flipper Zero UI with smooth animations
✅ Robust error handling and validation
✅ Seamless integration with all game systems
✅ Comprehensive test scenario created
Recommended improvements (optional):
- Use hex ID for key_id to prevent collisions
- Add cardToClone validation in clone mode
- Extract timing constants for maintainability
Overall assessment: Production ready with minor improvements recommended
Fix NPC interaction and event handling issues
- Added a visual problem-solution summary for debugging NPC event handling.
- Resolved cooldown bug in NPCManager by implementing explicit null/undefined checks.
- Modified PersonChatMinigame to prioritize event parameters over state restoration.
- Updated security guard dialogue in Ink scenarios to improve interaction flow.
- Adjusted vault key parameters in npc-patrol-lockpick.json for consistency.
- Changed inventory stylesheet references to hud.css in test HTML files for better organization.
feat(combat): Integrate chair kicking with punch mechanic
Update chair interaction to use the punch system instead of direct kicking:
**Changes to interactions.js:**
- Modified swivel chair interaction to trigger player punch instead of
directly applying kick velocity
- Simplified chair interaction handler to just call playerCombat.punch()
**Changes to player-combat.js:**
- Extended checkForHits() to detect chairs in punch range and direction
- Added kickChair() method that applies the same velocity calculation:
- Calculates direction from player to chair
- Applies 1200 px/s kick force in that direction
- Triggers spin direction calculation for visual rotation
- Adds visual feedback (flash chair, light screen shake)
- Chairs now respond to punch AOE damage like hostile NPCs
Now clicking a chair or pressing 'E' near it triggers a punch, and if the
chair is in punch range and facing direction, it gets kicked with the
original velocity physics. Multiple chairs can be kicked with one punch.
feat(combat): Implement hostile NPC behavior and final integration (Phase 6-7)
Complete hostile NPC combat system with chase behavior and integration:
**Phase 6: Hostile NPC Behavior**
- Modified npc-behavior.js determineState() to check hostile state from npcHostileSystem
- Implemented updateHostileBehavior() with chase and attack logic:
- NPCs chase player when hostile and in aggro range
- NPCs stop and attack when in attack range
- NPCs use directional movement with proper animations
- Integration with npcCombat system for attack attempts
- Added KO state check to prevent KO'd NPCs from acting
**Phase 7: Final Integration**
- Modified player.js to disable movement when player is KO
- Added visual KO effect (50% alpha) to NPC sprites in npc-hostile.js
- Connected all combat systems end-to-end:
- Ink dialogue → hostile tag → hostile state → chase behavior → combat
- Player interaction → punch → NPC damage → KO → visual feedback
- NPC chase → attack → player damage → HP UI → game over
Full combat loop now functional: hostile NPCs chase and attack player,
player can punch hostile NPCs, complete visual/audio feedback, game over on KO.
feat(combat): Add feedback, UI, and combat mechanics (Phase 2-5)
Implement comprehensive combat feedback, UI, and mechanics:
**Phase 2: Enhanced Feedback Systems**
- damage-numbers.js: Floating damage numbers with object pooling
- screen-effects.js: Screen flash and shake for combat feedback
- sprite-effects.js: Sprite tinting, flashing, and visual effects
- attack-telegraph.js: Visual indicators for incoming NPC attacks
**Phase 3: UI Components**
- health-ui.js: Player health display as hearts (5 hearts, shows when damaged)
- npc-health-bars.js: Health bars above hostile NPCs with color coding
- game-over-screen.js: KO screen with restart/main menu options
**Phase 4-5: Combat Mechanics**
- player-combat.js: Player punch system with AOE directional damage
- npc-combat.js: NPC attack system with telegraph and cooldowns
- Modified interactions.js to trigger punch on hostile NPC interaction
- Integrated all systems into game.js create() and update() loops
Combat now functional with complete visual/audio feedback pipeline.
Player can punch hostile NPCs, NPCs can attack player, health tracking works.
feat(combat): Add hostile NPC system foundation (Phase 0-1)
Implement core hostile NPC combat system infrastructure:
- Add #hostile tag handler to chat-helpers.js for Ink integration
- Fix security-guard.ink to use proper hub pattern with -> hub instead of -> END
- Add #hostile:security_guard tags to hostile conversation paths
- Create combat configuration system (combat-config.js)
- Create combat event constants (combat-events.js)
- Implement player health tracking system with HP and KO state
- Implement NPC hostile state management with HP tracking
- Add combat debug utilities for testing
- Add error handling utilities for validation
- Integrate combat systems into game.js create() method
- Create test-hostile.ink for testing hostile tag system
This establishes the foundation for hostile NPC behavior, allowing NPCs to
become hostile through Ink dialogue and tracking health for both player and NPCs.
docs(npc): Apply codebase-verified corrections to hostile NPC plans
Apply critical corrections based on actual codebase verification:
CORRECTIONS.md (Updated):
- ✅ Confirms #exit_conversation tag ALREADY IMPLEMENTED
* Location: person-chat-minigame.js line 537
* No handler needed in chat-helpers.js
- ❌ Hostile tag still needs implementation in chat-helpers.js
- Provides exact code for hostile tag handler
- Clarifies tag format: #hostile:npcId or #hostile (uses current NPC)
- Updated action items to reflect what's already working
INTEGRATION_UPDATES.md (New):
- Comprehensive correction document
- Issue 1 Corrected: Exit conversation already works
- Issue 6 Corrected: Punch mechanics are interaction-based with AOE
- Details interaction-based punch targeting:
* Player clicks hostile NPC OR presses 'E' nearby
* Punch animation plays in facing direction
* Damage applies to ALL NPCs in range + direction (AOE)
* Can hit multiple enemies if grouped (strategic gameplay)
- Provides complete implementation examples
- Removes complexity of target selection systems
- Uses existing interaction patterns
quick_start.md (Updated):
- Removed exit_conversation handler (already exists)
- Updated hostile tag handler code
- Added punch mechanics design section
- Clarified interaction-based targeting
- Added troubleshooting for exit_conversation
Key Findings:
✅ Exit conversation tag works out of the box
✅ Punch targeting uses existing interaction system (simpler!)
✅ AOE punch adds strategic depth without complexity
❌ Only ONE critical task remains: Add hostile tag to chat-helpers.js
Impact:
- Less work required (don't need exit_conversation handler)
- Simpler implementation (use existing interaction patterns)
- Better gameplay (AOE punches, directional attacks)
- Clear path forward with exact code examples
docs(npc): Add critical corrections and codebase integration review
Add comprehensive review of hostile NPC plans against actual codebase:
CORRECTIONS.md:
- Identifies critical Ink pattern error (-> END vs -> hub)
- Documents correct hub-based conversation pattern
- Provides corrected examples for all Ink files
- Explains why -> hub is required after #exit_conversation
FORMAT_REVIEW.md:
- Validates JSON scenario format against existing scenarios
- Reviews NPC object structure and required fields
- Documents correct Ink hub pattern from helper-npc.ink
- Proposes hostile configuration object for NPC customization
- Provides complete format reference and checklists
review2/integration_review.md:
- Comprehensive codebase analysis by Explore agent
- Identifies 2 critical blockers requiring immediate attention:
* Missing tag handlers for #hostile and #exit_conversation
* Incorrect Ink pattern (-> END) in planning documents
- Documents 4 important integration differences:
* Initialization in game.js not main.js
* Event dispatcher already exists (window.eventDispatcher)
* Room transition behavior needs design decision
* Multi-hostile NPC targeting needs design decision
- Confirms 8 systems are fully compatible with plan
- Provides existing code patterns to follow
- Corrects integration sequence
review2/quick_start.md:
- Step-by-step guide for Phase 0-1 implementation
- Includes complete code examples for critical systems
- Browser console test procedures
- Common issues and solutions
- Success criteria checklist
Key Findings:
✅ 90% compatible with existing codebase
❌ Must add tag handlers to chat-helpers.js before implementation
❌ Must fix all Ink examples to use -> hub not -> END
⚠️ Should follow game.js initialization pattern not main.js
⚠️ Should use existing window.eventDispatcher
⚠️ Need design decisions on room transitions and multi-targeting
All critical issues documented with solutions ready.
Implementation can proceed with high confidence after corrections applied.
docs(npc): Add comprehensive planning documents for hostile NPC system
Add detailed implementation plans for hostile NPC feature including:
- Complete implementation plan with phase-by-phase breakdown
- Architecture overview with system diagrams and data flows
- Detailed TODO list with 200+ actionable tasks
- Phase 0 foundation with design decisions and base components
- Enhanced combat feedback implementation guide
- Implementation roadmap with 6-day schedule
Add comprehensive review documents:
- Implementation review with risk assessment and recommendations
- Technical review analyzing code patterns and best practices
- UX review covering player experience and game feel
Key features planned:
- NPC hostile state triggered via Ink tags
- Player health system with heart-based UI
- NPC health bars and combat mechanics
- Punch combat for both player and NPCs
- Strong visual/audio feedback for combat
- Game over system and KO states
- Attack telegraphing for fairness
- Enhanced NPC chase behavior with LOS
- Debug utilities and error handling
- Comprehensive testing strategy
- Created TITLE_SCREEN_CUSTOMIZATION.md with examples for extending the title screen.
- Added TITLE_SCREEN_DEVELOPER_GUIDE.md for technical guidance on implementation.
- Introduced TITLE_SCREEN_IMPLEMENTATION.md detailing the architecture and features.
- Compiled TITLE_SCREEN_INDEX.md as a documentation index for easy navigation.
- Updated TITLE_SCREEN_OVERLAY_UPDATE.md to reflect changes in title screen display mode.
- Created TITLE_SCREEN_QUICK_START.md for a quick setup guide.
- Developed TITLE_SCREEN_README.md as a comprehensive overview of the title screen system.
- Added title-screen-demo.json scenario to demonstrate title screen functionality.
- Modified existing files to integrate the title screen into the game flow.
- Deleted outdated quick reference file and replaced it with a comprehensive LOS visualization guide.
- Updated console commands for enabling/disabling LOS and added detailed explanations for visual elements.
- Improved console output for distance and angle checks during NPC detection.
- Introduced new test functions for graphics rendering and system status checks.
- Enhanced logging during LOS cone drawing to provide detailed graphics object properties and rendering status.
- Created new documentation files for quick commands and debugging improvements.
- Added a structured troubleshooting flow for common issues related to LOS detection and rendering.
- Added core LOS detection module (`js/systems/npc-los.js`) with functions for distance and angle checks, and debug visualization.
- Integrated LOS checks into NPC manager (`js/systems/npc-manager.js`) to enhance lockpicking interruption logic based on player visibility.
- Updated scenario configurations for NPCs to include LOS properties.
- Created comprehensive documentation covering implementation details, configuration options, and testing procedures.
- Enhanced debugging capabilities with console commands and visualization options.
- Established performance metrics and future enhancement plans for server-side validation and obstacle detection.
- Added a new security guard NPC with conversation flow for lockpicking attempts.
- Integrated influence system to determine NPC reactions based on player choices.
- Created a new JSON scenario for the security guard's behavior and interactions.
- Refactored lockpicking system to allow NPC interruptions during attempts.
- Developed a test scenario to visualize NPC patrol and line-of-sight detection.
- Added a debug panel for testing line-of-sight visualization in the game.
- Added a new system to prevent NPCs from clipping through walls and tables during collisions.
- Introduced functions for position validation and safe movement: `isPositionSafe()`, `boundsOverlap()`, and `findSafeCollisionPosition()`.
- Updated `handleNPCCollision()` and `handleNPCPlayerCollision()` to utilize the new safe position logic, allowing NPCs to find alternative paths when blocked.
- Created comprehensive documentation detailing the implementation, testing procedures, and performance analysis.
- Ensured minimal performance impact with efficient collision checks and pathfinding.
- Added automatic collision avoidance for NPCs when colliding with each other and the player.
- Updated `setupNPCToNPCCollisions()` to include collision callbacks for NPC-to-NPC interactions.
- Created `handleNPCCollision()` to manage NPC-to-NPC collision responses, moving NPCs 5px northeast and recalculating paths.
- Implemented `handleNPCPlayerCollision()` for NPC-to-Player collisions, ensuring consistent behavior with NPC-to-NPC avoidance.
- Modified `updatePatrol()` to check for path recalculation after collisions.
- Enhanced console logging for collision events and path recalculations.
- Created comprehensive documentation covering implementation details, quick reference, and testing procedures.
- Ensured minimal performance impact with efficient pathfinding and collision detection.
