docs: update broken links

ffforest · ffforest · commit 73231cc3569d · 2025-01-22T14:48:34.000+08:00
diff --git a/docs/kusion/1-what-is-kusion/2-kusion-vs-x.md b/docs/kusion/1-what-is-kusion/2-kusion-vs-x.md
@@ -10,7 +10,7 @@ It can be difficult to understand how different software compare to each other.
  
 According to the [open GitOps principles](https://opengitops.dev/), GitOps systems typically have its desired state expressed declaratively, continuously observe actual system state and attempt to apply the desired state. In the design of Kusion toolchain, we refer to those principles but have no intention to reinvent any GitOps systems wheel. 
 
-Kusion adopts your GitOps process and improves it with richness of features. The declarative [AppConfiguration](../concepts/app-configuration) model can be used to express desired intent, once intent is declared [Kusion CLI](../reference/commands) takes the role to make production match intent as safely as possible. 
+Kusion adopts your GitOps process and improves it with richness of features. The declarative [AppConfiguration](../concepts/appconfigurations) model can be used to express desired intent, once intent is declared [Kusion CLI](../reference/commands) takes the role to make production match intent as safely as possible. 
 
 **vs. PaaS (Heroku, Vercel, etc.)**
 
@@ -24,7 +24,7 @@ Kusion allows you to have platform-like features without the constraints of a tr
 
 KubeVela is a modern software delivery and management control plane which makes it easier to deploy and operate applications on top of Kubernetes.
 
-Although some might initially perceive an overlap between Kusion and KubeVela, they are in fact complementary and can be integrated to work together. As a lightweight, purely client-side tool, coupled with corresponding [Generator](https://github.com/KusionStack/kusion-module-framework) implementation, Kusion can render [AppConfiguration](../concepts/app-configuration) schema to generate CRD resources for KubeVela and leverage KubeVela's control plane to implement application delivery.
+Although some might initially perceive an overlap between Kusion and KubeVela, they are in fact complementary and can be integrated to work together. As a lightweight, purely client-side tool, coupled with corresponding [Generator](https://github.com/KusionStack/kusion-module-framework) implementation, Kusion can render [AppConfiguration](../concepts/appconfigurations) schema to generate CRD resources for KubeVela and leverage KubeVela's control plane to implement application delivery.
 
 **vs. Helm**
 
diff --git a/docs/kusion/3-concepts/0-overview.md b/docs/kusion/3-concepts/0-overview.md
@@ -18,9 +18,9 @@ In this section, we will provide an overview of the core concepts of Kusion from
 
 The workflow of Kusion is illustrated in the diagram above, which consists of three steps. 
 
-The first step is **Write**, where the platform engineers build the [Kusion Modules](./3-module/1-overview.md) and initialize a [Workspace](./4-workspace/1-overview.md). And the application developers declare their operational intent in [AppConfiguration](./5-appconfiguration.md) under a specific [Project](./1-project/1-overview.md) and [Stack](./2-stack/1-overview.md) path. 
+The first step is **Write**, where the platform engineers build the [Kusion Modules](./3-module/1-overview.md) and initialize a [Workspace](./4-workspace/1-overview.md). And the application developers declare their operational intent in [AppConfiguration](./5-appconfigurations.md) under a specific [Project](./1-project/1-overview.md) and [Stack](./2-stack/1-overview.md) path. 
 
-The second step is the **Generate** process, which results in the creation of the **SSoT** (Single Source of Truth), also known as the [Spec](./6-spec.md) of the current operation. Kusion stores and version controls the Spec as part of a [Release](./8-release.md).
+The second step is the **Generate** process, which results in the creation of the **SSoT** (Single Source of Truth), also known as the [Spec](./6-specs.md) of the current operation. Kusion stores and version controls the Spec as part of a [Release](./8-release.md).
 
 The third step is **Apply**, which makes the `Spec` effective. Kusion parses the operational intent based on the `Spec` produced in the previous step. Before applying the `Spec`, Kusion will execute the `Preview` command (you can also execute this command manually) which will use a three-way diff algorithm to preview changes and prompt users to make sure all changes meet their expectations. And the `Apply` command will then actualize the operation intent onto various infrastructure platforms, currently supporting **Kubernetes**, **Terraform**, and **On-Prem** infrastructures. A [Release](./8-release.md) file will be created in the [Storage Backend](./7-backend/1-overview.md) to record an operation. The `Destroy` command will delete the resources recorded in the `Release` file of a project in a specific workspace. 
 
diff --git a/docs/kusion/3-concepts/10-resources.md b/docs/kusion/3-concepts/10-resources.md
@@ -1,6 +1,6 @@
 # Resources
 
-Kusion uses [Spec](./6-spec.md) to manage resource specifications. A Kusion resource is a logical concept that encapsulates physical resources on different resource planes, including but not limited to Kubernetes, AWS, AliCloud, Azure and Google Cloud.
+Kusion uses [Spec](./6-specs.md) to manage resource specifications. A Kusion resource is a logical concept that encapsulates physical resources on different resource planes, including but not limited to Kubernetes, AWS, AliCloud, Azure and Google Cloud.
 
 Kusion Resources are produced by [Kusion Module Generators](./3-module/1-overview.md) and usually map to a physical resource that can be applied via a Kusion Runtime.
 
diff --git a/docs/kusion/3-concepts/3-module/1-overview.md b/docs/kusion/3-concepts/3-module/1-overview.md
@@ -3,7 +3,7 @@
 A Kusion module is a reusable building block designed by platform engineers to standardize application deployments and enable application developers to self-service. It consists of two parts:
 
 - App developer-friendly schema: It is a [KCL schema](https://kcl-lang.io/docs/user_docs/guides/schema-definition/). Fields in this schema are recommended to be understandable to application developers and workspace-agnostic. For example, a database Kusion module schema only contains fields like database engine type and database version.
-- Kusion module generator: It is a piece of logic that generates the [Spec](../6-spec.md) with an instantiated schema mentioned above, along with platform configurations managed in [workspaces](../4-workspace/1-overview.md). As the most fundamental building block, Kusion module provides the necessary abstraction to the developers by hiding the complexity of infrastructures. A database Kusion module not only represents a cloud RDS, but it also contains logic to configure other resources such as security groups and IAM policies. Additionally, it seamlessly injects the database host address, username, and password into the workload's environment variables. The generator logic can be very complex in some situations so we recommend implementing it in a GPL like [go](https://go.dev/).
+- Kusion module generator: It is a piece of logic that generates the [Spec](../6-specs.md) with an instantiated schema mentioned above, along with platform configurations managed in [workspaces](../4-workspace/1-overview.md). As the most fundamental building block, Kusion module provides the necessary abstraction to the developers by hiding the complexity of infrastructures. A database Kusion module not only represents a cloud RDS, but it also contains logic to configure other resources such as security groups and IAM policies. Additionally, it seamlessly injects the database host address, username, and password into the workload's environment variables. The generator logic can be very complex in some situations so we recommend implementing it in a GPL like [go](https://go.dev/).
 
 Here are some explanations of the Kusion Module:
 
diff --git a/docs/kusion/3-concepts/3-module/2-develop-guide.md b/docs/kusion/3-concepts/3-module/2-develop-guide.md
@@ -113,7 +113,7 @@ service:                    Service
 randomPassword:             RandomPassword
 ```
 
-3. **Implement the [gRPC proto](https://github.com/KusionStack/kusion/blob/main/pkg/modules/proto/module.proto) generate interface.** The `generate` interface consumes the application developer's config described in the [`AppConfiguration`](../app-configuration) and the platform engineer's config described in the [`workspace`](../4-workspace/1-overview.md) to generate all infrastructure resources represented by this module.
+3. **Implement the [gRPC proto](https://github.com/KusionStack/kusion/blob/main/pkg/modules/proto/module.proto) generate interface.** The `generate` interface consumes the application developer's config described in the [`AppConfiguration`](../appconfigurations) and the platform engineer's config described in the [`workspace`](../4-workspace/1-overview.md) to generate all infrastructure resources represented by this module.
 
 ```go
 func (k *Kawesome) Generate(_ context.Context, request *module.GeneratorRequest) (*module.GeneratorResponse, error) {
@@ -139,7 +139,7 @@ type Patcher struct {
 ```
 
 The `GeneratorRequest` contains the application developer's config, platform engineer's config, workload config and related metadata a module could need to generate infrastructure resources.
-In the `GeneratorResponse`, there are two fields, `Resources` and `Patchers`. The `Resource` represents resources that should operated by Kusion and they will be appended into the [Spec](../spec). The `Patchers` are used to patch the workload and other resources.
+In the `GeneratorResponse`, there are two fields, `Resources` and `Patchers`. The `Resource` represents resources that should operated by Kusion and they will be appended into the [Spec](../specs). The `Patchers` are used to patch the workload and other resources.
 
 ### Workload
 
diff --git a/docs/kusion/3-concepts/5-appconfigurations.md b/docs/kusion/3-concepts/5-appconfigurations.md
@@ -1,9 +1,4 @@
----
-id: app-configuration
-sidebar_label: AppConfiguration
----
-
-# AppConfiguration
+# AppConfigurations
 
 As a modern cloud-native application delivery toolchain, declarative intent-based actuation is the central idea of Kusion, and `AppConfiguration` model plays the role of describing the intent, which provides a simpler path for on-boarding developers to the platform without leaking low-level details in runtime infrastructure and allows developers to fully focus on the application logic itself.
 
diff --git a/docs/kusion/3-concepts/6-specs.md b/docs/kusion/3-concepts/6-specs.md
@@ -1,9 +1,4 @@
----
-id: spec
-sidebar_label: Spec
----
-
-# Spec
+# Specs
 
 The spec is a system-generated, immutable, declarative representation of the resources involved in a particular deployment. As opposed to the static configurations that are stored in a stack folder in a git repository, which may or may not be scoped to a given deploy target, a spec is dynamically rendered from the aggregated intents from multiple sources, including those that are target-specific, and those aren't (e.g. global configs, constraints posed by security, compliance and so on, for example what kind of application may have Internet access). Specs are resource-facing desired states and are always rendered on the spot based on all the relevant inputs.
 
diff --git a/docs/kusion/3-concepts/8-release.md b/docs/kusion/3-concepts/8-release.md
@@ -13,7 +13,7 @@ Every time an `apply` or `destroy` operation is executed, it will trigger the ge
 For kusion server, the default release path is `releases/server/$SOURCE_NAME/$PROJECT_NAME/$WORKSPACE_NAME`
 :::
 
-The release file contains the [Spec](./6-spec.md) and [State](./8-release.md#state) of an application, both of which are composed of `Resources`, representing the expected description from the configuration code and the actual state of the resources respectively. In addition, the release file also contains the information of creation and modification time, operation phase, and application metadata, etc.
+The release file contains the [Spec](./6-specs.md) and [State](./8-release.md#state) of an application, both of which are composed of `Resources`, representing the expected description from the configuration code and the actual state of the resources respectively. In addition, the release file also contains the information of creation and modification time, operation phase, and application metadata, etc.
 
 ## State
 
diff --git a/docs/kusion/3-concepts/9-runs.md b/docs/kusion/3-concepts/9-runs.md
@@ -18,7 +18,7 @@ Please note that in the case of APIs the runs APIs are asynchronous. An external
 
 There are 4 types of runs:
 
-- Generate: Generate the resource-facing desired state, or [Spec](./6-spec.md) for the given stack and workspace
+- Generate: Generate the resource-facing desired state, or [Spec](./6-specs.md) for the given stack and workspace
 - Preview: Preview the resource changes for the given stack and workspace based on the difference between desired state and current state
 - Apply: Apply the desired state to the target workspace
 - Destroy: Destroy the resources for the given stack in the target workspace
diff --git a/docs/kusion/4-configuration-walkthrough/1-overview.md b/docs/kusion/4-configuration-walkthrough/1-overview.md
@@ -68,7 +68,7 @@ The schema for `AppConfiguration` is defined in the [KusionStack/kam](https://gi
 
 `AppConfiguration` consists of multiple sub-components that each represent either the application workload itself, its dependencies (in the form of [Kusion Modules](../concepts/module/overview)), relevant workflows or operational expectations. We will deep dive into the details on how to author each of these elements in this upcoming documentation series.
 
-For more details on the `AppConfiguration`, please refer to the [design documentation](../concepts/app-configuration).
+For more details on the `AppConfiguration`, please refer to the [design documentation](../concepts/appconfigurations).
 
 ## Authoring Configuration Files
 
diff --git a/docs/kusion/5-user-guides/1-using-kusion-cli/5-production-practice-case/1-production-practice-case.md b/docs/kusion/5-user-guides/1-using-kusion-cli/5-production-practice-case/1-production-practice-case.md
@@ -70,7 +70,7 @@ So far, PE has almost completed the fundamental work for setting up the IDP.
 
 ### Setup Kusion Storage Backend
 
-In order to get the available modules of the workspace and validate the generated [spec](../../../3-concepts/6-spec.md), developers need to communicate with PEs to obtain the AK/SK (usually with **Read-Only** permission), bucket name, and the endpoint to access the remote storage backend. And similar to the PEs, developers can set up the backend configs with the following commands. 
+In order to get the available modules of the workspace and validate the generated [spec](../../../3-concepts/6-specs.md), developers need to communicate with PEs to obtain the AK/SK (usually with **Read-Only** permission), bucket name, and the endpoint to access the remote storage backend. And similar to the PEs, developers can set up the backend configs with the following commands. 
 
 ```shell
 # please replace the env with actual AK/SK
