Some kernel rules don’t fit every project — the obvious example is git workflow, where trunk-based is wrong for a client repo that mandates PR reviews. That one is already a per-project setting (trunk vs PR mode). The RFC question is whether to generalize the pattern:
Proposal: a first-class, audited per-project override surface — a rule can be disabled, but the disable is visible, logged, and shows up in retros. Discipline with a paper trail instead of silent hook-forking.
Two precedents already point this direction: the git-workflow toggle above, and gate bypasses, which are logged per session and surfaced in retros today.
The hard design problem: keeping the override surface small enough that “configured” doesn’t quietly become “disabled”. Votes welcome; concrete rule-by-rule use cases from your projects are even more useful than votes.