Interface: DeviceEntry

A device entry in a driver's registry.

Each driver's data/devices.json lists entries of this shape. The driver still owns the data; contracts owns only the shape.

Extended by

ExpandedDeviceEntry

Properties

Property	Type	Description
`capabilities?`	`Readonly`<`Record`<`string`, `unknown`>>	Chassis-level capability flags — properties of the box, not the printhead. Most boolean capabilities are engine-level; this bag is for genuinely chassis-y things (Brother's `editorLite` USB-Mass-Storage trick, eventual battery / display flags). Open shape so drivers can extend without touching contracts.
`engines`	readonly `PrintEngine`[]	Print engines in this device. Always an array, never empty — single-engine devices fabricate a `'primary'` entry. Composite devices (Duo, Twin) carry one entry per independent engine.
`family`	`string`	Driver family this device belongs to, e.g. `'labelwriter'`.
`hardwareQuirks?`	`string`	In-source hardware quirks — immutable facts about the chassis. Distinct from `support.quirks`, which is editorial and changes with firmware revisions. Example: "PID collides with the LabelManager PnP variant; needs usb_modeswitch on Linux".
`key`	`string`	Stable key used as the registry export name (e.g. `'LW_450'`).
`modelNames?`	readonly `string`[]	Self-reported identity, network-management side: the model strings the device reports about itself, without vendor prefix. Sources are the IEEE-1284 device ID `MDL:` field, mDNS TXT `usb_MDL`, IPP `printer-device-id`, and SNMP `hrDeviceDescr` / `sysDescr`; the vendor word in front of them (`Brother QL-820NWB`) is stripped by the matcher, not stored here. Defaults to `[name]`. Set it only when the marketing name differs from the wire name: Brother reports `QL-820NWB` for the entry named `QL-820NWBc`, so that entry carries `modelNames: ['QL-820NWB', 'QL-820NWBc']`. Matching is by whole token, longest candidate first, so `QL-800` never matches a `QL-8000`-style longer name. Consumed by `matchModelName` in `@thermal-label/transport`. A sibling field for the wire-protocol side (the model code a printer answers with to a driver-specific identity query, e.g. niimbot's `PrinterInfo(0x08)`) is a separate concern and lands as its own field when a driver needs it; do not encode numeric protocol codes here.
`name`	`string`	Human-readable model name, e.g. `'LabelWriter 450'`.
~~`support`~~	`DeviceSupport`	Always defined; defaults to `{ status: 'untested' }`. Deprecated Author `verifications` instead. Kept populated by codegen (synthesised from `verifications` if present, else mapped from legacy authoring) so existing consumers keep working unchanged. Removed in the cleanup PR once all drivers migrate.
`transports`	`DeviceTransports`	Wire-protocol transports this device exposes.
`verifications?`	`Partial`<`Record`<`TransportType`, `VerificationCell`>>	Per-transport stored verifications. Authored by hardware-report PRs; expanded at codegen time into a derived grid (see `expandVerifications` in `./expand.js`). When absent, codegen falls back to legacy `support.status`.