v1.16.1 - Semantic Refactoring & Type Clarity (2025-12-12)¶
What Changed?¶
This release improves code clarity and semantic accuracy through comprehensive refactoring of type names and variable naming in the detection engine and event processor. A critical bug fix ensures the hit type bitmask correctly references the renamed detection count variable. All changes are purely internal with zero impact on functionality or protocol.
What's New¶
Type Naming Improvements¶
Unified Detection Type: The detection engine now uses detection_t for the struct containing hit counts and detection flag. This more explicitly represents "a detection event result" compared to the previous name.
Hit Count Struct: Internal type hit_count_t in DetectionProcessor clarifies that the structure contains multiple hit counts per channel (hit1, hit2, hit3), not just a generic "detection result."
Variable Naming: Local variable counts replaces the generic detection throughout the detection processor, improving semantic clarity. For example:
hit_count_t counts = {}; // Clearly: multiple hit counts
read_sensors(&event, counts);
led_feedback(counts);
Examples of improvements:
cosmic_detection_t→detection_t(cleaner, unified path specific)detected_t→detection_t(more explicit about content)detection_result_t→hit_count_t(semantic clarity)detectionvariable →countsvariable (specific, not generic)
Installation¶
Quick Start¶
# Get the release
git checkout v1.16.1
# Build
task build
# Upload
task upload
# Check it works
task monitor
What's Different from the Last Version?¶
🔧 Changed¶
- Detection engine type renamed from
cosmic_detection_t→detection_t(unified path specific) - Detection result type renamed
detection_result_t→hit_count_tfor semantic clarity - Local variable
detectionrenamed tocountsthroughout DetectionProcessor for improved readability - Variable
detection_occurredrenamed totriggeredin detector.cpp for brevity
🐛 Fixed¶
- Hit type bitmask now correctly references
countsvariable instead of olddetectionvariable name (ensures ENABLE_HITTYPE functionality works correctly)
Is It Safe to Upgrade?¶
Backward Compatible: Yes
- All changes are internal refactoring with zero protocol changes
- No changes to binary protocol, text commands, or sensor output format
- No functional behavior changes - identical detection logic and processing
- Serial communication remains unchanged (115200 baud)
- Existing configurations and builds continue to work without modification
Tests Passed¶
- ✅ Builds without errors (all three profiles: dev, debug, release)
- ✅ Type definitions consistent across all modules
- ✅ Hit type bitmask code now compiles without reference errors
- ✅ Variable naming consistent throughout detection pipeline
Release Details¶
- Date: 2025-12-12
- Version: v1.16.1
- Files Changed: 5 (plus 1 documentation navigation update)
- Commits: 7 (refactoring + bug fix + docs)
- Type: Maintenance Release (semantic refactoring)
Next Steps¶
With improved semantic clarity in the detection pipeline, future development can proceed with:
- Enhanced detection features - Detection type naming now precisely reflects data structure
- Extended hit type analysis - Hit type bitmask bug fix enables full ENABLE_HITTYPE functionality
- Further refactoring - Clean naming foundation for CommandParser class (Phase 14.0 planned)
See CLAUDE.md for the full roadmap and upcoming milestones.