clang-tidy-diff's changed-lines scope hides 101 findings in include/morph/, each a trap for the next edit to that line

[Yaraslaut]

Summary

The clang-tidy-diff gate analyses changed lines only. That is a reasonable
policy for a repository adopting a large check set, but it has a consequence
nobody has measured: the public headers under include/morph/ carry a body of
findings the gate structurally cannot see, and each one is a trap for whoever
next edits the line it sits on — the gate goes red on a change that did not
introduce the finding.

101 distinct findings, across 17 headers, from six test translation units.
That is a lower bound, not a total: six TUs out of ~180, and the check set is
the repository's own .clang-tidy with WarningsAsErrors: "*" and
HeaderFilterRegex: "include/morph/.*".

Verification status

Reproduced, on cab05413 plus PR #579's branch (which touches only
completion.hpp, none of the files below), clang-tidy 22.1.8, against
build/clang-debug's compile_commands.json:

for f in tests/test_completion.cpp tests/test_bridge_local.cpp \
         tests/test_remote_extra.cpp tests/test_wire_hardening.cpp \
         tests/test_offline_queue.cpp tests/test_forms_layout.cpp; do
  clang-tidy -p build/clang-debug --quiet "$f"
done

Deduplicated by normalised path + line + column (the same header reaches
clang-tidy through several ../ include chains, so a raw count double-counts):

distinct header findings: 101
files: 17

  21  include/morph/util/quantity.hpp
  18  include/morph/forms/forms.hpp
  17  include/morph/detail/quantity_equation.hpp
   7  include/morph/core/backend.hpp
   7  include/morph/core/wire.hpp
   6  include/morph/core/registry.hpp
   5  include/morph/core/bridge.hpp
   4  include/morph/journal/action_log.hpp
   3  include/morph/offline/offline_queue.hpp
   3  include/morph/session/session_auth.hpp
   2  include/morph/util/rational.hpp
   2  include/morph/core/remote.hpp
   2  include/morph/core/timeout_scheduler.hpp
   1  include/morph/attributes.hpp
   1  include/morph/core/model.hpp

By check:

  17  modernize-use-designated-initializers
  14  readability-redundant-member-init
  13  performance-unnecessary-value-param
  11  cppcoreguidelines-avoid-do-while
   7  cppcoreguidelines-macro-usage
   6  bugprone-easily-swappable-parameters
   4  misc-const-correctness
   4  misc-no-recursion

Real output, three representative lines:

include/morph/core/wire.hpp:414:37: error: the parameter 'message' of type
  'std::string' is copied for each invocation but only used as a const
  reference; consider making it a const reference
  [performance-unnecessary-value-param,-warnings-as-errors]

include/morph/core/backend.hpp:182:108: error: the parameter 'factory' of type
  'std::function<std::unique_ptr<::morph::model::detail::IModelHolder>()>' is
  copied for each invocation but only used as a const reference
  [performance-unnecessary-value-param,-warnings-as-errors]

include/morph/core/detail/../wire.hpp:313:20: error: do not use array subscript
  when the index is not an integer constant expression
  [cppcoreguidelines-pro-bounds-constant-array-index,-warnings-as-errors]

The full deduplicated list is reproducible with the loop above; it is not pasted
here because it is 101 lines and will drift.

Not verified: whether any of the 101 is a defect rather than a style
finding. Spot-checking two:

• wire.hpp:414 — makeErr(std::string message) is called with a string
  literal at ~30 sites in remote.hpp and then passes message to
  detail::sanitizeControlChars(std::string_view), which returns a fresh
  string. The by-value std::string parameter is a wasted allocation on every
  error reply. Small, real.
• executor.hpp:211 — runTask(std::function<void()> task) is called only as
  runTask(std::move(task)) from two sites, so the by-value parameter is a
  move, not a copy. The finding is technically correct and practically inert.

That mix is the point: nobody has looked, and the gate is not built to make
anyone look.

Why this matters more than the count

The cost is not the 101 findings. It is that the gate's failure is displaced
from its cause. A contributor who reformats one line of backend.hpp, or
whose change makes clang-tidy re-analyse a region, gets a red clang-tidy-diff
naming a finding they did not introduce — and the cheapest way out is a
NOLINT, which is how a check set decays.

This is the same shape AGENTS.md's "Verify rather than assert" names: the gate
reports success while measuring only the sliver of the codebase that moved.
It measures exactly what it claims to and no more; the gap is that nobody
has stated what it does not cover.

What would change the verdict

Close this when either:

• the 101 (or whatever the full-tree number turns out to be) are fixed or
  explicitly suppressed with a reason, so a full-tree clang-tidy run over
  include/morph/ is clean and could be gated; or
• a deliberate decision is recorded that changed-lines-only is the policy and
  latent header findings are accepted, in which case the trap should at least
  be documented where a contributor hitting it will find it
  (.clang-tidy's own header comment, or AGENTS.md's CI notes).

Re-open if the count grows without either.

Notes

Found while running the repository's own clang-tidy-diff as a pre-flight for
PR #579 (morph#553 / morph#565). Outside that PR's remit and deliberately not
folded into it. Nothing here is introduced by #579 — its own changed lines are
clean, and none of the 17 files above are in its diff except
include/morph/core/completion.hpp, which reports none.

[Yaraslaut]

Triage verdict: valid

Verified against 8858450d (current master). The framing is right, the mechanism is real, and neither of the issue's own closing conditions is currently met.

Configuration claims — all exact

.clang-tidy:21   WarningsAsErrors: "*"
.clang-tidy:23   HeaderFilterRegex: "include/morph/.*"
ci.yml:2054      # ── clang-tidy-diff (changed lines only) ─────────────
compile_commands.json  185 TUs   (issue says ~180)

The gate's own section header in ci.yml says "changed lines only" in so many words, and the header filter means header findings are produced — they are simply never reached unless the line moved. That combination is the whole finding.

Both spot-checks confirmed, including the one the issue calls inert

wire.hpp:414 — real. makeErr(std::string message, uint64_t callId = 0) passes message straight into detail::sanitizeControlChars(std::string_view) at :418, which returns a fresh std::string (:305). The by-value parameter buys nothing. I count 21 makeErr( call sites in remote.hpp alone, most with string literals — so this is a wasted allocation on error replies, exactly as described.

executor.hpp:211 — inert, as claimed. runTask(std::function<void()> task) has exactly two call sites, :165 and :190, and both are runTask(std::move(task)). The finding is technically correct and costs nothing today.

That the issue got both right — and volunteered that one of its two examples is not worth fixing — is why I am treating its unverified count as credible rather than inflated.

Independent corroboration from a different tool path

I did not re-derive the 101. A single clang-tidy -p build/clang-debug --quiet tests/test_wire_hardening.cpp exceeds 120 s on this machine, so the six-TU loop is beyond a triage sweep's budget; one run is still going as I write this.

But during unrelated work in this same session, the editor's own clangd/clang-tidy integration surfaced these without being asked:

executor.hpp:211:40  parameter 'task' ... copied for each invocation but only
                     used as a const reference [performance-unnecessary-value-param]
backend.hpp:242:108  parameter 'factory'      [performance-unnecessary-value-param]
backend.hpp:244:89   parameter 'onRegistered' [performance-unnecessary-value-param]
backend.hpp:245:77   parameter 'onError'      [performance-unnecessary-value-param]
backend.hpp:472:89   parameter 'onRegistered' [performance-unnecessary-value-param]
backend.hpp:473:77   parameter 'onError'      [performance-unnecessary-value-param]
backend.hpp:720:55   parameter 'session'      [performance-unnecessary-value-param]

That is executor.hpp:211 by name — one of the issue's two spot-checks — plus six in backend.hpp, against the issue's tabulated 7 for that file. A different tool path, a different invocation, the same body of findings. The premise holds.

Neither closing condition is met

The issue offers two ways out. I checked both:

1. Fixed or suppressed so a full-tree run is clean — no.
2. A recorded decision that changed-lines-only is the policy, documented where a contributor will find it — also no. .clang-tidy has no header comment at all (the file opens straight into Checks:). grep -niE "clang-tidy|changed.line" AGENTS.md returns nothing. grep -rniE "changed lines only|clang-tidy-diff" docs/ returns nothing.

So the scope is currently stated in exactly one place: a comment inside the CI workflow, which is the one place a contributor hitting the trap will not be looking.

Invariant 7, and one sharper case the issue understates

"Would this still pass if the feature did nothing?" applies to any issue proposing a gate — and this repository's named history is precisely this failure class: a coverage script measuring a quarter of the tree, a sanitizer job green with zero instrumentation, an invalid codecov.yml behaving permissively. The issue is fair that the gate does measure what it claims; the defect is that nobody wrote down what it does not.

One addition from experience in this repo: the trap is not only "edit a line". Because the gate diffs changed lines in headers, moving code to a new file makes every one of its lines newly lintable at once — so a pure refactor that relocates a header can surface dozens of pre-existing findings in a single PR, with no way to distinguish them from newly introduced ones. That is a sharper version of the displacement the issue describes and worth folding into whichever resolution is chosen.

Label correction

Re-labelling bug → enhancement. AGENTS.md: "Add bug only for a defect in shipped behaviour — not for a missing feature." The gate behaves as built; the gap is undocumented scope plus latent findings. (The one genuine shipped-behaviour defect surfaced here, makeErr's wasted allocation, is small and belongs in whichever PR resolves this — or its own issue, not this label.)

What would change the verdict

Unchanged from the issue, both conditions intact. Adding one preference: resolution 2 is the cheaper and more honest first move. Writing the scope into .clang-tidy's header and AGENTS.md's CI notes costs an hour and removes the ambush; fixing or suppressing 101+ findings is a real project that should be decided on its merits, not undertaken because a contributor got an unexplained red gate.

[Yaraslaut]

Follow-up: the count is re-derived, and it is conservative

My verdict above said I could not re-derive the 101. The run finished. I can, and from a single translation unit.

clang-tidy -p build/clang-debug --quiet tests/test_wire_hardening.cpp on 8858450d, deduplicated by normalised path + line + column + check:

distinct header findings: 93        <-- from ONE TU; the issue reports 101 from six

By file, against the issue's table:

file	this run (1 TU)	issue (6 TUs)
util/quantity.hpp	21	21
detail/quantity_equation.hpp	17	17
forms/forms.hpp	16	18
core/wire.hpp	8	7
core/backend.hpp	7	7
core/registry.hpp	6	6
core/bridge.hpp	5	5
journal/action_log.hpp	4	4
core/timeout_scheduler.hpp	2	2
util/rational.hpp	2	2
core/model.hpp	1	1
attributes.hpp	1	1

Nine of twelve are exact. By check, the head of the distribution is exact too: 17 modernize-use-designated-initializers, 14 readability-redundant-member-init, 13 performance-unnecessary-value-param, 7 cppcoreguidelines-macro-usage, 4 misc-no-recursion — all matching the issue's figures.

The interesting part: the findings saturate

One TU out of 185 produces 93 of the reported 101. That is not a sampling accident — it is what "header-only" means. The findings live in shared headers, so almost any TU that includes the stack surfaces nearly all of them, and adding TUs adds little.

This changes the remediation estimate, favourably. The natural reading of "101 from six TUs out of ~180" is that the full-tree number could be an order of magnitude larger. It is not. The corpus is bounded by the headers, not by the TU count, and a single well-chosen TU already covers most of it. Whoever takes resolution 1 is looking at roughly the stated number, not a multiple of it — and can iterate against one fast-ish command rather than a full-tree sweep.

Two small corrections

• I found three files the issue's table does not list (core/completion.hpp, session/session.hpp, core/executor.hpp — one each) and did not reach three it does (offline/offline_queue.hpp, session/session_auth.hpp, core/remote.hpp). Different TU, different include closure; both sets are real.
• The issue's closing note says completion.hpp "reports none". On master it reports one. No contradiction — the issue measured on Give Completion<T> a value-handling contract, and stop a benchmark racing on a dead frame #579's branch, which rewrites that header. Worth knowing so nobody reads the discrepancy as drift.

One methodological note for the next person

clang-tidy writes its diagnostics to stdout here, not stderr, and it buffers until exit — a single TU took over two minutes on this machine. If you redirect the streams separately and check the wrong one mid-run, it looks like a clean result. That is the same shape as the grep | head that lost #578's TSan report: redirect to a file and read it after the process exits.

Verdict unchanged: valid.

[Yaraslaut]

Not dispatched this sweep — this ticket needs a decision a lane cannot make, and one of its two exits is currently undispatchable anyway.

The issue offers two closes, and that is the right shape for the finding. But it means no lane can be handed this as written: picking between them is a policy call about the repository's clang-tidy posture, and a batched PR cannot carry a ticket whose first step is that choice.

Measured, and it changes the cost of exit 1. Exit 1 ("the 101 are fixed or explicitly suppressed") touches files other open work holds right now:

• include/morph/util/quantity.hpp (21 findings) and include/morph/util/rational.hpp (2) are held by PR fix(util): handle INT64_MIN rational operations #561, a fork PR — 23 of the 101.
• include/morph/core/bridge.hpp (5), include/morph/core/backend.hpp (7) and include/morph/forms/forms.hpp (18) are held by the lane working core: #567's registration surface gives Bridge no way to tell a natively non-blocking backend from a blocking one, and two shipped backends now need opposite behaviour at that one call site #593 and by core/forms: the compile-time budget — core drags the whole JSON/schema stack, and schema generation is superlinear in DAG paths #573's re-entry — 30 more.

So 53 of the 101 sit in files that are not free, which makes exit 1 undispatchable this sweep regardless of the policy decision. That is a fact about today, not an argument for exit 2 — it will not be true once those land.

What would make this dispatchable, in rough order of how much it costs:

1. Get the real number first. The issue is careful that 101 is "a lower bound, not a total: six TUs out of ~180." A full-tree run over include/morph/ produces the figure the decision actually turns on, and it is a measurement, not a change — so it collides with nothing and can run while the files above are held. Whichever exit is chosen, nobody should choose it against a lower bound when the total is one run away.
2. Then record the decision, on this issue, with the real figure.
3. Then dispatch the chosen exit, once the contended files are free.

I have not run (1) myself. Flagging rather than doing it, because it belongs to whoever owns the posture decision and its output is this issue's body, not a branch.

No verdict change. triage: valid stands — the finding is reproduced and the reasoning about displaced gate failure is sound. The hold is on sequencing, not on merit.

[Yaraslaut]

The full-tree number: 596 distinct findings across 42 headers, not 101 across 17

Measurement-only lane. No branch, no PR, no code change — the output is the
number and what to do with it.

Headline: the issue's 101 was a lower bound by a factor of 5.9x in count and
2.5x in file count. But the shape of the work is better than that ratio
suggests, and the gate the issue asks for turns out to be cheap — 53 seconds
on four cores. Both results are below, with the commands.

---

Step 1 — the real number

Verification status

Reproduced, on a020e69c (this worktree's HEAD). origin/master is
0e3b8823, one commit ahead — #609, whose diff touches no file under
include/morph/ (git diff --stat a020e69c origin/master -- include/morph
is empty), so the census below holds for master unchanged.

clang-tidy 22.1.8:

$ clang-tidy --version
LLVM (http://llvm.org/):
  LLVM version 22.1.8
  Optimized build.

Check set is the repository's own .clang-tidy — WarningsAsErrors: "*",
HeaderFilterRegex: "include/morph/.*" — unmodified.

What was run

The compile database is configured with the CI clang-tidy job's exact option
set (.github/workflows/ci.yml, "Configure (generates compile_commands.json
over every optional feature)"), so the database this measures is the one the
gate would read:

cmake --preset clang-debug \
  -DMORPH_BUILD_NET=ON -DMORPH_BUILD_QT=ON -DMORPH_BUILD_FORMS_QML=ON \
  -DMORPH_BUILD_OFFLINE_SQLITE=ON -DMORPH_BUILD_LOAD_TESTS=ON \
  -DMORPH_BUILD_HMAC_EXAMPLES=ON -DMORPH_BUILD_FUZZERS=ON \
  -DMORPH_BUILD_LADDER=ON -DMORPH_BUILD_BANK_EXAMPLE=ON

-- Configuring done (68.6s)

703 database entries, 695 distinct translation units — every one analysed,
no sampling:

clang-tidy -p build/clang-debug --quiet \
  --extra-arg=-std=c++23 --extra-arg=-Wno-missing-include-dirs <TU>

driven over all 695 at -P 12. Total wall time 1561 s (26 min) on a
12-core machine, taken in nine foreground slices:

start count jobs wall
    0    12   12   11
   12   108   12   55
  120   165   12   36
  285    60   12  139
  345   120   12  280
  465    96   12  259
  561    36   12  124
  597    48   12  194
  645    50   12  463
TOTAL TUs: 695   total wall: 1561 s = 26.0 min

Deduplicated exactly as the issue did — by normalised path + line + column,
because the same header reaches clang-tidy through several ../ include chains
and a raw count double-counts. The size of that effect here:

raw diagnostic lines (undeduplicated):                    60265
distinct findings (all paths), path+line+col:              3581
  of which under include/morph/:                            596

60265 → 3581 is a 17x double-count. Anyone quoting a raw clang-tidy line count
for this tree is quoting a number that is wrong by an order of magnitude.

Findings per header, descending

distinct header findings: 596
files: 42

 109  include/morph/forms/forms.hpp
  64  include/morph/session/session_auth.hpp
  53  include/morph/net/detail/sha1.hpp
  49  include/morph/util/quantity.hpp
  40  include/morph/forms/views.hpp
  37  include/morph/net/detail/ws_handshake.hpp
  30  include/morph/net/detail/tcp_socket.hpp
  24  include/morph/net/detail/base64.hpp
  23  include/morph/net/detail/ws_frame.hpp
  20  include/morph/net/socket_backend.hpp
  14  include/morph/core/bridge.hpp
  11  include/morph/offline/sqlite_offline_queue.hpp
  10  include/morph/core/registry.hpp
   9  include/morph/core/backend.hpp
   9  include/morph/core/wire.hpp
   9  include/morph/forms/app.hpp
   9  include/morph/forms/flows.hpp
   9  include/morph/net/socket_server.hpp
   7  include/morph/core/model.hpp
   7  include/morph/version.hpp
   6  include/morph/core/remote.hpp
   5  include/morph/offline/file_offline_queue.hpp
   4  include/morph/core/logger.hpp
   4  include/morph/forms/instance_constraints.hpp
   4  include/morph/journal/action_log.hpp
   4  include/morph/qt/forms/forms_controller_core.hpp
   3  include/morph/core/observability.hpp
   3  include/morph/offline/offline_queue.hpp
   3  include/morph/util/rational.hpp
   2  include/morph/core/executor.hpp
   2  include/morph/core/payload_schema.hpp
   2  include/morph/core/timeout_scheduler.hpp
   2  include/morph/journal/file_action_log.hpp
   1  include/morph/attributes.hpp
   1  include/morph/core/completion.hpp
   1  include/morph/core/file_io_ops.hpp
   1  include/morph/detail/quantity_equation.hpp
   1  include/morph/forms/i18n.hpp
   1  include/morph/offline/network_monitor.hpp
   1  include/morph/render/i18n.hpp
   1  include/morph/render/locale_format.hpp
   1  include/morph/session/session.hpp

Findings per check, descending

 250  cppcoreguidelines-pro-bounds-avoid-unchecked-container-access
  58  readability-identifier-length
  55  misc-const-correctness
  30  cppcoreguidelines-pro-bounds-constant-array-index
  28  readability-uppercase-literal-suffix
  26  performance-unnecessary-value-param
  21  readability-redundant-member-init
  13  cppcoreguidelines-macro-usage
  12  bugprone-easily-swappable-parameters
  11  cppcoreguidelines-avoid-do-while
   9  readability-redundant-typename
   6  concurrency-mt-unsafe
   6  cppcoreguidelines-macro-to-enum
   6  cppcoreguidelines-pro-bounds-array-to-pointer-decay
   6  modernize-macro-to-enum
   6  modernize-use-designated-initializers
   5  bugprone-empty-catch
   5  cppcoreguidelines-avoid-c-arrays
   5  modernize-avoid-c-arrays
   5  portability-template-virtual-member-function
   4  bugprone-unchecked-optional-access
   4  cppcoreguidelines-pro-type-reinterpret-cast
   4  modernize-avoid-c-style-cast
   4  readability-make-member-function-const
   3  cppcoreguidelines-pro-type-vararg
   3  cppcoreguidelines-special-member-functions
   3  modernize-use-starts-ends-with
   3  readability-convert-member-functions-to-static
   3  readability-function-cognitive-complexity
   3  readability-use-concise-preprocessor-directives
   2  bugprone-implicit-widening-of-multiplication-result
   2  bugprone-std-namespace-modification
   2  cert-dcl03-c
   2  cert-dcl58-cpp
   2  cppcoreguidelines-missing-std-forward
   2  cppcoreguidelines-owning-memory
   2  misc-static-assert
   2  readability-math-missing-parentheses
   2  readability-qualified-auto
   1  cert-err33-c
   1  cppcoreguidelines-prefer-member-initializer
   1  cppcoreguidelines-pro-bounds-pointer-arithmetic
   1  misc-header-include-cycle
   1  misc-multiple-inheritance
   1  modernize-use-ranges
   1  performance-move-const-arg
   1  performance-no-int-to-ptr
   1  performance-unnecessary-copy-initialization
   1  readability-avoid-nested-conditional-operator
   1  readability-container-contains
   1  readability-identifier-naming

(A finding at one path+line+col reported under two checks counts once in the
file table and once per check here, so the check column sums slightly above
596.)

Both of the issue's spot-checks still reproduce, verbatim

include/morph/core/wire.hpp:414:37: error: the parameter 'message' of type 'std::string' (aka 'basic_string<char>') is copied for each invocation but only used as a const reference; consider making it a const reference [performance-unnecessary-value-param]
include/morph/core/executor.hpp:211:40: error: the parameter 'task' of type 'std::function<void ()>' is copied for each invocation but only used as a const reference; consider making it a const reference [performance-unnecessary-value-param]

Reconciling 596 with 101 — where the extra 495 come from

Three distinct causes, all checked:

1. The six-TU sample could not reach most of the tree (the dominant cause).
Re-running the issue's own single best TU on today's master reproduces its
per-file table almost exactly:

TU: tests/test_wire_hardening.cpp
distinct header findings: 76
  21  include/morph/util/quantity.hpp        (issue: 21)
  16  include/morph/forms/forms.hpp          (issue: 18)
   7  include/morph/core/backend.hpp         (issue:  7)
   7  include/morph/core/wire.hpp            (issue:  7)
   6  include/morph/core/registry.hpp        (issue:  6)
   5  include/morph/core/bridge.hpp          (issue:  5)
   4  include/morph/journal/action_log.hpp   (issue:  4)
   2  include/morph/util/rational.hpp        (issue:  2)
   2  include/morph/core/timeout_scheduler.hpp (issue: 2)
   1  include/morph/attributes.hpp           (issue:  1)
   1  include/morph/core/model.hpp           (issue:  1)
   ...

So the method was sound; the include closure was the limit. 167 of the extra
findings are under include/morph/net/**, which no test TU in that sample
includes at all — MORPH_BUILD_NET is an opt-in POSIX-only component, and its
headers are only reached with it ON.

This corrects the triage follow-up's "the findings saturate" conclusion.
That comment reasoned, from 93 findings out of a reported 101 in one TU, that
"the corpus is bounded by the headers, not by the TU count, and a single
well-chosen TU already covers most of it". That is true within one include
closure and false across the tree: the best single TU covers 76 of 596
(13%). The saturation was an artefact of measuring only the headers that TU
includes. Flagging it because the follow-up explicitly said it "changes the
remediation estimate, favourably" — it does not, and nobody should plan against
it.

2. Some of the 101 have already been fixed. detail/quantity_equation.hpp
went from the issue's 17 to 1, and misc-no-recursion went from 4
to zero under include/morph/ (4 remain, in tests/ and examples/).
Both were collateral of 26bfdb8f — "util: bound what equation() renders, and
make rendering it in full cheap (fixes #582, fixes #602) (#603)". Real
progress, not drift; noted so nobody reads the discrepancy as instability.
modernize-use-designated-initializers likewise fell from 17 to 6.

3. include/morph/forms/** grew. 18 → 172 across six files, of which
views.hpp (40), app.hpp (9), flows.hpp (9) and instance_constraints.hpp
(4) do not appear in the issue's table at all.

What the run could not analyse — and why it does not change the total

Of the 695 TUs, 531 compiled fully. The rest:

• 154 are build-generated sources (*_autogen/mocs_compilation.cpp,
  .rcc/qmlcache/*.cpp, *_qmltyperegistrations.cpp) that do not exist in a
  configure-only tree. They produce no input files and nothing else. They are
  all under build/, contain no first-party code, and cannot hold a finding in
  include/morph/.
• 10 die on a missing .moc. Eight are generated QML plugin stubs; two
  are first-party sources. That second pair is a live gate defect, filed
  separately as clang-tidy-diff fails with a clang-diagnostic-error on any edit to the two sources that self-include their .moc #624 (it is about the gate mechanism, not the census, so it is
  not folded in here).

Neither set can hide a header finding: every public header is reached by at
least one of the 531 that did compile (see step 4).

---

Step 2 — classifying the work

Mechanical and safe — clang-tidy ships a fix-it; --fix is plausible

check	n	why it is safe
readability-uppercase-literal-suffix	28	0xffu → 0xffU. Lexical, no semantics.
readability-redundant-member-init	21	Deletes = {} on a member already default-initialised.
readability-redundant-typename	9	Removes typename where C++20 makes it redundant.
modernize-use-designated-initializers	6	Aggregate init, field order preserved.
modernize-avoid-c-style-cast	4	(T)x → static_cast<T>(x); check refuses where the cast is not equivalent.
readability-use-concise-preprocessor-directives	3	#if defined(X) → #ifdef X. This closes #600's finding.
modernize-use-starts-ends-with	3	s.rfind(p, 0) == 0 → s.starts_with(p).
misc-static-assert	2	assert(constexpr) → static_assert.
readability-math-missing-parentheses	2	Adds parentheses; no reassociation.
readability-qualified-auto	2	auto → auto *.
modernize-use-ranges, readability-container-contains	1 each	Direct rewrites.

81 findings, ~14% of the census. These are the ones a lane can take with
--fix and a diff review, and they are spread across every batch below rather
than concentrated — so they are not a batch of their own.

Mechanical but needs judgement — a fix-it exists, applying it is a decision

check	n	the judgement
readability-identifier-length	58	Renames h0..h4 (SHA-1 state words, the spec's own names), ok, id. For net/detail/sha1.hpp's 13, renaming is strictly worse than the standard's notation. The right answer is probably one line in .clang-tidy's existing IgnoredVariableNames — that file already carries such a list.
misc-const-correctness	55	Adds const to locals. The check is documented as producing false positives in templates; include/morph/net/** holds 35 of them and is heavily templated. Needs a compile after --fix, not just a diff read.
performance-unnecessary-value-param	26	Exactly the issue's own split: wire.hpp:414 is a real allocation per error reply, executor.hpp:211 is a move at both call sites. Sixteen of the 26 sit in files PRs hold. Each one changes a public signature.
cppcoreguidelines-avoid-do-while	11	Ten are one macro: MORPH_Q_BUILD at quantity.hpp:638 is a do { … } while (0). One suppression at the definition clears all ten — but that file is held by #561.
cppcoreguidelines-macro-usage / macro-to-enum / modernize-macro-to-enum	13 / 6 / 6	Six of these are version.hpp's MORPH_VERSION_MAJOR/MINOR/PATCH, which are documented in the header as existing to be #if-testable: "for #if-testable feature checks … #if MORPH_VERSION >= MORPH_MAKE_VERSION(1, 2, 0)". An enum cannot do that. Unfixable by construction — suppression with that sentence as the reason.
readability-make-member-function-const / convert-member-functions-to-static	4 / 3	Public API changes on net/detail/tcp_socket.hpp, bridge.hpp, executor.hpp, rational.hpp.
cppcoreguidelines-avoid-c-arrays / modernize-avoid-c-arrays	5 / 5	Same five sites, two checks. Socket/wire buffers; std::array is usually right but changes ABI-adjacent code.
portability-template-virtual-member-function	5	All core/model.hpp. A real portability statement about virtual members of a class template; needs the spec author, not a lane.
cppcoreguidelines-special-member-functions	3	Rule-of-five on the three net/ RAII types. Probably genuinely worth doing.

195 findings, 33%.

Findings that may be defects, not style — read these first

These are small in count and disproportionate in value. I did not confirm
any of them is a live bug; I am flagging them because a style-only reading of
this census would skip them:

include/morph/forms/forms.hpp:489:39: error: forwarding reference parameter 'action' is never forwarded inside the function body [cppcoreguidelines-missing-std-forward]
include/morph/forms/forms.hpp:489:57: error: forwarding reference parameter 'visitor' is never forwarded inside the function body [cppcoreguidelines-missing-std-forward]
include/morph/forms/forms.hpp:2151:52: error: unchecked access to optional value [bugprone-unchecked-optional-access]
include/morph/forms/forms.hpp:2176:65: error: unchecked access to optional value [bugprone-unchecked-optional-access]
include/morph/util/quantity.hpp:958:20: error: unchecked access to optional value [bugprone-unchecked-optional-access]
include/morph/util/quantity.hpp:959:28: error: unchecked access to optional value [bugprone-unchecked-optional-access]
include/morph/net/socket_backend.hpp:416:15: error: empty catch statements hide issues; to handle exceptions appropriately, consider re-throwing, handling, or avoiding catch altogether [bugprone-empty-catch]
include/morph/net/detail/tcp_socket.hpp:195:92: error: function is not thread safe [concurrency-mt-unsafe]
include/morph/detail/quantity_equation.hpp:30:10: error: circular header file dependency detected while including 'quantity.hpp', please check the include path [misc-header-include-cycle]

Plus cert-err33-c (1, an unchecked return in offline/) and
bugprone-implicit-widening-of-multiplication-result (2, in wire.hpp and
ws_handshake.hpp — both size arithmetic on the wire path).

concurrency-mt-unsafe × 6, all in net/detail/tcp_socket.hpp, is the one I
would look at hardest: a WebSocket transport is the last place a non-reentrant
libc call belongs.

Genuinely contentious

cppcoreguidelines-pro-bounds-avoid-unchecked-container-access — 250 of 596,
42% of the entire census. This one check decides the size of the project.

          76 include/morph/forms/forms.hpp
          61 include/morph/session/session_auth.hpp
          29 include/morph/forms/views.hpp
          19 include/morph/net/detail/sha1.hpp
          15 include/morph/net/detail/base64.hpp
          12 include/morph/util/quantity.hpp

It fires on every v[i], m[k] and s[i]. "Fixing" it means .at()
(throwing, and a behaviour change) or std::span/ranges (a rewrite). Neither is
a lint fix. There are three honest exits, and the owner should pick one before
any lane starts, because the answer changes 596 into either 346 or 596:

1. Disable the check in .clang-tidy. One line, -cppcoreguidelines-pro-bounds-avoid-unchecked-container-access, with a
   comment saying why. The file already disables five checks this way
   (-readability-magic-numbers, -misc-include-cleaner, …), so the precedent
   and the mechanism both exist. Census drops to 346.
2. Keep it and suppress per site with reasons. 250 reasoned suppressions is
   not a project anyone should sign up for.
3. Keep it and fix. A rewrite of the forms and session-auth hot paths.

I have a view: (1). Note that render/locale_format.hpp already carries a
NOLINTNEXTLINE for this very check on char const chr = text[i]; with the
reason "i is bounded by the loop condition" — and locale_format.hpp:457
(grouped += wholePart[i];, the finding recorded in #600's second comment)
has the identical bound and no suppression. That inconsistency is what 250
instances of a check nobody has decided about looks like.

bugprone-easily-swappable-parameters — 12, spread one or two per file:

include/morph/core/registry.hpp:770:42   'create'                        (2 × std::string_view)
include/morph/core/remote.hpp:894:83     'missingRequiredFields'         (2 × const std::string&)
include/morph/forms/forms.hpp:2403:30    'annotateNestedAggregate'       (2 × glz::generic_u64&)
include/morph/forms/i18n.hpp:79:47       'fieldKeyStem'                  (2 × std::string_view)
include/morph/net/detail/tcp_socket.hpp:192:29  'listen'                 (convertible types)
include/morph/net/detail/ws_handshake.hpp:229:43 'verifyServerHandshakeResponse'
include/morph/offline/file_offline_queue.hpp:286:22 'setAttempts'
include/morph/offline/network_monitor.hpp:149:42 'handleProbeResult'     (2 × int&)
include/morph/offline/offline_queue.hpp:223:47, :317:22  'setAttempts'
include/morph/render/i18n.hpp:56:46      'resolveText'
include/morph/session/session.hpp:185:67 'authorizeInstance'

Twelve reasoned NOLINTs is a real but finite piece of writing, and the
standard is already set in this tree — render/locale_format.hpp:181:

// NOLINTBEGIN(bugprone-easily-swappable-parameters)
// The two signs are adjacent `std::string_view`s sharing the suffix `Sign`, and
// the check is right that swapping them would be silent: the entry would take
// '+' as a negative and '-' as a positive. They stay in this order anyway,
// because it is normalizeLocaleNumber's own parameter order, and its single
// call site is four lines below this one. Reordering to break the adjacency
// would put the helper out of step with the function it exists to serve, which
// trades a mistake nobody can make here for one a reader of both would.

That paragraph is the bar. Anything less is what the issue calls "how a check
set decays". Note offline/offline_queue.hpp:223 and :317 and
file_offline_queue.hpp:286 are the same setAttempts(id, attempts) shape in
three places — one reason, cited three times, not three inventions.

misc-no-recursion — zero. The issue's 4 are gone with #603. Nothing
contentious left here.

---

Step 3 — what is dispatchable now

Against the five in-flight PRs named in the dispatch:

  49  include/morph/util/quantity.hpp           (PR #561, fork)
  14  include/morph/core/bridge.hpp             (PR #585)
   9  include/morph/core/backend.hpp            (PR #585)
   3  include/morph/util/rational.hpp           (PR #561, fork)
   2  include/morph/core/executor.hpp           (PR #585)
   0  include/morph/qt/forms/... /qt_websocket_backend.hpp (PR #585 — no findings)
held total: 77 of 596  ->  free: 519

PRs #609, #614 and #617 hold no include/morph/ header at all.

Only 13% is held, not half. The triage comment's "53 of the 101 sit in
files that are not free" was right for the 101; against the real corpus the
contended files are a minor share and the campaign is not blocked.

Six batches, by file tree

batch	findings	files	dominant checks
A — tail: version.hpp, attributes.hpp, journal/, render/, qt/forms/, detail/	21	8	macro-to-enum 6+6, redundant-member-init 4, value-param 4, macro-usage 4
B — net/	196	7	unchecked-container-access 47, const-correctness 35, identifier-length 26, uppercase-suffix 25, constant-array-index 18
C — forms/	172	6	unchecked-container-access 117, redundant-member-init 15, identifier-length 12, redundant-typename 9
D — session/	65	2	unchecked-container-access 61, c-style-cast 3
E — core/ (free part)	45	10	unchecked-container-access 10, identifier-length 8, template-virtual 5, macro-usage 4
F — offline/	20	4	const-correctness 9, swappable-params 4, reinterpret-cast 2
(held)	77	5	— after #561 and #585 land

Batch A in full, since it is the one I would dispatch first:

   7  include/morph/version.hpp
   4  include/morph/journal/action_log.hpp
   4  include/morph/qt/forms/forms_controller_core.hpp
   2  include/morph/journal/file_action_log.hpp
   1  include/morph/attributes.hpp
   1  include/morph/detail/quantity_equation.hpp
   1  include/morph/render/i18n.hpp
   1  include/morph/render/locale_format.hpp

Do batch A first — and it is not because it is small

It is 21 findings across 8 files, so it lands in one sitting. But the reason is
that A is the only batch that forces every policy precedent the other five
need, on a corpus small enough that getting a precedent wrong costs nothing:

• version.hpp (6 + 6 macro-to-enum) is the unfixable-by-construction
  case: the header documents the macros as #if-testable API. Batch A has to
  write the first reasoned suppression, and its wording becomes the template.
• locale_format.hpp:457 is the unchecked-container-access case, and the
  file already holds both a reasoned NOLINTNEXTLINE for that check and an
  unsuppressed twin. Whatever the owner decides about the 250, batch A is where
  it gets written down and made consistent — in one file, not 42.
• render/i18n.hpp:56 is one bugprone-easily-swappable-parameters, next door
  to the tree's existing worked example, so the paragraph standard gets set
  against the file that already demonstrates it.
• attributes.hpp:27 closes clang-tidy: an error-severity finding sits in attributes.hpp that the changed-lines gate can never report #600 as a by-product.

Then B/C/D/E/F are parallelisable by lanes that only have to follow precedent,
not set it. Dispatching B (196 findings) first means a lane inventing the
suppression policy inside the largest diff in the campaign.

Order after A: F (20) → E (45) → D (65) → B (196) → C (172), smallest-first
so each batch's rebase cost is paid against a smaller tree, and because D and C
are almost entirely one check — if the owner disables it, D drops 65 → 4 and C
drops 172 → 55, and those two batches merge into one lane's work.

---

Step 4 — the gate, and what it costs

A whole-tree run is 26 minutes. A whole-header gate is 53 seconds.

Running clang-tidy over all 695 database entries took 1561 s at -P 12.
Extrapolated to a 4-vCPU runner that is roughly 75–80 min — not viable per-PR.

But a gate over include/morph/ does not need 695 TUs, and the tree already
generates exactly the right ones. VERIFY_INTERFACE_HEADER_SETS ON
(CMakeLists.txt:182, and per-component at :465, :518, :669, :729) makes CMake
emit one standalone .cxx per public header at generate time — they are
already in the compile database this job configures:

verify_interface_header_sets TUs in compile db: 60
  of which analysed here: 60
findings covered by the VIHS family alone: 552
findings covered by everything else: 510
in VIHS but not elsewhere: 86
elsewhere but not in VIHS: 44

60 TUs cover 552 of the 596 (93%), and they cost:

$ # clang-tidy -p build/clang-debug --quiet --extra-arg=-std=c++23 \
$ #   --extra-arg=-Wno-missing-include-dirs <each of the 60 stubs>
TUs: 60  jobs: 12
wall: 31s

TUs: 60  jobs: 4
wall: 53s

53 seconds on four cores, on top of a configure the clang-tidy job already
performs and a build it already skips. That is per-PR viable with room to spare
— it is shorter than the job's existing Qt install step.

Two things a gate built this way must state, or it becomes the next control that
reports success while measuring nothing:

1. It misses 44 findings, and they are a specific kind — those that need a
   template instantiated, which a standalone header stub never does:

     20  include/morph/util/quantity.hpp
      6  include/morph/forms/forms.hpp
      6  include/morph/core/model.hpp
      5  include/morph/core/bridge.hpp
      4  include/morph/qt/forms/forms_controller_core.hpp
      2  include/morph/core/payload_schema.hpp
      1  include/morph/forms/flows.hpp
   

   Adding three user TUs closes almost all of it: tests/test_quantity.cpp,
   examples/kanban/tests/test_board_qml_bridge.cpp and
   examples/forms/gui_qml/FormsController.cpp between them contribute 176 of
   the census. A greedy cover over the whole run says the full 596 is reachable
   from 17 TUs:

   +368  -> 368   build/.../morph_net_verify_interface_header_sets/morph/net/socket_backend.hpp.cxx
   +103  -> 471   examples/kanban/tests/test_board_qml_bridge.cpp
   +66   -> 537   examples/forms/gui_qml/FormsController.cpp
   +17   -> 554   examples/lims/tests/test_result_entry.cpp
   +9    -> 563   build/.../morph/net/socket_server.hpp.cxx
   +7    -> 570   build/.../morph/version.hpp.cxx
   +6    -> 576   tests/test_quantity.cpp
   ... 10 more, +1 each
   

   A hand-picked TU list is exactly the kind of thing that silently rots, so I
   would gate on all 60 stubs plus every TU under tests/ rather than a
   curated 17 — and state the residual.

2. Eight detail/ headers get no stub, deliberately (CMakeLists.txt:245's
   comment: standalone compilation is a promise about public headers):

   include/morph/core/detail/execute_order_gate.hpp
   include/morph/core/detail/instance_directory.hpp
   include/morph/core/detail/reply_router.hpp
   include/morph/core/detail/subscription_registry.hpp
   include/morph/detail/fixed_string.hpp
   include/morph/detail/quantity_equation.hpp
   include/morph/forms/detail/schema_name.hpp
   include/morph/forms/detail/session_common.hpp
   

   They are still linted — HeaderFilterRegex reaches them transitively, which
   is how detail/quantity_equation.hpp:30's misc-header-include-cycle
   appears above — but a stub-only gate would not compile them standalone.
   That is the same distinction the FILE_SET comment already draws, and it
   should be repeated wherever this gate is documented.

Recommendation

Per-PR, not scheduled. 53 s is cheap enough that a nightly loses the
property that matters (a red gate attached to the change that caused it) for no
saving. It should run in the existing clang-tidy-diff job — same configure,
same database, a second step — so the whole clang-tidy surface stays in one job
and one artifact.

Sequencing matters: the gate must land last, after the batches, or it turns
596 pre-existing findings into a permanently red master. Until then the honest
interim is a non-blocking run posting the count, so the number moves
visibly and cannot regress unobserved.

---

What I did not verify

• Not run in CI. Every number here is from one Arch Linux machine, clang
  22.1.8, 12 cores. CI pins CLANG_VERSION and a different libstdc++; a
  different clang-tidy will not produce 596 exactly. The shape — which checks
  dominate, which files carry them — should survive; the integer will not.
• Not measured on a 4-vCPU GitHub runner. The 53 s figure is -P 4 on this
  machine's cores, which are faster than a runner's. Treat it as a floor;
  I would expect 1.5–2.5x on ubuntu-latest. The conclusion (a minute-scale
  gate, not an hour-scale one) has that much margin.
• Not established that any finding is a live defect. The nine flagged under
  "may be defects" are flagged on the strength of the check's own description,
  not on reading the surrounding code. wire.hpp:414 is the one exception, and
  that was already established in the issue and its triage.
• No --fix was run. The "mechanical and safe" column is a claim about
  which checks ship a FixItHint, not a measurement that applying 81 of them
  leaves the tree compiling.
• The -P 12 slice timings include process startup 695 times, so the 26 min
  total is a slight over-estimate of the analysis itself. Irrelevant at this
  resolution.
• No branch, no PR, no code change from this lane, per its remit: with 596
  findings the fix campaign is far past what one PR should carry.

What would change the verdict

• Re-measure after the owner decides on
  cppcoreguidelines-pro-bounds-avoid-unchecked-container-access. Disabling
  it makes this a 346-finding project; keeping it makes it a 596-finding one.
  Nothing else on this page moves the total by more than a few percent.
• Re-measure after fix(util): handle INT64_MIN rational operations #561 and qt: move QtWebSocketBackend onto the structural registration surface #585 land, which will change the held/free split
  and may change quantity.hpp's 49.
• Re-run on the CI image before writing the gate's timeout, so the number
  the workflow is tuned against is the number the workflow will see.

[Yaraslaut]

Three findings split out of the census into their own issues

Per AGENTS.md ("file it, link it, and keep the change you are making about one
thing"), three things the sweep turned up are recorded separately rather than
folded into the census above. All three have fixes that do not wait on the
cppcoreguidelines-pro-bounds-avoid-unchecked-container-access decision.

• clang-tidy-diff fails with a clang-diagnostic-error on any edit to the two sources that self-include their .moc #624 — clang-tidy-diff fails with a clang-diagnostic-error on any edit
  to the two sources that self-include their .moc. Not a header finding at
  all: a gate failure with no relationship to the diff. examples/common/testkit/test_qml_surface.cpp
  and src/qt/forms/tests/tst_main.cpp. Reproduced, including that
  -line-filter does not suppress it; latent because neither file has been
  touched since ci: give the clang-tidy gate the application ladder it claims to lint #483.

• morph::net formats every socket error with the non-thread-safe std::strerror, from threads it spawns itself #625 — morph::net formats every socket error with std::strerror, from
  threads it spawns itself. Seven sites in net/detail/tcp_socket.hpp; six of
  this census's concurrency-mt-unsafe findings, and the seventh already
  carries a NOLINTNEXTLINE whose stated reason is "as at every other throw
  site here" — consistency, not safety. This is the one finding in the 596 I
  would call a shipped-behaviour defect rather than a style finding.

• Four NOLINTNEXTLINE directives are wrapped onto two lines and suppress nothing; six findings leak past them #627 — four NOLINTNEXTLINE directives are wrapped onto two lines and
  suppress nothing; six findings leak past them. Two are in
  forms/forms.hpp, and they are why missing-std-forward at :489 and
  unchecked-container-access at :496 appear in the table above despite
  looking annotated. include/morph/detail/fixed_string.hpp:48 documents this
  exact hazard in prose and nothing enforces it. Six of the 596 are here only
  because a suppression that was written does not work — worth knowing before
  batch C is dispatched against forms.hpp's 109.

The remaining "may be defects" flagged in the report above
(bugprone-unchecked-optional-access × 4, cert-err33-c,
bugprone-implicit-widening-of-multiplication-result × 2) are not filed
separately: I reproduced the diagnostics but did not establish that any is a
live bug, and forms.hpp:2151/quantity.hpp:958 look like the check failing to
see through a has_value() helper guard. They are recorded above with real
output so the lane that touches those files reads them rather than rediscovering
them.

[Yaraslaut]

Owner decision: the check stays on, and all 250 findings get fixed.

cppcoreguidelines-pro-bounds-avoid-unchecked-container-access — 250 of the 596, 42% of the census — was put to the repository owner as the decision that sizes this campaign. The verdict is the strictest of the three options offered:

Keep it, fix all 250. Every v[i] on a runtime index in a public header becomes .at() or gets an individually reasoned NOLINT. The 37 existing NOLINTs stay.

So the campaign is 596 findings, not 346, and the measurement lane's conditional — "if the owner disables the big check, batch D drops 65 → 4 and batch C drops 172 → 55 and those two merge" — does not apply. Batch sizes stand as measured: A 21 · B net/ 196 · C forms/ 172 · D session/ 65 · E core/-free 45 · F offline/ 20.

I recommended disabling it and was overruled; recording that plainly so nobody re-opens the question on the strength of my argument. The evidence I weighed — 37 existing hand-written suppressions for this one check, and .clang-tidy's existing precedent of disabling five checks outright — is on the record above and did not carry.

What this means for anyone taking a batch

A bare NOLINT is not an acceptable remedy. The owner's choice was explicitly ".at() or an individually reasoned NOLINT", and AGENTS.md already names the alternative as the decay mode:

the cheapest way out is a NOLINT, which is how a check set decays.

The in-tree standard for what "reasoned" means is include/morph/render/locale_format.hpp:181 — a real paragraph explaining why the check is wrong here, not a restatement of the check's name. Prefer .at() wherever the branch is not on a measured hot path; reach for a reasoned suppression when it is, and say which.

Where the two differ materially, say so in the PR. .at() adds a bounds check the compiler usually cannot elide. If a batch converts something in a per-call path — wire.hpp's decode loops and forms.hpp's property walks are the candidates — that is worth a sentence, and possibly a measurement, rather than a silent conversion.

Batch order, revised

The measurement lane recommended A first, not for its size but because it is the only batch that forces every policy precedent the other five need, on a corpus where a wrong call is cheap — and it closes #600 as a by-product. That reasoning survives the decision and is still right.

One amendment: include/morph/render/locale_format.hpp is currently held by PR #630 (the #591 NumericLocale rewrite, which deletes three NOLINTBEGIN blocks from that file and rewrites the code around :457). Batch A must exclude it. The file rejoins batch A — or gets a small follow-up of its own — once #630 lands. Note #630 also changes the answer for that file, so re-measure it rather than reusing the census row.

Everything else in A is free.

Related

#626 (filed independently, same check, on locale_format.hpp) is a single instance of this census row. It should be closed by #630 as a side effect rather than worked separately — reconciled with this census, not duplicated by it.

#627 is load-bearing for this campaign and should be fixed before any batch that relies on suppressions: four NOLINTNEXTLINE directives are wrapped onto two lines and suppress nothing, leaking six findings. A campaign whose remedy is partly "write a reasoned NOLINT" cannot proceed on a tree where NOLINTs silently fail to apply.

[Yaraslaut]

A number from #632's measurement that bears on this census

Sizing #632 (tests/.clang-tidy's suppressions also silence include/morph/
headers) required running the whole tests/ TU set twice, which incidentally
produces a figure this census should see before its gate recipe is built on.
Posting it here rather than acting on it, since #580's own 596 has not been
re-measured this sweep.

Verification status: measured, on a8511aa6, clang-tidy 22.1.8, Arch
Linux, against the compile database ci.yml's clang-tidy job configures for
itself (clang-debug preset, every optional feature ON — 703 entries, 134
distinct TUs under tests/). Every one of the 134 was analysed; no TU failed
with a clang-diagnostic-error. Distinct findings are deduplicated on
(file, line, column, check).

With tests/.clang-tidy removed, so those 134 TUs are judged by the
repository-root configuration alone, findings inside include/morph/**:

=== 595 distinct header findings
    247  cppcoreguidelines-pro-bounds-avoid-unchecked-container-access
     57  readability-identifier-length
     55  misc-const-correctness
     30  cppcoreguidelines-pro-bounds-constant-array-index
     28  readability-uppercase-literal-suffix
     23  performance-unnecessary-value-param
     17  readability-redundant-member-init
     11  cppcoreguidelines-avoid-do-while
     11  bugprone-easily-swappable-parameters
      9  cppcoreguidelines-macro-usage
      9  readability-redundant-typename
      6  concurrency-mt-unsafe
      6  modernize-use-designated-initializers
      6  cppcoreguidelines-pro-bounds-array-to-pointer-decay

595, from tests/ TUs alone. This census reports 596 over a full-tree
sweep of 695 TUs, with 250 …unchecked-container-access and 58
readability-identifier-length. Against 595 / 247 / 57 that is a difference
of one, three and one.

What that suggests — and it is a suggestion, not a result, because I did not
re-run the census and did not difference the two finding sets item by item —
is that the 60 verify_interface_header_sets stubs plus the non-tests/ TUs
contribute almost nothing this census does not already reach through tests/.
If so, the gate recipe's two halves are close to redundant in coverage while
being very different in what they can report, which inverts the natural
reading of "all 60 stubs plus every TU under tests/".

The reason it matters for the recipe: with tests/.clang-tidy in place —
the configuration the recipe's tests/ half would actually run under — the
same 134 TUs report 262, not 595. 333 findings across 25 headers are
hidden, including 247 of the census's largest check. See #632, now fixed by
recording the reach and gating the record (the reach itself cannot be
narrowed; clang-tidy resolves configuration from the TU's path).

What I did not verify. I did not re-run the census, so I cannot say the
595 and the 596 are the same findings — only that the totals and the two
largest per-check counts nearly coincide. I did not measure the stubs at all.
Not reproduced on the CI image.

What would change the verdict. Difference the two sets item by item. If
the overlap is near-total, the gate should be built on the stubs and
non-tests/ TUs and the tests/ half dropped rather than kept as a
suppressed, under-reporting duplicate. If it is not, both halves are needed
and the tests/ half must carry the header-reach: caveat now recorded in
tests/.clang-tidy.

[Yaraslaut]

Data point from the #625 work, in case it helps size this.

include/morph/net/detail/tcp_socket.hpp carried six live
concurrency-mt-unsafe findings on a8511aa6 that the changed-lines gate
never reported, plus a seventh suppressed by hand — which is precisely the trap
this issue describes: the seventh only acquired its NOLINTNEXTLINE because
some earlier pull request happened to touch that line, and the reason written
on it ("as at every other throw site here") generalised the suppression to the
six that had none.

Measured, clang-tidy 22.1.8, a8511aa6 unmodified:

$ clang-tidy -p build/net --checks='-*,concurrency-mt-unsafe' \
    --header-filter='include/morph/.*' tests/net/test_tcp_socket.cpp
include/morph/net/detail/tcp_socket.hpp:195:92: error: function is not thread safe [concurrency-mt-unsafe,-warnings-as-errors]
include/morph/net/detail/tcp_socket.hpp:206:90: error: function is not thread safe [concurrency-mt-unsafe,-warnings-as-errors]
include/morph/net/detail/tcp_socket.hpp:211:92: error: function is not thread safe [concurrency-mt-unsafe,-warnings-as-errors]
include/morph/net/detail/tcp_socket.hpp:276:75: error: function is not thread safe [concurrency-mt-unsafe,-warnings-as-errors]
include/morph/net/detail/tcp_socket.hpp:353:81: error: function is not thread safe [concurrency-mt-unsafe,-warnings-as-errors]
include/morph/net/detail/tcp_socket.hpp:371:80: error: function is not thread safe [concurrency-mt-unsafe,-warnings-as-errors]

With the hand-written suppression deleted it is seven; with #625's fix applied
it is zero, exit 0.

Under the repo's full check set the same header reports 15 error-severity
findings on a8511aa6 (misc-const-correctness,
cppcoreguidelines-pro-type-reinterpret-cast,
readability-make-member-function-const,
readability-use-concise-preprocessor-directives,
bugprone-easily-swappable-parameters,
cppcoreguidelines-special-member-functions,
cppcoreguidelines-pro-bounds-pointer-arithmetic). #625 removes six of the
concurrency-mt-unsafe six; the other nine are untouched and still invisible
to CI.

Verification status: measured on a8511aa6 in a
-DMORPH_BUILD_NET=ON -DCMAKE_BUILD_TYPE=Debug clang-22 compile database, one
header. Not re-derived tree-wide, so this neither confirms nor revises this
issue's count of 101 — it is one file's contribution to it.

🤖 Generated with Claude Code

https://claude.ai/code/session_01VptDWG2fKr2vBnLSJcgzgW

[Yaraslaut]

A tree-wide measurement for this, from working #664

Measured on 563502ab, clang 22.1.8, Qt 6.11.2, with the clang-tidy job's own configure flags from a cold build directory. Not six TUs — all 423 in-workspace translation units of that job's 740-entry database, de-duplicated by (file, line, column, check):

distinct findings under --header-filter='.*' : 5577
  of which in a main file (always shown)     : 3010
  of which in an included header             : 2567

  by bucket:
     2930  first-party: examples/
     1422  build tree (_deps, vendored, generated)
      713  first-party: tests/
      488  first-party: include/
       22  first-party: src/
        2  system/toolchain

So this issue's include/morph/ slice is 488 findings across 34 headers, against the 101-in-17 lower bound recorded above. The whole-tree standing bill for a hypothetical whole-file leg is ~4155 (5577 minus the vendored bucket).

Two constraints for whoever takes this, both measured rather than argued:

• Excluding vendored code cannot be done with an inclusive first-party regex. A header filter is an unanchored search over an absolute path, and (include/morph|src|tests|examples)/ matches 608 headers under build/clang-debug/_deps — 244 glaze, 202 stdexec, 153 Lightweight — because FetchContent lays dependencies out as _deps/<name>-src/src/ and _deps/<name>-src/include/. The polarity that works is HeaderFilterRegex: ".*" plus an ExcludeHeaderFilterRegex naming the build tree; verified behaviourally, it takes one bank model TU from 1300 vendored diagnostic lines to 0.
• Wall clock: 423 TUs at -P 10 on a 12-core box is ~20 minutes. A four-core hosted runner pays more.

I filed #677 before finding this issue; it is the same defect at the wider scope and one of the two should be closed. Detail and the suggested direction are in its own comment.

Separately, and relevant to the framing here: #664 attributed the hidden examples/** header findings to the root HeaderFilterRegex. Measured, that regex has no observable effect on this job — a changed header is analysed as its own main file, where the filter does not apply, and an unchanged header's findings are dropped by -line-filter whatever the regex says. The changed-lines scope, i.e. this issue, is the whole of the mechanism. Evidence is on #664.

🤖 Generated with Claude Code

https://claude.ai/code/session_01VptDWG2fKr2vBnLSJcgzgW