The guardrails section deserves more attention than it usually gets in posts like this, so I am glad you wrote "long-lived, static access keys are never allowed" as a hard rule rather than a suggestion. One addition on the blocking example: in Claude Code specifically, command blocking does not need a custom hook schema. Per its permissions docs, settings.json supports deny rules for Bash patterns, and those are evaluated as deterministic rules rather than left to model refusal, which is probabilistic. The place I would push back gently is the context file example: rules like "Do not suggest EC2 or containers" age silently. When the team later adds a container workload, the stale rule fights every session and nobody remembers why. Dating the opinionated rules, or splitting hard invariants from current preferences, keeps the memory file from becoming the new tribal knowledge. How do you handle rule drift in yours?