Could CI have caught the #413-422 initializer-removal regression? An analysis

[CV-GPhL]

The recent Doxygen documentation PR series (#413-#422) silently removed ~218 member-variable initializers across 106 headers while reformatting comments. The partial fix in 2c1b0c5 caught the most severe cases, and PRs #427 / #428 address two further regressions I found while auditing the diffs.

Posting this as an issue (rather than a PR) because the right scope depends on your preferences for CI complexity.

The detection question

I ran clang-tidy against current master with a narrow check list:

clang-tidy --checks='-*,cppcoreguidelines-pro-type-member-init' -p build/ src/*.cpp

That single check flags 15 unique struct-initialization warnings. Auditing each against pre-regression state:

Warning	Status
metadata.hpp:108 TlsGroup T, L	Real regression - addressed in #428
grid.hpp GridMeta spacegroup	Real regression - addressed in #427
13 others (mtz.hpp Column::parent, symmetry.hpp Op::rot/tran, xds_ascii.hpp Refl, etc.)	Pre-existing, intentional (factory- or parser-filled)

So the check has very low false-positive noise on the existing codebase: most warnings are intentional design choices, and the few that aren't were the exact regressions we hit.

CI gaps that allowed this through

Looking at .github/workflows/ci.yml:

• No static analysis in any job (clang-tidy / cppcheck)
• EXTRA_WARNINGS is opt-in and only enabled on macos15, ubuntu2204, ubuntu2204_clang8 (not macos13, ubuntu2404arm, ubuntu2404, almalinux). Default in CMakeLists.txt is OFF.
• No runtime sanitizers (only valgrind on ubuntu2404, which catches different things)
• CMAKE_EXPORT_COMPILE_COMMANDS=ON is already in CMakeLists.txt, so a clang-tidy step would need no extra build-system plumbing

Possible directions

In rough order of disruption (lowest first):

• Enable EXTRA_WARNINGS on the CI jobs that currently lack it (macos13, ubuntu2404arm, ubuntu2404, almalinux). Trivial diff, just adds -DEXTRA_WARNINGS=ON to existing CMake invocations.
• Add a clang-tidy CI job with a narrow check list (e.g. cppcoreguidelines-pro-type-member-init, clang-analyzer-core.uninitialized.*), continue-on-error: true initially so it's informational and never blocks merge. Would have caught both fix(grid): restore spacegroup member initialization #427 and fix(metadata): restore TlsGroup tensor initialization #428 instantly.
• Add an AddressSanitizer + UndefinedBehaviorSanitizer job running the existing test suite under -fsanitize=address,undefined.
• Add CONTRIBUTING.md with a brief PR-review checklist (e.g. "watch for code changes in documentation-labelled PRs").

Happy to open PRs for any subset you'd accept - or to close this if you'd rather keep CI lean as-is. Just wanted to flag what was found and let you decide the scope.