@nocobase/plugin-ai 2.1.9 → 2.1.11

package/dist/ai/docs/nocobase/ai-employees/workflow/nodes/knowledge/index.md

@@ -64,6 +64,14 @@ The core of this example is three synchronization workflows. They process the sa
 
 `Key` is the most important field in the synchronization chain. Create, update, and delete workflows must use the same `Key` rule. The example directly uses the record ID of the `Answers` collection.
 
+:::tip Text content ingestion and vectorization
+
+When configuring a Create document or Update document node, if `Document type` is set to `Text`, the workflow first saves the text field selected in `Content` as a `.txt` document, then writes it to the target knowledge base. The knowledge base then generates segments according to the current segmentation settings, vectorizes enabled segments together with their related questions, and stores them in the vector database bound to the knowledge base.
+
+This process runs as an asynchronous workflow node. A completed node does not mean the document can be retrieved immediately. Usually, wait until `Status` in the `Documents` list changes to `Success` before checking segments or running hit tests.
+
+:::
+
 ## Operation guides
 
 - [Create document](./create-document)

package/dist/ai/docs/nocobase/api/cli/app/restart.md

@@ -35,6 +35,10 @@ If you explicitly pass `--env` and it differs from the current env, the CLI asks
 
 By default, when applicable, the CLI first runs `nb license plugins sync --skip-if-no-license` to synchronize the commercial plugins allowed by the current license. Then local envs automatically complete any required install or upgrade preparation before starting again, and Docker envs complete that step before recreating the container. Whenever the CLI needs to wait for readiness, it checks `__health_check`: it prints one waiting line first, then one progress line every 10 seconds until the app becomes available or times out.
 
+## Hook Scripts
+
+If the current env saved a hook with `nb init --hook-script`, `nb app restart` runs `afterAppStart(context)` once after the app restarts and passes `__health_check`. It uses `context.phase = 'app-start'` and `context.command = 'app:restart'`.
+
 ## Related Commands
 
 - [`nb app start`](./start.md)

package/dist/ai/docs/nocobase/api/cli/app/start.md

@@ -34,6 +34,13 @@ nb app start --env local-docker
 If you explicitly pass `--env` and it differs from the current env, the CLI asks for confirmation first. In non-interactive terminals or AI agent sessions, add `--yes` yourself or run `nb env use <name>` first and try again.
 
 By default, when applicable, the CLI first runs `nb license plugins sync --skip-if-no-license` to synchronize the commercial plugins allowed by the current license. Then local envs automatically complete any required install or upgrade preparation before starting, and Docker envs recreate the app container from saved env config. Whenever the CLI needs to wait for readiness, it checks `__health_check`: it prints one waiting line first, then one progress line every 10 seconds until the app becomes available or times out.
+
+## Hook Scripts
+
+If the current env saved a hook with `nb init --hook-script`, `nb app start` runs `afterAppStart(context)` after the app actually starts and passes `__health_check`. Installed envs use `context.phase = 'app-start'` and `context.command = 'app:start'`. If the app is already running, this command does not run the hook.
+
+For prepared envs created with `--prepare-only`, the first `nb app start` runs `beforeAppInstall(context)`, completes the first install and startup, then runs `afterAppStart(context)`. Both hooks receive `context.phase = 'init'` and `context.command = 'app:start'`.
+
 ## Related Commands
 
 - [`nb app stop`](./stop.md)

package/dist/ai/docs/nocobase/api/cli/app/upgrade.md

@@ -58,6 +58,12 @@ Step 4 automatically completes any required upgrade preparation for the current
 
 If the final `nb env update` step fails, the upgrade still counts as successful. The CLI prints a warning and tells you to run `nb env update <envName>` manually afterward.
 
+## Hook Scripts
+
+If the current env saved a hook with `nb init --hook-script`, `nb app upgrade` passes the upgrade lifecycle to the hook. For npm/Git source, source refresh runs `beforeDependencyInstall(context)` before dependency installation with `context.phase = 'upgrade'` and `context.command = 'app:upgrade'`.
+
+The app upgrade startup step then runs `beforeAppInstall(context)`, and after the app starts and passes `__health_check`, it runs `afterAppStart(context)`. Both hooks also use `context.phase = 'upgrade'` and `context.command = 'app:upgrade'`. Docker source does not run `beforeDependencyInstall`, but it does run the app-level hooks.
+
 ## Related Commands
 
 - [`nb source download`](../source/download.md)

package/dist/ai/docs/nocobase/api/cli/init.md

@@ -42,7 +42,7 @@ nb init --env app1 --resume
 
 `--prepare-only` is intended for flows where the env should be prepared first, then the license is activated, and only after that the app is installed and started.
 
-If you want to save the env config, prepare the source files or image, and get the database ready first, but delay the actual app installation and first startup, you can use:
+If you want to save the env config and prepare the database first, while delaying dependency download, app installation, and first startup, you can use:
 
 ```bash
 nb init --env app1 --prepare-only
@@ -67,6 +67,7 @@ By default, the CLI organizes local files under `app-path` using the following c
 
 ```text
 <app-path>/
+├── .nb/      # CLI metadata for this env, such as hooks.mjs
 ├── source/   # Default directory for app source code or downloaded content
 ├── storage/  # Runtime data directory
 └── .env      # Optional app environment variable file
@@ -74,6 +75,7 @@ By default, the CLI organizes local files under `app-path` using the following c
 
 Typically:
 
+- `.nb/` stores CLI-managed metadata. A script passed with `--hook-script` is copied to `<app-path>/.nb/hooks.mjs`, so later `nb app upgrade` and local source restore can reuse it
 - `source/` mainly corresponds to the local app directory for npm / Git envs. For Docker envs, the CLI also keeps this default path derivation, but most of the time you do not need to care about it manually. Pay special attention during upgrades: the `source/` directory will be deleted and downloaded again, so do not put files you need to keep here
 - `storage/` is used for runtime data, such as built-in database data, plugins, logs, and more
 - `.env` is an optional app environment variable file. You only need to add it in `<app-path>/.env` when you want to customize environment variables; if this file exists, Docker, npm, and Git install sources will all read it by default
@@ -101,7 +103,7 @@ If you are following the local UI wizard step by step, you can first use the tab
 | ------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | `Getting started`         | `--env`、`--yes`、`--ui`、`--locale`、`--verbose`、`--skip-skills`、`--resume`                                                                                                                                    |
 | `App environment`         | `--lang`、`--app-path`、`--app-port`、`--force`                                                                                                                                                                   |
-| `App source and version`  | `--source`、`--version`、`--skip-download`、`--git-url`、`--docker-registry`、`--docker-platform`、`--npm-registry`、`--replace`、`--dev-dependencies`、`--output-dir`、`--docker-save`、`--build`、`--build-dts` |
+| `App source and version`  | `--source`、`--version`、`--skip-download`、`--git-url`、`--docker-registry`、`--docker-platform`、`--npm-registry`、`--replace`、`--dev-dependencies`、`--output-dir`、`--docker-save`、`--build`、`--build-dts`、`--hook-script` |
 | `Configure the database`  | `--builtin-db`、`--db-dialect`、`--builtin-db-image`、`--db-host`、`--db-port`、`--db-database`、`--db-user`、`--db-password`、`--db-schema`、`--db-table-prefix`、`--db-underscored`                             |
 | `Create an admin account` | `--root-username`、`--root-email`、`--root-password`、`--root-nickname`                                                                                                                                           |
 | `Remote connection`       | `--api-base-url`、`--auth-type`、`--access-token`、`--username`、`--password`、`--skip-auth`                                                                                                                      |
@@ -184,6 +186,7 @@ The “Default” below means the value or behavior that `nb init` usually uses
 | `--npm-registry`                                     | string  | Empty                                                                                            | Registry used for npm/Git download and dependency installation                           |
 | `--build` / `--no-build`                             | boolean | `true`                                                                                           | Whether to build after installing npm/Git dependencies                                   |
 | `--build-dts`                                        | boolean | `false`                                                                                          | Whether to generate TypeScript declaration files during npm/Git builds                   |
+| `--hook-script`                                      | string  | None                                                                                             | Copy the specified hook module to `<app-path>/.nb/hooks.mjs` and save it in the env config; supports the `beforeDependencyInstall`, `beforeAppInstall`, and `afterAppStart` lifecycle hooks |
 
 ## Examples
 
@@ -233,6 +236,40 @@ nb init --env app1 --yes --source git --version latest \
   --git-url https://gitee.com/nocobase/nocobase.git
 ```
 
+### Extend the install flow with a hook script
+
+If you need to prepare extra content during installation, pass a local ESM module with `--hook-script`:
+
+```bash
+nb init --env app1 --yes --source git --hook-script ./hooks.mjs
+```
+
+The CLI copies this file to `<app-path>/.nb/hooks.mjs` and saves `hookScript: ".nb/hooks.mjs"` in the env config. Later `nb app start`, `nb app restart`, and `nb app upgrade` reuse it from that location.
+
+The hook file must default-export an object. Implement only the methods you need:
+
+```js
+export default {
+  beforeDependencyInstall: async (context) => {
+    // Runs after git clone / npm scaffold and before yarn install.
+  },
+  beforeAppInstall: async (context) => {
+    // Runs before the app-level install or upgrade command.
+  },
+  afterAppStart: async (context) => {
+    // Runs after the app actually starts and passes the health check.
+  },
+};
+```
+
+- `beforeDependencyInstall` only applies to npm/Git source and runs right before the real `yarn install`; Docker source does not run it
+- `beforeAppInstall` runs before app-level install or upgrade commands, and applies to npm/Git/Docker source
+- `afterAppStart` runs after the app actually starts and passes `__health_check`; `nb app start`, `nb app restart`, and `nb app upgrade` may all trigger it
+
+`--prepare-only` only saves the env config and copies the hook file. It does not execute hooks. When you later run `nb app start` for the first time, the CLI runs the first-install hooks with `context.phase` set to `init` and `context.command` set to `app:start`.
+
+`context` includes lifecycle information such as `phase`, `command`, `source`, `version`, `appPath`, `sourcePath`, `storagePath`, `hookScript`, and `envConfig`. If a hook throws, the current CLI command fails. Because `afterAppStart` can run repeatedly during start, restart, and upgrade flows, keep it idempotent.
+
 ### Quick install and use basic authentication
 
 If you want to quickly install a local app in non-interactive mode and directly save `basic` authentication after installation, you can also write it like this. This way, you do not need to open a browser to complete OAuth.

package/dist/ai/docs/nocobase/api/cli/source/download.md

@@ -33,6 +33,7 @@ nb source download [flags]
 | `--npm-registry` | string | Registry used for npm/Git downloads and dependency installation |
 | `--build` / `--no-build` | boolean | Whether to build after npm/Git dependency installation |
 | `--build-dts` | boolean | Whether to generate TypeScript declaration files during npm/Git build |
+| `--hook-script` | string | Hook module to run after npm scaffold or Git clone and before dependency installation; only applies to npm/Git source |
 
 ## Examples
 
@@ -47,8 +48,26 @@ nb source download --source git --version alpha --git-url=git@github.com:nocobas
 nb source download --source git --version fix/cli-v2
 nb source download -y --source npm --version alpha --build-dts
 nb source download -y --source npm --version alpha --npm-registry=https://registry.npmmirror.com
+nb source download -y --source git --version beta --hook-script ./hooks.mjs
 ```
 
+## Pre-install hook
+
+`--hook-script` only affects the current `nb source download` run. If you want the hook to be saved with the env and reused by `nb app upgrade` or local source restore, pass it through [`nb init --hook-script`](../init.md) instead.
+
+The hook file must default-export an object with `beforeDependencyInstall(context)`:
+
+```js
+export default {
+  beforeDependencyInstall: async ({ sourcePath, version, envConfig }) => {
+    // Runs after git clone / npm scaffold and before yarn install.
+  },
+};
+```
+
+When you run `nb source download --hook-script` directly, `beforeDependencyInstall` receives `context.phase` as `source-download` and `context.command` as `source:download`. This command does not run `beforeAppInstall` or `afterAppStart`; those hooks belong to app install, start, restart, and upgrade flows.
+
+
 ## Version Aliases
 
 With Git source, common dist-tags are resolved to branches: `latest` -> `main`, `beta` -> `next`, `alpha` -> `develop`.

package/dist/ai/docs/nocobase/data-sources/data-modeling/collection-fields/validation.md

@@ -78,6 +78,9 @@ After configuring field rules, the corresponding validation rules will be trigge
 
 ![20250819201027](https://nocobase-docs.oss-cn-beijing.aliyuncs.com/20250819201027.png)
 
+When the field is used in a form, field validation rules are also displayed in the field validation settings. These rules appear under **Server-side field validation rules** and are read-only there. If you need to change them, edit the field in Data source → Collection configuration.
+
+You can still add extra rules for the current form field under **Client-side validation rules**. These rules only apply to the current field component. The final validation result combines **Server-side field validation rules** and **Client-side validation rules**.
 
 Validation rules also apply to sub-table and sub-form components:
 
@@ -93,12 +96,12 @@ Note that in sub-form or sub-table scenarios, required validation for associatio
 ![20250819203016](https://nocobase-docs.oss-cn-beijing.aliyuncs.com/20250819203016.png)
 
 
-## Differences from Client-Side Field Validation
-Client-side and server-side field validation are applied in different scenarios, with significant differences in implementation and rule trigger timing, so they need to be managed separately.
+## Differences Between Server-Side Field Validation Rules and Client-Side Validation Rules
+Server-side field validation rules and client-side validation rules are configured in different places and have different scopes.
 
 ### Configuration Method Differences
-- **Client-side validation**: Configure rules in edit forms (as shown in the figure below)
-- **Server-side field validation**: Set field rules in Data Source → Collection Configuration
+- **Server-side field validation rules**: Set field rules in Data source → Collection configuration. These rules are the base rules of the field.
+- **Client-side validation rules**: Configure extra rules in a form field's settings. These rules only affect the current field component.
 
 ![20250819203836](https://nocobase-docs.oss-cn-beijing.aliyuncs.com/20250819203836.png)
 
@@ -109,7 +112,7 @@ Client-side and server-side field validation are applied in different scenarios,
 
 
 ### Validation Trigger Timing Differences
-- **Client-side validation**: Triggers validation in real-time as users fill in fields, displaying error messages immediately.
-- **Server-side field validation**: Validates on the server side before data entry after data submission, with error messages returned through API responses.
-- **Application scope**: Server-side field validation takes effect not only during form submission but also triggers in all scenarios involving data addition or modification, such as workflows and data imports.
-- **Error messages**: Client-side validation supports custom error messages, while server-side validation does not currently support custom error messages.
+- **Server-side field validation rules**: Trigger frontend validation when the field is used in a form, and also validate before data is written. They also apply to scenarios that create or update data, such as workflows and data imports.
+- **Client-side validation rules**: Trigger frontend validation in the current form field only.
+- **Rule display**: Server-side field validation rules are shown as inherited read-only rules. Client-side validation rules are shown separately and can be edited there.
+- **Error messages**: Client-side validation rules support custom error messages, while server-side field validation rules do not currently support custom error messages.

package/dist/ai/docs/nocobase/development/index.md

@@ -2,8 +2,8 @@
 pageType: home
 pageName: development
 title: "NocoBase Development Guide"
-description: "NocoBase development guide: plugin development, FlowEngine, RunJS, block/field/action extensions, data source extensions, workflow extensions, authentication extensions."
-keywords: "NocoBase,development guide,plugin development,FlowEngine,RunJS,NocoBase extensions"
+description: "NocoBase development guide: plugin development, shared components, FlowEngine, RunJS, block/field/action extensions, data source extensions, workflow extensions, authentication extensions."
+keywords: "NocoBase,development guide,plugin development,shared components,FlowEngine,RunJS,NocoBase extensions"
 features:
   - title: Core Development
     details: Master NocoBase's underlying extension mechanism and advanced development capabilities, including the plugin system, AI assistance, FlowEngine and RunJS environment, to build a solid development foundation.
@@ -24,6 +24,10 @@ features:
         details: JavaScript execution environment for JS blocks, JS fields, and JS actions, and similar scenarios.
         link: /runjs
         showOnHome: true
+      - title: Shared Components
+        details: Reuse the built-in form, filter, table, and icon components in NocoBase client v2 when building plugin pages.
+        link: /shared-components
+        showOnHome: true
   - title: Plugin Ecosystem
     details: Extend the capabilities of existing plugins through other plugins, building a hierarchical and modular plugin ecosystem to enhance system extensibility and collaboration.
     items:

package/dist/ai/docs/nocobase/interface-builder/fields/field-settings/validation-rules.md

@@ -30,10 +30,14 @@ Most fields support the configuration of validation rules. After a field is conf
 ![20251028230554](https://static-docs.nocobase.com/20251028230554.png)
 
 
-### Frontend Validation in Field Configuration
+### Client-Side Validation Rules in Field Settings
 
 Validation rules set in the field configuration will trigger frontend validation to ensure user input complies with the regulations.
 
+If the corresponding collection field already has validation rules, those rules are shown in the validation settings under **Server-side field validation rules**. They are inherited from the data source field configuration and are read-only here. If you need to change them, edit the collection field in Data source → Collection configuration.
+
+Rules added under **Client-side validation rules** only apply to the current field component. They do not change the collection field configuration. When both groups exist, NocoBase applies the inherited field rules and client-side validation rules together.
+
 
 ![20251028230105](https://static-docs.nocobase.com/20251028230105.png)
 
@@ -45,4 +49,4 @@ Validation rules set in the field configuration will trigger frontend validation
 **Text fields** also support custom regex validation to meet specific format requirements.
 
 
-![20251028230903](https://static-docs.nocobase.com/20251028230903.png)
+![20251028230903](https://static-docs.nocobase.com/20251028230903.png)

package/dist/ai/docs/nocobase/plugin-development/client/index.md

@@ -29,6 +29,7 @@ Specifically:
 1. **[Plugin](./plugin)**: The plugin entry class. Register routes, models, and other resources in lifecycle methods like `load()`.
 2. **[Router](./router)**: Register page routes via `router.add()` and plugin settings pages via `pluginSettingsManager`.
 3. **[Component](./component/index.md)**: Routes mount React components. Just use React + Antd by default -- no different from regular frontend development.
+| Find reusable form, filter, and table components       | [Shared Components](/shared-components/)                 |
 4. **[Context](./ctx/index.md)**: In plugins, access context via `this.context`; in components, use `useFlowContext()` to get the context. This gives you access to NocoBase capabilities -- making requests (`ctx.api`), internationalization (`ctx.t`), logging (`ctx.logger`), etc.
 5. **[FlowEngine](./flow-engine/index.md)**: If your components need to appear in the "Add Block / Field / Action" menus and support visual configuration by users, you need to wrap them with FlowModel.
 

package/dist/ai/docs/nocobase/shared-components/create-form-registry.md

@@ -0,0 +1,38 @@
+---
+title: "createFormRegistry"
+description: "createFormRegistry: Create an internal registry for plugin extension items."
+keywords: "createFormRegistry,NocoBase,client-v2"
+---
+
+# createFormRegistry
+
+`createFormRegistry` is used to create an internal registry for plugin extension items.
+
+## Basic Usage
+
+```ts
+import { createFormRegistry, type FormRegistryEntry } from '@nocobase/client-v2';
+
+interface StorageType extends FormRegistryEntry {
+  title: string;
+  Component: React.ComponentType;
+}
+
+const storageTypes = createFormRegistry<StorageType>('file-manager/storage-types');
+
+storageTypes.register({ name: 'local', title: 'Local', Component: LocalStorageForm });
+storageTypes.register({ name: 's3', title: 'Amazon S3', Component: S3StorageForm });
+
+const s3 = storageTypes.get('s3');
+const all = storageTypes.list();
+```
+
+## API
+
+| Prop | Type | Description |
+| --- | --- | --- |
+| `register(entry)` | `-` | Register an entry |
+| `unregister(name)` | `-` | Remove an entry |
+| `get(name)` | `-` | Get an entry by name |
+| `has(name)` | `-` | Check whether an entry exists |
+| `list()` | `-` | Return all entries |

package/dist/ai/docs/nocobase/shared-components/filter/collection-filter-panel.md

@@ -0,0 +1,44 @@
+---
+title: "CollectionFilterPanel"
+description: "CollectionFilterPanel: Embed a Collection filter panel in a page."
+keywords: "CollectionFilterPanel,NocoBase,client-v2"
+---
+
+# CollectionFilterPanel
+
+`CollectionFilterPanel` is used to embed a Collection filter panel in a page.
+
+## Basic Usage
+
+```tsx
+import { CollectionFilterPanel, type CollectionFilterPanelRef } from '@nocobase/client-v2';
+
+const ref = useRef<CollectionFilterPanelRef>(null);
+
+<CollectionFilterPanel ref={ref} collection={collection} t={t} />;
+
+const filter = ref.current?.getFilter();
+```
+
+## API
+
+| Prop | Type | Description |
+| --- | --- | --- |
+| `collection` | `Collection | undefined` | Collection used as the field source |
+| `initialValue` | `Record<string, unknown>` | Initial filter value |
+| `onChange` | `(filter) => void` | Change callback |
+| `t` | `(key, options?) => string` | Translation function |
+| `filterableFieldNames` | `string[]` | Field allowlist |
+| `nonfilterableFieldNames` | `string[]` | Field blocklist |
+| `noIgnore` | `boolean` | Skip allowlist restrictions |
+
+## Methods
+
+| Method | Description |
+| --- | --- |
+| `getFilter()` | Get the compiled filter |
+| `reset()` | Clear all conditions |
+
+## Related Links
+
+- [CollectionFilter](./)

package/dist/ai/docs/nocobase/shared-components/filter/index.md

@@ -0,0 +1,44 @@
+---
+title: "CollectionFilter"
+description: "CollectionFilter: Filter a Collection with multiple conditions."
+keywords: "CollectionFilter,NocoBase,client-v2"
+---
+
+# CollectionFilter
+
+`CollectionFilter` is used to filter a Collection with multiple conditions.
+
+## Basic Usage
+
+```tsx
+import { CollectionFilter } from '@nocobase/client-v2';
+
+<CollectionFilter
+  collection={collection}
+  t={t}
+  onChange={(filter) => {
+    listRequest.run({ filter });
+  }}
+/>;
+```
+
+## API
+
+| Prop | Type | Description |
+| --- | --- | --- |
+| `collection` | `Collection | undefined` | Collection used as the field source |
+| `initialValue` | `Record<string, unknown>` | Initial filter value |
+| `onChange` | `(filter) => void` | Change callback |
+| `t` | `(key, options?) => string` | Translation function |
+| `filterableFieldNames` | `string[]` | Field allowlist |
+| `nonfilterableFieldNames` | `string[]` | Field blocklist |
+| `noIgnore` | `boolean` | Skip allowlist restrictions |
+| `buttonText` | `React.ReactNode` | Custom button text |
+| `showCount` | `boolean` | Whether to show the number of conditions |
+| `popoverProps` | `PopoverProps` | Props passed to Antd Popover |
+| `buttonProps` | `ButtonProps` | Props passed to Antd Button |
+| `popoverMinWidth` | `number` | Minimum width of the Popover content |
+
+## Related Links
+
+- [CollectionFilterPanel](./collection-filter-panel)

package/dist/ai/docs/nocobase/shared-components/form/code-scanner.md

@@ -0,0 +1,34 @@
+---
+title: "CodeScanner"
+description: "CodeScanner: Control the low-level full-screen scanner."
+keywords: "CodeScanner,NocoBase,client-v2"
+---
+
+# CodeScanner
+
+`CodeScanner` is used to control the low-level full-screen scanner.
+
+## Basic Usage
+
+```tsx
+import { CodeScanner } from '@nocobase/client-v2';
+
+<CodeScanner
+  visible={visible}
+  onClose={() => setVisible(false)}
+  onScanSuccess={(text) => setValue(text)}
+/>;
+```
+
+## API
+
+| Prop | Type | Description |
+| --- | --- | --- |
+| `visible` | `boolean` | Whether the scanner is visible |
+| `formatsToSupport` | `Html5QrcodeSupportedFormats[]` | Supported QR code or barcode formats |
+| `onClose` | `() => void` | Called when the scanner closes |
+| `onScanSuccess` | `(result: string) => void` | Called after a successful scan |
+
+## Related Links
+
+- [ScanInput](./scan-input)

package/dist/ai/docs/nocobase/shared-components/form/dialog-form-layout.md

@@ -0,0 +1,45 @@
+---
+title: "DialogFormLayout"
+description: "DialogFormLayout: Put a standard form in a dialog."
+keywords: "DialogFormLayout,NocoBase,client-v2"
+---
+
+# DialogFormLayout
+
+`DialogFormLayout` is used to put a standard form in a dialog.
+
+## Basic Usage
+
+```tsx
+import { DialogFormLayout } from '@nocobase/client-v2';
+
+ctx.viewer.dialog({
+  closable: true,
+  content: () => (
+    <DialogFormLayout title={t('Bind verifier')} onSubmit={handleSubmit}>
+      <Form form={form} layout="vertical">
+        <Form.Item name="code" label={t('Code')}>
+          <Input />
+        </Form.Item>
+      </Form>
+    </DialogFormLayout>
+  ),
+});
+```
+
+## API
+
+| Prop | Type | Description |
+| --- | --- | --- |
+| `title` | `React.ReactNode` | Title content |
+| `children` | `React.ReactNode` | Content rendered inside the component |
+| `onCancel` | `() => void | Promise<void>` | Called before Cancel closes the view |
+| `onSubmit` | `() => void | Promise<void>` | Called when Submit is clicked |
+| `submitting` | `boolean` | Loading state of the submit button |
+| `submitText` | `React.ReactNode` | Submit button text |
+| `cancelText` | `React.ReactNode` | Cancel button text |
+| `footer` | `React.ReactNode` | Replace the default footer |
+
+## Related Links
+
+- [DrawerFormLayout](./drawer-form-layout)

package/dist/ai/docs/nocobase/shared-components/form/drawer-form-layout.md

@@ -0,0 +1,45 @@
+---
+title: "DrawerFormLayout"
+description: "DrawerFormLayout: Put a standard form in a drawer."
+keywords: "DrawerFormLayout,NocoBase,client-v2"
+---
+
+# DrawerFormLayout
+
+`DrawerFormLayout` is used to put a standard form in a drawer.
+
+## Basic Usage
+
+```tsx
+import { DrawerFormLayout } from '@nocobase/client-v2';
+
+ctx.viewer.drawer({
+  width: '50%',
+  closable: true,
+  content: () => (
+    <DrawerFormLayout title={t('Add provider')} onSubmit={handleSubmit}>
+      <Form form={form} layout="vertical">
+        <Form.Item name="name" label={t('Name')} rules={[{ required: true }]}>
+          <Input />
+        </Form.Item>
+      </Form>
+    </DrawerFormLayout>
+  ),
+});
+```
+
+## API
+
+| Prop | Type | Description |
+| --- | --- | --- |
+| `title` | `React.ReactNode` | Title content |
+| `children` | `React.ReactNode` | Content rendered inside the component |
+| `onSubmit` | `() => void | Promise<void>` | Called when Submit is clicked |
+| `submitting` | `boolean` | Loading state of the submit button |
+| `submitText` | `React.ReactNode` | Submit button text |
+| `cancelText` | `React.ReactNode` | Cancel button text |
+| `footer` | `React.ReactNode` | Replace the default footer |
+
+## Related Links
+
+- [DialogFormLayout](./dialog-form-layout)

package/dist/ai/docs/nocobase/shared-components/form/env-variable-input.md

@@ -0,0 +1,30 @@
+---
+title: "EnvVariableInput"
+description: "EnvVariableInput: Allow only `$env` is used to environment variables."
+keywords: "EnvVariableInput,NocoBase,client-v2"
+---
+
+# EnvVariableInput
+
+`EnvVariableInput` is used to allow only `$env` environment variables.
+
+## Basic Usage
+
+```tsx file="../_demos/env-variable-input.tsx" preview
+```
+
+## API
+
+| Prop | Type | Description |
+| --- | --- | --- |
+| `value` | `string` | Current value |
+| `onChange` | `(value: string) => void` | Change callback |
+| `addonBefore` | `React.ReactNode` | Content before the input |
+| `disabled` | `boolean` | Whether disabled |
+| `password` | `boolean` | Mask plain non-variable values |
+| `placeholder` | `string` | Placeholder text |
+
+## Related Links
+
+- [VariableInput](./variable-input)
+- [TypedVariableInput](./typed-variable-input)

package/dist/ai/docs/nocobase/shared-components/form/file-size-input.md

@@ -0,0 +1,24 @@
+---
+title: "FileSizeInput"
+description: "FileSizeInput: Enter a file size and store it as bytes."
+keywords: "FileSizeInput,NocoBase,client-v2"
+---
+
+# FileSizeInput
+
+`FileSizeInput` is used to enter a file size and store it as bytes.
+
+## Basic Usage
+
+```tsx file="../_demos/file-size-input.tsx" preview
+```
+
+## API
+
+| Prop | Type | Description |
+| --- | --- | --- |
+| `value` | `number` | Current value |
+| `onChange` | `(value: number | null) => void` | Change callback |
+| `disabled` | `boolean` | Whether disabled |
+| `min` | `number` | Minimum value |
+| `max` | `number` | Maximum value |

package/dist/ai/docs/nocobase/shared-components/form/json-text-area.md

@@ -0,0 +1,28 @@
+---
+title: "JsonTextArea"
+description: "JsonTextArea: Edit JSON / JSON5 configuration."
+keywords: "JsonTextArea,NocoBase,client-v2"
+---
+
+# JsonTextArea
+
+`JsonTextArea` is used to edit JSON / JSON5 configuration.
+
+## Basic Usage
+
+```tsx file="../_demos/json-text-area.tsx" preview
+```
+
+## API
+
+| Prop | Type | Description |
+| --- | --- | --- |
+| `value` | `unknown` | Current value |
+| `onChange` | `(value: unknown) => void` | Change callback |
+| `space` | `number` | Stringify indentation |
+| `json5` | `boolean` | Whether to parse with JSON5 |
+| `showError` | `boolean` | Whether to show parse errors |
+
+## Related Links
+
+- [VariableJsonTextArea](./variable-json-text-area)

package/dist/ai/docs/nocobase/shared-components/form/password-input.md

@@ -0,0 +1,23 @@
+---
+title: "PasswordInput"
+description: "PasswordInput: Enter a password with a strength indicator."
+keywords: "PasswordInput,NocoBase,client-v2"
+---
+
+# PasswordInput
+
+`PasswordInput` is used to enter a password with a strength indicator.
+
+## Basic Usage
+
+```tsx file="../_demos/password-input.tsx" preview
+```
+
+## API
+
+| Prop | Type | Description |
+| --- | --- | --- |
+| `value` | `string` | Current value |
+| `onChange` | `(event) => void` | Change callback |
+| `disabled` | `boolean` | Whether disabled |
+| `placeholder` | `string` | Placeholder text |