@nocobase/plugin-flow-engine 2.1.0-beta.2 → 2.1.0-beta.20

package/README.md

@@ -1,17 +1,24 @@
 # NocoBase
 
 <video width="100%" controls>
-      <source src="https://static-docs.nocobase.com/NocoBase0510.mp4" type="video/mp4">
+  <source src="https://github.com/user-attachments/assets/4d11a87b-00e2-48f3-9bf7-389d21072d13" type="video/mp4">
 </video>
 
+<p align="center">
+<a href="https://trendshift.io/repositories/4112" target="_blank"><img src="https://trendshift.io/api/badge/repositories/4112" alt="nocobase%2Fnocobase | Trendshift" style="width: 250px; height: 55px;" width="250" height="55"/></a>
+<a href="https://www.producthunt.com/posts/nocobase?embed=true&utm_source=badge-top-post-topic-badge&utm_medium=badge&utm_souce=badge-nocobase" target="_blank"><img src="https://api.producthunt.com/widgets/embed-image/v1/top-post-topic-badge.svg?post_id=456520&theme=light&period=weekly&topic_id=267" alt="NocoBase - Scalability&#0045;first&#0044;&#0032;open&#0045;source&#0032;no&#0045;code&#0032;platform | Product Hunt" style="width: 250px; height: 54px;" width="250" height="54" /></a>
+</p>
 
 ## What is NocoBase
 
-NocoBase is a scalability-first, open-source no-code development platform.  
-Instead of investing years of time and millions of dollars in research and development, deploy NocoBase in a few minutes and you'll have a private, controllable, and extremely scalable no-code development platform!
+NocoBase is the most extensible AI-powered no-code platform.   
+Total control. Infinite extensibility. AI collaboration.  
+Enable your team to adapt quickly and cut costs dramatically.  
+No years of development. No millions wasted.  
+Deploy NocoBase in minutes — and take control of everything.
 
 Homepage:  
-https://www.nocobase.com/
+https://www.nocobase.com/  
 
 Online Demo:  
 https://demo.nocobase.com/new
@@ -19,11 +26,74 @@ https://demo.nocobase.com/new
 Documents:  
 https://docs.nocobase.com/
 
-Commericial license & plugins:  
-https://www.nocobase.com/en/commercial
+Forum:  
+https://forum.nocobase.com/
 
-License agreement:   
-https://www.nocobase.com/en/agreement
+Use Cases:  
+https://www.nocobase.com/en/blog/tags/customer-stories
 
+## Release Notes
 
-## Contact Us:  
+Our [blog](https://www.nocobase.com/en/blog/timeline) is regularly updated with release notes and provides a weekly summary.
+
+## Distinctive features
+
+### 1. Data model-driven, not form/table–driven
+
+Instead of being constrained by forms or tables, NocoBase adopts a data model–driven approach, separating data structure from user interface to unlock unlimited possibilities.
+
+- UI and data structure are fully decoupled
+- Multiple blocks and actions can be created for the same table or record in any quantity or form
+- Supports the main database, external databases, and third-party APIs as data sources
+
+![model](https://static-docs.nocobase.com/model.png)
+
+### 2. AI employees, integrated into your business systems
+Unlike standalone AI demos, NocoBase allows you to embed AI capabilities seamlessly into your interfaces, workflows, and data context, making AI truly useful in real business scenarios.
+
+- Define AI employees for roles such as translator, analyst, researcher, or assistant
+- Seamless AI–human collaboration in interfaces and workflows
+- Ensure AI usage is secure, transparent, and customizable for your business needs
+
+![AI-employee](https://static-docs.nocobase.com/ai-employee-home.png)
+
+### 3. What you see is what you get, incredibly easy to use
+
+While enabling the development of complex business systems, NocoBase keeps the experience simple and intuitive.
+
+- One-click switch between usage mode and configuration mode
+- Pages serve as a canvas to arrange blocks and actions, similar to Notion
+- Configuration mode is designed for ordinary users, not just programmers
+
+![wysiwyg](https://static-docs.nocobase.com/wysiwyg.gif)
+
+### 4. Everything is a plugin, designed for extension
+Adding more no-code features will never cover every business case. NocoBase is built for extension through its plugin-based microkernel architecture.
+
+- All functionalities are plugins, similar to WordPress
+- Plugins are ready to use upon installation
+- Pages, blocks, actions, APIs, and data sources can all be extended through custom plugins
+
+![plugins](https://static-docs.nocobase.com/plugins.png)
+
+## Installation
+
+NocoBase supports three installation methods:
+
+- <a target="_blank" href="https://docs.nocobase.com/welcome/getting-started/installation/docker-compose">Installing With Docker (👍Recommended)</a>
+
+  Suitable for no-code scenarios, no code to write. When upgrading, just download the latest image and reboot.
+
+- <a target="_blank" href="https://docs.nocobase.com/welcome/getting-started/installation/create-nocobase-app">Installing from create-nocobase-app CLI</a>
+
+  The business code of the project is completely independent and supports low-code development.
+
+- <a target="_blank" href="https://docs.nocobase.com/welcome/getting-started/installation/git-clone">Installing from Git source code</a>
+
+  If you want to experience the latest unreleased version, or want to participate in the contribution, you need to make changes and debug on the source code, it is recommended to choose this installation method, which requires a high level of development skills, and if the code has been updated, you can git pull the latest code.
+
+## How NocoBase works
+
+<video width="100%" controls>
+  <source src="https://github.com/user-attachments/assets/8d183b44-9bb5-4792-b08f-bc08fe8dfaaf" type="video/mp4">
+</video>

package/dist/ai/ai-employees/nathan/index.d.ts

@@ -0,0 +1,10 @@
+/**
+ * This file is part of the NocoBase (R) project.
+ * Copyright (c) 2020-2024 NocoBase Co., Ltd.
+ * Authors: NocoBase Team.
+ *
+ * This project is dual-licensed under AGPL-3.0 and NocoBase Commercial License.
+ * For more information, please refer to: https://www.nocobase.com/agreement.
+ */
+declare const _default: import("@nocobase/ai").AIEmployeeOptions;
+export default _default;

package/dist/ai/ai-employees/nathan/index.js

@@ -0,0 +1,41 @@
+/**
+ * This file is part of the NocoBase (R) project.
+ * Copyright (c) 2020-2024 NocoBase Co., Ltd.
+ * Authors: NocoBase Team.
+ *
+ * This project is dual-licensed under AGPL-3.0 and NocoBase Commercial License.
+ * For more information, please refer to: https://www.nocobase.com/agreement.
+ */
+
+var __defProp = Object.defineProperty;
+var __getOwnPropDesc = Object.getOwnPropertyDescriptor;
+var __getOwnPropNames = Object.getOwnPropertyNames;
+var __hasOwnProp = Object.prototype.hasOwnProperty;
+var __export = (target, all) => {
+  for (var name in all)
+    __defProp(target, name, { get: all[name], enumerable: true });
+};
+var __copyProps = (to, from, except, desc) => {
+  if (from && typeof from === "object" || typeof from === "function") {
+    for (let key of __getOwnPropNames(from))
+      if (!__hasOwnProp.call(to, key) && key !== except)
+        __defProp(to, key, { get: () => from[key], enumerable: !(desc = __getOwnPropDesc(from, key)) || desc.enumerable });
+  }
+  return to;
+};
+var __toCommonJS = (mod) => __copyProps(__defProp({}, "__esModule", { value: true }), mod);
+var nathan_exports = {};
+__export(nathan_exports, {
+  default: () => nathan_default
+});
+module.exports = __toCommonJS(nathan_exports);
+var import_ai = require("@nocobase/ai");
+var nathan_default = (0, import_ai.defineAIEmployee)({
+  username: "nathan",
+  description: "AI employee for coding",
+  avatar: "nocobase-002-male",
+  nickname: "Nathan",
+  position: "Frontend code engineer",
+  bio: "An frontend engineer specializing in JavaScript, HTML, and CSS.",
+  greeting: "Hello, I\u2019m Nathan, your frontend code engineer. I\u2019ll generate high-quality JavaScript / HTML / CSS code for you. What would you like me to build today?"
+});

package/dist/ai/ai-employees/nathan/prompt.md

@@ -0,0 +1,132 @@
+You are an AI coding assistant for NocoBase RunJS.
+
+RunJS is used in:
+
+- JS Block
+- JS Field
+- JS Item
+- JS Action
+- Event Flow
+- Linkage Rules
+
+Runtime:
+
+- Sandboxed environment
+- Access via \`ctx\`
+- Supports top-level await (PREFER whenever possible)
+- JSX → ctx.libs.React.createElement
+- Dynamic ESM via ctx.importAsync()
+
+
+# Core Rule (Strict)
+
+Never guess.
+
+You must NOT assume:
+
+- ctx APIs
+- context variables
+- collections / fields / schema
+- runtime behavior
+- React / Antd exposure
+- browser globals (window, document, location, history, navigator)
+
+All of the above MUST be verified via tools or NocoBase docs.
+
+If not confirmed → ask user.
+
+# Mandatory Workflow (Every Task)
+
+Follow this exact order. Do NOT skip ahead to coding.
+
+1. Runtime inspection first
+   - Use `frontend-developer` skill guidance.
+   - Call:
+     - `getContextEnvs`
+     - `getContextVars`
+     - `getContextApis`
+   - Goal: confirm what the current runtime exposes.
+   - This step does NOT replace documentation lookup.
+
+2. Documentation lookup before writing any code
+   - Use `document-search` skill guidance.
+   - You MUST call:
+     - `searchDocs`
+     - `readDocEntry`
+   - Always search docs before coding when the task involves any of the following:
+     - RunJS / workflow / JS Block / JS Field / JS Item / JS Action / Event Flow / Linkage Rules
+     - `ctx` APIs, runtime constraints, rendering, routing, requests, imports, React, Antd
+     - any NocoBase-specific feature, component, schema, collection behavior, or API usage
+   - Do not rely on memory, prior experience, or "common NocoBase patterns" as a substitute for this step.
+   - Minimum requirement:
+     - search for the relevant module / keywords
+     - read the most relevant matching entry or entries
+     - extract the concrete constraints or APIs you will rely on
+   - Only after this step may you decide how to implement the solution.
+
+3. Data inspection when data model is involved
+   - Use `data-metadata` skill guidance.
+   - If the task touches collections, fields, relations, filtering, querying, or record structure, call:
+     - `getDatasources`
+     - `getCollectionNames`
+     - `getCollectionMetadata`
+     - `searchFieldMetadata`
+   - Do not invent collection names, field names, relation paths, or schema details.
+
+4. Resolve uncertainty before coding
+   - If runtime inspection, docs, or metadata still leave a gap, stop and use `suggestions` or ask the user.
+   - If a required fact is unverified, you must not start writing code yet.
+
+5. Write code only after steps 1-4 are complete
+   - `frontend-developer` is the implementation skill, not the starting shortcut.
+   - Never use `frontend-developer` alone as justification to begin coding.
+   - The code must be based on verified runtime context, verified documentation, and verified metadata when applicable.
+
+6. Validate before output (REQUIRED)
+   - `lintAndTestJS` must pass before output.
+   - If validation fails, fix the code and validate again.
+
+# Coding Rules
+
+- Single file
+- Prefer top-level await
+- No import / require
+- Libraries ONLY via ctx.importAsync()
+- HTTP ONLY via ctx.request()
+- Only call ctx.render when UI is required
+- JSX uses ctx.libs.React by default
+- When rendering UI, PREFER Ant Design components via ctx.libs.antd to match NocoBase style
+- Inline styles only
+
+Forbidden:
+
+- fetch
+- XMLHttpRequest
+- localStorage
+- eval
+- new Function
+- Direct document / window access unless explicitly documented
+
+# i18n
+
+All user-facing strings MUST use: \`ctx.t(...)\`
+
+# Security
+
+Never inject unsanitized user input into DOM.
+
+# Output Rules
+
+- Markdown
+- Exactly ONE complete code block at end
+- No partial snippets
+- Brief explanation after code
+
+# Standard
+
+Senior NocoBase engineer mindset:
+Tool-driven, deterministic, production-minded.
+
+If unsure: search.
+If still unsure: ask.
+Never guess.

package/dist/ai/ai-employees/nathan/skills/frontend-developer/SKILLS.md

@@ -0,0 +1,69 @@
+---
+name: frontend-developer
+description: Assists with writing, validating, and testing JavaScript code snippets for NocoBase workflows and frontend blocks.
+introduction:
+  title: '{{t("ai.skills.frontendDeveloper.title", { ns: "@nocobase/plugin-ai" })}}'
+  about: '{{t("ai.skills.frontendDeveloper.about", { ns: "@nocobase/plugin-ai" })}}'
+---
+
+You are a professional frontend developer assistant for NocoBase.
+
+You help users write, validate, and test JavaScript code for workflows, including:
+- Workflow nodes (e.g., Custom JS, Calculation, Conditional branches)
+- Frontend blocks and pages
+
+# Primary Workflow
+
+When helping users with JavaScript code, follow this process:
+
+1. **Understand the Context**
+   - Use `getContextVars` to understand what variables are available in the current context
+   - Use `getContextApis` to see what API methods can be used
+   - Use `getContextEnvs` to understand the current page/block/flow model metadata
+
+2. **Write the Code**
+   - Write clean, correct JavaScript/JSX code based on the user's requirements
+   - Ensure the code follows best practices for NocoBase workflows
+
+3. **Validate the Code**
+   - Use `lintAndTestJS` to lint and test the code before final output
+   - Fix any errors reported by the linting tool
+   - Do not output final code unless it passes validation
+
+4. **Submit the Code**
+   - Once validated, provide the final code to the user
+   - Explain how the code works and what it does
+
+# Available Tools
+
+- `getContextVars`: Retrieves available variables from the current context. Variables are references only — you must explicitly resolve values via `await ctx.getVar(path)`. Supports dot-notation for progressive drilling (e.g., `ctx.popup.record.id`).
+- `getContextApis`: Returns available API methods from the context that can be used in the code.
+- `getContextEnvs`: Returns metadata about the current page, block, or flow model.
+- `lintAndTestJS`: Lints, performs sandbox checks, and trial-runs JavaScript/JSX code. Returns success/failure with diagnostics. **Always call this tool before outputting final code to verify it works.**
+
+# Code Writing Guidelines
+
+## Variable Access
+
+- Always use `await ctx.getVar(path)` to get actual values
+- Use dot-notation for nested paths: `await ctx.getVar('ctx.popup.record.id')`
+- Prefer specific paths instead of fetching entire objects when possible
+
+## Return Values
+
+- For Custom JS nodes, use `return` to output data to the next node
+- Return values are passed as input to subsequent nodes in the workflow
+- Example: `return { result: calculatedValue };`
+
+## Error Handling
+
+- Wrap code in try-catch blocks when appropriate
+- Return error information in a consistent format
+- Example: `return { error: 'Error message', details: ... };`
+
+## Best Practices
+
+- Keep code concise and readable
+- Use meaningful variable names
+- Add comments for complex logic
+- Test code with the lint tool before final submission

package/dist/ai/{tools → ai-employees/nathan/skills/frontend-developer/tools}/getContextApis.js

@@ -44,9 +44,9 @@ var getContextApis_default = (0, import_ai.defineTools)({
     description: "Get available API methods from context",
     schema: import_zod.z.object({})
   },
-  invoke: async (ctx, _args, id) => {
+  invoke: async (ctx, _args, runtime) => {
     const { toolCallResults } = ctx.action.params.values || {};
-    const { result } = (toolCallResults == null ? void 0 : toolCallResults.find((item) => item.id === id)) ?? {};
+    const { result } = (toolCallResults == null ? void 0 : toolCallResults.find((item) => item.id === runtime.toolCallId)) ?? {};
     if (toolCallResults && result) {
       return {
         status: "success",

package/dist/ai/{tools → ai-employees/nathan/skills/frontend-developer/tools}/getContextEnvs.js

@@ -44,9 +44,9 @@ var getContextEnvs_default = (0, import_ai.defineTools)({
     description: "Get current page/block/flow model metadata from context",
     schema: import_zod.z.object({})
   },
-  invoke: async (ctx, _args, id) => {
+  invoke: async (ctx, _args, runtime) => {
     const { toolCallResults } = ctx.action.params.values || {};
-    const { result } = (toolCallResults == null ? void 0 : toolCallResults.find((item) => item.id === id)) ?? {};
+    const { result } = (toolCallResults == null ? void 0 : toolCallResults.find((item) => item.id === runtime.toolCallId)) ?? {};
     if (toolCallResults && result) {
       return {
         status: "success",

package/dist/ai/{tools → ai-employees/nathan/skills/frontend-developer/tools}/getContextVars.js

@@ -60,9 +60,9 @@ instead of fetching the entire object, e.g.
       )
     })
   },
-  invoke: async (ctx, _args, id) => {
+  invoke: async (ctx, _args, runtime) => {
     const { toolCallResults } = ctx.action.params.values || {};
-    const { result } = (toolCallResults == null ? void 0 : toolCallResults.find((item) => item.id === id)) ?? {};
+    const { result } = (toolCallResults == null ? void 0 : toolCallResults.find((item) => item.id === runtime.toolCallId)) ?? {};
     if (toolCallResults && result) {
       return {
         status: "success",

package/dist/ai/{tools → ai-employees/nathan/skills/frontend-developer/tools}/lintAndTestJS.js

@@ -46,9 +46,9 @@ var lintAndTestJS_default = (0, import_ai.defineTools)({
       code: import_zod.z.string().describe("The JavaScript/JSX code to preview and validate")
     })
   },
-  invoke: async (ctx, _args, id) => {
+  invoke: async (ctx, _args, runtime) => {
     const { toolCallResults } = ctx.action.params.values || {};
-    const { result } = (toolCallResults == null ? void 0 : toolCallResults.find((item) => item.id === id)) ?? {};
+    const { result } = (toolCallResults == null ? void 0 : toolCallResults.find((item) => item.id === runtime.toolCallId)) ?? {};
     if (toolCallResults && result) {
       return {
         status: result.status ?? "error",

package/dist/ai/docs/runjs/context/block-model.md

@@ -1,49 +1,49 @@
 # ctx.blockModel
 
-The parent block model (BlockModel instance) that hosts the current JS field / JS block. In JSField, JSItem, JSColumn, etc., `ctx.blockModel` refers to the form block or table block that hosts the current JS logic; in a standalone JSBlock it may be `null` or the same as `ctx.model`.
+The parent block model (BlockModel instance) where the current JS Field / JS Block is located. In scenarios such as JSField, JSItem, and JSColumn, `ctx.blockModel` points to the form block or table block carrying the current JS logic. In a standalone JSBlock, it may be `null` or the same as `ctx.model`.
 
-## Use Cases
+## Scenarios
 
 | Scenario | Description |
-|----------|-------------|
-| **JSField** | Access parent form block's `form`, `collection`, `resource` for linkage or validation |
-| **JSItem** | Access parent table/form block's resource and collection in sub-table items |
-| **JSColumn** | Access parent table block's `resource` (e.g. `getSelectedRows`), `collection` |
-| **Form actions / event flow** | Use `form` for pre-submit validation, `resource` for refresh, etc. |
+|------|------|
+| **JSField** | Access the `form`, `collection`, and `resource` of the parent form block within a form field to implement linkage or validation. |
+| **JSItem** | Access the resource and collection information of the parent table/form block within a sub-table item. |
+| **JSColumn** | Access the `resource` (e.g., `getSelectedRows`) and `collection` of the parent table block within a table column. |
+| **Form Actions / FlowEngine** | Access `form` for pre-submission validation, `resource` for refreshing, etc. |
 
-> Note: `ctx.blockModel` is only available in RunJS contexts that have a parent block; in a standalone JSBlock (no parent form/table) it may be `null`—check before use.
+> Note: `ctx.blockModel` is only available in RunJS contexts where a parent block exists. In standalone JSBlocks (without a parent form/table), it may be `null`. It is recommended to perform a null check before use.
 
-## Type
+## Type Definition
 
 ```ts
 blockModel: BlockModel | FormBlockModel | TableBlockModel | CollectionBlockModel | DataBlockModel | null;
 ```
 
-The exact type depends on the parent block: form blocks are usually `FormBlockModel` / `EditFormModel`, table blocks are usually `TableBlockModel`.
+The specific type depends on the parent block type: form blocks are mostly `FormBlockModel` or `EditFormModel`, while table blocks are mostly `TableBlockModel`.
 
 ## Common Properties
 
 | Property | Type | Description |
-|----------|------|-------------|
-| `uid` | `string` | Block model unique id |
-| `collection` | `Collection` | Collection bound to the block |
-| `resource` | `Resource` | Resource instance (`SingleRecordResource` / `MultiRecordResource`, etc.) |
-| `form` | `FormInstance` | Form block: Ant Design Form instance (`getFieldsValue`, `validateFields`, `setFieldsValue`, etc.) |
-| `emitter` | `EventEmitter` | Event emitter; can listen to `formValuesChange`, `onFieldReset`, etc. |
+|------|------|------|
+| `uid` | `string` | Unique identifier of the block model. |
+| `collection` | `Collection` | The collection bound to the current block. |
+| `resource` | `Resource` | The resource instance used by the block (`SingleRecordResource` / `MultiRecordResource`, etc.). |
+| `form` | `FormInstance` | Form Block: Ant Design Form instance, supporting `getFieldsValue`, `validateFields`, `setFieldsValue`, etc. |
+| `emitter` | `EventEmitter` | Event emitter, used to listen for `formValuesChange`, `onFieldReset`, etc. |
 
-## Relation to ctx.model, ctx.form
+## Relationship with ctx.model and ctx.form
 
-| Need | Recommended |
-|------|-------------|
-| **Parent block of current JS** | `ctx.blockModel` |
-| **Read/write form fields** | `ctx.form` (same as `ctx.blockModel?.form`; more convenient in form blocks) |
-| **Model for current execution context** | `ctx.model` (field model in JSField, block model in JSBlock) |
+| Requirement | Recommended Usage |
+|------|----------|
+| **Parent block of the current JS** | `ctx.blockModel` |
+| **Read/Write form fields** | `ctx.form` (equivalent to `ctx.blockModel?.form`, more convenient in form blocks) |
+| **Model of the current execution context** | `ctx.model` (Field model in JSField, Block model in JSBlock) |
 
-In JSField, `ctx.model` is the field model and `ctx.blockModel` is the form/table block that hosts it; `ctx.form` is usually `ctx.blockModel.form`.
+In a JSField, `ctx.model` is the field model, and `ctx.blockModel` is the form or table block carrying that field; `ctx.form` is typically `ctx.blockModel.form`.
 
 ## Examples
 
-### Table: get selected rows and process
+### Table: Get selected rows and process
 
 ```ts
 const rows = ctx.blockModel?.resource?.getSelectedRows?.() || [];
@@ -53,7 +53,7 @@ if (rows.length === 0) {
 }
 ```
 
-### Form: validate and refresh
+### Form Scenario: Validate and Refresh
 
 ```ts
 if (ctx.blockModel?.form) {
@@ -62,15 +62,15 @@ if (ctx.blockModel?.form) {
 }
 ```
 
-### Listen to form changes
+### Listen for Form Changes
 
 ```ts
 ctx.blockModel?.emitter?.on?.('formValuesChange', (payload) => {
-  // React to latest form values or re-render
+  // Implement linkage or re-rendering based on the latest form values
 });
 ```
 
-### Trigger block re-render
+### Trigger Block Re-render
 
 ```ts
 ctx.blockModel?.rerender?.();
@@ -78,13 +78,13 @@ ctx.blockModel?.rerender?.();
 
 ## Notes
 
-- In a **standalone JSBlock** (no parent form/table), `ctx.blockModel` may be `null`; use optional chaining: `ctx.blockModel?.resource?.refresh?.()`.
-- In **JSField / JSItem / JSColumn**, `ctx.blockModel` is the form or table block that hosts the field; in **JSBlock**, it may be the block itself or an ancestor, depending on hierarchy.
-- `resource` exists only on data blocks; `form` exists only on form blocks; table blocks usually have no `form`.
+- In a **standalone JSBlock** (without a parent form or table block), `ctx.blockModel` may be `null`. It is recommended to use optional chaining when accessing its properties: `ctx.blockModel?.resource?.refresh?.()`.
+- In **JSField / JSItem / JSColumn**, `ctx.blockModel` refers to the form or table block carrying the current field. In a **JSBlock**, it may be itself or an upper-level block, depending on the actual hierarchy.
+- `resource` only exists in data blocks; `form` only exists in form blocks. Table blocks typically do not have a `form`.
 
 ## Related
 
-- [ctx.model](./model.md): model for current execution context
-- [ctx.form](./form.md): form instance, common in form blocks
-- [ctx.resource](./resource.md): resource instance (same as `ctx.blockModel?.resource` when present)
-- [ctx.getModel()](./get-model.md): get another block model by uid
+- [ctx.model](./model.md): The model of the current execution context.
+- [ctx.form](./form.md): Form instance, commonly used in form blocks.
+- [ctx.resource](./resource.md): Resource instance (equivalent to `ctx.blockModel?.resource`, use directly if available).
+- [ctx.getModel()](./get-model.md): Get other block models by UID.