@nocobase/plugin-flow-engine 2.1.0-alpha.3 → 2.1.0-alpha.30

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,42 @@
+/**
+ * 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",
+  category: "developer",
+  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,168 @@
+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`.
+   - 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:
+     - use a compact Bash script that first searches file paths / filenames, then reads focused snippets from the best matches
+     - run broader content search only when path search is insufficient or ambiguous
+     - extract the concrete constraints or APIs you will rely on
+     - start narrow; prefer returning an initial answer once focused snippets confirm the needed constraints
+   - Prefer one combined `searchDocs` call over multiple small calls. Good pattern:
+     ```bash
+     printf '## Candidate files\n'
+     rg --files interface-builder | grep -Ei 'runjs|js-|event|linkage' | head -50
+
+     printf '\n## JS Block\n'
+     sed -n '1,180p' interface-builder/blocks/other-blocks/js-block.md
+
+     printf '\n## RunJS\n'
+     sed -n '1,180p' interface-builder/runjs.md
+     ```
+   - Avoid broad full-tree scans such as `find .` or `rg ... .`. Pick likely top-level directories first, then search inside them.
+   - Do not pipe output into `rg`; use `grep` for pipeline filtering, and call `rg --files <dir>` or `rg -n <pattern> <dir>` with explicit path arguments.
+   - Use `rg -g '*.md' -g '*.mdx'`; do not use unsupported `rg --include` options.
+   - Stop searching once the snippets directly confirm the API or constraint needed for the code. Do not read adjacent overview, quickstart, definition, lifecycle, or development pages just for extra background unless the user asks for more depth.
+   - 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.
+   - If you need to inspect the current editor code, call `readJSCode`. Never use `searchDocs` for current editor code, and never say the current code cannot be read.
+   - Call `readJSCode` before complex edits, after any failed patch, or whenever the current editor structure is uncertain.
+   - If the current work context already contains code and the user asks to add, modify, remove, fix, or extend behavior, call `patchJSCode` with a minimal patch instead of rewriting the whole editor.
+   - Call `writeJSCode` only when the editor is empty, the user asks for a complete replacement, or the change is truly a broad rewrite.
+   - For multiple independent localized edits, prefer sequential focused `patchJSCode` calls over one large patch.
+   - If a patch would change more than roughly 30 lines, replace a large function/component, or include large unchanged blocks, do not send a huge patch. Either split it into focused patches or use `writeJSCode` as a deliberate broad rewrite when the replacement is clearer than the diff.
+   - Do NOT put the complete code in a normal assistant message for validation.
+
+6. Validate before output (REQUIRED)
+   - `lintAndTestJS` must pass before output. Omit the `code` argument so it validates the current editor code.
+   - If validation fails, do not guess or repeatedly patch from memory.
+   - Track the failing rule, line, and symbol. Do not make multiple cosmetic rewrites for the same diagnostic.
+   - Treat every validation failure as new evidence and classify it before changing code:
+     - Unknown or missing `ctx` member / runtime API / library exposure → call `getContextApis`, `getContextVars`, or `getContextEnvs` again, then search docs for that exact API or error.
+     - Unsupported syntax, sandbox restriction, import/render/request error, React/Antd usage error → call `searchDocs` again with the exact diagnostic text and the related feature keywords.
+     - Collection, field, relation, filter, or record-shape error → call the data metadata tools again for the exact collection or field involved.
+     - Plain JavaScript syntax or type error that is fully explained by the diagnostic → call `patchJSCode` with a minimal unified diff patch, then validate again.
+   - If one direct fix for the same lint rule still fails, stop changing that same expression. Re-read the exact code shape and consider whether the diagnostic is a static-check false positive or unsupported pattern before patching again.
+   - If `patchJSCode` fails to apply, call `readJSCode` before any retry, then decide whether a smaller patch or a full `writeJSCode` replacement is the clearer edit.
+   - After one failed direct fix, you MUST go back to runtime inspection, documentation lookup, metadata lookup, or ask the user before another code change.
+   - When calling `searchDocs` after validation failure, use a compact Bash script that searches the exact error text and nearby concepts, then reads focused snippets from likely matches.
+   - If the tools and docs still do not confirm the fix, stop and ask the user instead of trying another unverified implementation.
+   - When calling `patchJSCode`, provide only the unified diff patch. The tool reads the current editor code directly.
+   - Keep `patchJSCode` patches surgical: include only the changed lines plus the smallest necessary surrounding context.
+   - Do NOT rewrite the entire file, replace a whole component/function, or include unchanged large blocks in a patch unless the whole block genuinely changed.
+   - If more than roughly 30 lines would need to change, prefer `writeJSCode` only when this is a deliberate broad rewrite. For incremental requests, split into focused `patchJSCode` patches.
+
+# 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
+- Do NOT output a complete code block after using `writeJSCode` / `patchJSCode`.
+- Final response should be brief: say that the code has been written to the editor and validation passed.
+- If validation cannot pass, summarize the blocking diagnostics and ask for the missing verified information.
+
+# 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,86 @@
+---
+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
+   - Use `readJSCode` before complex edits, after any patch failure, or whenever the current editor structure is uncertain. Never use documentation search to read current editor code.
+   - If the current work context already contains code and the user asks to add, modify, remove, fix, or extend behavior, use `patchJSCode` with a minimal patch instead of rewriting the whole editor
+   - Use `writeJSCode` only when the editor is empty, the user asks for a complete replacement, or the change is truly a broad rewrite
+   - If an edit would require a large patch, split it into focused patches. If the change replaces a large function/component or the patch would be larger than the full replacement, use `writeJSCode` as a deliberate broad rewrite.
+   - Ensure the code follows best practices for NocoBase workflows
+
+3. **Validate the Code**
+   - Use `lintAndTestJS` with no `code` argument to lint and test the current editor code before final output
+   - Fix plain JavaScript syntax errors directly when the diagnostic fully explains the problem
+   - Use `patchJSCode` with a minimal unified diff patch for follow-up fixes instead of rewriting the full code
+   - Track the failing rule, line, and symbol. If one direct fix for the same lint rule still fails, stop changing the same expression and gather new evidence instead of trying cosmetic rewrites.
+   - Keep patches surgical: include only changed lines plus the smallest necessary context. Do not include unchanged large blocks or rewrite entire components/functions unless they genuinely changed.
+   - If `patchJSCode` fails to apply, call `readJSCode` before retrying. Do not say the current code cannot be read.
+   - If the error involves NocoBase runtime APIs, `ctx`, sandbox restrictions, imports, rendering, React, Antd, requests, collections, fields, or record structure, do not guess. Go back to the relevant inspection or documentation tools before changing code:
+     - Runtime exposure errors: call `getContextEnvs`, `getContextVars`, or `getContextApis` again
+     - NocoBase API / runtime / sandbox / UI errors: use the documentation search skill again with the exact error and relevant feature keywords
+     - Data model errors: use data metadata tools again for the exact collection, field, or relation
+   - After one failed direct fix, you must gather new evidence from tools or docs before another code change
+   - 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
+   - If `lintAndTestJS` validated and ran the current editor code successfully, remind the user that the code has not been saved permanently yet and they should click the save button manually.
+
+# 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.
+- `readJSCode`: Reads the complete JavaScript/JSX code currently in the active editor. Use before complex patches, after patch failure, or whenever the current editor structure is uncertain.
+- `writeJSCode`: Writes complete JavaScript/JSX code directly into the current editor and returns write metadata. Use only for an empty editor, explicit complete replacement, or deliberate broad rewrite.
+- `patchJSCode`: Applies a minimal unified diff patch to the current editor code and writes it back. Provide only the patch; the tool reads the current editor code directly.
+- `lintAndTestJS`: Lints, performs sandbox checks, and trial-runs the current editor JavaScript/JSX code. Returns success/failure with diagnostics. **Always call this tool before final response 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

@@ -41,14 +41,16 @@ var lintAndTestJS_default = (0, import_ai.defineTools)({
   },
   definition: {
     name: "lintAndTestJS",
-    description: "Lint, sandbox-check and trial-run a JavaScript snippet. Returns success/failure with diagnostics. Call this tool BEFORE outputting final code to verify it works.",
+    description: "Lint, sandbox-check and trial-run the current editor JavaScript/JSX code. Returns success/failure with diagnostics. Call this tool after writeJSCode or patchJSCode before final response.",
     schema: import_zod.z.object({
-      code: import_zod.z.string().describe("The JavaScript/JSX code to preview and validate")
+      code: import_zod.z.string().optional().describe(
+        "Optional JavaScript/JSX code to preview and validate. Omit this to validate the current editor code."
+      )
     })
   },
-  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/ai-employees/nathan/skills/frontend-developer/tools/patchJSCode.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").ToolsOptions;
+export default _default;

package/dist/ai/ai-employees/nathan/skills/frontend-developer/tools/patchJSCode.js

@@ -0,0 +1,65 @@
+/**
+ * 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 patchJSCode_exports = {};
+__export(patchJSCode_exports, {
+  default: () => patchJSCode_default
+});
+module.exports = __toCommonJS(patchJSCode_exports);
+var import_ai = require("@nocobase/ai");
+var import_zod = require("zod");
+var patchJSCode_default = (0, import_ai.defineTools)({
+  scope: "SPECIFIED",
+  execution: "frontend",
+  defaultPermission: "ALLOW",
+  introduction: {
+    title: `{{t("ai.tools.patchJSCode.title")}}`,
+    about: `{{t("ai.tools.patchJSCode.about")}}`
+  },
+  definition: {
+    name: "patchJSCode",
+    description: "Apply a minimal unified diff patch to the code currently in the editor, then write the patched code back to the editor. Use this for adding, modifying, removing, fixing, or extending existing code. The tool reads the current editor code directly; only provide the patch. Keep patches surgical: include only changed lines plus the smallest necessary context, and do not include unchanged large blocks.",
+    schema: import_zod.z.object({
+      patch: import_zod.z.string().describe(
+        "Minimal unified diff patch to apply to the current editor code. Include only changed lines plus the smallest necessary context."
+      )
+    })
+  },
+  invoke: async (ctx, _args, runtime) => {
+    const { toolCallResults } = ctx.action.params.values || {};
+    const { result } = (toolCallResults == null ? void 0 : toolCallResults.find((item) => item.id === runtime.toolCallId)) ?? {};
+    if (toolCallResults && result) {
+      return {
+        status: result.status ?? "error",
+        content: JSON.stringify(result.content ?? {})
+      };
+    }
+    return {
+      status: "error",
+      content: JSON.stringify({ success: false, message: "Patch code failed: no result returned" })
+    };
+  }
+});

package/dist/ai/ai-employees/nathan/skills/frontend-developer/tools/readJSCode.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").ToolsOptions;
+export default _default;

package/dist/ai/ai-employees/nathan/skills/frontend-developer/tools/readJSCode.js

@@ -0,0 +1,61 @@
+/**
+ * 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 readJSCode_exports = {};
+__export(readJSCode_exports, {
+  default: () => readJSCode_default
+});
+module.exports = __toCommonJS(readJSCode_exports);
+var import_ai = require("@nocobase/ai");
+var import_zod = require("zod");
+var readJSCode_default = (0, import_ai.defineTools)({
+  scope: "SPECIFIED",
+  execution: "frontend",
+  defaultPermission: "ALLOW",
+  introduction: {
+    title: `{{t("ai.tools.readJSCode.title")}}`,
+    about: `{{t("ai.tools.readJSCode.about")}}`
+  },
+  definition: {
+    name: "readJSCode",
+    description: "Read the complete JavaScript/JSX code currently in the active editor. Use before complex patches, after patchJSCode fails, or whenever the current editor structure is uncertain. Do not use searchDocs to read editor code.",
+    schema: import_zod.z.object({})
+  },
+  invoke: async (ctx, _args, runtime) => {
+    const { toolCallResults } = ctx.action.params.values || {};
+    const { result } = (toolCallResults == null ? void 0 : toolCallResults.find((item) => item.id === runtime.toolCallId)) ?? {};
+    if (toolCallResults && result) {
+      return {
+        status: result.status ?? "error",
+        content: JSON.stringify(result.content ?? {})
+      };
+    }
+    return {
+      status: "error",
+      content: JSON.stringify({ success: false, message: "Read code failed: no result returned" })
+    };
+  }
+});

package/dist/ai/ai-employees/nathan/skills/frontend-developer/tools/writeJSCode.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").ToolsOptions;
+export default _default;