Contributing

Contributing a protocol finding

The protocol is mapped, not documented by the vendor. A device does something on the wire, you observe it, and it becomes a record the whole crate can read. This is how that lands in the code.

One catalog entry

A new finding is usually a single entry in src/catalog.rs, in the same shape as the reference's own tables:

AUTO_AWARE: bool = (0x01, 0x1d) "auto aware mode"
    read  Confirmed, codec::flag,
    write Unknown,   None,
    note  "drops the mode to transparency on its own";

That is the whole change. The surface probe picks it up, bose-connect catalog lists it, cargo doc documents it, and dev.get(&AUTO_AWARE) works. A named accessor in src/api.rs is optional and one line:

pub fn auto_aware(&mut self) -> Result<bool> { self.get(&AUTO_AWARE) }

Add the bytes you observed to the matching device in src/fixtures.rs, and the test suite covers the entry without hardware.

Evidence gates the write

read and write each carry how well that direction is understood, and only Confirmed is writable:

evidence	meaning
Confirmed	a write changed what a read returned
Syntax("…")	seen on the wire; the effect was never verified
Ineffective("…")	the form is accepted and changes nothing
Unknown	no format

So the writes the crate refuses are not special cases in the code — they are table entries. Device::set returns the entry's own reason string, which is the error the user reads, rather than sending a guessed format. That encodes the reference's lesson: a capture establishes the syntax, not the semantics. Do not mark a write Confirmed until you have watched it change a read.

Before the pull request

• cargo test and cargo clippy are clean.
• One topic per PR, branched off main — plain GitHub flow.
• The catalog note is copied verbatim from the reference where one exists, so the two can be diffed.

See the library guide for the layering the entry fits into.