Move "Exceptions" to after "Rationale"

docs/rules/imports/avoid-importing-input.md

@@ -35,7 +35,11 @@ allow if {
 }
 ```
 
-**Exceptions**
+## Rationale
+
+Using an import for `input` is not necessary, as both `input` and `data` are globally available.
+
+## Exceptions
 
 Using an alias for `input` can sometimes be useful, e.g. when using `input` is known to represent something specific,
 like a Terraform plan. Aliasing of specific input attributes should however be avoided in favor of local assignments.
@@ -58,16 +62,12 @@ allow if {
 }
 ```
 
-## Rationale
-
-Using an import for `input` is not necessary, as both `input` and `data` are globally available. 
-
 ## Configuration Options
 
 This linter rule provides the following configuration options:
 
 ```yaml
-rules: 
+rules:
   imports:
     avoid-importing-input:
       # one of "error", "warning", "ignore"

docs/rules/style/avoid-get-and-list-prefix.md

@@ -31,24 +31,24 @@ developers contains user if {
 }
 ```
 
-**Exceptions**
-
-Using `is_`, or `has_` for boolean helper functions, like `is_admin(user)` may be easier to comprehend than
-`admin(user)`.
-
 ## Rationale
 
 Since Rego evaluation is generally free of side effects, any rule or function is essentially a "getter". Adding a
 `get_` prefix to a rule or function (like `get_resources`) thus adds little of value compared to just naming it
 `resources`. Additionally, the type and return value of the rule should serve to tell whether a rule might return a
 single value (i.e. a complete rule) or a collection (a partial rule).
 
+## Exceptions
+
+Using `is_`, or `has_` for boolean helper functions, like `is_admin(user)` may be easier to comprehend than
+`admin(user)`.
+
 ## Configuration Options
 
 This linter rule provides the following configuration options:
 
 ```yaml
-rules: 
+rules:
   style:
     avoid-get-and-list-prefix:
       # one of "error", "warning", "ignore"

docs/rules/style/prefer-snake-case.md

@@ -26,24 +26,24 @@ import future.keywords.in
 user_is_admin if "admin" in input.user.roles
 ```
 
-**Exceptions**
+## Rationale
+
+The built-in functions use `snake_case` for naming — follow that convention for your own rules, functions, and
+variables, unless you have a really good reason not to.
+
+## Exceptions
 
 In many cases, you might not control the format of the `input` data — if the domain of a policy (e.g. Envoy)
 mandates a different style, making an exception might seem reasonable. Adapting policy format after `input` is however
 prone to inconsistencies, as you'll likely end up mixing different styles in the same policy (due to imports of common
 code, etc).
 
-## Rationale
-
-The built-in functions use `snake_case` for naming — follow that convention for your own rules, functions, and
-variables, unless you have a really good reason not to.
-
 ## Configuration Options
 
 This linter rule provides the following configuration options:
 
 ```yaml
-rules: 
+rules:
   style:
     prefer-snake-case:
       # one of "error", "warning", "ignore"