chore: docs linting changes

docs/configuration/uds-configure-policy-exemptions.md

@@ -6,9 +6,10 @@ weight: 3
 
 By default policy exemptions ([UDSExemptions](https://github.com/defenseunicorns/uds-core/blob/uds-docs/src/pepr/operator/crd/generated/exemption-v1alpha1.ts)) are only allowed in a single namespace -- `uds-policy-exemptions`. We recognize this is not a conventional pattern in K8s, but believe it is ideal for UDS for the following reasons:
 
-- highlights the fact that an exemption can reduce the overall security posture of the cluster 
+- highlights the fact that an exemption can reduce the overall security posture of the cluster
 - makes maintaining RBAC for controlling exemptions more straightforward
 - reduces the risk that an unintentional mis-configuration of RBAC allows a cluster exemption that would otherwise be denied
+
 ## Allow All Namespaces
 
 If you believe that the default scoping is not the right approach for your cluster, you can configure UDS-CORE at deploy time to allow exemption CRs in all namespaces.
@@ -18,6 +19,7 @@ If you believe that the default scoping is not the right approach for your clust
 or via a uds bundle config:
 
 uds-config.yaml
+
 ```yaml
 options:
   # options here
@@ -28,4 +30,4 @@ shared:
 variables:
  # package specific variables here
 
-```
+```

docs/configuration/uds-monitoring-metrics.md

@@ -4,7 +4,7 @@ type: docs
 weight: 1
 ---
 
-UDS Core leverages Pepr to handle setup of Prometheus scraping metrics endpoints, with the particular configuration necessary to work in a STRICT mTLS (Istio) environment. We handle this with both mutations of existing service monitors and generation of service monitors via the `Package` CR. 
+UDS Core leverages Pepr to handle setup of Prometheus scraping metrics endpoints, with the particular configuration necessary to work in a STRICT mTLS (Istio) environment. We handle this with both mutations of existing service monitors and generation of service monitors via the `Package` CR.
 
 ## Mutations
 
@@ -33,11 +33,11 @@ spec:
       path: "/mymetrics" # Add if metrics are exposed on a different path than "/metrics"
 ```
 
-This config is used to generate service monitors and corresponding network policies to setup scraping for your applications. The `ServiceMonitor`s will go through the mutation process to add `tlsConfig` and `scheme` to work in an istio environment. 
+This config is used to generate service monitors and corresponding network policies to setup scraping for your applications. The `ServiceMonitor`s will go through the mutation process to add `tlsConfig` and `scheme` to work in an istio environment.
 
 This spec intentionally does not support all options available with a `ServiceMonitor`. While we may add additional fields in the future, we do not want to simply rebuild the `ServiceMonitor` spec since mutations are already available to handle Istio specifics. The current subset of spec options is based on the bare minimum necessary to craft resources.
 
-NOTE: While this is a rather verbose spec, each of the above fields are strictly required to craft the necessary service monitor and network policy resources. 
+NOTE: While this is a rather verbose spec, each of the above fields are strictly required to craft the necessary service monitor and network policy resources.
 
 ## Notes on Alternative Approaches
 
@@ -46,6 +46,7 @@ In coming up with this feature a few alternative approaches were considered but
 ### Generation based on service lookup
 
 An alternative spec option would use the service name instead of selectors/port name. The service name could then be used to lookup the corresponding service and get the necessary selectors/port name (based on numerical port). There are however 2 issues with this route:
+
 1. There is a timing issue if the `Package` CR is applied to the cluster before the app chart itself (which is the norm with our UDS Packages). The service would not exist at the time the `Package` is reconciled. We could lean into eventual consistency here, if we implemented a retry mechanism for the `Package`, which would mitigate this issue.
 2. We would need an "alert" mechanism (watch) to notify us when the service(s) are updated, to roll the corresponding updates to network policies and service monitors. While this is doable it feels like unnecessary complexity compared to other options.
 

docs/configuration/uds-user-groups.md

@@ -7,7 +7,9 @@ weight: 4
 UDS Core deploys Keycloak which has some preconfigured groups that applications inherit from SSO and IDP configurations.
 
 ## Applications
+
 ### Grafana
+
 Grafana [maps the groups](https://github.com/defenseunicorns/uds-core/blob/49cb11a058a9209cee7019fa552b8c0b2ef73368/src/grafana/values/values.yaml#L37) from Keycloak to it's internal `Admin` and `Viewer` groups.
 
 | Keycloak Group | Mapped Grafana Group |
@@ -18,6 +20,7 @@ Grafana [maps the groups](https://github.com/defenseunicorns/uds-core/blob/49cb1
 If a user doesn't belong to either of these Keycloak groups the user will be unauthorized when accessing Grafana.
 
 ### Neuvector
+
 Neuvector [maps the groups](https://github.com/defenseunicorns/uds-core/blob/main/src/neuvector/chart/templates/uds-package.yaml#L31-L35) from Keycloak to it's internal `admin` and `reader` groups.
 
 | Keycloak Group | Mapped Neuvector Group |
@@ -26,6 +29,7 @@ Neuvector [maps the groups](https://github.com/defenseunicorns/uds-core/blob/mai
 | `Auditor`      | `reader`               |
 
 ## Keycloak
+
 {{% alert-note %}}
 All groups are under the Uds Core parent group. Frequently a group will be referred to as Uds Core/Admin or Uds Core/Auditor. In the Keycloak UI this requires an additional click to get down to the sub groups.
 {{% /alert-note %}}
@@ -37,8 +41,9 @@ UDS Core ships with a [templated](https://github.com/defenseunicorns/uds-identit
 Alternatively, the `realmInitEnv` can be configured via bundle overrides like in the [k3d-standard-bundle](https://github.com/defenseunicorns/uds-core/blob/main/bundles/k3d-standard/uds-bundle.yaml#L96).
 
 Configuring your own IDP can be achieved via:
+
 * Custom uds-identity-config with a templated realm.json
 
 * Keycloak Admin UI and click ops
 
-* Custom [realm.json](https://github.com/defenseunicorns/uds-identity-config/blob/main/src/realm.json#L1712-L1813) for direct import in Keycloak 
+* Custom [realm.json](https://github.com/defenseunicorns/uds-identity-config/blob/main/src/realm.json#L1712-L1813) for direct import in Keycloak

docs/deployment/distribution-support.md

@@ -16,4 +16,4 @@ UDS Core is a versatile software baseline designed to operate effectively across
 | --------------- | ---------------------- | --------------------------------------------------------------------------------------------------------- |
 | K3d, Amazon EKS | Tested                 | Supported Kubernetes distributions undergoing testing in CI environments.                                 |
 | RKE2            | Tested                 | Supported Kubernetes distribution tested in production environments other than CI.                        |
-| Other           | Untested/Unknown state | Compatible Kubernetes distributions that are not explicitly tested, documented, or supported by UDS Core. |
+| Other           | Untested/Unknown state | Compatible Kubernetes distributions that are not explicitly tested, documented, or supported by UDS Core. |

docs/development/uds-development-maintenance.md

@@ -4,8 +4,8 @@ type: docs
 weight: 1
 ---
 
-# UDS Bundle [name]
+## UDS Bundle [name]
 
-## How to upgrade this bundle
+### How to upgrade this bundle
 
 [Description and steps for upgrading this UDS bundle. Include any historic problems to watch out for]