Safe testing

Capture, verify, restore

Change one reversible setting at a time. Save the old value, verify the result, and restore it.

Protect the hardwareDo not try unknown setters. Use the typed developer CLI and stop if the device, power state, response, or saved value is unclear.

Plan one change. Record the current value, target value, expected result, and restore value. Use a separate capture for each setting or power state.
Identify the device. Confirm the model, VID/PID, BIOS, HID usage, and feature-report length. A display name is not enough.
Prepare the test. Close unrelated activity and set the required AC, battery, USB-C, HDR, or display state.
Start an isolated capture. Run USBPcapCMD in its own console process group and stop it with a targeted CTRL_BREAK_EVENT. Never broadcast a console control event to process-group ID 0.
Change one setting. Record an annotation around the action. Do not use other pages in the vendor app during the capture.
Verify and restore. Confirm the new state, restore the saved value, and confirm it again before ending the session.
Decode and sanitize. Compare the smallest relevant packet window. Keep the model, action, bounded payload, response shape, and evidence checks. Remove serials, paths, session data, and unrelated packets.
Validate the typed command. The command must show the action, save the old value, ask for confirmation, apply one value, check it, restore it, and report each result.
Add support only after it passes. Require decoder tests, negative tests, a successful application, confirmation, and restoration. Never expose raw class, ID, or payload inputs.

Capture matrix

Evidence	Required question	Pass condition
Setter delta	Which request changed when one UI value changed?	Stable across a repeat capture and absent from a no-op control window.
Response	Did firmware acknowledge the same transaction and payload contract?	Envelope, status, checksum, class, ID, length, and payload validator pass.
Getter	Can firmware independently report the effect?	Different known states decode distinctly. Otherwise document setter-only or generic readback.
Application	Did the physical behavior change as intended?	Interactive observation matches the typed target.
Restoration	Can the exact prior state be recovered?	Restore command succeeds and readback/observation matches the saved state.
Negative cases	What must be rejected?	Wrong PID/model/interface, malformed response, invalid value, unsupported combination, and cancellation fail closed.

Decoding rules

Compare payload bytes only after validating the 90-byte envelope.
Keep channel/selector bytes symbolic instead of cloning nearly identical code.
Distinguish an exact readback from a generic firmware state. Manual fan modes are a current example.
Separate firmware-backed effects from software-rendered frame streams.
Never infer a setter from a getter by simply clearing the high bit.
Never assume an older Blade implementation is valid for the current PID.

Testing order

Complete each stage before moving to the next. If a check fails, return to the previous stage.

Offline decode. Work from a private capture and a sanitized byte window. No device handle is open.
Read-only replay. Add a typed query with an exact response contract. Reject unknown statuses, lengths, selectors, reserved bytes, and values.
No-op observation. Repeat the same vendor UI state and prove the candidate setter is absent or stable in a no-change window.
Reversible typed validation. Save prior state, require the exact-target confirmation, apply one admitted value, read or observe it, then restore.
Production support. Link the sanitized fixture and validation result to reviewed source. Expose only the named capability.

Response evidence record

Add this record to the core change. Keep raw PCAP files and local logs private.

Model / VID:PID / BIOS:
HID usage page / usage / feature-report length:
Question and single UI action:
Power source and required preconditions:
Request class/ID and sanitized payload shape:
Expected status, class/ID, payload length and response shape:
Unknown or malformed values rejected:
Independent getter, generic readback, or one-shot-only:
Saved prior state and restoration result:
Negative controls and repeat count:
Core tests and sanitized fixture paths:
Remaining inference or unsupported variants:

Private evidence handling

Keep private

PCAP files, HID paths, serials, transaction streams, user or machine names, local paths, diagnostic exports, screenshots with account data, and unreviewed payload collections.

Publish after review

Model and firmware scope, usage and report length, action name, class/ID, bounded payload shape, accepted response, readback limits, tests, and restoration result.

Stop conditions

The exact host model, VID/PID, HID interface, or feature-report length no longer matches.
The prior value cannot be read or recovered, or a setter has no bounded restoration plan.
Two nominally identical captures disagree outside the transaction identifier or another understood field.
A response has an unknown status, checksum, class, ID, length, selector, reserved byte, or enum value.
Another controller changes the same subsystem during validation.
Stopping capture would require broadcasting a console control event or killing an unverified process.

Review checklist

[ ] Exact model, VID/PID, BIOS and HID interface documented
[ ] One action per capture and a no-op comparison available
[ ] Prior state saved and restoration verified
[ ] Request and response envelope validation implemented
[ ] Payload bounds and enum/value validation implemented
[ ] Timeout, cancellation and malformed-response tests included
[ ] Fixture contains no serial, HID path, user path or raw PCAP
[ ] Capability remains hidden when evidence is absent
[ ] No raw-command IPC or production CLI option introduced