clangd's database is the one CMake Tools copies from the selected preset,
as in libavr, rather than one chip's tree. .gitattributes drops two Studio
patterns nothing here matches, .clangd is ASCII, and the comments in it,
check.sh and .gitattributes state the reason without the account of how it
was found.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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>
BlackMarkandClaude Opus 5.5