exception-documentationlisted

## Purpose Some invariants genuinely can't be met in every situation — a legacy client needs a public endpoint, a third-party system has no workload-identity support and needs a static key. That's fine, occasionally, as long as it's a decision someone made on purpose and can find again later. This skill is the template that turns "we had to break the rule here" into a durable, reviewable record instead of a comment nobody will trust six months from now. ## When to use it Any time a change violates one of the standing invariants (private-by-default networking, managed identity over secrets, naming/tagging convention, remote state with locking) and there's a genuine reason it has to. Write the exception *before* or *alongside* implementing the deviation — not after the fact when someone asks about it. ## Required fields Every documented exception needs all four of these — a deviation missing any one of them is not a documented exception, it's an undocumented one with extra steps: 1. **Rationale** — Why can't this resource follow the rule? Be specific about the actual constraint (e.g. "third-party partner's system only supports static API keys, no OAuth/federation option" or "legacy consumer application requires a public endpoint until its Q3 migration lands"), not a restatement of the exception itself. 2. **Compensating control** — What's in place instead to keep the risk bounded? For a public endpoint: IP allow-listing, WAF rules, rate limiting. For a static secret: shor