Mihai_LeanZero - This is a really good point. A do-not-touch list is a documentation-layer fix for what's ultimately an enforcement-layer problem — under task pressure, "explicitly told not to" and "structurally prevented from" are very different guarantees, and I was implicitly leaning on the former. The pre-commit check with an explicit human override is the right shape for this. It also fixes a subtler issue: a written rule can be technically correct but still get "worked around" by an agent that convinces itself an edit is fine, whereas a hard gate doesn't care about the justification. Same logic applies to your review_cadence point, and I think it's the sharper of the two - a metadata field that nobody's watching is really just a comment with extra steps. A CI check that flags any file where last_updated is older than the stated cadence (and fails the build, or at least nags loud enough to be annoying) turns it from a norm into something that actually gets caught. Do you enforce the cadence check in CI, or is it more of a periodic manual audit on your end? Curious how granular you've gone with it — per-file, per-directory, or one blanket rule for the whole context file.