fix: known doom lint issues

Author: JounQin

.yarn/releases/yarn-4.12.0.cjs

@@ -9,4 +9,4 @@ plugins:
     path: .yarn/plugins/plugin-prepare-lifecycle.cjs
     spec: "https://github.com/un-es/yarn-plugin-prepare-lifecycle/releases/download/v0.0.1/index.js"
 
-yarnPath: .yarn/releases/yarn-4.12.0.cjs
+yarnPath: .yarn/releases/yarn-4.14.1.cjs

.yarn/releases/yarn-4.14.1.cjs

@@ -17,7 +17,7 @@ The Alauda Application Services platform is a robust, open-source service manage
 
 - Container Infrastructure: The Alauda Application Services platform is built on Kubernetes and leverages the underlying infrastructure it provides to offer foundational capabilities such as data persistence and external access.
 
-# Rich Services Support \{#compatible_sc}
+## Rich Services Support \{#compatible_sc}
 
 The Alauda Application Services platform supports various types of services, including databases, caches, message queues, etc. The following are the main supported alauda application services versions and compatible storage class information:
 

.yarnrc.yml

@@ -14,7 +14,7 @@ A Blue-Green Deployment is a deployment strategy where two identical environment
 
 When a new version of the application is ready to be deployed, it is deployed to the green environment. Once the new version is deployed and tested, traffic is switched to the green environment, making it the new production environment. The blue environment then becomes the non-production environment, where future versions of the application can be deployed.
 
-# Benefits of Blue Green Deployments
+## Benefits of Blue Green Deployments
 
 - Zero Downtime: Blue-Green Deployments allow new versions of applications to be deployed with zero downtime, as traffic is switched from the blue environment to the green environment seamlessly.
 
@@ -26,7 +26,7 @@ When a new version of the application is ready to be deployed, it is deployed to
 
 - Flexibility: Blue-Green Deployments provide flexibility in the deployment process. Multiple versions of an application can be deployed side-by-side, allowing for easy testing and experimentation.
 
-# Blue Green Deployment with Argo Rollouts
+## Blue Green Deployment with Argo Rollouts
 
 Argo Rollouts is a Kubernetes controller and set of CRDs which provide advanced deployment capabilities such as blue-green, canary, canary analysis, experimentation, and progressive delivery features to Kubernetes.
 

docs/en/appservice/overview/architecture.mdx

@@ -17,15 +17,15 @@ Canary Deployment is a progressive release strategy where a new application vers
 > - **Canary Steps**: A series of incremental traffic shifting actions, such as directing 25%, then 50% of traffic to the new version.
 > - **Pause Steps**: Introduce wait intervals for manual or automatic validation before progressing to the next canary step.
 
-# Benefits of Canary Deployments
+## Benefits of Canary Deployments
 
 - **Risk mitigation**: By deploying changes to a small subset of servers initially, you can find issues and address them before the full rollout, minimizing the impact on users.
 - **Incremental rollouts**: This approach allows gradual exposure to new features, which helps you effectively monitor performance and user feedback.
 - **Real-time feedback**: Canary deployments provide immediate insights into the performance and stability of new releases under real-world conditions.
 - **Flexibility**: You can adjust the deployment process based on performance metrics. This allows for a dynamic rollout that you can pause or roll back as needed.
 - **Cost-effectiveness**: Unlike blue/green deployments, canary deployments don't require a separate environment, making them more resource-efficient.
 
-# Canary Deployments with Argo Rollouts
+## Canary Deployments with Argo Rollouts
 
 Argo Rollouts supports canary deployment strategy to rollout a deployment, and control the traffic through Gateway API Plugin. In ACP, you could use ALB to act as a Gateway API Provider to implement the traffic control for Argo Rollouts.
 

docs/en/developer/building_application/operation_maintaining/application_rollouts/bluegreen_deployment.mdx

@@ -19,7 +19,7 @@ The status of native applications and their corresponding meanings are as follow
 
 **Note**: Similarly, the numbers in the computing component status indicate the number of container groups.
 
-# Deployment
+## Deployment
 
 - Running: All Pods are in normal operation.
 

docs/en/developer/building_application/operation_maintaining/application_rollouts/canary_deployment.mdx

@@ -10,11 +10,11 @@ i18n:
 
 With Alauda Container Platform you can interact with images, depending on where the registries of the images are located, any authentication requirements around those registries, and how you want your builds and deployments to behave. 
 
-# Image pull policy
+## Image pull policy
 
 Each container in a pod has a container image. After you have created an image and pushed it to a registry, you can then refer to it in the pod. 
 
-## Image pull policy overview
+### Image pull policy overview
 
 When Alauda Container Platform creates containers, it uses the container `imagePullPolicy` to determine if the image should be pulled prior to starting the container. There are three possible values for `imagePullPolicy`: 
 
@@ -29,13 +29,13 @@ If a container imagePullPolicy parameter is not specified, Alauda Container Plat
 1. If the tag is latest, Alauda Container Platform defaults imagePullPolicy to Always.
 2. Otherwise, Alauda Container Platform defaults imagePullPolicy to IfNotPresent. 
 
-# Using image pull secrets
+## Using image pull secrets
 
 If you are using the Alauda Container Platform image registry, then your pod service account should already have the correct permissions and no additional action should be required. 
 
 However, for other scenarios, such as referencing images across Alauda Container Platform projects or from secured registries, additional configuration steps are required. 
 
-## Allowing pods to reference images from other secured registries
+### Allowing pods to reference images from other secured registries
 
 To pull a secured container from other private or secured registries, you must create a pull secret from your container client credentials, such as `Docker`, and add it to your service account. 
 
@@ -45,11 +45,11 @@ By default, Docker uses $HOME/.docker/config.json.
 
 These files store your authentication information if you have previously logged in to a secured or insecure registry. 
 
-## Creating a pull secret
+### Creating a pull secret
 
 You can obtain the image pull secret to pull an image from a private container image registry or repository. You can refer to [Pull an Image from a Private Registry](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/).
 
-## Using a pull secret in a workload
+### Using a pull secret in a workload
 
 You can use a pull secret to allow workloads to pull images from a private registry with one of the following methods: 
 

docs/en/developer/building_application/operation_maintaining/status.mdx

@@ -7,13 +7,11 @@ i18n:
 
 # Lifecycle Policy
 
-# Version Lifecycle Timeline  
+## Version Lifecycle Timeline
 
 Below is the lifecycle schedule for released versions of the Alauda Container Platform Builds Operator:
 
 
 | **Version** | **Release Date** | **End of Life** |
 |:-----------:|:----------------:|:---------------:|
 | v1.1.0      | 2025-08-15       | 2027-08-15      |
-
-

docs/en/developer/images/how_to/manging_images.mdx

@@ -2,7 +2,7 @@
   "name": "acp-docs",
   "type": "module",
   "private": true,
-  "packageManager": "yarn@4.12.0",
+  "packageManager": "yarn@4.14.1",
   "scripts": {
     "build": "doom build",
     "dev": "doom dev",
@@ -14,7 +14,7 @@
     "update-ac-manual": "node scripts/update-ac-manual.js release-1.0"
   },
   "dependencies": {
-    "@alauda/doom": "^1.22.0"
+    "@alauda/doom": "^2.2.0"
   },
   "devDependencies": {
     "prettier": "^3.7.4",