chore: move current user guides of kusion to a new dir for cli (#590)

* chore: move current user guides of kusion to a new dir for cli

* fix: broken link error

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

@@ -93,7 +93,7 @@ The `importedResources` block is designed to declare the import of existing clou
 
 ### secretStore
 
-The `secretStore` field can be used to access the sensitive data stored in a cloud-based secrets manager. More details can be found in [here](../5-user-guides/4-secrets-management/1-using-cloud-secrets.md). 
+The `secretStore` field can be used to access the sensitive data stored in a cloud-based secrets manager. More details can be found in [here](../5-user-guides/1-using-kusion-cli/4-secrets-management/1-using-cloud-secrets.md). 
 
 ### context
 

docs/kusion/4-configuration-walkthrough/8-monitoring.md

@@ -8,7 +8,7 @@ As of version 0.11.0, Kusion supports integration with Prometheus by managing sc
 
 For the monitoring configuration to work (more specifically, consumed by Prometheus), this requires the target cluster to have installed Prometheus correctly, either as a Kubernetes operator or a server/agent.
 
-More about how to set up Prometheus can be found in the [Prometheus User Guide for Kusion](../user-guides/observability/prometheus)
+More about how to set up Prometheus can be found in the [Prometheus User Guide for Kusion](../5-user-guides/1-using-kusion-cli/3-observability/1-prometheus.md)
 :::
 
 ## Import
@@ -26,7 +26,7 @@ import monitoring as m
 
 In addition to the KCL configuration file, there are also workspace-level configurations that should be set first. In an ideal scenario, this step is done by the platform engineers. 
 
-In the event that they do not exist for you or your organization, e.g. if you are an individual developer, you can either do it yourself or use the [default values](#default-values) provided by the KusionStack team. The steps to do this yourself can be found in the [Prometheus User Guide for Kusion](../user-guides/observability/prometheus#setting-up-workspace-configs).
+In the event that they do not exist for you or your organization, e.g. if you are an individual developer, you can either do it yourself or use the [default values](#default-values) provided by the KusionStack team. The steps to do this yourself can be found in the [Prometheus User Guide for Kusion](../5-user-guides/1-using-kusion-cli/3-observability/1-prometheus.md#setting-up-workspace-configs).
 
 :::info
 
@@ -87,7 +87,7 @@ Note that numbered ports only work when your Prometheus is not running as an ope
 
 Neither `path` and `port` are required fields if Prometheus runs as an operator. If omitted, `path` defaults to `/metrics`, and `port` defaults to the container port or service port, depending on which resource is being monitored. If Prometheus does not run as an operator, both fields are required.
 
-Scraping scheme, interval and timeout are considered platform-managed configurations and are therefore managed as part of the [workspace configurations](../user-guides/observability/prometheus#setting-up-workspace-configs).
+Scraping scheme, interval and timeout are considered platform-managed configurations and are therefore managed as part of the [workspace configurations](../5-user-guides/1-using-kusion-cli/3-observability/1-prometheus.md#setting-up-workspace-configs).
 
 More details about how the Prometheus integration works can be found in the [design documentation](https://github.com/KusionStack/kusion/blob/main/docs/prometheus.md).
 
@@ -99,4 +99,4 @@ If no workspace configurations are found, the default values provided by the Kus
 - Scraping scheme defaults to http
 - Defaults to NOT running as an operator
 
-If any of the default values does not meet your need, you can change them by [setting up the workspace configuration](../user-guides/observability/prometheus#setting-up-workspace-configs).
+If any of the default values does not meet your need, you can change them by [setting up the workspace configuration](../5-user-guides/1-using-kusion-cli/3-observability/1-prometheus.md#setting-up-workspace-configs).

docs/kusion/5-user-guides/1-cloud-resources/1-database.md → docs/kusion/5-user-guides/1-using-kusion-cli/1-cloud-resources/1-database.md

@@ -11,7 +11,7 @@ This tutorial will demonstrate how to deploy a WordPress application with Kusion
 
 ## Prerequisites
 
-- Install [Kusion](../../2-getting-started/1-install-kusion.md). 
+- Install [Kusion](../../../2-getting-started/1-install-kusion.md). 
 - Install [kubectl CLI](https://kubernetes.io/docs/tasks/tools/#kubectl) and run a [Kubernetes](https://kubernetes.io/) or [k3s](https://docs.k3s.io/quick-start) or [k3d](https://k3d.io/v5.4.4/#installation) or [MiniKube](https://minikube.sigs.k8s.io/docs/tutorials/multi_node) cluster. 
 - Prepare a cloud service account and create a user with at least **VPCFullAccess** and **RDSFullAccess** related permissions to use the Relational Database Service (RDS). This kind of user can be created and managed in the Identity and Access Management (IAM) console of the cloud vendor. 
 - The environment that executes `kusion` needs to have connectivity to terraform registry to download the terraform providers. 
@@ -125,7 +125,7 @@ kusion workspace show
 The `workspace.yaml` is a sample configuration file for workspace management, including `MySQL` module configs. Workspace configurations are usually declared by **Platform Engineers** and will take effect through the corresponding stack. 
 
 :::info
-More details about the configuration of Workspace can be found in [Concepts of Workspace](../../3-concepts/4-workspace.md). 
+More details about the configuration of Workspace can be found in [Concepts of Workspace](../../../3-concepts/4-workspace.md). 
 :::
 
 ## Create Project And Stack

docs/kusion/5-user-guides/1-cloud-resources/2-expose-service.md → docs/kusion/5-user-guides/1-using-kusion-cli/1-cloud-resources/2-expose-service.md

@@ -123,7 +123,7 @@ tree
 ```
 
 :::info
-More details about the directory structure can be found in [Project](../../3-concepts/1-project/1-overview.md) and [Stack](../../3-concepts/2-stack/1-overview.md). 
+More details about the directory structure can be found in [Project](../../../3-concepts/1-project/1-overview.md) and [Stack](../../../3-concepts/2-stack/1-overview.md). 
 :::
 
 ### Update And Review Configuration Codes

docs/kusion/5-user-guides/2-working-with-k8s/1-deploy-application.md → docs/kusion/5-user-guides/1-using-kusion-cli/2-working-with-k8s/1-deploy-application.md

@@ -6,7 +6,7 @@ id: deploy-application
 
 This guide shows you how to use Kusion CLIs to complete the deployment of an application running in Kubernetes.
 We call the abstraction of application operation and maintenance configuration as `AppConfiguration`, and its instance as `Application`.
-It is essentially a configuration model that describes an application. The complete definition can be seen [here](../../reference/modules/developer-schemas/app-configuration).
+It is essentially a configuration model that describes an application. The complete definition can be seen [here](../../../6-reference/2-modules/1-developer-schemas/app-configuration.md).
 
 In production, the application generally includes minimally several k8s resources:
 
@@ -31,7 +31,7 @@ Before we start, we need to complete the following steps:
 1、Install Kusion
 
 We recommend using HomeBrew(Mac), Scoop(Windows), or an installation shell script to download and install Kusion.
-See [Download and Install](../../getting-started/install-kusion) for more details.
+See [Download and Install](../../../2-getting-started/1-install-kusion.md) for more details.
 
 2、Running Kubernetes cluster
 
@@ -44,7 +44,7 @@ This guide is to deploy an app using Kusion, relying on the Kusion CLI and an ex
 
 ### Initializing workspace configuration
 
-In version 0.10.0, we have introduced the new concept of [workspaces](../../concepts/workspace), which is a logical layer whose configurations represent an opinionated set of defaults, often appointed by the platform team. In most cases workspaces are represented with an "environment" in traditional SDLC terms. These workspaces provide a means to separate the concerns between the **application developers** who wish to focus on business logic, and a group of **platform engineers** who wish to standardize the applications on the platform.
+In version 0.10.0, we have introduced the new concept of [workspaces](../../../3-concepts/4-workspace.md), which is a logical layer whose configurations represent an opinionated set of defaults, often appointed by the platform team. In most cases workspaces are represented with an "environment" in traditional SDLC terms. These workspaces provide a means to separate the concerns between the **application developers** who wish to focus on business logic, and a group of **platform engineers** who wish to standardize the applications on the platform.
 
 Driven by the discipline of Platform Engineering, management of the workspaces, including create/updating/deleting workspaces and their configurations should be done by dedicated platform engineers in a large software organizations to facilitate a more mature and scalable collaboration pattern.
 
@@ -120,7 +120,7 @@ The project directory has the following files that are automatically generated:
 In general, the `.k` files are the KCL source code that represents the application configuration, and the `.yaml` is the static configuration file that describes behavior at the project or stack level.
 
 :::info
-See [Project](../../concepts/project/overview) and [Stack](../../concepts/stack/overview) for more details about Project and Stack.
+See [Project](../../../3-concepts/1-project/1-overview.md) and [Stack](../../../3-concepts/2-stack/1-overview.md) for more details about Project and Stack.
 :::
 
 The `kusion init` command will create a demo quickstart application, we may update the `dev/kcl.mod` and `dev/main.k` later. 
@@ -189,7 +189,7 @@ cd simple-service/dev && kusion preview
 ```
 
 :::tip
-For instructions on the kusion command line tool, execute `kusion -h`, or refer to the tool's online [documentation](../../reference/commands).
+For instructions on the kusion command line tool, execute `kusion -h`, or refer to the tool's online [documentation](../../../6-reference/1-commands/index.md).
 :::
 
 ## Applying

docs/kusion/5-user-guides/2-working-with-k8s/10-customize-health-policy.md → docs/kusion/5-user-guides/1-using-kusion-cli/2-working-with-k8s/10-customize-health-policy.md

@@ -8,9 +8,9 @@ Kusion now offers advanced customized health checks leveraging the power of `KCL
 
 ## Prerequisites
 
-Please refer to the [prerequisites](deploy-application#prerequisites) in the guide for deploying an application.
+Please refer to the [prerequisites](1-deploy-application.md#prerequisites) in the guide for deploying an application.
 
-The example below also requires you to have [initialized the project](deploy-application#initializing) using the `kusion workspace create` and `kusion init` command, which will create a workspace and also generate a [`kcl.mod` file](deploy-application#kclmod) under the stack directory.
+The example below also requires you to have [initialized the project](1-deploy-application.md#initializing) using the `kusion workspace create` and `kusion init` command, which will create a workspace and also generate a [`kcl.mod` file](1-deploy-application.md#kclmod) under the stack directory.
 
 ## Defining a Health Policy
 
@@ -191,4 +191,4 @@ Ensure that the resource meets the conditions defined in your health policy.
 
 Customized health checks provides a powerful way to ensure your Kubernetes resources are in the desired state before considering an `apply` operation complete. By defining health policies, you can automate the validation of your resources and ensure they meet specific criteria before being considered healthy. By leveraging KCL, you can create sophisticated health check logic tailored to your specific `project` needs.
 
-For more details on KCL and its syntax, refer to the [KCL documentation](../../4-configuration-walkthrough/2-kcl-basics.md).
+For more details on KCL and its syntax, refer to the [KCL documentation](../../../4-configuration-walkthrough/2-kcl-basics.md).

docs/kusion/5-user-guides/2-working-with-k8s/2-container.md → docs/kusion/5-user-guides/1-using-kusion-cli/2-working-with-k8s/2-container.md

@@ -6,17 +6,17 @@ id: container
 
 You can manage container-level configurations in the `AppConfiguration` model via the `containers` field (under the `workload` schema). By default, everything defined in the `containers` field will be treated as application containers. Sidecar containers will be supported in a future version of kusion.
 
-For the full `Container` schema reference, please see [here](../../reference/modules/developer-schemas/workload/service#schema-container) for more details.
+For the full `Container` schema reference, please see [here](../../../6-reference/2-modules/1-developer-schemas/workload/service.md#schema-container) for more details.
 
 ## Pre-requisite
 
-Please refer to the [prerequisites](deploy-application#prerequisites) in the guide for deploying an application.
+Please refer to the [prerequisites](1-deploy-application.md#prerequisites) in the guide for deploying an application.
 
-The example below also requires you to have [initialized the project](deploy-application#initializing) using the `kusion workspace create` and `kusion init` command, which will create a workspace and also generate a [`kcl.mod` file](deploy-application#kclmod) under the stack directory.
+The example below also requires you to have [initialized the project](1-deploy-application.md#initializing) using the `kusion workspace create` and `kusion init` command, which will create a workspace and also generate a [`kcl.mod` file](1-deploy-application.md#kclmod) under the stack directory.
 
 ## Managing Workspace Configuration
 
-In the last guide, we introduced a step to [initialize a workspace](deploy-application#initializing-workspace-configuration) with an empty configuration. The same empty configuration will still work in this guide, no changes are required there.
+In the last guide, we introduced a step to [initialize a workspace](1-deploy-application.md#initializing-workspace-configuration) with an empty configuration. The same empty configuration will still work in this guide, no changes are required there.
 
 However, if you (or the platform team) would like to set default values for the workloads to standardize the behavior of applications in the `dev` workspace, you can do so by updating the `~/dev.yaml`:
 
@@ -40,7 +40,7 @@ The workspace configuration need to be updated with the command:
 kusion workspace update dev -f ~/dev.yaml
 ```
 
-For a full reference of what can be configured in the workspace level, please see the [workspace reference](../../reference/modules/workspace-configs/workload/service).
+For a full reference of what can be configured in the workspace level, please see the [workspace reference](../../../6-reference/2-modules/2-workspace-configs/workload/service.md).
 
 ## Example
 
@@ -89,7 +89,7 @@ import network as n
 
 ## Apply
 
-Re-run steps in [Applying](deploy-application#applying), new container configuration can be applied.
+Re-run steps in [Applying](1-deploy-application.md#applying), new container configuration can be applied.
 
 ```
 $ kusion apply

docs/kusion/5-user-guides/2-working-with-k8s/3-service.md → docs/kusion/5-user-guides/1-using-kusion-cli/2-working-with-k8s/3-service.md

@@ -8,17 +8,17 @@ You can determine how to expose your service in the `AppConfiguration` model via
 
 Unless explicitly defined, each of the ports exposed is by default exposed privately as a `ClusterIP` type service. You can expose a port publicly by specifying the `public` field in the `Port` schema. At the moment, the implementation for publicly access is done via Load Balancer type service backed by cloud providers. Ingress will be supported in a future version of kusion.
 
-For the `Port` schema reference, please see [here](../../reference/modules/developer-schemas/workload/service#schema-port) for more details.
+For the `Port` schema reference, please see [here](../../../6-reference/2-modules/1-developer-schemas/workload/service.md#schema-port) for more details.
 
 ## Prerequisites
 
-Please refer to the [prerequisites](deploy-application#prerequisites) in the guide for deploying an application.
+Please refer to the [prerequisites](1-deploy-application.md#prerequisites) in the guide for deploying an application.
 
-The example below also requires you to have [initialized the project](deploy-application#initializing) using the `kusion workspace create` and `kusion init` command, which will create a workspace and also generate a [`kcl.mod` file](deploy-application#kclmod) under the stack directory.
+The example below also requires you to have [initialized the project](1-deploy-application.md#initializing) using the `kusion workspace create` and `kusion init` command, which will create a workspace and also generate a [`kcl.mod` file](1-deploy-application.md#kclmod) under the stack directory.
 
 ## Managing Workspace Configuration
 
-In the first guide in this series, we introduced a step to [initialize a workspace](deploy-application#initializing-workspace-configuration) with an empty configuration. The same empty configuration will still work in this guide, no changes are required there.
+In the first guide in this series, we introduced a step to [initialize a workspace](1-deploy-application.md#initializing-workspace-configuration) with an empty configuration. The same empty configuration will still work in this guide, no changes are required there.
 
 However, if you (or the platform team) would like to set default values for the services to standardize the behavior of applications in the `dev` workspace, you can do so by updating the `~/dev.yaml`:
 
@@ -40,7 +40,7 @@ The workspace configuration need to be updated with the command:
 kusion workspace update dev -f ~/dev.yaml
 ```
 
-For a full reference of what can be configured in the workspace level, please see the [workspace reference](../../reference/modules/workspace-configs/networking/network).
+For a full reference of what can be configured in the workspace level, please see the [workspace reference](../../../6-reference/2-modules/2-workspace-configs/networking/network.md).
 
 ## Example
 
@@ -92,7 +92,7 @@ The code above changes the service port to expose from `80` in the last guide to
 
 ## Applying
 
-Re-run steps in [Applying](deploy-application#applying), new service configuration can be applied.
+Re-run steps in [Applying](1-deploy-application.md#applying), new service configuration can be applied.
 
 ```
 $ kusion apply

docs/kusion/5-user-guides/2-working-with-k8s/4-image-upgrade.md → docs/kusion/5-user-guides/1-using-kusion-cli/2-working-with-k8s/4-image-upgrade.md

@@ -6,17 +6,17 @@ id: image-upgrade
 
 You can declare the application's container image via `image` field of the `Container` schema.
 
-For the full `Container` schema reference, please see [here](../../reference/modules/developer-schemas/workload/service#schema-container) for more details.
+For the full `Container` schema reference, please see [here](../../../6-reference/2-modules/1-developer-schemas/workload/service.md#schema-container) for more details.
 
 ## Pre-requisite
 
-Please refer to the [prerequisites](deploy-application#prerequisites) in the guide for deploying an application.
+Please refer to the [prerequisites](1-deploy-application.md#prerequisites) in the guide for deploying an application.
 
-The example below also requires you to have [initialized the project](deploy-application#initializing) using the `kusion workspace create` and `kusion init` command, which will create a workspace and also generate a [`kcl.mod` file](deploy-application#kclmod) under the stack directory.
+The example below also requires you to have [initialized the project](1-deploy-application.md#initializing) using the `kusion workspace create` and `kusion init` command, which will create a workspace and also generate a [`kcl.mod` file](1-deploy-application.md#kclmod) under the stack directory.
 
 ## Managing Workspace Configuration
 
-In the first guide in this series, we introduced a step to [initialize a workspace](deploy-application#initializing-workspace-configuration) with an empty configuration. The same empty configuration will still work in this guide, no changes are required there.
+In the first guide in this series, we introduced a step to [initialize a workspace](1-deploy-application.md#initializing-workspace-configuration) with an empty configuration. The same empty configuration will still work in this guide, no changes are required there.
 
 ## Example
 
@@ -40,7 +40,7 @@ Everything else in `main.k` stay the same.
 
 ## Applying
 
-Re-run steps in [Applying](deploy-application#applying), update image is completed.
+Re-run steps in [Applying](1-deploy-application.md#applying), update image is completed.
 
 ```
 $ kusion apply