Safe testing

Capture, verify, restore

Change one reversible setting at a time. Record the old value, check the result, then restore it.

Before any write

Protect the hardware

Do not test unknown setters. Use the typed developer CLI for one reversible change at a time.

Stop immediately Stop if the device, power state, response, readback, or saved value becomes unclear.

Record the current value, target value, expected result, and restore value. Use a separate capture for each setting or power state.
Confirm the model, VID/PID, BIOS, EC, MCU, HID usage, and feature-report length. Record a safely unreadable version as unavailable rather than guessing. A display name is not enough.
Close unrelated activity and set the required AC, battery, USB-C, HDR, or display state.
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 and mark the action in the capture. Do not open other pages in the vendor app while recording.
Confirm the new state, restore the saved value, and confirm it again before ending the session.
Compare the smallest useful packet window. Keep the model, action, bounded payload, response shape, and evidence checks. Remove serials, paths, session data, and unrelated packets.
Use a typed command that names the action, saves the old value, asks for confirmation, applies and checks one value, then restores it.
Add support only after decoder tests, negative tests, application, confirmation, and restoration pass. 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?	The change repeats in another capture and is absent from a no-op window.
Response	Did firmware acknowledge the same transaction and payload contract?	The envelope, status, checksum, class, ID, length, and payload all pass validation.
Getter	Can firmware independently report the effect?	Known states decode to different values. Otherwise, document setter-only or generic readback.
Application	Did the physical behavior change as intended?	What happened on the laptop matches the typed target.
Restoration	Can the exact prior state be recovered?	The restore command succeeds, and readback or observation matches the saved state.
Negative cases	What must be rejected?	A wrong PID, model, or interface fails closed. So do malformed responses, invalid values, unsupported combinations, and cancellation.

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.

From capture to production

Move on only after the current stage passes.

Decode a private capture from a sanitized byte window while no device handle is open.
Add a typed read-only query with an exact response contract. Reject unknown statuses, lengths, selectors, reserved bytes, and values.
Repeat the same vendor UI state and prove the candidate setter is absent or stable when nothing changes.
Save the prior state, require confirmation for the exact target, apply one admitted value, read or observe it, then restore it.
Link the sanitized fixture and validation result to reviewed source before production use. Expose only the named capability.

Response evidence record

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

Model / VID:PID:
BIOS / EC / MCU:
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 observed BIOS, EC, and MCU versions, 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, EC, MCU 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