Model support

Adding a Blade model

Each Blade is a separate hardware target with its own evidence and safety checks.

Current admission

Supported models

See supported models and verified firmware in the Protocol reference.

Documentation is not admission The production manifest and typed code remain authoritative.

Record the model name and number, VID/PID, firmware, HID usage, report lengths, and a reliable host check. Never store the laptop serial number.
Match exactly one read-only interface. Reject missing, blocked, ambiguous, or mismatched devices.
Decode safe identity, thermal, fan, battery, lighting, and firmware queries before testing setters. Reject malformed and unknown responses.
Follow the safe testing guide for every value and power state. Save and restore the prior value. Evidence from another model does not count.
Add only typed, verified controls. Missing evidence means no control, not a guessed default. Reuse shared names, but keep byte differences in the model protocol code. Never expose a raw command API.
Test reconnect, sleep and resume, service restart, power changes, malformed replies, other controllers, restoration, and long runs. Then add the model's protocol table, exact firmware scope, and reviewed core revision.

Layer	Contributor responsibility	Failure behavior
Identity	Define the model number, VID/PID, observed BIOS, EC, and MCU versions, validated firmware scope, usage tuples, and exact report lengths.	Reject the device if anything required for admission is missing, mismatched, or ambiguous. Record safely unreadable informational versions as unavailable.
Envelope	Share a report codec only after proving identical status, transaction, class, ID, payload length, checksum, report ID, padding, and terminator behavior.	Reject malformed or unknown responses. Do not turn them into defaults.
Queries	Write typed requests and command-specific response decoders before policy or UI depends on the state.	Hide the capability or power decision when its query is unavailable or unknown.
Setters	Add one named action per sanitized fixture. Include independent readback, or document a one-shot response contract and restoration evidence.	Do not add a raw class, ID, or payload API. A command without evidence stays unavailable.
Capabilities	Expose only commands allowed by the exact identity, admitted fixtures, readable state, power limits, and controller ownership.	A new model may support fewer controls than an older one.
Documentation	Add a model-specific table and the reviewed core revision. Keep response shapes symbolic unless exact bytes explain the contract.	Documentation cannot authorize a command that core has not admitted.

Include sanitized fixtures, decoder and integration tests, restoration evidence, and an interactive validation summary.
Prove that a wrong PID, identity, usage tuple, report length, or ambiguous interface receives no writes.
Document getters and setters separately, including accepted response lengths, value bounds, and readback limits.
State whether confirmation comes from exact readback, generic state, visual observation, or a one-shot response.
Test restart, reconnect, sleep and resume, power changes, and external controllers without write loops.
Verify that the UI and service enforce power limits and that diagnostic exports remain redacted.
Link the documentation change and the reviewed openblade-core revision.
List unsupported and setter-only behavior.
Keep raw captures and local logs private.