From bdb22a553078be6129f06c1941b3a9b27db409e1 Mon Sep 17 00:00:00 2001 From: GitHub Copilot Date: Fri, 15 May 2026 08:59:08 -0700 Subject: [PATCH 1/3] docs: remove LLM-style phrasing and sensitive reverse engineering references - Replace 'key X' headings/labels with plain equivalents throughout - Remove 'comprehensive' filler in descriptions - Remove 'Test Milestone' tracking blocks from reimplementation guide - Replace 'reverse engineer' with neutral 'document' in control_modes - Remove 'Grundfos GO mobile app' reference - Replace 'Traffic analysis and hardware probing' with 'Testing' - Rename 'Hardware Probing' section to 'Testing Methodology' - Remove Wireshark BLE capture references from tooling lists - Replace 'Real packet captures' with 'Protocol sample data' - Change 'Extracted from the GENI profile' to 'Defined in the GENI profile' - Clean up packet trace language (remove specific capture counts and dates) --- .gitignore | 1 + docs/TESTING_STRATEGY.md | 8 +-- docs/api/constants.md | 2 +- docs/guides/control_modes.md | 2 +- docs/guides/historical_data.md | 2 +- docs/guides/time_management.md | 2 +- docs/guides/understanding_telemetry.md | 2 +- docs/integrations/esphome.md | 2 +- docs/protocol/architecture.md | 2 +- docs/protocol/autoadapt_modes.md | 5 +- docs/protocol/ble_architecture.md | 4 +- docs/protocol/control_modes.md | 5 +- .../packet_traces/06_alarms_warnings.md | 12 ++-- docs/protocol/schedules.md | 8 +-- docs/protocol/telemetry.md | 2 +- docs/reference/data_models.md | 4 +- docs/reimplementation/README.md | 4 +- docs/reimplementation/architecture.md | 10 ++-- docs/reimplementation/checklist.md | 2 +- docs/reimplementation/common_pitfalls.md | 8 +-- docs/reimplementation/layer_by_layer.md | 60 +------------------ docs/troubleshooting/service_discovery.md | 2 +- 22 files changed, 43 insertions(+), 106 deletions(-) diff --git a/.gitignore b/.gitignore index 9c17f83..68f0336 100644 --- a/.gitignore +++ b/.gitignore @@ -51,3 +51,4 @@ traffic_db site tox_output.log tools +.obsidian diff --git a/docs/TESTING_STRATEGY.md b/docs/TESTING_STRATEGY.md index 25a2925..998f77e 100644 --- a/docs/TESTING_STRATEGY.md +++ b/docs/TESTING_STRATEGY.md @@ -2,7 +2,7 @@ ## Overview -This document outlines the testing strategy for the alpha-hwr library, covering reliability, maintainability, and serving as a reference for other language implementations. +This document describes the testing strategy for the alpha-hwr library, designed to ensure reliability, maintainability, and serve as a reference for other language implementations. ## Testing Pyramid @@ -261,7 +261,7 @@ tests/ │ └── fixtures/ ├── conftest.py # Pytest fixtures - ├── sample_packets.py # Real packet captures + ├── sample_packets.py # Protocol sample data └── test_vectors.py # Protocol test vectors ``` @@ -284,8 +284,8 @@ tests/ ## Test Data & Fixtures -### Real Packet Captures -Store real packet captures for validation: +### Protocol Sample Data +Store known-good protocol frames for validation: ```python # tests/fixtures/sample_packets.py diff --git a/docs/api/constants.md b/docs/api/constants.md index 78be1a4..c8c8d38 100644 --- a/docs/api/constants.md +++ b/docs/api/constants.md @@ -69,7 +69,7 @@ Addresses for Legacy Class 3 Register Polling. ## ERROR_CODES (Dictionary) -A lookup table mapping error codes to human-readable descriptions. Extracted from the GENI profile. +A lookup table mapping error codes to human-readable descriptions. Defined in the GENI profile. ```python from alpha_hwr.constants import ERROR_CODES diff --git a/docs/guides/control_modes.md b/docs/guides/control_modes.md index 04f020f..68e850f 100644 --- a/docs/guides/control_modes.md +++ b/docs/guides/control_modes.md @@ -1,6 +1,6 @@ # Control Modes and Setpoints -This guide covers the ALPHA HWR's control modes and setpoint configuration. +This guide provides details on the ALPHA HWR's control modes and setpoint configuration. ## Overview diff --git a/docs/guides/historical_data.md b/docs/guides/historical_data.md index cc662f4..df7a83a 100644 --- a/docs/guides/historical_data.md +++ b/docs/guides/historical_data.md @@ -16,7 +16,7 @@ Unlike basic telemetry which is real-time, historical data allows you to analyze ## Historical Trends (Object 53) -The pump maintains two resolutions of trend data for key metrics: +The pump maintains two resolutions of trend data: 1. **High Resolution**: Last 10 cycles. 2. **Standard Resolution**: Last 100 cycles. diff --git a/docs/guides/time_management.md b/docs/guides/time_management.md index e468621..aba607b 100644 --- a/docs/guides/time_management.md +++ b/docs/guides/time_management.md @@ -6,7 +6,7 @@ The Grundfos ALPHA HWR pump maintains an internal real-time clock (RTC) used for The pump's timekeeping is managed via GENI DataObjects (Class 10). While older protocols used simple Unix timestamps (Class 14/16), modern firmware relies on **Object 94**, which provides a structured date and time representation (Year, Month, Day, Hour, Minute, Second, etc.). -### Key Objects +### Objects | Object | SubID | Name | Description | | :--- | :--- | :--- | :--- | diff --git a/docs/guides/understanding_telemetry.md b/docs/guides/understanding_telemetry.md index a20b7f2..9c12ef1 100644 --- a/docs/guides/understanding_telemetry.md +++ b/docs/guides/understanding_telemetry.md @@ -1,6 +1,6 @@ # Understanding Pump Telemetry -This guide explains the key metrics reported by the ALPHA HWR pump and how to interpret them for optimal system performance. +This guide explains the metrics reported by the ALPHA HWR pump and how to interpret them for optimal system performance. ## Core Metrics diff --git a/docs/integrations/esphome.md b/docs/integrations/esphome.md index 2d841d9..59f9f77 100644 --- a/docs/integrations/esphome.md +++ b/docs/integrations/esphome.md @@ -120,7 +120,7 @@ async def to_code(config): ### 2. Protocol Constants (`alpha_hwr.h`) -Key sections of the header file: +Sections of the header file: ```cpp #pragma once diff --git a/docs/protocol/architecture.md b/docs/protocol/architecture.md index 42f21a6..44029b2 100644 --- a/docs/protocol/architecture.md +++ b/docs/protocol/architecture.md @@ -107,7 +107,7 @@ stateDiagram-v2 ## 6. Layer Responsibilities -| Layer | Responsibility | Key Components | +| Layer | Responsibility | Components | | :--- | :--- | :--- | | **Application** | User Interface | CLI, Scripts | | **Client** | Unified API | `AlphaHWRClient` | diff --git a/docs/protocol/autoadapt_modes.md b/docs/protocol/autoadapt_modes.md index 5888a9c..d1e6322 100644 --- a/docs/protocol/autoadapt_modes.md +++ b/docs/protocol/autoadapt_modes.md @@ -177,12 +177,9 @@ alpha-hwr control set-autoadapt-combined --value 3.5 ## Testing Methodology -### Hardware Probing +### Testing Methodology ```bash -# Probe for configuration SubIDs -python probe_autoadapt_config.py - # Test mode switching python test_mode_support.py diff --git a/docs/protocol/ble_architecture.md b/docs/protocol/ble_architecture.md index 3ec05a6..a721e6f 100644 --- a/docs/protocol/ble_architecture.md +++ b/docs/protocol/ble_architecture.md @@ -200,7 +200,7 @@ ObjID: 16-bit identifier (big-endian) ### Object IDs and SubIDs -**Key Objects:** +**Objects:** | Object | SubID Range | Type | Purpose | | :--- | :--- | :--- | :--- | @@ -450,7 +450,7 @@ The ALPHA HWR BLE architecture uses: 3. **GENI protocol** for operations (Class 10 DataObjects) 4. **Schedule layers** for application logic (5 independent SubIDs) -**Key Takeaways:** +**Summary:** - Schedule layers are **SubIDs within Object 84**, not separate BLE characteristics - Multi-chunk splitting is **critical** for packets >20 bytes diff --git a/docs/protocol/control_modes.md b/docs/protocol/control_modes.md index 690952d..220c056 100644 --- a/docs/protocol/control_modes.md +++ b/docs/protocol/control_modes.md @@ -1,6 +1,6 @@ # Control Modes - Complete Support Matrix -This document covers all 32 control modes defined in the GENI protocol and their support status on the Grundfos ALPHA HWR pump. +This document provides an overview of all 32 control modes defined in the GENI protocol and their support status on the Grundfos ALPHA HWR pump. ## Executive Summary @@ -184,7 +184,6 @@ alpha-hwr control set-temperature --min 35 --max 39 **Hardware Support:** - Mode switching works reliably (mode byte 0x19, suffix 0x38 0xC6 0x70 0x00) - Successfully operates on ALPHA HWR hardware -- Exposed in Grundfos GO mobile app - Supports configurable ON/OFF durations (1-60 minutes) **Implementation:** @@ -318,7 +317,7 @@ These methods still exist in the service layer for GENI protocol compatibility b ### For Developers 1. **No Further Investigation Needed:** All GENI protocol modes have been verified for ALPHA HWR compatibility. -2. **Mode 25 Protocol:** See issue #14 for ongoing work to reverse engineer cycle time parameter protocol. +2. **Mode 25 Protocol:** See issue #14 for ongoing work to document the cycle time parameter protocol. 3. **Documentation Complete:** Support matrix is fully documented for the 5 ALPHA HWR modes. --- diff --git a/docs/protocol/packet_traces/06_alarms_warnings.md b/docs/protocol/packet_traces/06_alarms_warnings.md index c569c1c..f40b2e6 100644 --- a/docs/protocol/packet_traces/06_alarms_warnings.md +++ b/docs/protocol/packet_traces/06_alarms_warnings.md @@ -196,7 +196,7 @@ All these OpSpecs use the 7-byte header before data: [OpSpec] [Seq-H] [Seq-L] [ID-H] [ID-L] [Res-H] [Res-L] [DataLen] [Data...] ``` -The key difference is that OpSpec 0x09 contains **uint16 codes** rather than **IEEE 754 floats**. +The main difference is that OpSpec 0x09 contains **uint16 codes** rather than **IEEE 754 floats**. ## Integration Notes @@ -235,13 +235,13 @@ text_sensor: ### Initial Confusion (Now Resolved) -Early Python implementations incorrectly expected **OpSpec 0x13** for alarm responses. This was based on speculation before hardware validation. +Early Python implementations incorrectly expected **OpSpec 0x13** for alarm responses. This was based on speculation before testing against actual hardware. -**Hardware validation (ESPHome, Feb 2025)** confirmed that the pump actually responds with **OpSpec 0x09**, using the standard Active Query Response format. +**Testing** confirmed that the pump actually responds with **OpSpec 0x09**, using the standard Active Query Response format. -### Key Discovery +### Discovery -The breakthrough came from analyzing 100+ real packet captures showing consistent OpSpec 0x09 responses with data value `0x0000`, which was initially misinterpreted as "not supported." In reality, `0x0000` simply means "no active alarms." +Testing against real hardware revealed consistent OpSpec 0x09 responses with data value `0x0000`, which was initially misinterpreted as "not supported." In reality, `0x0000` simply means "no active alarms." ## References @@ -254,7 +254,7 @@ The breakthrough came from analyzing 100+ real packet captures showing consisten This documentation is based on: -- 100+ real packet captures from ALPHA HWR pump (Feb 2025) +- Real-world testing with an ALPHA HWR pump - Successful ESPHome C++ implementation (tested on ESP32-C3) - Cross-validation between Python and ESPHome implementations - Protocol documentation at https://eman.github.io/alpha-hwr/reimplementation/ diff --git a/docs/protocol/schedules.md b/docs/protocol/schedules.md index 63c317d..c25df83 100644 --- a/docs/protocol/schedules.md +++ b/docs/protocol/schedules.md @@ -23,7 +23,7 @@ The ALPHA HWR supports **5 independent schedule layers** that allow complex sche - **Layer 3 (SubID 1003)**: Seasonal/temporary adjustments - **Layer 4 (SubID 1004)**: Special events or overrides -**Key Features:** +**Features:** - Each layer contains a full 7-day schedule (42 bytes) - Layers can have **overlapping time windows** (e.g., Layer 0 and Layer 1 both active on Monday) - The pump operates whenever **any layer** is active @@ -118,7 +118,7 @@ await client.delete_schedule() ## Unsupported Features ### Alternative Schedules -Traffic analysis and hardware probing confirmed that "Alternative Schedule" slots (typically associated with SubIDs 1100+) are **not supported** on this firmware version. The `ClockProgramOverview` (Obj 84, Sub 1) reports `max_nof_alternative_events_per_day = 0`. +Testing confirmed that "Alternative Schedule" slots (typically associated with SubIDs 1100+) are **not supported** on this firmware version. The `ClockProgramOverview` (Obj 84, Sub 1) reports `max_nof_alternative_events_per_day = 0`. ## Python Implementation @@ -220,7 +220,7 @@ Different schedule operations require different OpSpec codes: - `0x93` = `(4 << 5) | 19` = OpSpec 4, Length 19 - `0xB3` = `(5 << 5) | 19` = OpSpec 5, Length 19 -**Key Differences:** +**Differences:** - **OpSpec 0x93**: Used for enable/disable (Type 218 ClockProgramOverview, 10 bytes) - **OpSpec 0xB3**: Used for schedule writes (Type 222 ClockProgramWeekDayInterval, 42 bytes) - The OpSpec determines which structure type the pump expects @@ -613,7 +613,7 @@ alpha-hwr schedule ## Schedule Validation -The library validates schedule entries to prevent conflicts and errors. +The library includes validation for schedule entries to prevent conflicts and errors. ### ScheduleEntry Model diff --git a/docs/protocol/telemetry.md b/docs/protocol/telemetry.md index f3e439b..28eb868 100644 --- a/docs/protocol/telemetry.md +++ b/docs/protocol/telemetry.md @@ -151,7 +151,7 @@ Older firmware or specific integration scenarios might require active polling in * **Command**: `READ` (OpCode `0x03`) * **Frame Start**: `0x27` (Request) -### Key Registers +### Registers | Register Address | Name | Data Contained | | :--- | :--- | :--- | diff --git a/docs/reference/data_models.md b/docs/reference/data_models.md index 7764937..e75827a 100644 --- a/docs/reference/data_models.md +++ b/docs/reference/data_models.md @@ -154,7 +154,7 @@ if alarms: ## ScheduleEntry Model -The `ScheduleEntry` class represents a single schedule time window. All fields are validated on construction. +The `ScheduleEntry` class represents a single schedule time window with built-in validation. ### Properties @@ -179,7 +179,7 @@ The `ScheduleEntry` class represents a single schedule time window. All fields a | `begin_time_obj` | `datetime.time` | Begin time as time object | | `end_time_obj` | `datetime.time` | End time as time object | -### Key Methods +### Methods #### Duration and Validation diff --git a/docs/reimplementation/README.md b/docs/reimplementation/README.md index 3bee8d6..6f4bbf4 100644 --- a/docs/reimplementation/README.md +++ b/docs/reimplementation/README.md @@ -33,7 +33,7 @@ The ALPHA HWR pump uses the GENI protocol over Bluetooth Low Energy (BLE). This - Grundfos ALPHA HWR pump (any variant) - BLE-capable computer or device -- BLE debugging tools (nRF Connect, Wireshark with BTLE, etc.) +- BLE debugging tools (nRF Connect, LightBlue, etc.) ## Implementation Approach @@ -116,7 +116,7 @@ graph TD ``` -### Key Concepts +### Concepts #### 1. Authentication The pump requires a specific sequence of "magic packets" to unlock: diff --git a/docs/reimplementation/architecture.md b/docs/reimplementation/architecture.md index 0d61de0..8e8d3ab 100644 --- a/docs/reimplementation/architecture.md +++ b/docs/reimplementation/architecture.md @@ -25,7 +25,7 @@ graph TD - `session.py` - Connection state machine - `transport.py` - BLE send/receive abstraction -**Key Responsibilities**: +**Responsibilities**: - Manage BLE connection lifecycle - Execute authentication sequence - Handle packet transmission/reception @@ -40,7 +40,7 @@ graph TD - `frame_parser.py` - Parse GENI frames - `telemetry_decoder.py` - Decode telemetry payloads -**Key Responsibilities**: +**Responsibilities**: - Build valid GENI protocol packets - Parse received packets - Calculate CRC checksums @@ -56,7 +56,7 @@ graph TD - `schedule.py` - Schedule management - `configuration.py` - Backup/restore -**Key Responsibilities**: +**Responsibilities**: - Expose high-level operations - Handle complex multi-step workflows - Validate inputs @@ -67,7 +67,7 @@ graph TD **File**: `client.py` -**Key Responsibilities**: +**Responsibilities**: - Single entry point for applications - Manage service lifecycles - Handle connection/disconnection @@ -187,7 +187,7 @@ stateDiagram-v2 - **RECEIVING**: Processing notification - **ERROR**: Communication failure -## Key Design Patterns +## Design Patterns ### 1. Layered Architecture Each layer has clear boundaries and responsibilities. Upper layers depend only on adjacent lower layers. diff --git a/docs/reimplementation/checklist.md b/docs/reimplementation/checklist.md index f25c8fb..8799b6f 100644 --- a/docs/reimplementation/checklist.md +++ b/docs/reimplementation/checklist.md @@ -248,7 +248,7 @@ Your implementation is considered **complete** when: - [x] Documentation complete Your implementation is considered **production-ready** when: -- [x] Error handling robust +- [x] Error handling complete - [x] Performance optimized - [x] Security reviewed - [x] Cross-platform tested diff --git a/docs/reimplementation/common_pitfalls.md b/docs/reimplementation/common_pitfalls.md index c1bb6e6..4e24179 100644 --- a/docs/reimplementation/common_pitfalls.md +++ b/docs/reimplementation/common_pitfalls.md @@ -177,7 +177,7 @@ class Transport: self._response_buffer.clear() ``` -**Key Points:** +**Notes:** - Frame start: `0x24` (response) or `0x27` (request) - Expected length: `packet[1] + 4` (length field + start byte + length byte + 2-byte CRC) - Buffer fragments until complete @@ -457,7 +457,7 @@ Decoded floats from offset 13: [5] 0x45653AD0 = 3667.7 RPM (speed) ``` -**Key Differences:** +**Differences:** | Aspect | Passive Notification (0x0E) | Register-Read Response (0x30/0x2b) | |--------|---------------------------|----------------------------------| | **OpSpec** | 0x0E | 0x30, 0x2b, 0x14, etc | @@ -635,7 +635,7 @@ def parse_frame(data): raise InvalidFrame() ``` -**Key:** +**Legend:** - `0x27` = Request (from client to pump) - `0x24` = Response (from pump to client) @@ -899,8 +899,6 @@ assert session.is_authenticated() ### Use BLE Debugging Tools - **nRF Connect** - Monitor BLE traffic -- **Wireshark** - Capture BLE packets -- **Logic Analyzer** - Hardware-level debugging --- diff --git a/docs/reimplementation/layer_by_layer.md b/docs/reimplementation/layer_by_layer.md index 53a50c9..c8df951 100644 --- a/docs/reimplementation/layer_by_layer.md +++ b/docs/reimplementation/layer_by_layer.md @@ -1,6 +1,6 @@ # Layer-by-Layer Implementation Guide -This guide walks through implementing the ALPHA HWR protocol step-by-step, from lowest to highest layer. Follow this order to build a working implementation incrementally with testable milestones at each stage. +This guide walks through implementing the ALPHA HWR protocol step-by-step, from lowest to highest layer. Follow this order to build a working implementation incrementally. ## Table of Contents @@ -78,9 +78,6 @@ async def discover_pump(serial_number=None): raise Exception("Pump not found") ``` -**Test Milestone**: -- [x] Can discover pump by name -- [x] Returns correct device address --- @@ -119,10 +116,6 @@ async def connect_to_pump(device_address): return (client, tx_char, rx_char) ``` -**Test Milestone**: -- [x] Successfully connects to pump -- [x] Discovers GENI service -- [x] Can access TX/RX characteristics --- @@ -143,9 +136,6 @@ async def enable_notifications(client, rx_char): await client.start_notify(rx_char, notification_handler) ``` -**Test Milestone**: -- [x] Notifications enabled without error -- [x] Handler receives data when pump sends --- @@ -171,10 +161,6 @@ async def receive_packet(timeout=5.0): raise TimeoutError("No response from pump") ``` -**Test Milestone**: -- [x] Can send arbitrary bytes -- [x] Can receive responses -- [x] Timeout works correctly --- @@ -217,10 +203,6 @@ assert calc_crc16_modbus(b"\x07\xe7\xf8\x0a\x04\x00\x85") == 0x1202 assert calc_crc16_modbus(b"\x06\xe7\xf8\x00\x67") == 0xE3A3 ``` -**Test Milestone**: -- [x] Matches all test vectors -- [x] Handles empty input -- [x] Handles large inputs --- @@ -259,10 +241,6 @@ assert decode_float_be(bytes([0x3F, 0xC0, 0x00, 0x00])) == 1.5 assert abs(decode_float_be(bytes([0x46, 0x65, 0xB0, 0x00])) - 14710.0) < 0.1 ``` -**Test Milestone**: -- [x] Encodes all test values correctly -- [x] Decodes all test values correctly -- [x] Round-trip conversion (encode → decode) is accurate --- @@ -296,10 +274,6 @@ assert encode_uint16_be(0x0601) == bytes([0x06, 0x01]) assert decode_uint16_be(bytes([0x56, 0x00])) == 0x5600 ``` -**Test Milestone**: -- [x] Encodes correctly -- [x] Decodes correctly -- [x] Handles edge cases (0, max value) --- @@ -384,10 +358,6 @@ assert packet[4] == 0x0A # Class 10 assert len(packet) == 12 # Header (4) + APDU (6) + CRC (2) ``` -**Test Milestone**: -- [x] Builds valid INFO command -- [x] CRC is correct -- [x] Length field is correct --- @@ -450,10 +420,6 @@ assert packet[5] == 0x84 # OpSpec: SET (0x80) + 4 bytes (0x04) assert len(packet) == 16 # Header (4) + APDU (10: class, opspec, ids, data) + CRC (2) ``` -**Test Milestone**: -- [x] Builds valid SET command -- [x] OpSpec encodes data length correctly -- [x] CRC is correct --- @@ -538,10 +504,6 @@ assert frame["obj_id"] == 0x0057 assert len(frame["payload"]) == 4 ``` -**Test Milestone**: -- [x] Parses valid responses -- [x] Detects CRC errors -- [x] Extracts payload correctly --- @@ -592,10 +554,6 @@ async def authenticate(tx_char): await asyncio.sleep(0.1) # Longer delay after final packet ``` -**Test Milestone**: -- [x] Sends all packets without error -- [x] Respects timing delays -- [x] After authentication, commands work See [02_authentication.md](../protocol/packet_traces/02_authentication.md) for detailed explanation. @@ -663,10 +621,6 @@ class Session: raise Exception(f"Operation requires authenticated session, current state: {self.state}") ``` -**Test Milestone**: -- [x] State transitions work correctly -- [x] Guards prevent invalid operations -- [x] Error state is set on failures --- @@ -736,10 +690,6 @@ class TelemetryService: } ``` -**Test Milestone**: -- [x] Successfully reads motor state -- [x] Successfully reads flow/pressure -- [x] Parses values correctly --- @@ -796,10 +746,6 @@ class ControlService: raise Exception("Stop command failed") ``` -**Test Milestone**: -- [x] Successfully sets mode -- [x] Successfully stops pump -- [x] Detects errors --- @@ -857,7 +803,3 @@ async def main(): print(f"Flow: {flow['flow_m3h']} m³/h") ``` -**Test Milestone**: -- [x] Context manager works -- [x] Services accessible -- [x] Clean disconnect diff --git a/docs/troubleshooting/service_discovery.md b/docs/troubleshooting/service_discovery.md index 3947b77..7f75ff6 100644 --- a/docs/troubleshooting/service_discovery.md +++ b/docs/troubleshooting/service_discovery.md @@ -255,7 +255,7 @@ custom_component: - [ ] Authentication packets sent successfully - [ ] Telemetry notifications received -## Key Takeaway +## Summary **The most reliable discovery method is to match by Grundfos Company ID (`0000fe5d-...`) in BLE service data, since all ALPHA HWR pumps advertise this regardless of firmware version. Alternatively, match by device name pattern ("ALPHA_").** From f883909a6ae5f34fb3093cfa7a04d20ffe31960c Mon Sep 17 00:00:00 2001 From: Emmanuel Levijarvi Date: Fri, 15 May 2026 09:03:39 -0700 Subject: [PATCH 2/3] Potential fix for pull request finding Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> --- docs/TESTING_STRATEGY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/TESTING_STRATEGY.md b/docs/TESTING_STRATEGY.md index 998f77e..b19c872 100644 --- a/docs/TESTING_STRATEGY.md +++ b/docs/TESTING_STRATEGY.md @@ -2,7 +2,7 @@ ## Overview -This document describes the testing strategy for the alpha-hwr library, designed to ensure reliability, maintainability, and serve as a reference for other language implementations. +This document describes the testing strategy for the alpha-hwr library, designed to ensure reliability and maintainability, and to serve as a reference for other language implementations. ## Testing Pyramid From 0f69a828c28a7b2beda2fb1b28b1c96127e02c11 Mon Sep 17 00:00:00 2001 From: Emmanuel Levijarvi Date: Fri, 15 May 2026 09:04:23 -0700 Subject: [PATCH 3/3] Potential fix for pull request finding Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> --- docs/protocol/autoadapt_modes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/protocol/autoadapt_modes.md b/docs/protocol/autoadapt_modes.md index d1e6322..e6ff908 100644 --- a/docs/protocol/autoadapt_modes.md +++ b/docs/protocol/autoadapt_modes.md @@ -177,7 +177,7 @@ alpha-hwr control set-autoadapt-combined --value 3.5 ## Testing Methodology -### Testing Methodology +### Test Commands ```bash # Test mode switching