Skip to content

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_tdetection_t (cleaner, unified path specific)
  • detected_tdetection_t (more explicit about content)
  • detection_result_thit_count_t (semantic clarity)
  • detection variable → counts variable (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_tdetection_t (unified path specific)
  • Detection result type renamed detection_result_thit_count_t for semantic clarity
  • Local variable detection renamed to counts throughout DetectionProcessor for improved readability
  • Variable detection_occurred renamed to triggered in detector.cpp for brevity

🐛 Fixed

  • Hit type bitmask now correctly references counts variable instead of old detection variable 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:

  1. Enhanced detection features - Detection type naming now precisely reflects data structure
  2. Extended hit type analysis - Hit type bitmask bug fix enables full ENABLE_HITTYPE functionality
  3. Further refactoring - Clean naming foundation for CommandParser class (Phase 14.0 planned)

See CLAUDE.md for the full roadmap and upcoming milestones.