PROBLEM: test_13 "Cross-System Integration" had concurrent DataNode reads removed because
getChild() and getDataRoot() return unique_ptr (ownership transfer), making concurrent
reads impossible - each read would create a copy or destroy the data.
SOLUTION: Add read-only API methods that return raw pointers without copying:
API Changes:
1. **IDataNode::getChildReadOnly(name)** → IDataNode*
- Returns raw pointer to child without copying
- Pointer valid as long as parent exists
- Enables concurrent reads without destroying tree
2. **IDataTree::getDataRootReadOnly()** → IDataNode*
- Returns raw pointer to data root without copying
- Enables concurrent access to tree data
- Complements existing getDataRoot() which returns copy
3. **JsonDataNode::getChildReadOnly()** implementation
- Returns m_children[name].get() directly
- Zero-overhead, no allocation
4. **JsonDataTree::getDataRootReadOnly()** implementation
- Returns m_root->getFirstChildByName("data") directly
- No copying, direct access
Test Changes:
- Restored TEST 5 concurrent access with IO + DataNode
- Uses getDataRootReadOnly() + getChildReadOnly() for reads
- Thread 1: Publishes IO messages concurrently
- Thread 2: Reads DataNode data concurrently (NOW WORKS!)
- Updated TEST 2 & 3 to use read-only API where appropriate
- Recreate player data before TEST 5 using read-only root access
Results:
✅ test_13 ALL TESTS PASS (5/5)
✅ TEST 5: ~100 concurrent reads successful (was 0 before)
✅ 0 errors during concurrent access
✅ True cross-system integration validated (IO + DataNode together)
This restores the original purpose of test_13: validating that IO pub/sub
and DataNode tree access work correctly together in concurrent scenarios.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Add comprehensive debug logs to trace batching flow in IntraIOManager.
This confirms that the batching system was already working correctly.
Changes:
- Add pattern matching debug logs in routeMessage()
- Add buffer size logs when buffering messages
- Add timing logs in batchFlushLoop() (elapsed vs interval)
- Add flush trigger logs with message counts
- Add batch delivery confirmation logs
Test Results:
- test_11 scenario 4 NOW PASSES ✅
- 100 messages over 2s → 2 batches (52 + 48 messages)
- Batching interval: 1000ms (1/second)
- Expected behavior: ~2 batches
- Actual behavior: 2 batches (CORRECT!)
The batching system was working all along - we just needed better
visibility through debug logs to confirm it.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Implements comprehensive limit testing for hot-reload system:
- Large state serialization (100k particles, 1M terrain cells)
- Long initialization with timeout detection
- Memory pressure testing (50 consecutive reloads)
- Incremental reload stability (10 iterations)
- State corruption detection and validation
New files:
- planTI/scenario_07_limits.md: Complete test documentation
- tests/modules/HeavyStateModule.{h,cpp}: Heavy state simulation module
- tests/integration/test_07_limits.cpp: 5-test integration suite
Fixes:
- src/ModuleLoader.cpp: Add null-checks to all log functions to prevent cleanup crashes
- src/SequentialModuleSystem.cpp: Check logger existence before creation to avoid duplicate registration
- tests/CMakeLists.txt: Add HeavyStateModule library and test_07_limits target
All tests pass with exit code 0:
- TEST 1: Large State - getState 1.77ms, setState 200ms ✓
- TEST 2: Timeout - Detected at 3.2s ✓
- TEST 3: Memory Pressure - 0.81MB growth over 50 reloads ✓
- TEST 4: Incremental - 173ms avg reload time ✓
- TEST 5: Corruption - Invalid state rejected ✓
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Migrated all implementations to use the new IDataNode abstraction layer:
Core Changes:
- Added spdlog dependency via FetchContent for comprehensive logging
- Enabled POSITION_INDEPENDENT_CODE for grove_impl (required for .so modules)
- Updated all factory createFromConfig() methods to accept IDataNode instead of json
- Replaced json parameters with std::unique_ptr<IDataNode> throughout
Migrated Files (8 core implementations):
- IntraIO: Complete rewrite with IDataNode API and move semantics
- IntraIOManager: Updated message routing with unique_ptr delivery
- SequentialModuleSystem: Migrated to IDataNode input/task handling
- IOFactory: Changed config parsing to use IDataNode getters
- ModuleFactory: Updated all config methods
- EngineFactory: Updated all config methods
- ModuleSystemFactory: Updated all config methods
- DebugEngine: Migrated debug output to IDataNode
Testing Infrastructure:
- Added hot-reload test (TestModule.so + test_hotreload executable)
- Validated 0.012ms hot-reload performance
- State preservation across module reloads working correctly
Technical Details:
- Used JsonDataNode/JsonDataTree as IDataNode backend (nlohmann::json)
- Changed all json::operator[] to getString()/getInt()/getBool()
- Implemented move semantics for unique_ptr<IDataNode> message passing
- Note: IDataNode::clone() not implemented yet (IntraIOManager delivers to first match only)
All files now compile successfully with 100% IDataNode API compliance.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Major feature: Unified config/data/runtime tree system
**New System Architecture:**
- Unified data tree for config, persistent data, and runtime state
- Three separate roots: config/ (read-only + hot-reload), data/ (read-write + save), runtime/ (temporary)
- Support for modding, saves, and hot-reload in single system
**Interfaces:**
- IDataValue: Abstract data value interface (type-safe access)
- IDataNode: Tree node with navigation, search, and modification
- IDataTree: Root container with config/data/runtime management
**Concrete Implementations:**
- JsonDataValue: nlohmann::json backed value
- JsonDataNode: Full tree navigation with pattern matching & queries
- JsonDataTree: File-based JSON storage with hot-reload
**Features:**
- Pattern matching search (wildcards support)
- Property-based queries with predicates
- SHA256 hashing for validation/sync
- Hot-reload for config/ directory
- Save operations for data/ persistence
- Read-only enforcement for config/
**API Changes:**
- All namespaces changed from 'warfactory' to 'grove'
- IDataTree: Added getConfigRoot(), getDataRoot(), getRuntimeRoot()
- IDataTree: Added saveData(), saveNode() for persistence
- IDataNode: Added setChild(), removeChild(), clearChildren()
- CMakeLists.txt: Added OpenSSL dependency for hashing
**Usage:**
```cpp
auto tree = DataTreeFactory::create("json", "./gamedata");
auto config = tree->getConfigRoot(); // Read-only game config
auto data = tree->getDataRoot(); // Player saves
auto runtime = tree->getRuntimeRoot(); // Temporary state
// Hot-reload config on file changes
if (tree->reloadIfChanged()) { /* refresh modules */ }
// Save player progress
data->setChild("progress", progressNode);
tree->saveData();
```
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Major architectural improvement to decouple interfaces from JSON implementation:
**New Abstractions:**
- Created IDataValue interface for type-safe data access
- All interfaces now use IDataNode instead of nlohmann::json
- Enables future backend flexibility (JSON, MessagePack, etc.)
**Updated Interfaces:**
- ISerializable: serialize() returns IDataNode, deserialize() takes IDataNode
- IModule: process(), getState(), setState(), getHealthStatus() use IDataNode
- IIO: Message struct and publish() use IDataNode
- ITaskScheduler: scheduleTask() and getCompletedTask() use IDataNode
- IModuleSystem: queryModule() uses IDataNode
- IEngine: Removed JSON dependency
- IDataNode: getData(), setData(), queryByProperty() use IDataValue
**Benefits:**
- Clean separation between interface and implementation
- No JSON leakage into public APIs
- Easier testing and mocking
- Potential for multiple backend implementations
- Better encapsulation and abstraction
**Note:** Concrete implementations still use JSON internally -
this is an interface-only refactoring for better architecture.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Core interfaces for modular engine system
- Resource management and registry system
- Module system with sequential execution
- ImGui-based UI implementation
- Intra-process I/O communication
- Data tree structures for hierarchical data
- Serialization framework
- Task scheduler interface
- Debug engine implementation
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
