selfpatch/ros2_medkit

Context PR #274 added per-entity debounce thresholds. When multiple entities with different resolved configs report the same fault_code, the last reporter's config determines the status transition. This is documented behavior but can be a production footgun. Example Motor (confirmation_threshold=-5) reports OVERHEAT -> counter=-1, PREFAILED. Lidar (confirmation_threshold=-1) reports same OVERHEAT -> counter=-2, lidar config applied, -2<=-1 -> CONFIRMED. Motor's debounce policy was bypassed because lidar came in with a more lenient config. Proposed solution Add RCLCPP_WARN_ONCE (or RCLCPP_WARN_THROTTLE) when a fault_code receives events with different resolved DebounceConfig values. This requires tracking per-fault the last-used config (e.g., a std::unordered_map<std::string, DebounceConfig> in FaultManagerNode). Alternative: validate at YAML load time whether configured prefixes could cause overlapping matches for common fault_code patterns. Why not done in #274 Requires per-fault stat

Summary The global DELETE /faults?status= endpoint lacks a test that verifies the status filter actually works (e.g. inject a confirmed fault → DELETE with ?status=pending → verify the confirmed fault still exists). Current integration tests only check that 204 is returned, because demo nodes continuously re-report faults making absence checks flaky. Proposed solution (optional) Add a C++ unit test (~30-50 lines) with a mock fault manager: Mock list_faults() to return known faults with different statuses Call handle_clear_all_faults_global with ?status=pending Verify clear_fault() was only called on pending faults Existing patterns in test_fault_manager.cpp can be reused — no new test infrastructure needed. Additional context (optional) Raised during PR #228 review by @bburda.

Summary The ConfigHandlers class has no unit test file. It handles SOVD configuration CRUD operations (reading/writing ROS 2 parameters via HTTP) and has 5 methods. Methods to test (5): handle_list_configurations - lists available parameter sets for an entity handle_get_configuration - gets current values of a specific configuration set handle_set_configuration - sets parameter values handle_delete_configuration - resets a specific configuration to defaults handle_delete_all_configurations - resets all configurations for an entity Proposed solution (optional) Create test/test_config_handlers.cpp: #include <gtest/gtest.h> #include <nlohmann/json.hpp> #include "ros2_medkit_gateway/http/handlers/config_handlers.hpp" class ConfigHandlersTest : public ::testing::Test {}; // Test: invalid entity ID returns 400 TEST_F(ConfigHandlersTest, ListConfigsInvalidEntityReturns400) { /* ... */ } // Test: non-existent entity returns 404 TEST_F(ConfigHandlersTest, GetConfigUnknownEntityReturns404)

Summary Several core classes in the gateway lack Doxygen documentation (@brief, @param, @return comments). This makes it harder for new contributors to understand the architecture without reading the full implementation. Priority classes that need documentation: GatewayNode (include/ros2_medkit_gateway/gateway_node.hpp) — the main ROS 2 node orchestrating all subsystems DataAccessManager (include/ros2_medkit_gateway/data_access_manager.hpp) — manages topic data access and sampling ConfigurationManager (include/ros2_medkit_gateway/configuration_manager.hpp) — handles ROS 2 parameter configuration via SOVD API OperationManager (include/ros2_medkit_gateway/operation_manager.hpp) — manages service/action operations Proposed solution (optional) Add Doxygen-style documentation to each class and its public methods. Example: /** * @brief Main ROS 2 node that orchestrates the SOVD-compatible HTTP gateway. * * GatewayNode initializes and coordinates all subsystems: discovery, REST

Summary Implement GET /{entity-path}/data-groups endpoint to return logical groupings of data items. Data groups are custom collections defined in the capability description or derived from namespace structure. They allow clients to organize and filter data resources by logical purpose (e.g., "motion", "environment"). Data groups differ from data categories: categories are fixed semantic types (identData, currentData, storedData, sysInfo), while groups are user-defined logical collections that can span multiple categories. Currently the route is registered in rest_server.cpp but returns 501 Not Implemented. (ISO 17978-3, §7.9) Proposed solution GET /api/v1/{entity-path}/data-groups List all data groups defined for an entity. Applies to entity types: Components, Apps (SOVDServer aggregation level excluded per spec) Path parameters: Parameter Type Required Description {entity-path} URL segment Yes e.g., components/engine_ecu or apps/temp_sensor Query parameters: Parameter