clang-tidy-diff still analyses the runner's Catch2, not one the repository pins (#666's first closing condition)

[Yaraslaut]

PR #673 closes #666 by its second closing condition — the clang-tidy-diff job
now asserts the Catch2 it analyses against (scripts/check_catch2_pin.sh . --strict), and a workstation run of the same script prints the divergence
instead of staying silent. That makes the divergence loud. It does not remove
it.

#666's first closing condition is the stronger one and is still open:

Close it if the job stops depending on the runner's Catch2 — e.g. the
clang-tidy job builds Catch2 from the version CMakeLists.txt already pins
for FetchContent (v3.8.1) rather than apt-get install catch2, so local and
CI analyse the same expansion.

If the job analysed a Catch2 the repository pins, a local run of the job's own
configure would analyse the same headers, and there would be nothing for a gate
to report. The gate in #673 is the second-best outcome: it tells you the two
measurements differ, it cannot make them agree.

What it would take

Removing catch2 from the clang-tidy job's apt-get install line is not
sufficient on its own, for two reasons:

1. A workstation with a system Catch2 still diverges. CMakeLists.txt:560
   is find_package(Catch2 CONFIG QUIET) with the FetchContent v3.8.1
   fallback only on NOT Catch2_FOUND. A contributor with a distribution
   Catch2 (3.16.0 here) would keep getting theirs. Forcing the pinned one needs
   something like CMAKE_DISABLE_FIND_PACKAGE_Catch2=ON in that job's
   configure, or a morph-level option.
2. examples/common/CMakeLists.txt calls find_package(Catch2 3 CONFIG QUIET) and treats "not found" as a hard FATAL_ERROR, relying on the
   Tests section's FetchContent having already resolved one
   (CMakeLists.txt:618-627). Whether that second find_package still
   succeeds under CMAKE_DISABLE_FIND_PACKAGE_Catch2=ON — FetchContent's
   CMAKE_FIND_PACKAGE_REDIRECTS_DIR config would normally satisfy it, and
   CMAKE_DISABLE_FIND_PACKAGE_<Pkg> would normally block even that — is the
   question that decides whether this is a one-line change or a restructuring.

The clang-tidy job turns MORPH_BUILD_LADDER on, so it goes through that
examples/common path.

Verification status

• Inferred from reading, not measured. Nothing here was built: the
  reasoning is from CMakeLists.txt:558-572 and :615-627 plus the
  clang-tidy job's configure flags in .github/workflows/ci.yml.
• Measured (in tests/ci: a race regression test that detects its race, and a Catch2 version that is checked rather than asserted (fixes #668, fixes #666, refs #667) #673, on 7a343e6f): ubuntu-24.04's package is
  catch2 3.4.0-1build1 (Launchpad, noble Release pocket, no -updates
  publication), and this workstation has 3.16.0. That the two differ is the
  premise; that the difference changes a clang-tidy outcome is clang-tidy-diff run locally is silently blind to Catch2 TEST_CASE cognitive-complexity findings the CI job reports #666's own
  measurement, not re-run here.
• Not verified: whether CMAKE_DISABLE_FIND_PACKAGE_Catch2=ON breaks
  examples/common, which is the one thing that decides the size of this. One
  configure of the clang-tidy job's own flag set would settle it.
• Not attempted here: examples/common/CMakeLists.txt is held by PR bank/gui + ci: clear the eleven bank-GUI sources' clang-tidy debt, and gate the Q_OBJECT header split that no build catches early (fixes #656, fixes #659) #665.

What would change the verdict

• Close as fixed when the clang-tidy-diff job's compile database resolves
  Catch2 to a version this repository pins, demonstrated by
  scripts/check_catch2_pin.sh finding the pinned version rather than apt's —
  and by a local run of the job's configure producing the same version on a
  machine that has a different distribution Catch2 installed.
• Close as invalid if the configure turns out not to be able to reach that
  state without the ladder losing its Catch2, in which case the finding is that
  the ladder's find_package coupling is the blocker and that is the better
  ticket.
• Reduce in scope if the divergence turns out not to be version-driven at
  all — clang-tidy-diff run locally is silently blind to Catch2 TEST_CASE cognitive-complexity findings the CI job reports #666 notes its own evidence (3.5.3 headers ahead on -isystem restore
  CI's behaviour) is consistent with a path-ordering explanation it did not
  exclude.

Found while closing #666 in PR #673; filed rather than folded in, per AGENTS.md.

🤖 Generated with Claude Code

https://claude.ai/code/session_01VptDWG2fKr2vBnLSJcgzgW

[Yaraslaut]

Triage: valid — the mechanism is confirmed, and this is the root the other two were symptoms of

CMakeLists.txt:560:                 find_package(Catch2 CONFIG QUIET)
examples/common/CMakeLists.txt:169: find_package(Catch2 3 CONFIG QUIET)
.github/workflows/ci.yml:251,259,417,574,786:  sudo apt-get install -y ... catch2

So the build resolves Catch2 from whatever the runner has, the compile database records those include paths, and clang-tidy-diff analyses test TUs against the runner's Catch2 — not one this repository chose or can reproduce.

triage: valid, enhancement, area: ci.

Why this ranks above #666 rather than beside it

#666 is the observable symptom: a local clang-tidy-diff is silently green on a diff CI fails. #673's check_catch2_pin.sh closes #666's second closing condition — it makes the divergence loud. This ticket is the first one: stop the divergence existing.

And the three are now distinguishable in a way they were not this morning:

• tests/.clang-tidy (and nine copies) name the wrong Catch2 version for the clang-tidy job #667 turned out invalid — the version claim in the nine .clang-tidy files was correct all along; CI installs 3.4.0, verified against the v3.4.0 tag. My own triage of it was wrong and is corrected there.
• clang-tidy-diff run locally is silently blind to Catch2 TEST_CASE cognitive-complexity findings the CI job reports #666 is real and is being mitigated, not fixed, by a warning.
• This is the thing that would make the warning unnecessary.

That ordering matters for whoever picks this up: a fix here retires #666's gate rather than duplicating it, and the gate should be removed or reduced in the same change if so.

For whoever takes it

• CMAKE_DISABLE_FIND_PACKAGE_Catch2 plus a fetched, pinned Catch2 is the shape the filer names, and it is the one that makes local and CI agree by construction. The cost is build time on every leg that currently gets Catch2 from apt in seconds, and that cost should be measured before committing to it — it lands on far more legs than the clang-tidy one.
• examples/common/CMakeLists.txt is free now (bank/gui + ci: clear the eleven bank-GUI sources' clang-tidy debt, and gate the Q_OBJECT header split that no build catches early (fixes #656, fixes #659) #665 merged), but .github/workflows/ci.yml is held by PR tests/ci: a race regression test that detects its race, and a Catch2 version that is checked rather than asserted (fixes #668, fixes #666, refs #667) #673 until that lands.
• Whatever you do must keep scripts/check_catch2_pin.sh (tests/ci: a race regression test that detects its race, and a Catch2 version that is checked rather than asserted (fixes #668, fixes #666, refs #667) #673) honest — either it keeps checking a real pin, or it goes away with its reason recorded. A gate left asserting a version nothing installs is the failure this cluster is made of.

Verification status: the filer says "inferred from reading, nothing built", and my check above is also static — I confirmed the find_package calls and the apt installs, not the resulting compile-database entries. The direct measurement is one grep for catch2 in a CI compile_commands.json, and nobody has run it.

What would change the verdict

Close as invalid if the compile database turns out not to carry Catch2 include paths at all — e.g. if the test TUs reach it only through a target property clang-tidy never sees. That would mean the divergence has some other cause, and #666's mechanism paragraph would need rewriting rather than this ticket implementing.

🤖 Generated with Claude Code

https://claude.ai/code/session_01VptDWG2fKr2vBnLSJcgzgW

[Yaraslaut]

Handed back, not rejected — with a design that is measured and works, and three facts the ticket does not have

Worked in the laneINSTALL-batch-681-674 lane alongside #681. #681 landed; this one is handed back deliberately. Everything below was measured on 7d4ca453 (clang 22.1.8, cmake 4.4.3, Arch Linux, 12 cores), unless it says otherwise.

1. The stated mechanism is wrong in detail — but the ticket is still valid

The ticket and my own triage both say the compile database records the runner's Catch2 include paths. It does not record any.

$ cmake -S . -B b-sys -G Ninja -DMORPH_BUILD_TESTS=ON -DCMAKE_EXPORT_COMPILE_COMMANDS=ON
$ python3 -c "... print tokens containing 'catch2' for tests/testkit/catch_main.cpp ..."
[]

The full command for that TU carries -I<repo>/tests -I<repo>/include -isystem <build>/_deps/glaze-src/include and nothing else. find_package(Catch2) resolves to an imported target whose INTERFACE_INCLUDE_DIRECTORIES is /usr/include, which CMake omits from the command line because it is an implicit compiler directory.

So the real mechanism is: #include <catch2/...> is resolved by the compiler's default system include path, which is apt's 3.4.0 on the runner and whatever the developer has locally. The effect is identical to what the ticket describes and the fix is the same, but the ticket's "what would change the verdict" reads

Close as invalid if the compile database turns out not to carry Catch2 include paths at all

which, read literally, this measurement satisfies. It should not close as invalid: the divergence is real, it is just one level lower than stated. Recording it because AGENTS.md asks for findings that contradict the work.

2. CMAKE_DISABLE_FIND_PACKAGE_Catch2 + a fetched Catch2, exactly as the ticket names it, makes clang-tidy much worse

A fetched Catch2's include directory arrives as -I, not as an implicit system directory. clang-tidy then treats every Catch2 macro expansion as user code. On one test TU:

$ clang-tidy -p <system-catch2 build>  --quiet tests/test_executor.cpp
      1 [performance-unnecessary-value-param,-warnings-as-errors]

$ clang-tidy -p <fetched-catch2 build> --quiet tests/test_executor.cpp
     21 [cppcoreguidelines-avoid-do-while,-warnings-as-errors]
     11 [misc-use-anonymous-namespace,-warnings-as-errors]
      1 [performance-unnecessary-value-param,-warnings-as-errors]

1 finding becomes 45, all 44 new ones out of REQUIRE and TEST_CASE expansions, across 134 tests/ TUs plus every example suite. Shipped as written, the ticket's shape turns the clang-tidy job permanently red.

The missing ingredient is SYSTEM. Rewriting the same compile database's Catch2 -I to -isystem restores the baseline exactly:

$ clang-tidy -p <fetched build, catch2 -I rewritten to -isystem> --quiet tests/test_executor.cpp
      1 [performance-unnecessary-value-param,-warnings-as-errors]

3. The design that works, verified end to end

    include(FetchContent)
    include(cmake/DepCache.cmake)
    morph_cache_dep(Catch2 https://github.com/catchorg/Catch2.git v3.8.1)
    FetchContent_Declare(
        Catch2
        GIT_REPOSITORY https://github.com/catchorg/Catch2.git
        GIT_TAG        v3.8.1
        GIT_SHALLOW    TRUE
        SYSTEM
    )
    FetchContent_MakeAvailable(Catch2)

i.e. delete find_package(Catch2 CONFIG QUIET) at CMakeLists.txt:560 and always fetch, with SYSTEM (CMake 3.25+; the project already requires 3.25). Measured with that patch applied:

• the compile database carries -isystem <build>/_deps/catch2-src/src/catch2/.. -isystem <build>/_deps/catch2-build/generated-includes;
• clang-tidy -p <build> tests/test_executor.cpp reports 1 finding — byte-for-byte the system-Catch2 baseline;
• the whole suite builds and passes against v3.8.1: 100% tests passed out of 1564, Total Test time (real) = 70.06 sec.

FetchContent_MakeAvailable also writes a find_package redirect, so examples/common/CMakeLists.txt:169's find_package(Catch2 3 CONFIG QUIET) still resolves — not verified, because configuring the ladder locally needs ODBC/yaml-cpp/Qt that this box does not have. It should be replaced by a TARGET Catch2::Catch2WithMain check rather than left to the redirect.

4. The build-time cost, measured

Cold, no compiler cache, -j4 (the hosted runners' vCPU count), clang 22.1.8, Debug, C++23:

shallow clone of v3.8.1	1.7 s (0 s on a self-hosted runner: cmake/DepCache.cmake caches it)
configure delta	0.5 s
build Catch2 + morph_test_main, 108 objects, -j4	98.5 s
same at -j12	18.4 s

17 Linux legs install catch2 from apt today (linux-compilers ×4, linux-sanitizers ×3, linux-coverage, kanban-tsan, bank-sanitizers, linux-qt, ladder-tests, ladder-sanitizers, linux-all-features ×2, valgrind, clang-tidy). Cold cost is therefore ~1.7 min of added wall time per leg, and because the legs run in parallel the critical path grows by about that much — roughly 3-7% of a 26-74 min run — plus ~28 runner-minutes.

Inferred, not measured: warm runs should cost near zero. cmake/CompileCache.cmake is included at CMakeLists.txt:117 and sets CMAKE_CXX_COMPILER_LAUNCHER as a directory-scope variable, which the Catch2 subdirectory added at line 563 inherits, so sccache caches those 108 objects per preset like any others. I did not verify this on a runner.

My reading: the build-time cost is acceptable. That is not why this is handed back.

5. Why it is handed back: it cannot be done without the nine .clang-tidy files, and one of them is another lane's

v3.8.1 already carries the NOLINT the nine files say arrived in 3.15.3:

$ grep -rn "NOLINT(bugprone-chained-comparison)" _deps/catch2-src/src/catch2/
internal/catch_test_macro_impl.hpp:50: catchAssertionHandler.handleExpr( Catch::Decomposer() <= __VA_ARGS__ ); /* NOLINT(bugprone-chained-comparison) */ \

and a probe TU containing one REQUIRE(a == b) confirms the consequence:

catch2 3.16.0 (/usr/include, implicit system) ..... 0 bugprone-chained-comparison
fetched 3.8.1 via -I    (user headers) ............ 0 bugprone-chained-comparison
fetched 3.8.1 via -isystem ........................ 0 bugprone-chained-comparison

So pinning v3.8.1 makes the single suppression in all nine */tests/.clang-tidy files inert, and makes their prose — CI pins catch2 3.4.0 -- ubuntu-24.04's package, which predates that comment — false. The change therefore has to rewrite all nine, and retire scripts/check_catch2_pin.sh (207 lines) plus scripts/test_check_catch2_pin.sh, or re-point the gate at the CMake pin, in which case all nine must state the new version or the gate's Rule B rejects them.

One of those nine is examples/bank/tests/.clang-tidy, and examples/bank/** is held by a concurrent lane. There is no version of this change that lands complete and leaves that file alone:

• leave it and delete the gate → a false sentence about the pin, unchecked, in the tree;
• leave it and reduce the gate → the gate fails on it, red CI;
• change it → cross-lane edit, which this lane is bound not to make.

Shipping the CMake half now and the nine files later is exactly the "two mechanisms claiming the same thing" the ticket warns against, so I did not.

Side finding, already true on master: because the current code falls back to fetching v3.8.1 whenever no system Catch2 is present, any contributor without the distro package already has those nine suppressions inert today. Their justification is environment-dependent on 7d4ca453, before anything here changes.

What the next lane needs

1. Coordinate the bank file, or take the batch when the BANK lane is idle.
2. Apply §3 verbatim; it is measured, not proposed.
3. Decide the pin: v3.8.1 (nine suppressions die, and should be deleted rather than left) or v3.4.0 (byte-identical to today's CI behaviour, nine suppressions stay live, but pins a 2023 release and is untested against clang 22/C++23 here).
4. Drop catch2 from the 12 apt-get install lines and CATCH2_VERSION from ci.yml, and retire the pin gate's behavioural half — with no apt package it reads nothing.
5. Replace examples/common/CMakeLists.txt:169's find_package with a TARGET Catch2::Catch2WithMain check.

What would change the verdict

Hand this back to a lane once examples/bank/** is free, or split item 3's .clang-tidy work into its own ticket that the bank lane owns. Nothing measured here needs redoing.

🤖 Generated with Claude Code

https://claude.ai/code/session_01VptDWG2fKr2vBnLSJcgzgW

[Yaraslaut]

Runner: sequencing decision — this is blocked on a lane boundary I drew, not on the design

The #684 lane handed this back with a design proven end to end (prototyped, measured, reverted): delete find_package(Catch2 CONFIG QUIET) at CMakeLists.txt:560, always FetchContent v3.8.1 with SYSTEM, yielding -isystem in the compile database, clang-tidy parity at 1 finding, and 100% tests passed out of 1564.

It did not land because finishing it requires editing nine */tests/.clang-tidy files and retiring scripts/check_catch2_pin.sh in the same change — and one of those nine, examples/bank/tests/.clang-tidy, is held by a concurrent lane I assigned examples/bank/** to. Shipping the CMake half alone would leave the CMake pin and the gate both claiming to be the source of truth, which is the state this ticket exists to remove.

That is a coordination failure of mine, not a defect in the work. The lane was right to stop at the boundary rather than cross it, and right not to ship half.

The sequence

1. The BANK lane's PR lands (it touches examples/bank/tests/.clang-tidy only incidentally, via RESOURCE_LOCK work in examples/bank/CMakeLists.txt).
2. This ticket is then dispatched to a single lane owning both CMakeLists.txt and all nine .clang-tidy files, with retiring check_catch2_pin.sh in the same change.

It should not be split further: the gate, the nine files and the CMake pin are one fix site, and #683's check_catch2_pin.sh was only ever a mitigation for #666 pending this.

Three corrections to this ticket, all measured on 7d4ca453

1. The stated mechanism is wrong in detail. The compile database records no Catch2 include path at all — find_package resolves to /usr/include, which CMake omits as an implicit directory. The divergence is real, but it lives in the default system include path, not in a recorded -I.

Read literally, that satisfies this issue's own closing condition ("Close as invalid if the compile database turns out not to carry Catch2 include paths at all"). I am not closing it. The condition was written to catch "the divergence has some other cause"; the cause is the one described, reached by a different route. The right response is to fix the explanation, which this comment does.

2. The shape this ticket names would turn clang-tidy permanently red. A fetched Catch2 arrives as -I, so its macro expansions become user code: 1 finding → 45 on a single TU (21 cppcoreguidelines-avoid-do-while, 11 misc-use-anonymous-namespace, out of REQUIRE/TEST_CASE). FetchContent_Declare(... SYSTEM) restores parity exactly — measured back at 1, the same finding. Any implementation must use SYSTEM, and that is now the load-bearing detail of this ticket.

3. Pinning v3.8.1 makes the nine suppressions inert. v3.8.1 already carries the NOLINT(bugprone-chained-comparison) those files attribute to 3.15.3, so their prose ("CI pins catch2 3.4.0") becomes false. Worth knowing: this is already true on master for any contributor without the distro package, who gets 3.8.1 via the existing fallback. So the nine files are already inert for some readers today.

Cost, so nobody re-derives it

Cold, no compiler cache, -j4, Debug, clang 22.1.8: shallow clone 1.7 s, configure delta 0.5 s, Catch2's 108 objects + morph_test_main 98.5 s (18.4 s at -j12). 17 Linux legs install apt catch2 today, so ~1.7 min on the critical path, ~3–7% of a 26–74 min run, ~28 extra runner-minutes. Warm cost near zero via sccache — inferred from CMakeLists.txt:117, not measured on a runner.

That cost is acceptable and is not why this was handed back.

🤖 Generated with Claude Code

https://claude.ai/code/session_01VptDWG2fKr2vBnLSJcgzgW

[Yaraslaut]

Handed back a second time, on the same boundary, which is now wider than it was

Dispatched to this lane as part of a gates batch. I did not start it, and the
reason is worth recording rather than repeating: every file the finished
change has to touch belongs to another lane this sweep.

The design is not in question. The #684 lane's comment above proved it end to
end — delete find_package(Catch2 CONFIG QUIET) at CMakeLists.txt:560, always
FetchContent v3.8.1 with SYSTEM, clang-tidy parity at 1 finding,
100% tests passed out of 1564. Nothing there needs redoing.

What the change needs, against what this lane owns

This lane owns .github/workflows/**, scripts/**, cmake/ where a ticket
requires it, and docs/CMakeLists.txt. The change needs:

file	owner this sweep
CMakeLists.txt (delete the find_package)	unowned, but see below
examples/common/CMakeLists.txt (TARGET Catch2::Catch2WithMain check)	the examples/** lane
tests/.clang-tidy	the tests/** lane
examples/{bank,bookmarks,crm,kanban,ledger,lims,pastebin,polls}/tests/.clang-tidy, examples/common/testkit/.clang-tidy	the examples/** lane

Measured on c6f6d953, the set of .clang-tidy files carrying the
bugprone-chained-comparison suppression and the "CI pins catch2 3.4.0" prose
is now ten, not nine:

$ grep -rln "chained-comparison" --include=.clang-tidy .
examples/bank/tests/.clang-tidy
examples/bookmarks/tests/.clang-tidy
examples/common/testkit/.clang-tidy
examples/crm/tests/.clang-tidy
examples/kanban/tests/.clang-tidy
examples/ledger/tests/.clang-tidy
examples/lims/tests/.clang-tidy
examples/pastebin/tests/.clang-tidy
examples/polls/tests/.clang-tidy
tests/.clang-tidy

Nine of the ten are under examples/** and the tenth is under tests/**, so
two concurrent lanes hold them, not one. The runner's sequencing note above
assumed a single bank file; the constraint has widened since.

Verification status

Measured: the ten-file list and their ownership, on c6f6d953. Not
attempted: anything from the #684 lane's design — no configure, no build, no
clang-tidy run. This comment adds a file count and a boundary, not a result.

What would change the verdict

Unchanged from the runner's note: dispatch this to a single lane owning
CMakeLists.txt, examples/common/CMakeLists.txt and all ten .clang-tidy
files, with retiring scripts/check_catch2_pin.sh in the same change. Shipping
the CMake half alone still leaves the CMake pin and the gate both claiming to be
the source of truth, which is the state this ticket exists to remove.

[Yaraslaut]

Handed back a third time, on the same boundary — with the one thing the previous two hand-backs do not say

Dispatched to a CI/scripts lane owning .github/workflows/**, scripts/*.py,
scripts/*.sh and CMakePresets.json, with CMakeLists.txt and tests/**
explicitly held by open PRs this sweep. I did not start it. Repeating the
boundary would add nothing, so this comment adds a measurement instead.

The boundary, re-measured on d03c66f3

Unchanged from the previous hand-back: ten .clang-tidy files, nine under
examples/** and one under tests/**.

$ grep -rln "chained-comparison" --include=.clang-tidy . | sort
examples/bank/tests/.clang-tidy
examples/bookmarks/tests/.clang-tidy
examples/common/testkit/.clang-tidy
examples/crm/tests/.clang-tidy
examples/kanban/tests/.clang-tidy
examples/ledger/tests/.clang-tidy
examples/lims/tests/.clang-tidy
examples/pastebin/tests/.clang-tidy
examples/polls/tests/.clang-tidy
tests/.clang-tidy

$ grep -n "find_package(Catch2" CMakeLists.txt examples/common/CMakeLists.txt
CMakeLists.txt:555:    find_package(Catch2 CONFIG QUIET)
examples/common/CMakeLists.txt:168:find_package(Catch2 3 CONFIG QUIET)

The new part: the half this lane does own is the half that must not ship first

ci.yml carries CATCH2_VERSION: "3.4.0" and 22 lines mentioning catch2,
including the apt-get install on every Linux leg. That is this lane's file,
and it is the obvious "partial" step — drop catch2 from the apt installs and
let CMake's existing fallback take over.

Doing that alone turns the clang-tidy job red, and the mechanism is already
in the tree rather than hypothetical. CMakeLists.txt:555-562:

    find_package(Catch2 CONFIG QUIET)
    if(NOT Catch2_FOUND)
        include(FetchContent)
        include(cmake/DepCache.cmake)
        morph_declare_dep(Catch2 https://github.com/catchorg/Catch2.git v3.8.1
            GIT_SHALLOW TRUE)
        FetchContent_MakeAvailable(Catch2)
    endif()

No SYSTEM. The #684 lane measured what that costs clang-tidy: a fetched
Catch2's headers arrive as -I, so every REQUIRE/TEST_CASE expansion is
user code, and one test TU goes from 1 finding to 45 (21
cppcoreguidelines-avoid-do-while, 11 misc-use-anonymous-namespace). Across
134 tests/ TUs plus every example suite, that is a permanently red job.

So the decomposition that looks safest from inside this lane -- "ship the CI
half now, the CMake half later" -- is the one that breaks CI, and it breaks it
via a file this lane cannot fix (SYSTEM goes on the FetchContent_Declare in
CMakeLists.txt). Worth stating explicitly, because a future lane holding only
the workflows will see 22 apt lines and a fallback that already exists and
conclude the opposite.

Corollary already true on master, and worth a line in whatever ticket lands:
any contributor without the distro package gets fetched 3.8.1 via -I
today, so their local clang-tidy is already the 45-findings configuration
while CI's is the 1-finding one. That is morph#666's divergence with the sign
flipped, and it is live now.

Verification status

Measured on d03c66f3: the ten-file list, the two find_package sites, the
absence of SYSTEM at CMakeLists.txt:555-562, CATCH2_VERSION: "3.4.0" at
ci.yml:113, 22 catch2 mentions in ci.yml. Not re-measured: the
1-finding vs 45-finding figures, which are the #684 lane's and are quoted, not
reproduced -- no build was configured here.

What would change the verdict

Unchanged, and now with one addition: dispatch to a single lane owning
CMakeLists.txt, examples/common/CMakeLists.txt, all ten .clang-tidy files
and .github/workflows/ci.yml -- the last because the apt installs and
CATCH2_VERSION have to go in the same change as the SYSTEM, not before it.

🤖 Generated with Claude Code

https://claude.ai/code/session_01VptDWG2fKr2vBnLSJcgzgW

[Yaraslaut]

Closed — out of scope under the CI reduction

This issue proposes adding or tightening CI enforcement. morph#755 moved in the opposite direction deliberately: the check surface had reached 57 checks per PR across 51 jobs and 31 checker scripts, while more than half the open backlog was CI maintaining itself. The meta-gates — the checks policing other checks — were removed.

The finding itself is not disputed and the analysis stands; what has changed is the appetite for enforcing it in CI. Closed as not planned, not as invalid.

No compile, test, sanitizer, coverage or platform coverage was removed — every build, sanitizer, Valgrind, coverage and platform leg still runs. The trade is that pins, citations and conventions of this kind are now conventions rather than gates.

Re-open if the cost/benefit changes — the evidence recorded here would not need re-gathering.