[AZ-189] Update coding and testing rules for clarity and consistency

- Revised coding standards to emphasize readability, meaningful comments, and test verification.
- Adjusted test coverage thresholds to 75% for business logic and clarified expectations for test scenarios.
- Enhanced guidelines for handling skipped tests, emphasizing the need for investigation and resolution.
- Updated commit message format and length requirements for better adherence to Git conventions.

Made-with: Cursor

_docs/02_tasks/todo/AZ-197_remove_hardware_id.md

@@ -0,0 +1,70 @@
+# Remove Hardware ID Binding
+
+**Task**: AZ-197_remove_hardware_id
+**Name**: Remove hardware ID binding from resource flow
+**Description**: Remove CheckHardwareHash, UpdateHardware, HardwareService and simplify API encryption key derivation. Sealed Jetsons eliminate the credential-reuse threat this was protecting against.
+**Complexity**: 3 points
+**Dependencies**: None
+**Component**: Admin API, Loader
+**Tracker**: AZ-197
+**Epic**: AZ-181
+
+## Problem
+
+The `Hardware` field on `User` and the `CheckHardwareHash` flow were designed to bind a user account to a specific physical machine, preventing credential reuse across machines when users had desktop installers. With sealed Jetsons (secure boot, fTPM, no user filesystem access, no installers distributed), this threat no longer exists. The hardware binding adds unnecessary complexity and failure modes (HardwareIdMismatch on drive replacement, etc.).
+
+## Outcome
+
+- Simpler resource download flow without hardware fingerprint requirement
+- Simpler API encryption key derivation (email + password only)
+- Removal of dead code paths related to hardware binding
+- Fewer failure modes in production
+
+## Scope
+
+### Admin API changes
+
+- Remove `CheckHardwareHash` and `UpdateHardware` from `IUserService` / `UserService`
+- Remove `PUT /users/hardware/set` endpoint from `Program.cs`
+- Simplify `POST /resources/get/{dataFolder}`: remove `request.Hardware` parameter, derive encryption key without hardware hash
+- Simplify `POST /resources/check`: remove hardware check entirely (or remove the endpoint if unused)
+- Update `Security.GetApiEncryptionKey` to not require `hardwareHash` parameter
+- Remove or deprecate `Security.GetHWHash`
+- Leave `User.Hardware` column nullable in DB (no migration needed, just stop writing/reading it)
+- Remove `SetHWRequest` DTO
+- Remove `HardwareIdMismatch` and `BadHardware` from `ExceptionEnum`
+
+### Loader client changes
+
+- Remove `HardwareService` class (`hardware_service.pyx`, `hardware_service.pxd`)
+- Update `api_client.pyx` `load_bytes`: stop gathering hardware info, stop sending `hardware` field in resource request
+- Update `security.pyx` `get_api_encryption_key`: remove `hardware_hash` parameter
+- Update `security_provider.py`, `tpm_security_provider.py`, `legacy_security_provider.py`: remove `get_hw_hash` and update `get_api_encryption_key` signature
+- Update `GetResourceRequest` validator to not require Hardware field
+
+### Excluded
+
+- Database migration to drop the `hardware` column (leave nullable, stop using it)
+- Changes to user registration or login flow
+
+## Acceptance Criteria
+
+**AC-1: Resource download works without hardware**
+Given a provisioned device with valid email and password
+When the loader calls POST /resources/get without a hardware field
+Then the resource is returned and can be decrypted using email + password only
+
+**AC-2: No hardware endpoints remain**
+Given the updated admin API
+When PUT /users/hardware/set is called
+Then 404 is returned
+
+**AC-3: Encryption key derivation is simplified**
+Given the updated Security class
+When GetApiEncryptionKey is called
+Then it derives the key from email + password only (no hardware hash)
+
+**AC-4: HardwareService removed from loader**
+Given the updated loader codebase
+When the build is run
+Then it compiles without hardware_service.pyx/pxd