say that VIA can save lighting to EEPROM, and that this tool does not

The README claimed the keyboard's VIA protocol "does not expose a
standard command to save RGB state to internal EEPROM, so profiles
rely on files instead". The command exists: id_custom_save is 0x09 and
id_eeprom_reset is 0x0A, both in QMK's quantum/via.h and both
implemented in quantum/via.c, one case per lighting channel.

This tool sends neither. internal/via/protocol.go defines 0x07 and 0x08
and nothing else, so the corrected claim is smaller than the false one
rather than a feature: the commands are there, the tool does not use
them yet, and 0x0A is compiled out unless the keymap asks for it.

A profile is still the right thing for a file, for reasons that have
nothing to do with EEPROM: it names a board's effects, it applies to
another board, and it survives a reflash.

README.md

@@ -880,7 +880,7 @@ board", and that file is gone, so the field would have been unanswerable:
 | `qmk-rgb-tool info [zone]`             | Show per-zone RGB state; without a zone, every channel |
 | `qmk-rgb-tool effect <zone> [name\|index]` | Set an effect by name, or a raw effect index 0–255, verified by read-back; a board that does not implement the index clamps it to the highest it does |
 | `qmk-rgb-tool effect <zone>`           | With no name, list the effects that zone has; `effect all` lists every channel |
-| `qmk-rgb-tool keyboard fetch`         | Download the VIA definition for the connected keyboard |
+| `qmk-rgb-tool keyboard fetch`         | Download the VIA definition for the connected keyboard. A definition already stored for that board is not replaced, because it may be one you have edited; `--force` overwrites it |
 | `qmk-rgb-tool keyboard definitions`   | List every definition in use, from the per-user directory and built into the binary, each marked with which it is |
 | `qmk-rgb-tool brightness <zone> <val>` | Set brightness (0–255) on the named zones, verified by read-back |
 | `qmk-rgb-tool speed <zone> <val>`     | Set effect speed (0–255) on the named zones, verified by read-back; on `logo` and `side` only 0, 1 and 4 are reachable |
@@ -949,10 +949,36 @@ which keyboard. A profile written before this field existed has no board and is
 loaded without complaint. The keys are the names the file was written with, so
 a profile written before a board was renamed reports the key it cannot place and
 skips it. `load` applies the zones the profile names, and a second argument
-narrows that to the channels it names. They are the only way to persist RGB
-settings across reboots. The keyboard's VIA protocol does not expose a
-standard command to save RGB state to internal EEPROM, so profiles rely on
-files instead.
+narrows that to the channels it names.
+
+A profile is a file because a file is portable: it names a board's effects, it
+can be applied to another board, and it survives the keyboard being reflashed.
+The keyboard has a second, different way to keep lighting settings, which a
+profile does not replace — see [Saving on the Keyboard](#saving-on-the-keyboard).
+
+## Saving on the Keyboard
+
+A profile is a file, and a file is the portable answer: it names a board's
+effects, it applies to another board, and it survives a reflash. A keyboard has a
+second, different way to keep lighting settings, and VIA already has the commands
+for it. This tool does not send them yet, which is stated here because the earlier
+version of this document claimed they did not exist.
+
+| Command | ID | What it does |
+|---|---:|---|
+| `id_custom_save` | `0x09` | writes one channel's current lighting configuration to the keyboard's EEPROM |
+| `id_eeprom_reset` | `0x0A` | resets the VIA area of the EEPROM, behind the firmware's `VIA_EEPROM_ALLOW_RESET` |
+
+Both are in QMK's `quantum/via.h` and implemented in `quantum/via.c`, one case
+per lighting channel. The difference from a profile is what they are for: they
+make the keyboard hold its lighting across a power cycle and a reset on its own,
+with no host involved, where a profile has to be applied by something.
+
+Neither is sent by this tool — `internal/via/protocol.go` defines `0x07` and
+`0x08` and nothing else — and it cannot be assumed that a given keyboard has
+them: `0x0A` is compiled out unless the keymap asks for it. A caller can tell,
+because the response is the command byte, and `0xFF` when the firmware does not
+handle it.
 
 ## Architecture
 

definitions/README.md

@@ -9,6 +9,13 @@ This is not the directory the tool reads at runtime. That is the per-user
 there, and a file placed there — or passed with `--definition` — takes precedence
 over the one built in. To use or correct a definition, put it there, not here.
 
+`keyboard fetch` does not replace a file that is already in the per-user
+directory, because that file may be one you have edited and nothing on disk says
+which it is. It refuses and names the file; `--force` overwrites. A board's file
+is recognised by the `vendorId`/`productId` it carries, so the check follows a
+renamed file too, and `--force` removes the file it replaced rather than leaving
+two files for one board.
+
 ## What belongs here
 
 A board's file, only when VIA's own collection does not carry that board, kept as