Config drift across the callers: the cross-repository view

Priority: low-medium. The per-repository work is filed where it can be done; this is the umbrella and the record of what is deliberately different.

Target state, per the owner: config identical across xstd, tabula and bit_set, with differences only where lib or test dependencies actually require them.

Where the work lives

xstd needs no issue of its own: it is the superset, and every difference resolves toward it. That is an assumption worth stating rather than a decision on record.

dctl is out of scope for now.

The three decisions that span repos

These are the only items where bit_set and tabula agree with each other and disagree with xstd, and none is settled by the dependency rule:

1. -modernize-use-trailing-return-type — suppressed in bit_set and tabula, not in xstd, which writes trailing returns throughout. Pure style; no dependency angle at all. Either all three suppress it or none do.
2. -misc-include-cleaner — disabled outright in bit_set and tabula; xstd keeps it on and passes IgnoreHeaders: 'boost/.*', which is strictly more informative. Enabling it surfaces findings that cannot be predicted without running clang-tidy against a compile database, so it wants a spike first.
3. The CheckOptions block — absent in both. Adopting readability-operators-representation is a no-op in bit_set (verified: zero ||, zero logical !, its only && is a forwarding reference) and a ~7-site code change in tabula.

Workflow-set drift

xstd and tabula have identical workflow sets. bit_set differs in exactly two ways, both covered by the issues above: no canary.yml (#71), and appleclang.yml where everyone else has apple-clang.yml (#72).

Justified differences — recorded so they are not re-litigated

Each of these survives the dependency rule and should stay:

What would keep it closed

The drift above was found by hand, by diffing three checkouts. Nothing would have reported it, and nothing will report the next one.

A report, not enforcement: a self-check.yml leg listing, per shared file, whether the callers agree — on the weekly cron it already runs, output to the step summary, never failing. Enforcement would be wrong; a caller with a real local need should not have to come here first. But drift should have to be looked at once, and either explained in a one-line comment in the file or removed.

Related

• #26 item 5 — self-check.yml querying the packagers for ladder freshness. Same shape: cpp-ci noticing when something it owns has gone stale.
• #38 — coverage.yml untested. Also a "nothing checks this" gap, but with a real failure mode rather than an explanatory one.

The proposed entry point is self-check.yml, alongside the existing weekly cron and the shared configuration files compared across xstd, tabula, and bit_set. First inspect how the current self-check workflow produces its step summary; done means a non-failing report lists agreement for each shared file and leaves justified differences explainable.