docs: update concepts sidebar

docs/kusion/2-getting-started/2-deliver-quickstart.md

@@ -102,7 +102,7 @@ network = { oci = "oci://ghcr.io/kusionstack/network", tag = "0.2.0" }
 ```
 
 :::info
-More details about the application model and module dependency declaration can be found in [Kusion Module guide for app dev](../3-concepts/3-kusion-module/3-app-dev-guide.md). 
+More details about the application model and module dependency declaration can be found in [Kusion Module guide for app dev](../3-concepts/3-module/3-app-dev-guide.md). 
 :::
 
 :::tip

docs/kusion/3-concepts/1-project/_category_.json

@@ -1,3 +1,3 @@
 {
-    "label": "Project"
+    "label": "Projects"
 }

docs/kusion/3-concepts/2-stack/_category_.json

@@ -1,3 +1,3 @@
 {
-    "label": "Stack"
+    "label": "Stacks"
 }

docs/kusion/3-concepts/3-module/_category_.json

@@ -0,0 +1,3 @@
+{
+    "label": "Modules"
+}

docs/kusion/3-concepts/4-workspace.md

@@ -1,6 +1,6 @@
 ---
 id: workspace
-sidebar_label: Workspace
+sidebar_label: Workspaces
 ---
 
 # Workspace
@@ -71,7 +71,7 @@ The values of the same fields in `patcher` will override the `default`, and one
 
 In the `patcher`, the applied Projects are assigned by the field `ProjectSelector`, which is an array of the Project names. The `ProjectSelector` is provided rather than something may like `StackSelector`, which specifies the applied Stacks. Here are the reasons. Explaining from the perspective of using Workspace, the mapping of Workspace and Stack is specified by the Kusion operation commands' users. While explaining from the perspective of the relationship among Project, Stack and Workspace, Workspace is designed for the reuse of platform-level configuration among multiple Projects. When a Project "encounters" a Workspace, it becomes a "Stack instance", which can be applied to a series of real resources. If using something like `StackSelector`, the reuse would not get realized, and Workspace would also lose its relevance. For more information of the relationship, please refer to [Project](project/overview) and [Stack](stack/overview). 
 
-Different Module and KAM has different name, fields, and corresponding format and restrictions. When writing the configuration, check the corresponding Module's or KAM's description, and make sure all the requisite Modules and KAMs have correctly configured. Please refer to [Kuiosn Module](kusion-module/overview) and find more information. The example above gives a sample of the Module `mysql`.
+Different Module and KAM has different name, fields, and corresponding format and restrictions. When writing the configuration, check the corresponding Module's or KAM's description, and make sure all the requisite Modules and KAMs have correctly configured. Please refer to [Kuiosn Module](module/overview) and find more information. The example above gives a sample of the Module `mysql`.
 
 ## Managing Workspace
 

docs/kusion/3-concepts/7-backend.md

@@ -1,6 +1,6 @@
 ---
 id: backend
-sidebar_label: Backend
+sidebar_label: Backends
 ---
 
 # Backend

docs/kusion/4-configuration-walkthrough/1-overview.md

@@ -66,7 +66,7 @@ As a general best practice, we recommend managing the common configurations in `
 
 The schema for `AppConfiguration` is defined in the [KusionStack/kam](https://github.com/KusionStack/kam/blob/main/v1/app_configuration.k) repository. It is designed as a unified, application-centric model that encapsulates the comprehensive configuration details and in the meantime, hides the complexity of the infrastructure as much as possible.
 
-`AppConfiguration` consists of multiple sub-components that each represent either the application workload itself, its dependencies (in the form of [Kusion Modules](../concepts/kusion-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.
+`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).
 
@@ -86,7 +86,7 @@ In the context of Kusion, we abstracted a core set of KCL Schemas (such as the a
 
 ### Kusion Modules
 
-To extend the capabilities beyond the core KAM model, we use a concept known as [Kusion Modules](../concepts/kusion-module/overview) to define components that could best abstract the capabilities during an application delivery. We provide a collection of official out-of-the-box Kusion Modules that represents the most common capabilities. They are maintained in [KusionStack's GitHub container registry](https://github.com/orgs/KusionStack/packages). When authoring an application configuration file, you can simply declare said Kusion Modules as dependencies and import them to declare ship-time capabilities that the application requires.
+To extend the capabilities beyond the core KAM model, we use a concept known as [Kusion Modules](../concepts/module/overview) to define components that could best abstract the capabilities during an application delivery. We provide a collection of official out-of-the-box Kusion Modules that represents the most common capabilities. They are maintained in [KusionStack's GitHub container registry](https://github.com/orgs/KusionStack/packages). When authoring an application configuration file, you can simply declare said Kusion Modules as dependencies and import them to declare ship-time capabilities that the application requires.
 
 If the modules in the KusionStack container registry does not meet the needs of your applications, Kusion provides the necessary mechanisms to extend with custom-built Kusion Modules. You can always create and publish your own module, then import the new module in your application configuration written in KCL.
 

docs/kusion/5-user-guides/5-production-practice-case/1-production-practice-case.md

@@ -6,7 +6,7 @@ id: collaborate-with-github-actions
 
 In this article, we will introduce how to use Kusion CLI in combination with GitHub Actions to achieve team collaboration in production practice. 
 
-Adopting the concept of separation of concerns, we divide the staff involved in application delivery and operation into two groups: **Platform Engineers (PEs)** and **Developers (Devs)**. As the builders of the Internal Developer Platform (IDP), platform engineers are primarily responsible for creating the [storage backend](../../3-concepts/7-backend.md) for the Kusion CLI in team collaborative scenarios (e.g. AWS S3 or Alicloud OSS), developing custom reusable [Kusion modules](../../3-concepts/3-kusion-module/1-overview.md), and creating and maintaining standardized platform configurations in [workspace](../../3-concepts/4-workspace.md). While application developers can focus on writing the application business logic and the configuration codes, self-serving the application delivery and operation by triggering the automated CI/CD pipelines. [GitHub Actions](https://github.com/features/actions) is such a CI/CD platform, and by customizing [GitHub Actions workflow](https://docs.github.com/en/actions/using-workflows), the pipeline such as building, testing, and deploying will be executed automatically. 
+Adopting the concept of separation of concerns, we divide the staff involved in application delivery and operation into two groups: **Platform Engineers (PEs)** and **Developers (Devs)**. As the builders of the Internal Developer Platform (IDP), platform engineers are primarily responsible for creating the [storage backend](../../3-concepts/7-backend.md) for the Kusion CLI in team collaborative scenarios (e.g. AWS S3 or Alicloud OSS), developing custom reusable [Kusion modules](../../3-concepts/3-module/1-overview.md), and creating and maintaining standardized platform configurations in [workspace](../../3-concepts/4-workspace.md). While application developers can focus on writing the application business logic and the configuration codes, self-serving the application delivery and operation by triggering the automated CI/CD pipelines. [GitHub Actions](https://github.com/features/actions) is such a CI/CD platform, and by customizing [GitHub Actions workflow](https://docs.github.com/en/actions/using-workflows), the pipeline such as building, testing, and deploying will be executed automatically. 
 
 In the following sections, we will demonstrate the specific workflow from the perspectives of both PEs and Devs with the sample workflows from our [konfg](https://github.com/KusionStack/konfig) and [catalog](https://github.com/KusionStack/catalog) repository. 
 

docs_versioned_docs/version-v0.12/2-getting-started/2-deliver-quickstart.md

@@ -102,7 +102,7 @@ network = { oci = "oci://ghcr.io/kusionstack/network", tag = "0.2.0" }
 ```
 
 :::info
-More details about the application model and module dependency declaration can be found in [Kusion Module guide for app dev](../3-concepts/3-kusion-module/3-app-dev-guide.md). 
+More details about the application model and module dependency declaration can be found in [Kusion Module guide for app dev](../3-concepts/3-module/3-app-dev-guide.md). 
 :::
 
 :::tip

docs_versioned_docs/version-v0.12/3-concepts/1-project/_category_.json

@@ -1,3 +1,3 @@
 {
-    "label": "Project"
+    "label": "Projects"
 }

docs_versioned_docs/version-v0.12/3-concepts/2-stack/_category_.json

@@ -1,3 +1,3 @@
 {
-    "label": "Stack"
+    "label": "Stacks"
 }

docs_versioned_docs/version-v0.12/3-concepts/3-module/_category_.json

@@ -0,0 +1,3 @@
+{
+    "label": "Modules"
+}

docs_versioned_docs/version-v0.12/3-concepts/4-workspace.md

@@ -71,7 +71,7 @@ The values of the same fields in `patcher` will override the `default`, and one
 
 In the `patcher`, the applied Projects are assigned by the field `ProjectSelector`, which is an array of the Project names. The `ProjectSelector` is provided rather than something may like `StackSelector`, which specifies the applied Stacks. Here are the reasons. Explaining from the perspective of using Workspace, the mapping of Workspace and Stack is specified by the Kusion operation commands' users. While explaining from the perspective of the relationship among Project, Stack and Workspace, Workspace is designed for the reuse of platform-level configuration among multiple Projects. When a Project "encounters" a Workspace, it becomes a "Stack instance", which can be applied to a series of real resources. If using something like `StackSelector`, the reuse would not get realized, and Workspace would also lose its relevance. For more information of the relationship, please refer to [Project](project/overview) and [Stack](stack/overview). 
 
-Different Module and KAM has different name, fields, and corresponding format and restrictions. When writing the configuration, check the corresponding Module's or KAM's description, and make sure all the requisite Modules and KAMs have correctly configured. Please refer to [Kuiosn Module](kusion-module/overview) and find more information. The example above gives a sample of the Module `mysql`.
+Different Module and KAM has different name, fields, and corresponding format and restrictions. When writing the configuration, check the corresponding Module's or KAM's description, and make sure all the requisite Modules and KAMs have correctly configured. Please refer to [Kuiosn Module](module/overview) and find more information. The example above gives a sample of the Module `mysql`.
 
 ## Managing Workspace
 

docs_versioned_docs/version-v0.12/3-concepts/7-backend.md

@@ -1,6 +1,6 @@
 ---
 id: backend
-sidebar_label: Backend
+sidebar_label: Backends
 ---
 
 # Backend