The pin moves to libavr's USI I2C rate fix and to the two override surfaces the
fan-controller port filed - a PWM solve that can be pinned, and a capture edge
that is a value rather than a template argument. Nothing here names any of
them; four presets green and no image moved.
`tools/check.sh` is new, and its absence was the defect: this repository had no
committed gate at all, so "run the suite" was a snippet somebody remembered -
and the order in a snippet is the one thing nobody re-derives. Every preset
built before any is tested is subtle and load-bearing, because the
mode-identity check reads the sibling mode's tree and a build-then-test-per-
preset run holds a fresh image against a stale sibling. The loop is libavr's
`tools/check-presets.sh`; nothing is written after the call, there being nothing
beyond the presets this repository knows to ask.
And `.vscode/settings.json` stops naming a toolchain prefix. It named
`D:/dev/libavr/local/toolchain/avr-gcc-16.1.0-mingw`: a path true of one machine
(libavr guidance rule 50) and, since the in-repo toolchain copies went, true of
none. `local/machine.cmake` is where a checkout says that, and it already did.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The three files libavr's consumers carry: .vscode/settings.json names the
atmega328p-generated database and passes --query-driver, .clangd holds the
stand-ins clang needs for GCC's AVR dialect -- and no database, because this
driver is made to be vendored and the file travels with it -- and
extensions.json names the two extensions. The libavr pin advances to the
editor-audit fixes, without which every TU inherits device.hpp's
alias-shadowing errors. The preset builds green from the pin and clangd
reports zero errors on the example TU.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
