@nocobase/plugin-ai 2.1.0-beta.44 → 2.1.0-beta.46

package/dist/ai/docs/nocobase/ai/install-upgrade-migration.mdx

@@ -1,50 +1,50 @@
 ---
-title: "Installation, Upgrade and Migration Guide: Using the NocoBase CLI"
-description: "Migrate from legacy Docker, create-nocobase-app, and Git-source installations to the new NocoBase CLI workflow."
-keywords: "NocoBase CLI,installation migration,upgrade migration,nb init,nb app upgrade,Docker,create-nocobase-app,Git source"
+title: 'Installation and Upgrade Migration Guide: Using NocoBase CLI'
+description: 'Migrate from legacy Docker, create-nocobase-app, and Git source installation upgrade methods to the new NocoBase CLI workflow.'
+keywords: 'NocoBase CLI,installation migration,upgrade migration,nb init,nb app upgrade,Docker,create-nocobase-app,Git source'
 ---
 
-# Installation, Upgrade and Migration Guide: Using the NocoBase CLI
+# Installation and Upgrade Migration Guide: Using NocoBase CLI
 
 :::danger
-The CLI's installation and application maintenance capabilities are still under active development. They are currently better suited for local development, test environments, and AI Agent integration scenarios. We do not recommend using them directly for production installation, upgrade, or operations.
+The CLI's installation and application maintenance capabilities are still under development. At present, it is more suitable for local development, test environments, and AI Agent integration scenarios, and is not recommended for direct installation, upgrade, operation, and maintenance in production environments.
 :::
 
-The new NocoBase CLI (`nb`) consolidates installation, connection, start, stop, log inspection, upgrade, and cleanup into a single command set. Compared with the legacy approach, where Docker, create-nocobase-app, and Git-source installations each have their own dedicated documentation, the CLI is better suited for local development, test environment maintenance, as well as AI Agent integration and collaboration.
+The new NocoBase CLI (`nb`) unifies installation, connection, startup, shutdown, log viewing, upgrade, and cleanup into one set of commands. Compared with the separate workflows in the old documentation for Docker, create-nocobase-app, and Git source, the CLI is better suited for local development, test environment maintenance, and AI Agent integration and collaboration.
 
-This guide is intended for the following scenarios:
+This article applies to the following scenarios:
 
-- You are installing or upgrading NocoBase using the legacy documentation and want to switch to the new CLI workflow.
-- You already have a NocoBase deployment from a legacy installation method and want the CLI to manage or connect to it.
-- You need to prepare a connectable, maintainable NocoBase environment for an AI Agent.
+- You are installing or upgrading NocoBase according to the old documentation and want to switch to the new CLI approach.
+- You already have a NocoBase deployed in a legacy way and want the CLI to manage or connect to it.
+- You need to prepare a connectable and maintainable NocoBase environment for an AI Agent.
 
-## Differences between the legacy and new approaches
+## Differences between the old and new approaches
 
-The legacy approach splits documentation by installation source. Each source requires its own download, configuration, installation, startup, and upgrade commands.
+The old approach splits documentation by installation source, and each source requires separate download, configuration, installation, startup, and upgrade commands.
 
-**Legacy installation docs**
+**Old installation documentation**
 
 - [Docker installation](/get-started/installation/docker)
 - [create-nocobase-app installation](/get-started/installation/create-nocobase-app)
 - [Git source installation](/get-started/installation/git)
 
-**Legacy upgrade docs**
+**Old upgrade documentation**
 
 - [Upgrading a Docker installation](/get-started/upgrading/docker)
 - [Upgrading a create-nocobase-app installation](/get-started/upgrading/create-nocobase-app)
 - [Upgrading a Git source installation](/get-started/upgrading/git)
 
-The new approach uses `nb init` as the entry point and stores the application source, runtime directory, storage directory, database, and API connection information in a single CLI env. Whether the source is Docker, npm, or Git, the same `nb app`, `nb source`, and `nb db` commands are used for maintenance whenever possible.
+The new approach uses `nb init` as the entry point and records the application source, runtime directory, storage directory, database, and API connection information in a CLI env. After that, whether the source is Docker, npm, or Git, maintenance uses the same set of `nb app`, `nb source`, and `nb db` commands as much as possible.
 
-| Scenario | Legacy approach | New CLI approach |
-| --- | --- | --- |
-| Installation entry point | `docker compose`, `create-nocobase-app`, `git clone` | `nb init` or `nb init --ui` |
-| Application runtime management | Switch directories, edit compose, run yarn/pm2 commands | `nb app start/stop/restart/logs/down` |
-| Upgrade | Separate command set per installation method | `nb app upgrade -e <env>` |
-| Development mode | `yarn dev` | `nb source dev -e <env>` |
-| Database status | Manually inspect containers or database services | `nb db ps -e <env>` |
-| View environment status and details | Manually track paths, ports, and access URLs | `nb env list`, `nb env info <env>` |
-| Connect to existing applications | Not unified across legacy install docs | `nb init --ui` or `nb init --api-base-url` |
+| Scenario                            | Old approach                                              | New CLI approach                                  |
+| ----------------------------------- | --------------------------------------------------------- | ------------------------------------------------- |
+| Installation entry point            | `docker compose`, `create-nocobase-app`, `git clone`      | `nb init` or `nb init --ui`                       |
+| Application runtime management      | Switch directories, modify compose, run yarn/pm2 commands | `nb app start/stop/restart/logs`, `nb env remove` |
+| Upgrade                             | One set of commands per installation method               | `nb app upgrade -e <env>`                         |
+| Development mode                    | `yarn dev`                                                | `nb source dev -e <env>`                          |
+| Database status                     | Manually inspect containers or database services          | `nb db ps -e <env>`                               |
+| View environment status and details | Manually record paths, ports, and access URLs             | `nb env list`, `nb env info <env>`                |
+| Access existing applications        | Not covered uniformly in old installation docs            | `nb init --ui` or `nb init --api-base-url`        |
 
 ## Install the CLI
 
@@ -53,14 +53,14 @@ npm install -g @nocobase/cli@beta
 nb --version
 ```
 
-After installation, you can view help:
+After installation, you can view the help:
 
 ```bash
 nb --help
 nb init --help
 ```
 
-## Install NocoBase the new way
+## Install NocoBase using the new approach
 
 ### Recommended: use the visual wizard
 
@@ -68,13 +68,13 @@ nb init --help
 nb init --ui
 ```
 
-The wizard walks you through:
+The wizard will guide you to choose:
 
-- Creating a new application or connecting to an existing one
-- Installation source: Docker, npm, or Git
+- Create a new application or connect to an existing application
+- Installation source: Docker, npm, Git
 - NocoBase version
-- Built-in or external database
-- Admin account and password
+- Use the built-in database or an external database
+- Administrator account and password
 
 ### Use the terminal interactive wizard
 
@@ -84,13 +84,13 @@ nb init
 
 ### Use non-interactive commands
 
-The default installation uses Docker with the built-in PostgreSQL database:
+The default installation method is Docker and uses the built-in PostgreSQL database:
 
 ```bash
 nb init --yes --env app1
 ```
 
-Install a specific version with Docker:
+Install a specified version with Docker:
 
 ```bash
 nb init --yes --env app1 --source docker --version beta
@@ -108,7 +108,7 @@ Install from Git source:
 nb init --yes --env app1 --source git --version beta
 ```
 
-Install from Git source with a specific built-in database type:
+Install from Git source and specify the built-in database type:
 
 ```bash
 nb init --yes --env app1 --source git --version beta --db-dialect mysql
@@ -117,10 +117,10 @@ nb init --yes --env app1 --source git --version beta --db-dialect mysql
 Connect to an existing NocoBase application:
 
 ```bash
-# OAuth authentication is used by default
+# Uses OAuth authentication by default
 nb init --yes --env app1 --api-base-url=http://next.v2.test.nocobase.com/nocobase/api
 
-# Use Token authentication
+# Use token authentication
 nb init --yes --env app1 \
   --api-base-url=http://next.v2.test.nocobase.com/nocobase/api \
   --auth-type=token \
@@ -128,24 +128,24 @@ nb init --yes --env app1 \
 ```
 
 :::tip
-`--env` is the environment name within the CLI. Subsequent commands such as start, upgrade, and log viewing can target the same application via `-e app1`.
+`--env` is the environment name in the CLI. Subsequent commands such as startup, upgrade, and log viewing can all specify the target application with `-e app1`.
 :::
 
-## Upgrade the new way
+## Upgrade using the new approach
 
-In the legacy approach, Docker, create-nocobase-app, and Git source each have their own upgrade commands. The new CLI unifies them as:
+In the old approach, the upgrade commands for Docker, create-nocobase-app, and Git source were different; the new CLI unifies them as:
 
 ```bash
 nb app upgrade -e app1
 ```
 
-If you only want to run the upgrade flow against the source code or images you already have, without pulling new code or images:
+If you only want to run the upgrade process using the source code or image that has already been downloaded, without pulling new code or images:
 
 ```bash
 nb app upgrade -e app1 --skip-code-update
 ```
 
-Or use the shorthand:
+Or use the short form:
 
 ```bash
 nb app upgrade -e app1 -s
@@ -153,48 +153,43 @@ nb app upgrade -e app1 -s
 
 ## Common maintenance commands
 
-| Action | Command |
-| --- | --- |
-| Start application | `nb app start -e app1` |
-| Stop application | `nb app stop -e app1` |
-| Restart application | `nb app restart -e app1` |
-| View logs | `nb app logs -e app1` |
-| View env and API authentication status | `nb env list` |
-| View env details | `nb env info app1` |
-| View built-in database status | `nb db ps -e app1` |
-| Upgrade application | `nb app upgrade -e app1` |
-| Stop and clean up runtime resources | `nb app down -e app1` |
+| Operation                                          | Command                              |
+| -------------------------------------------------- | ------------------------------------ |
+| Start application                                  | `nb app start -e app1`               |
+| Stop application                                   | `nb app stop -e app1`                |
+| Restart application                                | `nb app restart -e app1`             |
+| View logs                                          | `nb app logs -e app1`                |
+| View env and API authentication status             | `nb env list`                        |
+| View env details                                   | `nb env info app1`                   |
+| View built-in database status                      | `nb db ps -e app1`                   |
+| Upgrade application                                | `nb app upgrade -e app1`             |
+| Stop application and built-in database             | `nb app stop -e app1 --with-db`      |
+| Completely remove env and locally hosted resources | `nb env remove app1 --purge --force` |
 
-By default, `nb app down` stops the application and removes the runtime containers and local application files managed by the CLI, while preserving storage data and the env configuration. To remove everything you must explicitly confirm:
+If you just want to stop the application together with the built-in database managed by the CLI, the default is to simply use `nb app stop -e app1 --with-db`.
 
-```bash
-nb app down -e app1 --all --yes
-```
-
-:::warning
-`--all --yes` deletes the storage data and CLI env configuration for the env. Only use it when you are sure you have backups and no longer need this environment.
-:::
+If you are sure this env is no longer needed, then use `nb env remove app1 --purge --force`. It will remove hosted runtime resources, storage data, and, when applicable, local app files downloaded and managed by the CLI.
 
 ## Daily development commands
 
-`nb source` manages local source code projects. It is mainly used for npm and Git source envs.
+`nb source` is used to manage local source projects and is mainly suitable for npm and Git source envs.
 
-| Action | Command |
-| --- | --- |
-| Run application in development mode | `nb source dev -e app1` |
-| Build source | `nb source build --cwd /your/workspace/app1/source` |
-| Run tests | `nb source test --cwd /your/workspace/app1/source` |
-| Download or refresh source/images | `nb source download --source git --version beta` |
+| Operation                           | Command                                             |
+| ----------------------------------- | --------------------------------------------------- |
+| Run application in development mode | `nb source dev -e app1`                             |
+| Build source code                   | `nb source build --cwd /your/workspace/app1/source` |
+| Run tests                           | `nb source test --cwd /your/workspace/app1/source`  |
+| Download or refresh source/image    | `nb source download --source git --version beta`    |
 
 :::tip
-Docker envs are typically managed via `nb app start`, `nb app logs`, and `nb app upgrade`, and do not use `nb source dev`.
+Docker envs are usually managed through `nb app start`, `nb app logs`, and `nb app upgrade`, and do not use `nb source dev`.
 :::
 
-## NB_CLI_ROOT and directory layout
+## NB_CLI_ROOT and directory structure
 
-The CLI stores global configuration and local application files under the directory referenced by `NB_CLI_ROOT`.
+The CLI stores global configuration and local application files in the directory corresponding to `NB_CLI_ROOT`.
 
-By default, `NB_CLI_ROOT` is the current user's home directory, that is, the path returned by Node.js `os.homedir()`. For example, on macOS this is typically `/Users/<user>`. So, without any extra configuration, files generated by `nb init --yes --env app1` usually live at:
+By default, `NB_CLI_ROOT` is the current user's home directory, that is, the path returned by Node.js `os.homedir()`. For example, on macOS it is usually `/Users/<user>`. Therefore, without additional configuration, the files generated by `nb init --yes --env app1` are usually located at:
 
 ```text
 ~
@@ -205,13 +200,13 @@ By default, `NB_CLI_ROOT` is the current user's home directory, that is, the pat
     └── storage
 ```
 
-You can also specify `NB_CLI_ROOT` explicitly:
+You can also explicitly specify `NB_CLI_ROOT`:
 
 ```bash
 export NB_CLI_ROOT=/your/workspace
 ```
 
-After that, the configuration file and default application directory are placed under that directory:
+After setting it, the configuration file and default application directory will both be placed under that directory:
 
 ```text
 /your/workspace
@@ -224,79 +219,79 @@ After that, the configuration file and default application directory are placed
 
 Where:
 
-- `.nocobase/config.json` stores envs, the current environment, API URL, source path, storage path, database configuration, and so on.
+- `.nocobase/config.json` stores information such as envs, current environment, API address, source path, storage path, and database configuration.
 - `<envName>/source` is the source code or application directory managed by the CLI.
 - `<envName>/storage` is the application storage directory managed by the CLI.
 
 :::warning
-Once an application has been initialized, keep using the same `NB_CLI_ROOT`. If you change `NB_CLI_ROOT` later, the CLI will look for `.nocobase/config.json` under the new directory, and any relative `appRootPath` or `storagePath` values will be resolved against the new directory, which may cause the application to be missing or read/write the wrong directory.
+After initializing the same application, keep using the same `NB_CLI_ROOT`. If you later change `NB_CLI_ROOT`, the CLI will look for `.nocobase/config.json` in the new directory, and relative `appRootPath` and `storagePath` will also be resolved against the new directory, which may cause the application to not be found or to read and write to the wrong directory.
 :::
 
-The CLI currently uses only the global config scope. To change where configuration and local application files are stored, set `NB_CLI_ROOT`.
+The CLI currently only uses the global configuration scope. If you need to adjust where configuration and local application files are stored, set `NB_CLI_ROOT`.
 
-When inspecting and locating applications, prefer `nb env list` and `nb env info`:
+When viewing and locating applications, prefer `nb env list` and `nb env info`:
 
 ```bash
-# List configured envs and API authentication status
+# View configured envs and API authentication status
 nb env list
 
-# View detailed information for a specific env
+# View detailed information for an env
 nb env info app1
 ```
 
-`nb env list` is intended as a quick overview. The `App Status` column reflects the authentication status obtained by accessing the application API with the saved Token/OAuth credentials, and no longer shows the database status. To check the runtime status of the built-in database, use:
+`nb env list` is intended for a quick overview. Here, `App Status` is the authentication status obtained by accessing the application API with the saved Token/OAuth credentials, and no longer displays database status. To view the running status of the built-in database, use:
 
 ```bash
 nb db ps -e app1
 ```
 
-Only switch the default env when you actually need to:
+Only use this when you need to switch the default env:
 
 ```bash
 nb env use app1
 ```
 
-## Migrate from the legacy approach to the CLI
+## Migrate from the old approach to CLI
 
-There are two migration strategies: **connect to an existing application**, or **bring a local application directory under CLI management**. If your legacy application is already running stably, we recommend starting with "connect to an existing application", which carries the lowest risk.
+There are two migration strategies: **connect to an existing application**, or **bring a local application directory under CLI management**. If your old application is already running stably, it is recommended to first use "connect to an existing application", which has the lowest risk.
 
-### Option 1: Connect to an existing application
+### Method 1: connect to an existing application
 
-Use this option when NocoBase is already running through Docker, create-nocobase-app, Git source, or a server deployment.
+Suitable for NocoBase instances already running via Docker, create-nocobase-app, Git source, or server deployment.
 
 ```bash
-# OAuth authentication is used by default
+# Uses OAuth authentication by default
 nb init --yes --env app1 --api-base-url=http://next.v2.test.nocobase.com/nocobase/api
 
-# Use Token authentication
+# Use token authentication
 nb init --yes --env "app$RANDOM" \
   --api-base-url=http://next.v2.test.nocobase.com/nocobase/api \
   --auth-type=token \
   --access-token=<token>
 ```
 
-This option only stores the API connection. The CLI does not take over starting, stopping, or upgrading the legacy application, nor does it manage its source or storage directories. It is suitable for letting an AI Agent or CLI API commands connect to an existing application.
+This approach only stores the API connection. The CLI will not take over startup, shutdown, upgrade, source directory, or storage directory management of the old application. It is suitable for allowing AI Agents or CLI API commands to connect to existing applications.
 
-To refresh authentication:
+If you need to refresh authentication:
 
 ```bash
 nb env auth app1
 ```
 
-### Option 2: Create a new CLI env and migrate files
+### Method 2: create a new CLI env and then migrate files
 
-Use this option when you want `nb app` and `nb source` to manage the local application going forward.
+Suitable for scenarios where you want to use `nb app` and `nb source` to manage local applications afterward.
 
-Before migrating, complete the following:
+Before migration, complete the following first:
 
-1. Stop the legacy application.
-2. Back up the legacy database.
-3. Back up the legacy `storage` directory.
-4. Record the key environment variables of the legacy application, such as `APP_KEY`, `TZ`, `DB_*`, and `DB_UNDERSCORED`.
+1. Stop the old application.
+2. Back up the old database.
+3. Back up the old `storage` directory.
+4. Record the key environment variables of the old application, such as `APP_KEY`, `TZ`, `DB_*`, and `DB_UNDERSCORED`.
 
-#### Migrating from a legacy Docker installation
+#### Migrate from an old Docker installation
 
-A legacy Docker installation typically keeps application data in the `storage` directory inside the project:
+The old Docker approach usually stores application data in the project's `storage` directory:
 
 ```text
 /old-docker-project
@@ -304,7 +299,7 @@ A legacy Docker installation typically keeps application data in the `storage` d
 └── storage
 ```
 
-We recommend choosing a new `NB_CLI_ROOT` first, then creating a new Docker env with the CLI. The example below assumes `NB_CLI_ROOT` is `/your/workspace`.
+It is recommended to first determine the new `NB_CLI_ROOT`, then use the CLI to create a new Docker env. The following example assumes that `NB_CLI_ROOT` is `/your/workspace`.
 
 ```bash
 export NB_CLI_ROOT=/your/workspace
@@ -312,7 +307,7 @@ nb init --yes --env app2 --source docker --version beta
 nb app stop -e app2
 ```
 
-The new env uses the following directories by default:
+The new env will use the following directories by default:
 
 ```text
 /your/workspace
@@ -321,18 +316,18 @@ The new env uses the following directories by default:
     └── storage
 ```
 
-Then copy the legacy `storage` to `/your/workspace/app2/storage` and make sure the database connection and `APP_KEY` match the legacy environment.
+Then copy the old `storage` to `/your/workspace/app2/storage`, and make sure the database connection, `APP_KEY`, and other configurations match the old environment.
 
-After copying and confirming the database configuration, start the application:
+After the copy is complete and the database configuration is confirmed, start the application:
 
 ```bash
 nb app start -e app2
 nb app logs -e app2
 ```
 
-#### Migrating from a legacy create-nocobase-app or Git source installation
+#### Migrate from an old create-nocobase-app or Git source installation
 
-In legacy npm/Git installations, the source code, `.env`, and `storage` typically live in the same project directory:
+The old npm/Git approach usually places the source code, `.env`, and `storage` in the same project directory:
 
 ```text
 /old-nocobase
@@ -342,7 +337,7 @@ In legacy npm/Git installations, the source code, `.env`, and `storage` typicall
 └── storage
 ```
 
-We recommend choosing a new `NB_CLI_ROOT` first, then creating a new npm or Git env. The example below assumes `NB_CLI_ROOT` is `/your/workspace`.
+It is recommended to first determine the new `NB_CLI_ROOT`, then create a new npm or Git env. The following example assumes that `NB_CLI_ROOT` is `/your/workspace`.
 
 ```bash
 export NB_CLI_ROOT=/your/workspace
@@ -352,12 +347,12 @@ nb app stop -e app3
 
 Then migrate as needed:
 
-- Move the custom plugin source from the legacy project into the corresponding location under `/your/workspace/app3/source`.
-- Copy `storage` from the legacy project to `/your/workspace/app3/storage`.
-- Sync the key settings from the legacy `.env` into the CLI env configuration or the initialization arguments.
-- To keep using the original database, disable the built-in database during initialization and provide the legacy database connection details.
+- Migrate custom plugin source code from the old project to the corresponding directory under `/your/workspace/app3/source`.
+- Copy the old project's `storage` to `/your/workspace/app3/storage`.
+- Sync key configurations from the old `.env` to the CLI env configuration or initialization parameters.
+- If using the original database, disable the built-in database during initialization and fill in the old database connection information.
 
-Example of initializing with an external database:
+Example of initialization with an external database:
 
 ```bash
 nb init --yes --env app3 --source git --version beta \
@@ -370,7 +365,7 @@ nb init --yes --env app3 --source git --version beta \
   --db-password nocobase
 ```
 
-Once migrated, start the application and check the logs:
+After migration, start it and view the logs:
 
 ```bash
 nb app start -e app3
@@ -378,30 +373,30 @@ nb app logs -e app3
 ```
 
 :::warning
-Never overwrite `source` or `storage`, or run an upgrade against a production database, without backups. Always do a full dry run in a test environment before performing the actual migration.
+Do not directly overwrite `source`, `storage`, or connect to the production database for upgrades without a backup. Before formal migration, it is recommended to do a full rehearsal once in a test environment.
 :::
 
-## Legacy command quick reference
-
-| Legacy command | New CLI command |
-| --- | --- |
-| `docker compose up -d app` | `nb app start -e app1` |
-| `docker compose stop app` | `nb app stop -e app1` |
-| `docker compose logs -f app` | `nb app logs -e app1` |
-| `docker compose pull app && docker compose up -d app` | `nb app upgrade -e app1` |
-| `yarn create nocobase-app my-nocobase-app ...` | `nb init --yes --env app1 --source npm --version beta` |
-| `npx create-nocobase-app@beta my-nocobase-app ...` | `nb init --yes --env app1 --source npm --version beta` |
-| `git clone ... -b next --depth=1 my-nocobase` | `nb init --yes --env app1 --source git --version beta` |
-| `git clone ... -b develop --depth=1 my-nocobase` | `nb init --yes --env app1 --source git --version alpha` |
-| `yarn dev` | `nb source dev -e app1` |
-| `yarn nocobase upgrade` | `nb app upgrade -e app1` |
-| `yarn nocobase upgrade --skip-code-update` | `nb app upgrade -e app1 -s` |
-| Manually tracking multiple application URLs | `nb env list`, `nb env info app1` |
-| Manually connecting to existing applications | `nb init --yes --env app1 --api-base-url=http://next.v2.test.nocobase.com/nocobase/api` |
+## Quick reference for old command migration
+
+| Old command                                           | New CLI command                                                                         |
+| ----------------------------------------------------- | --------------------------------------------------------------------------------------- |
+| `docker compose up -d app`                            | `nb app start -e app1`                                                                  |
+| `docker compose stop app`                             | `nb app stop -e app1`                                                                   |
+| `docker compose logs -f app`                          | `nb app logs -e app1`                                                                   |
+| `docker compose pull app && docker compose up -d app` | `nb app upgrade -e app1`                                                                |
+| `yarn create nocobase-app my-nocobase-app ...`        | `nb init --yes --env app1 --source npm --version beta`                                  |
+| `npx create-nocobase-app@beta my-nocobase-app ...`    | `nb init --yes --env app1 --source npm --version beta`                                  |
+| `git clone ... -b next --depth=1 my-nocobase`         | `nb init --yes --env app1 --source git --version beta`                                  |
+| `git clone ... -b develop --depth=1 my-nocobase`      | `nb init --yes --env app1 --source git --version alpha`                                 |
+| `yarn dev`                                            | `nb source dev -e app1`                                                                 |
+| `yarn nocobase upgrade`                               | `nb app upgrade -e app1`                                                                |
+| `yarn nocobase upgrade --skip-code-update`            | `nb app upgrade -e app1 -s`                                                             |
+| Manually record multiple application addresses        | `nb env list`, `nb env info app1`                                                       |
+| Manually connect to an existing application           | `nb init --yes --env app1 --api-base-url=http://next.v2.test.nocobase.com/nocobase/api` |
 
 ## Related links
 
-- [AI Agent integration guide](/ai/quick-start)
-- [NocoBase CLI command reference](/api/cli)
-- [Comparison of installation methods and versions](/get-started/quickstart)
+- [AI Agent Integration Guide](/ai/quick-start)
+- [NocoBase CLI Command Reference](/api/cli)
+- [Installation methods and version comparison](/get-started/quickstart)
 - [Install and upgrade plugins](/get-started/install-upgrade-plugins)

package/dist/ai/docs/nocobase/ai-dev/capabilities.md

@@ -18,7 +18,7 @@ Here is a list of everything AI can currently help you do. Each capability comes
 
 :::warning Note
 
-- NocoBase is migrating from `client` (v1) to `client-v2`, and `client-v2` is still under development. The client code generated by AI development is based on `client-v2` and can only be used under the `/v2/` path. It is available for early access and experimentation, but is not recommended for production use.
+- NocoBase is migrating from `client` (v1) to `client-v2`, and `client-v2` is still under development. The client code generated by AI development is based on `client-v2` and can only be used under the `/v/` path. It is available for early access and experimentation, but is not recommended for production use.
 - AI-generated code may not be 100% correct. We recommend reviewing it before enabling. If you encounter issues at runtime, send the error message to AI and let it investigate and fix -- it usually takes just a few rounds of conversation to resolve.
 - We recommend using GPT or Claude series models for development, as they produce the best results. Other models can also work, but generation quality may vary.
 

package/dist/ai/docs/nocobase/ai-dev/index.md

@@ -33,7 +33,7 @@ Your browser will automatically open the visual configuration page, guiding you
 
 :::warning Note
 
-- NocoBase is migrating from `client` (v1) to `client-v2`, and `client-v2` is still under development. The client code generated by AI development is based on `client-v2` and can only be used under the `/v2/` path. It is available for early access and experimentation, but is not recommended for production use.
+- NocoBase is migrating from `client` (v1) to `client-v2`, and `client-v2` is still under development. The client code generated by AI development is based on `client-v2` and can only be used under the `/v/` path. It is available for early access and experimentation, but is not recommended for production use.
 - AI-generated code may not be 100% correct. We recommend reviewing it before enabling. If you encounter issues at runtime, send the error message to AI and let it investigate and fix -- it usually takes just a few rounds of conversation to resolve.
 - We recommend using GPT or Claude series models for development, as they produce the best results. Other models can also work, but generation quality may vary.
 

package/dist/ai/docs/nocobase/ai-dev/watermark-plugin.md

@@ -34,7 +34,7 @@ Make sure you have:
 
 :::warning Note
 
-- NocoBase is migrating from `client` (v1) to `client-v2`, and `client-v2` is still under development. The client code generated by AI development is based on `client-v2` and can only be used under the `/v2/` path. It is available for early access and experimentation, but is not recommended for production use.
+- NocoBase is migrating from `client` (v1) to `client-v2`, and `client-v2` is still under development. The client code generated by AI development is based on `client-v2` and can only be used under the `/v/` path. It is available for early access and experimentation, but is not recommended for production use.
 - AI-generated code may not be 100% correct. We recommend reviewing it before enabling. If you encounter issues at runtime, send the error message to AI and let it investigate and fix -- it usually takes just a few rounds of conversation to resolve.
 
 :::

package/dist/ai/docs/nocobase/api/cli/app/autostart/disable.md

@@ -0,0 +1,44 @@
+---
+title: "nb app autostart disable"
+description: "nb app autostart disable command reference: disable application autostart for one env."
+keywords: "nb app autostart disable,NocoBase CLI,autostart,env"
+---
+
+# nb app autostart disable
+
+Disable the application autostart flag for one env.
+
+After disabling it, the env no longer participates in `nb app autostart run`. This command does not stop an already running app by itself. If you also want to stop the current runtime, use `nb app stop` separately.
+
+## Usage
+
+```bash
+nb app autostart disable [flags]
+```
+
+## Flags
+
+| Flag | Type | Description |
+| --- | --- | --- |
+| `--env`, `-e` | string | CLI env name to remove from app autostart. Uses the current env when omitted |
+| `--yes`, `-y` | boolean | Skip the interactive confirmation when explicit `--env` points to a different env than the current env |
+
+## Examples
+
+```bash
+nb app autostart disable
+nb app autostart disable --env app1
+nb app autostart disable --env app1 --yes
+```
+
+## Notes
+
+This command only changes the saved autostart flag. It does not stop the app directly. If an env was not enabled for autostart before, running this command keeps it in the disabled state.
+
+Just like `enable`, the CLI only checks for a cross-env confirmation when you explicitly pass `--env`. In non-interactive terminals or AI agent flows, add `--yes` yourself when needed.
+
+## Related commands
+
+- [`nb app autostart enable`](./enable.md)
+- [`nb app autostart list`](./list.md)
+- [`nb app stop`](../stop.md)

package/dist/ai/docs/nocobase/api/cli/app/autostart/enable.md

@@ -0,0 +1,44 @@
+---
+title: "nb app autostart enable"
+description: "nb app autostart enable command reference: enable application autostart for one local or Docker env."
+keywords: "nb app autostart enable,NocoBase CLI,autostart,env"
+---
+
+# nb app autostart enable
+
+Enable the application autostart flag for one env.
+
+This flag only applies to `local` or `docker` envs whose runtimes are managed by the CLI on the current machine. It does not start the application immediately. Instead, it adds the env to the set that can later be started by `nb app autostart run`.
+
+## Usage
+
+```bash
+nb app autostart enable [flags]
+```
+
+## Flags
+
+| Flag | Type | Description |
+| --- | --- | --- |
+| `--env`, `-e` | string | CLI env name to add to app autostart. Uses the current env when omitted |
+| `--yes`, `-y` | boolean | Skip the interactive confirmation when explicit `--env` points to a different env than the current env |
+
+## Examples
+
+```bash
+nb app autostart enable
+nb app autostart enable --env app1
+nb app autostart enable --env app1 --yes
+```
+
+## Notes
+
+The CLI only checks whether the target env differs from the current env when you explicitly pass `--env`. In interactive terminals it confirms first. In non-interactive terminals or AI agent flows, you need to add `--yes` yourself, or switch the current env with `nb env use <name>` before retrying.
+
+If the target env is not a CLI-managed `local` or `docker` runtime on the current machine, the command fails and does not save the autostart flag.
+
+## Related commands
+
+- [`nb app autostart disable`](./disable.md)
+- [`nb app autostart list`](./list.md)
+- [`nb app autostart run`](./run.md)