@nocobase/app-plugin-agents 0.1.0-beta.4 → 0.1.0-beta.6

package/CHANGELOG.md

@@ -1,5 +1,98 @@
 # @nocobase/app-plugin-agents
 
+## 0.1.0-beta.6
+
+### Minor Changes
+
+- 4044a42: Allow workflow Run agent rules to start a fresh session on every stage entry while preserving working directories and other agents' sessions. Preserve the choice across queued run merges, confirmation requests and retries, and expose it in run responses.
+
+  New software development workflows enable fresh sessions for proposal review and code review. Existing workflows are unchanged: workflow owners can enable “Start a new session every time” in the rule editor. The agents database migration adds `freshSession` columns to runs and run requests with a default of false; no existing workflow configuration is migrated.
+
+- 0f7ed64: Give a run's git a repository credential whenever it needs one, instead of one handed out at the claim that a long run outlives, and say why a push failed.
+
+  - Protocol version 9 adds the `gitCredentials` runner feature, `RunGit.onDemand` (repository URLs whose credential the runner asks for), `POST /api/agents/runners/runs/:runId/gitCredentials` (`GitCredentialRequest` → `GitCredential`), the reasons `REPO_ACCESS_UNAVAILABLE` and `REPO_ACCESS_DENIED`, the run failures `repoAccessUnavailable` (retried) and `repoAccessDenied`, and `RepoReport.failure` (`authFailed`, `credentialUnavailable`, `credentialDenied`, `leaseLost`, `rejected`, `error`). Nothing of version 8 changed: an application on this version still hands claim-time credentials to runners without the feature. A runner of this version is refused by an application that does not know version 9, so update the application before its runners.
+  - Repository access providers may implement `issue(request)`. For a runner with the feature the claim tells them `onDemand` (in `forRun`'s context and `prepare(run, { onDemand })`), they list their repositories in `RunGit.onDemand` and mint nothing at the claim; the plugin then calls `issue` outside any transaction, within 15 seconds, only while that runner holds that attempt of the run under a live lease, and only for a URL the claim listed, compared exactly. `issue` answers a credential with its expiry, null when the repository is not its own, or throws `RepoAccessError('unavailable' | 'denied', message)` with a message safe to show; with `refresh` it should issue a new credential rather than a cached one. Each issued credential is added to the run's redaction, and is never stored. A provider without `issue` keeps working as before.
+  - Migration `202610100002_ag_add_run_git_credentials` adds `agRuns.gitCredentialUrls` (the URLs the claim listed) and `agRunRepos.failureReason` and `failureDetail`; a run's repositories (`RunRepo`) gain optional `failure` so existing application schemas remain compatible. The server always supplies it, null when the repository was pushed or not tried. Applications should show it, since a run that completed may still have work that was not pushed.
+  - The runner keeps a run's credentials in the worker's memory and no longer puts any password in the agent's environment. The agent's git gets them through the runner's credential helper, which reaches the worker over a Unix socket private to the run; the runner's own git (checkout, submodules, the end-of-run push, which previously sent no credential) uses the same, never the host's credential helpers, and retries once with a fresh credential when the remote refuses one. The agent is told on stderr why git got no credential, and each failure is recorded as an `error` event with `meta.kind` `gitCredential`.
+  - Host-side operations in task checkouts use the safe Git wrapper, retaining its metadata and configuration checks, protected hooks and fixed push URL/refspec. Run credentials disable restoration of host helpers; the agent environment clears helpers per repository URL before installing the runner's helper. Confirmed pushes update remote-tracking refs and the protected workspace record so cleanup recognizes pushed work.
+
+- e9301ed: Check a subject’s admission policy in the claim transaction and cancel outdated issue runs without failing or retrying them. The same policy, with the subject's new optional `selectInputs`, also decides whether input may join a working run and whether pending input is delivered to it: input the subject rejects waits in a queued run for the claim to admit or cancel, and pending input it no longer admits or selects is marked handled instead of being delivered, or of holding the run's completion open. The runner completes again, rather than starting a turn with an empty prompt, when input it was told is pending never arrives. Studio permits its executor only in execution statuses and workflow agents only in their current stage; an agent mentioned by name, or answered under its own comment, runs in any stage, except the executor. Earlier stage instructions are left out of the turn rather than cancelling the run, which is cancelled only when nothing else remains. Approving a proposal now requires an eligible executor (`DESIGN_EXECUTOR_REQUIRED` otherwise). Requeue live workspace contention without consuming execution attempts, bounded by a six-hour wait, with a compatible failure fallback for older applications.
+
+  Filter obsolete stage instructions consistently from the assembled task, turn and delivered inputs. Record permission-rejected executor claims atomically and notify the owner once with the required pull request permission and reassignment options. Preserve restart after an acknowledged project move.
+
+- ee41a40: Show the executing agent's active work on issue tables and boards using scoped batch summaries, with pending approvals taking precedence and visible-page refreshes.
+
+### Patch Changes
+
+- 69309da: Normalize the runner artifact response description's string quoting to satisfy the shared formatter, without changing its text or runtime behavior.
+- a50b4f6: Expose the chat query cache for application submission coordinators and keep conversation details and history current after sends. Explain unavailable header targets and query recovery conversations only when creation results are unknown. Keep upload tasks attached to their draft when an editor switches conversations, preserving pending sends across remounts.
+- ca0bfe2: Normalize formatting of the agent distribution API description without changing its content or behavior.
+- ee217d5: Start a fresh conversation with context recovery instructions when the requested conversation no longer exists, and report its session so later runs resume it. Claude checks its session file before opening the query, preserving immediate handling of startup errors. Cancelled runs now also report their confirmed session.
+- b4c2116: Add compatible directory settlement diagnostics and repository-scoped merged head evidence. Recheck ended workspaces before cleanup, permit untracked leftovers only after commit and tracked-change checks, preserve unpushed submodule commits, cancel a removal when the follow-up report no longer confirms the work is over, and show low disk reports with permission-aware workspace diagnostics.
+- 107edd5: Keep in-flight subject run requests when refresh signals arrive so slow responses can update the shared run cache instead of being repeatedly cancelled by discovery polling.
+- c1b397d: Correct Alibaba Qwen's default DashScope base URL.
+- 90d5fab: Remove a working directory once its subject's work is over, on the subject's status alone. Studio counts an issue as over when it is done or cancelled, whatever its pull requests are, and resolves directories without a known run by their issue key. The agents plugin no longer checks which runner worked on a subject, so legacy directories on any runner are decided too, and no longer asks bindings for commit evidence. The runner removes an ended directory with anything never pushed in it, and logs that it did; it still keeps one a run holds or used since the report, and one the second report no longer confirms as ended. Directories whose work goes on keep their unpushed-work protection. Runners released earlier still keep ended directories with unpushed work, since decisions now carry no commit evidence.
+
+  New runners connected to older applications that only return legacy remove lists continue protecting unpushed commits and changes. Only a settled directory decision permits discarding unpushed work; automatic collection confirms that decision in a second report before deletion.
+
+- Updated dependencies [251d19e]
+- Updated dependencies [ca0bfe2]
+- Updated dependencies [0f7ed64]
+- Updated dependencies [e9301ed]
+- Updated dependencies [ee217d5]
+- Updated dependencies [b4c2116]
+  - @nocobase/app-plugin-authentication@2.0.0-beta.5
+  - @nocobase/app-cli-client@0.1.0-beta.3
+  - @nocobase/agent-protocol@0.1.0-beta.4
+
+## 0.1.0-beta.5
+
+### Minor Changes
+
+- 40a5679: An application can name the runner and its CLI on npm when it has no tarball of them. `agents.dist.npm` maps a product to its npm package and an exact version, such as `{ nocobase-runner: { package: '@nocobase/agent-runner', version: '1.0.0' } }`; a product `agents.dist.dir` has a current version of is still served from there exactly as before. Only callers that say they understand the answer receive it: the resolve route (`/api/agents/dist/products/<product>/targets/<target>`) answers `{ kind: 'npm', product, version, package, channel }` (or `kind=npm` lines with `format=env`) to a request with `accept=npm`, and a heartbeat answer carries `npmUpgrade` instead of `upgrade` only to a runner that declares the new `npm` feature. Every other caller gets what it got before: the artifact when there is a tarball, otherwise a 404 and no update.
+
+  `@nocobase/agent-protocol` adds `DistNpmPackage`, `DistResolution`, `DIST_ACCEPT_NPM`, `NpmUpgradeNotice`, `HeartbeatResponse.npmUpgrade` and the `npm` runner feature (`NPM_UPGRADE_FEATURE`), and moves `PROTOCOL_VERSION` to 8 so that a runner announcing `npm` is refused cleanly by a server that does not know it. Nothing of protocol 7 changed: a server speaking 8 still serves runners speaking 3 to 7. A runner speaking 8 is shown as needing an upgrade by an application that serves only up to 7, so upgrade the application before its runners.
+
+  NocoBase Studio pins the runner it serves to the exact `@nocobase/agent-runner` version it was built with, recorded by `pnpm build` in `dist/server/agents/served-versions.json` (the runner stays out of the deployment's dependencies), and names it on npm when its image carries no runner tarballs. Redeploying Studio moves runners that understand npm updates to that version.
+
+- 13620d9: The runner and an application's CLI can now be installed and updated from npm when the application serves no tarball of them and names the exact npm version instead (`agents.dist.npm`). The install script asks with `accept=npm`; for an npm answer it checks for Node.js 24 or newer and `npm` (or `NOCOBASE_NPM`), runs `npm install --prefix <prefix>/versions/<version> --no-save --no-audit --no-fund --omit=optional <package>@<version>` and writes a launcher at `versions/<version>/bin/<command>`, so `current`, the linked command and the runner's user service work as they do for a tarball, and links `<prefix>/node` to the Node.js it checked. The runner declares the `npm` feature and installs a heartbeat's `npmUpgrade` the same way between runs; `nocobase-runner update` and `<cli> update` follow either answer, and an installation moves between tarball and npm versions in both directions (`installNpmVersion`, `npmLauncherScript` and `UpdateTarget` in `@nocobase/app-cli-client/install`). An application that answers no npm form is handled exactly as before.
+
+  `@nocobase/agent-runner` and `@nocobase/app-cli-client` now depend on exactly the `@nocobase/agent-protocol` they were built with, and `@nocobase/studio-cli` and `@nocobase/agent-runner` on exactly their `@nocobase/app-cli-client`, so a version installed from npm behaves as it was built.
+
+  `nocobase skills sync` no longer reads Skills from a packaged application CLI (a dependency declaring `nocobase.cli`, such as `@nocobase/studio-cli`): its `skills/` is for that command's users. NocoBase Studio declares `@nocobase/studio-cli`, so its build pins `nb-studio` to the version it was built with, and its CLI documentation and home-page agent prompt say that `nb-studio` needs Node.js 24 or newer with npm. The application development Skill documents `nocobase cli build --universal`.
+
+- 459c33f: `nocobase cli build --universal` packs the application's CLI, or with `--runner` the runner, into one platform-independent tarball, `<product>-v<version>-universal.tar.gz`, that carries no Node.js and runs on the machine's own Node.js 24 or newer; without `--targets` it is the only tarball packed. Its launcher runs on `NOCOBASE_NODE`, the installation's `<prefix>/node`, `node` on PATH, or the Node a previous standalone version of the installation still carries, so a runner's user service, whose PATH usually has no `node`, keeps starting.
+
+  The agents plugin serves that tarball to every platform without a tarball of its own (one built for the platform still wins) and marks the answer with `universal: true` (`universal=true` with `format=env`); answers for platform tarballs are unchanged. For a universal tarball the install script checks that `node` is Node.js 24 or newer before downloading, stops with how to install it otherwise, and links `<prefix>/node` to it; with `--runner` it prints a `corepack enable` hint when `pnpm` is missing. The "Add runtime" dialog says the host needs Node.js 24 or newer.
+
+  An update of an installed CLI or runner to a version without a bundled Node (`applyUpdate` of `@nocobase/app-cli-client/install`) first leaves the Node it runs on in `<prefix>/node` (`pinNode`), copied when it is a Node an older version bundles, so a runner that updates itself from a standalone version keeps a Node after the old versions are removed.
+
+### Patch Changes
+
+- 9d28d61: The install script checks for npm with an explicit `if`, which shellcheck accepts.
+- 97bd30b: The runner now runs agents with full access and the real home of the user it runs as, and is no longer a sandbox. Codex runs with approval policy `never` and the `danger-full-access` sandbox, accepting any approval it still asks for; Claude Code runs in `bypassPermissions` mode with no hooks; OpenCode and Pi have every permission request allowed. The command policy (allowed commands, denied patterns, download rules, path checks) and the isolated per-workspace home are gone; each run still gets its own TMPDIR, and Codex a per-workspace `CODEX_HOME` linking `auth.json` and `config.toml` from `~/.codex`. The push guard (the `pre-push` hook that let a checkout push only its run's branch) is removed, and an earlier runner's is deleted on upgrade; the run's short-lived repository credential is still provided, so protect default branches on the code host.
+
+  Operators: an agent can now read and change anything the runner's user can, including SSH keys, cloud credentials and `~/.nocobase-runner`. Run the runner as a dedicated OS user that holds only what agents need, in a container or in a VM, and not as root (Claude Code refuses `bypassPermissions` as root). `start --agent-home` is gone. Agents' tool policies keep their idle timeout and turn limit; their permission mode and command patterns are accepted and no longer enforced, and the agent page no longer shows the command rules.
+
+- d3763a2: Studio's `pnpm build` now packs the universal `nocobase-runner` and `nb-studio` packages into `dist/runners/`, at the exact versions it records in `dist/server/agents/served-versions.json` (`nb-studio` at `@nocobase/studio-cli`'s version, the runner at `@nocobase/agent-runner`'s), and fails when they differ. Studio serves them from there by default, so every build, deployment archive and image serves the runner and CLI it was built with, including to runners installed from a package, which can only update from one. `agents.dist.dir` in `config.yml` and `NB_STUDIO_RUNNERS_DIST` still take precedence, and npm stays the fallback for a Studio without packages, such as `pnpm dev`. The build installs the packages' dependencies with npm, so it needs access to the npm registry. The Dockerfile no longer takes a `runners-dist/` directory, and it rejects a prebuilt `dist/` without `dist/runners`. The published package now includes `ai/`, the Skills `nb-studio` ships, which an installed Studio needs to pack it.
+
+  `nb-studio` packages are now versioned as `@nocobase/studio-cli` rather than as Studio. An installation that served `nb-studio` packed with `pnpm nocobase cli build` and no `--version` handed out Studio's version, which sorts higher, so `nb-studio update` does not offer the new package there: install `nb-studio` again with the install script.
+
+  The agents plugin's documentation describes building the runner and CLI into an application's own build output as an alternative to separate CI artifacts.
+
+  `@nocobase/studio-cli` now shares Studio's version line (a `fixed` changesets group), so the `nb-studio` Studio serves keeps the versions earlier Studio builds handed out and `nb-studio update` offers it to existing installations.
+
+- Updated dependencies [40a5679]
+- Updated dependencies [91f5344]
+- Updated dependencies [17a183c]
+- Updated dependencies [13620d9]
+- Updated dependencies [97bd30b]
+- Updated dependencies [459c33f]
+  - @nocobase/agent-protocol@0.1.0-beta.3
+  - @nocobase/app-cli@1.0.0-beta.18
+  - @nocobase/app-plugin-authentication@2.0.0-beta.4
+  - @nocobase/app-cli-client@0.1.0-beta.2
+
 ## 0.1.0-beta.4
 
 ### Minor Changes

package/README.md

@@ -2,6 +2,8 @@
 
 Agents for NocoBase applications: the agents people configure, their runs, and people's conversations with agents. Runner agents run on the runners people connect (each a runtime: a runner on a server, a VM or someone's own device), which this plugin registers, hands work to and serves the runner and CLI tarballs for; the wire protocol runners and the application's CLI speak is `@nocobase/agent-protocol`, and the runner is `@nocobase/agent-runner` (`nocobase-runner`).
 
+Workspace cleanup supports optional application bindings for legacy subject keys (`SubjectWorkspaces.resolveKeys`) and trusted merged PR head evidence by repository (`SubjectWorkspaces.commits`). Ownership must be confirmed from saved runs; settlement never bypasses local tracked-change, commit or submodule checks. Runtime diagnostics require the existing machine-information permission and distinguish ended work, allowed cleanup and retained work, with the workspace report's timestamp. See [workspace cleanup integration](https://github.com/nocobase/nocobase/blob/v3-develop/packages/plugins/app-plugin-agents/docs/workspace-cleanup.md) for the protocol, binding rules and compatibility behavior.
+
 An agent is one of two types, chosen when it is created and never changed. A **work** agent drives a coding tool on a runner, in a working directory. An **online** agent talks to a model of one of the model services this plugin keeps and is run by the application itself, on the server: it needs no runner, answers in seconds, and its tools are the application's commands. Both share everything else: runs, conversations, transcripts, permissions, usage and reports.
 
 The plugin knows no domain of its own beyond conversations: what agents work on (subjects), the scopes variables are kept in, the business actions an agent may be given, the presets to start an agent from and the report pages are the application's, which contributes them through the extension points below; the CLI's business commands are the application's own routes, each described with `cliRoute()`. The assembling application does it in `server/agents` and `client/agents`. With nothing contributed, the plugin still runs agents in conversations on runners, with its own commands.
@@ -12,13 +14,13 @@ Applications forward the `notice` event of type `run_secrets_not_allowed` to the
 
 Repository access providers that mint credentials in `prepare` implement the idempotent `discard(run, prepared)` hook to revoke them when the claim is skipped or rolled back. It runs outside the transaction and receives the same prepared value as `forRun`. The application owns code host credentials and their revocation API; providers without this hook cannot revoke externally issued credentials.
 
-- **Agents** (`agAgents`): who an agent is and how it works: its name, description and avatar, optional instructions (the last layer of its brief, preferences that never override the rules or the task), its type (`runner` or `online`, immutable: a patch naming one is refused), the business actions it may perform, who may wake it and how many attempts a run gets. Which tool or model it works with is an ordered list, `modelEntries`, whose first entry is its default, each entry with its own reasoning effort (`effort`, null for the default). A runner agent's entries pair a coding tool with a model (null for the tool's default) and an effort its tool takes (`TOOL_EFFORTS` of `@nocobase/agent-protocol`), and it has its skills, its tool policy, its own variables, optionally the runners it may run on, and how many runs it may have at once; it has at least one entry. An online agent's entries pair a model service with one of its models (an entry is checked against what the model catalog offers when it is added) and an effort among `ONLINE_EFFORTS`, and it has none of a runner's settings; an online agent with no entry is not configured yet: it is listed as needing a model and left out of `GET /api/agents/available` until it has one; it is offered no business action meant for runner agents only (`AgentActionOption.types`). Its configuration carries a `revision`, raised by every change (editing, archiving, restoring): `PATCH /api/agents/:agentId` names the revision it was made against (`expectedRevision`) and is refused with 409 `REVISION_CONFLICT` (`metadata.revision` the current one) when someone saved the agent since, and a patch that changes nothing raises nothing. Every change is kept in its history (`agAgentChanges`, `GET /api/agents/:agentId/history`, with `afterRevision` for what came after a revision): who, when, and the fields that changed with their values before and after, except its variables, which are named with whether they were added, changed or removed, never valued. Archiving an agent withdraws its queued runs at once; archiving and deleting it announce `agent.removed`.
+- **Agents** (`agAgents`): who an agent is and how it works: its name, description and avatar, optional instructions (the last layer of its brief, preferences that never override the rules or the task), its type (`runner` or `online`, immutable: a patch naming one is refused), the business actions it may perform, who may wake it and how many attempts a run gets. Which tool or model it works with is an ordered list, `modelEntries`, whose first entry is its default, each entry with its own reasoning effort (`effort`, null for the default). A runner agent's entries pair a coding tool with a model (null for the tool's default) and an effort its tool takes (`TOOL_EFFORTS` of `@nocobase/agent-protocol`), and it has its skills, its tool policy (of which runners use only the idle timeout and the turn limit: they run agents with full access, see the agent-runner README), its own variables, optionally the runners it may run on, and how many runs it may have at once; it has at least one entry. An online agent's entries pair a model service with one of its models (an entry is checked against what the model catalog offers when it is added) and an effort among `ONLINE_EFFORTS`, and it has none of a runner's settings; an online agent with no entry is not configured yet: it is listed as needing a model and left out of `GET /api/agents/available` until it has one; it is offered no business action meant for runner agents only (`AgentActionOption.types`). Its configuration carries a `revision`, raised by every change (editing, archiving, restoring): `PATCH /api/agents/:agentId` names the revision it was made against (`expectedRevision`) and is refused with 409 `REVISION_CONFLICT` (`metadata.revision` the current one) when someone saved the agent since, and a patch that changes nothing raises nothing. Every change is kept in its history (`agAgentChanges`, `GET /api/agents/:agentId/history`, with `afterRevision` for what came after a revision): who, when, and the fields that changed with their values before and after, except its variables, which are named with whether they were added, changed or removed, never valued. Archiving an agent withdraws its queued runs at once; archiving and deleting it announce `agent.removed`.
 - **Runners** (`agRunners`), shown as runtimes: registered with a one-time token (`POST /api/agents/runners/registrationTokens`, or `pnpm nocobase agents runner-token`). Anyone may add a personal runner (`ownerOnly`: it runs only work its owner started) and later share it with the team; adding a team runner needs `agents.runners` manage. A runner reports its system, its features, its coding tools with versions and whether each is signed in, and what its owner's local policy lets it take (`policy`); it authenticates with its key (`agRunnerCredentials`), sends heartbeats and long-polls for work. Which of its coding tools it is offered work for is chosen on the web (`enabledTools`, null for every tool), carried from "Add runtime" on the registration token (`agRegistrationTokens`). A runner speaking a protocol this application does not serve is kept connected as `upgrade_required`: it gets no work, has what it holds released, and its owner is told once per protocol through the `notice` event (`runner_upgrade_required`; `notice.cleared` once it no longer holds). Only its owner changes a runner (its name, slots, coding tools and trust), because it is their machine with their tools' sign-ins and credentials; a manager of runners changes only a runner whose owner can no longer act (none recorded, or disabled or deleted in the application's directory, `people.provide({ inactive })`). A manager of runners may still revoke anyone's runner in an emergency, and delete it once revoked: its owner is told (`runner_revoked`) and the application's `security` log records who did it. A runner whose owner can no longer act (`people.provide({ inactive })`) is refused with `RUNNER_OWNER_DISABLED`. A runner fits an agent's run only when its owner's local policy lets it take that agent's runs, on that subject, with those repositories; `availability` and the agents list count only such runners. Every heartbeat answer announces workspace reports (`workspaces`): a runner reports the working directories it keeps for this application (`POST /api/agents/runners/workspaces`, each with the last run that worked there and whether it holds unpushed work, with the free space on the disk holding them) and is told which of those runs belong to subjects whose work is over (`remove`) or goes on (`keep`), as each subject kind's `workspaces.settled` says; a kind without it never counts as over, and only the runner's own runs are answered for. The last report is kept on the runner (`agRunners.workspaceUsage`, `Runner.workspaceUsage`) with each directory's subject and what was decided, for the Runtimes page.
 - **The claim**: one long-poll (`POST /api/agents/runners/claim?wait=true`) answers `jobs` and `runs` together, at most `free` items, from the runner's slots, which jobs and runs share (`slots`): jobs first. A heartbeat reconciles both, releasing what the server no longer thinks the runner holds and asking it to stop what was cancelled.
 - **Jobs** (`agJobs`, `agJobEvents`): only for the off-by-default runner build method (such as an application's `acme.builds.method: runner`): a `build` (check out a commit, run an administrator's command, upload its outputs), of kinds the application registers (`jobs.register(kind, { validate, prepare, onEvent, onDone })`, then `jobs.enqueue`, `get` and `watch`). A runner takes a job only when it reports `jobs.build`, someone turned on "Takes build jobs" (`acceptJobs`), it is shared or belongs to who started the job, and its policy lets it check out the job's repository. Jobs retry `runnerOffline`, `leaseExpired`, `startTimeout`, `checkoutFailed` and `policyRefused` while attempts remain, and open the stored variables they name through this plugin's variables at claim, audited as delivered.
-- **Distribution**: the application serves two products as standalone tarballs that bundle Node, one per platform (`server/distribution`): its CLI (`agents.cli.name`, such as `acme`) and the runner, `nocobase-runner` (`RUNNER_PRODUCT`). `pnpm nocobase cli build` of `@nocobase/app-cli` packs the CLI the application's `package.json` declares under `nocobase.cli`, and `cli build --runner` the runner, each into a directory of its own, `storage/runners/dist/<channel>/<product>/`, with a `manifest.json` of every file's SHA-256 and size, so CI builds them as separate artifacts mounted into storage. The install script installs the CLI under `~/.local/share/<cli>`: by default the CLI alone, with a download token any signed-in person mints (`POST /api/agents/dist/downloadTokens`, `agDownloadTokens`: the CLI for one platform, three downloads within 30 minutes), as `curl -fsSL <server>/api/agents/dist/installScript | sh -s -- --token <token>`; "Add runtime" shows the same line with `--runner --server <server>` and a registration token, which also installs `nocobase-runner` under `~/.local/share/nocobase-runner`, runs `nocobase-runner register` and `nocobase-runner service install` (an application that serves no CLI still gets its runtime). A token of the other kind fails before anything is installed. A runner reports the product it runs as on registration and every heartbeat (`agRunners.product`), and the heartbeat answer carries an `upgrade` notice when the channel serves a newer version of that product for the runner's platform; a runner that reports none (one from before) is offered no update, and the Runtimes page says to install it again.
+- **Distribution**: the application serves two products as standalone tarballs that bundle Node, one per platform, or as one universal tarball (`cli build --universal`) that runs on the machine's Node.js 24 or newer and is served to every platform without one of its own, answered with `universal: true` (`server/distribution`): its CLI (`agents.cli.name`, such as `acme`) and the runner, `nocobase-runner` (`RUNNER_PRODUCT`). `pnpm nocobase cli build` of `@nocobase/app-cli` packs the CLI the application's `package.json` declares under `nocobase.cli`, and `cli build --runner` the runner, each into a directory of its own, `storage/runners/dist/<channel>/<product>/`, with a `manifest.json` of every file's SHA-256 and size, so CI builds them as separate artifacts mounted into storage, or an application builds them into its own build output and points `agents.dist.dir` there, as NocoBase Studio does. The install script installs the CLI under `~/.local/share/<cli>`: by default the CLI alone, with a download token any signed-in person mints (`POST /api/agents/dist/downloadTokens`, `agDownloadTokens`: the CLI for one platform, three downloads within 30 minutes), as `curl -fsSL <server>/api/agents/dist/installScript | sh -s -- --token <token>`; "Add runtime" shows the same line with `--runner --server <server>` and a registration token, which also installs `nocobase-runner` under `~/.local/share/nocobase-runner`, runs `nocobase-runner register` and `nocobase-runner service install` (an application that serves no CLI still gets its runtime). A token of the other kind fails before anything is installed. A runner reports the product it runs as on registration and every heartbeat (`agRunners.product`), and the heartbeat answer carries an `upgrade` notice when the channel serves a newer version of that product for the runner's platform; a runner that reports none (one from before) is offered no update, and the Runtimes page says to install it again. A product the directory has no current version of may be named on npm instead (`agents.dist.npm`: its package and exact version, which a machine installs with the Node.js 24 or later it already has): the resolve route answers `{ kind: 'npm', product, version, package, channel }` to a caller that sends `accept=npm`, and a heartbeat answer carries `npmUpgrade` to a runner with the `npm` feature when it runs an older version. Everyone else is answered as before (404, no update), and a product the directory has is always served from it. The install script, `<cli> update` and the runner's self-update all ask with `accept=npm` (the runner declares `npm`) and install an npm answer with the machine's npm into the same layout as a tarball: `npm install --prefix <prefix>/versions/<version> --no-save --no-audit --no-fund --omit=optional <package>@<version>`, then a launcher at `versions/<version>/bin/<command>` that starts `node_modules/.bin/<command>` on `<prefix>/node` (`npmLauncherScript` of `@nocobase/app-cli-client/install`).
 
-- **Runs** (`agRuns`): one agent working on one subject, keyed by (agent, subject, thread), with the agent's type kept on the run (`agentType`). A subject kind takes the agent types its binding names (`agentTypes`, runner only by default); a run of another type is refused (`AGENT_TYPE_NOT_ALLOWED`). New work joins the run already on it as the same person (`actorUserId`) while that run can still be told, else that person's queued one, else starts a new run: work woken by different people never shares a run, so it neither borrows another's identity nor waits for a runner that will not take it. Runs of one key are still claimed one at a time, whoever they work as. Queued runs are claimed by `priority` (lower first; 0 by default), then oldest first; a run given a `fireAt` is not claimed before that moment. Work merged into a queued run raises it to the more urgent priority and the earlier moment of the two. Runners take only runner agents' runs. A claim hands a run to a runner that fits in one transaction: one of the agent's tools enabled, installed and signed in there (the run takes the first entry of the agent's list whose tool is, recorded on the run as `tool` and `model` and passed to the tool; a model the tool's account cannot use fails the run `modelUnavailable`), the agent naming no runner or naming this one, the runner shared with the team or owned by the person who woke the agent, its features covering what the run needs (worked out from the payload: checkouts, directories, skills, secrets), a team runner when one of the variables the run gets is for team runners only (`teamRunnersOnly`), and a free slot within the agent's concurrency. The variables are checked and opened in the claim's transaction, so the runner receives what was checked; a personal runner left out for them notes on the run which variables asked for a team runner (`teamOnlyVariables`, cleared when the run is taken, requeued or given new input), and its wait is `secretsNotAllowed` with those variables. Before a run exists, `eligibility` (`runnersFor`, `canClaim`, `mayQueue`, `teamOnly`) answers by the same rules whether a runner would take an agent's work done as a person, with the scopes and features the caller names; `availability` and `GET /api/agents/available` use it for the caller. A working directory that is a directory on one runner pins the run to that runner, one run at a time per directory. The claim renders the brief (kept per run, `agRunBriefs`), mints a run token, and hands over the working directories, the merged variables, the skills and the CLI to install. Events, usage and branches are recorded as the runner reports them; completing requires every input to be handled.
+- **Runs** (`agRuns`): one agent working on one subject, keyed by (agent, subject, thread), with the agent's type kept on the run (`agentType`). A subject kind takes the agent types its binding names (`agentTypes`, runner only by default); a run of another type is refused (`AGENT_TYPE_NOT_ALLOWED`). New work joins the run already on it as the same person (`actorUserId`) while that run can still be told, else that person's queued one, else starts a new run: work woken by different people never shares a run, so it neither borrows another's identity nor waits for a runner that will not take it. Runs of one key are still claimed one at a time, whoever they work as. Queued runs are claimed by `priority` (lower first; 0 by default), then oldest first; a run given a `fireAt` is not claimed before that moment. Work merged into a queued run raises it to the more urgent priority and the earlier moment of the two. Runners take only runner agents' runs. A claim hands a run to a runner that fits in one transaction: one of the agent's tools enabled, installed and signed in there (the run takes the first entry of the agent's list whose tool is, recorded on the run as `tool` and `model` and passed to the tool; a model the tool's account cannot use fails the run `modelUnavailable`), the agent naming no runner or naming this one, the runner shared with the team or owned by the person who woke the agent, its features covering what the run needs (worked out from the payload: checkouts, directories, skills, secrets), a team runner when one of the variables the run gets is for team runners only (`teamRunnersOnly`), and a free slot within the agent's concurrency. The variables are checked and opened in the claim's transaction, so the runner receives what was checked; a personal runner left out for them notes on the run which variables asked for a team runner (`teamOnlyVariables`, cleared when the run is taken, requeued or given new input), and its wait is `secretsNotAllowed` with those variables. Before a run exists, `eligibility` (`runnersFor`, `canClaim`, `mayQueue`, `teamOnly`) answers by the same rules whether a runner would take an agent's work done as a person, with the scopes and features the caller names; `availability` and `GET /api/agents/available` use it for the caller. A working directory that is a directory on one runner pins the run to that runner, one run at a time per directory. The claim renders the brief (kept per run, `agRunBriefs`), mints a run token, and hands over the working directories, the merged variables, the skills and the CLI to install. Events, usage and branches are recorded as the runner reports them; completing requires every input to be handled. A runner that finds the subject's working directory held by another live run reports `workspaceBusy`: the run goes back to the queue, freeing its slot, and is tried again after 30 seconds, doubling up to two minutes; these waits do not count against the agent's attempts, and the run fails `workspaceBusy` only once it has waited six hours (`WORKSPACE_WAIT_LIMIT_MS`).
 - **Run requests** (`agRunRequests`): work someone asked of an agent on a subject another person answers for, waiting for that person to confirm it (see "Work someone else causes" below).
 - **Workload** (`runs.workload({ subjectKind, limit? })`, `shared/runs.ts`): the open runs on one kind of subject for a board of work, without claiming anything. Held runs come with their runner, the newest input's trigger and their newest text, tool call, status or error (`lastActivity`); queued runs with their place in the claim order (among the runs claimable now, and among the agent's) and why they wait, by the claim's own rules in its order (`RUN_WAIT_REASONS`: the agent archived, delayed until a moment, no runner online, the agent's named runners offline, its tool not signed in anywhere, only other people's personal runners, missing features, only personal runners whose owner may not receive the run's variables, the same work already held, the agent's concurrency full, every fitting runner busy, preparation retrying, or next). A wait is a code and the values its words need (`params`), never text: the client words it with `formatRunWait(t, wait)` from `client/runs.ts`, in this plugin's namespace (`runWait.reasons.<reason>`), which an application may override in its locale file or replace with its own formatter. It also answers each agent's load (held, queued, its limit, whether a runner could take its work) and the runners' (online, holding work, slots and slots used). It reads a bounded number of tables, never one query per subject; the caller decides what of it a person may see.
 - **Online runs** (`server/online`): every application instance runs an executor that takes online agents' runs through the same claim transaction (`claims.claimServer`, the run held by `server:<instance>`, so two instances never take one run), with the entry of the agent's list the subject asks for (a conversation's choice, `ConversationPatch.model`, while the agent still lists it) or else its first, recorded on the run as `modelService` and `model`; a failing model fails the run, nothing falls back to another entry and reports through the same lifecycle a runner's requests reach (start, events, lease, complete, fail, cancel-ack), so conversations, transcripts, retries, failed-run handling and the sweeper are unchanged. No slots and no per-agent concurrency limit apply. A run is a loop of model calls through the plugin's model gateway (`online.gateway`, below): each streams its text, which a conversation shows as a draft message growing in place, and ends with the tool calls to make and what the call used, recorded at once as the run's usage (tool `chat`, the model the provider named). It has two tools (`online/sandbox.ts`): `bash`, a sandboxed shell (`just-bash`, in process: no real processes, no network, a 10-second deadline per command, its output cut to what the model reads; the build bundles the part of `just-bash` it uses into `dist/server/vendor/just-bash.js` with `THIRD_PARTY_LICENSES.txt` beside it, so the plugin does not depend on `just-bash`, and leaves out Python, JavaScript, SQLite, curl, html-to-markdown and xz/zstd archives, which answer that they are not available), and `skill`, which reads one of the run's skills (its SKILL.md and its file tree). The shell mounts the run's skills read-only at `/skills/<slug>/` (text only, at most 5 MB per run; binary files are listed but not readable, and scripts are never run) with `/tmp` as scratch, and carries the application's CLI (`online/cli-command.ts`): `acme`, built from the run's command manifest (the application's `GET /api/cli/manifest`, the actions of the person who woke the agent that the agent is configured with), each command one request sent through the application itself with the run's token, so the route checks the permission again; the line is read by the CLI's own parser (`@nocobase/app-cli-client/parse`), so flags, `--<flag>-file` and the body's `--file` (read from the shell's files), `--from-env` (the shell's exported variables), usage errors and exit codes are the CLI's; help and `acme docs` work from the manifest, `--json` prints the cli-envelope, and commands that send or save files are refused. Skills every online run gets besides its own (the CLI's) are registered with `online.skills`. A refused or failed call is a result the model reads. Input that arrives meanwhile is answered in the same run; a run that calls tools for more than `maxSteps` model calls fails `stepLimit`. The gateway's errors become failure reasons: `config` → `modelUnavailable`, `auth` → `toolAuth`, `quota` → `toolQuota`, `rateLimit` → `toolRateLimit` and `network` → `toolNetwork` (both retried while attempts remain), `contextOverflow` → `contextOverflow`, anything else `unknown`. A cancel request aborts the model call within a second; at shutdown an instance hands its runs back (`runnerOffline`), and one that stops renewing its leases loses them to the sweeper (`leaseExpired`). The brief of an online run has a system layer of its own (`onlineSystemLayer`): the CLI in its shell instead of a terminal, no workspace, its skills by name and description (`onlineSkillsSection`), and links to the pages of what it relied on.
@@ -98,25 +100,25 @@ Realtime announcements carry no content: `agents:runs:<runId>` when a run's stat
 
 Everything the application contributes goes through `agentsToken` (`server/tokens.ts`) at boot. Text people read is an `I18nText` (`{ key, ns }`, `shared/i18n`) in the contributor's own namespace.
 
-| Extension point                                                       | What the application gives                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       |
-| --------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
-| `subjects.register(binding)`                                          | A kind of subject runs work on: `kind`, `title`, `triggers` (what `input.payload.trigger` values mean, for the run panel), `preview` (a `SubjectSample`: the assembly of a made-up subject of the kind, its values marked with `sampleValue`, offered as a scenario of "Preview full prompt"), `context.assemble` (the brief's task and context, the turn, the working directories, the scopes, and `guidance`: the subject's own lines of the rules and of the environment check), `sink.onRunFinished`, `queuedExpiryMs` (how long a run may wait for a runner; forever without it), `reports.describe` (a subject's label, whether the person may see it, and its `group`), and `agentTypes` (`['runner']` by default; a kind whose runs need no working directory adds `online`). The claim tells `assemble` how the agent reaches the commands (`claim.dialect`, `cli` or `tools`): name them with `commandRef(dialect, cli, id, flag?)` (`acme issue get` in both: an online agent runs the CLI in its shell, writing files under `/tmp`). |
-| `scopes.register(kind)`                                               | A scope of variables and default skills (`key`, `title`, `description`, `access(scopeId, userId)`). `agent` is reserved; `workdir` is a core key the application registers to decide who may see and change a working directory's.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               |
-| `actions.provide(source)`                                             | The business actions an agent may be configured with (`key`, `group`, `title`, `groupTitle`, `description`, `defaultOn` for the new-agent dialog), and those never granted to an agent, listed only to show the boundary (`grantable: false` with a `reason`).                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   |
-| `presets.register(preset)`                                            | A role a new agent can start from (`name`, `nameText`, `description`, `descriptionText`, `instructions`, `actions`).                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             |
-| `gate.set(gate)`                                                      | Who holds which business actions: an `ActionGate` answering `allowed(identity)` for a person or a run, and optionally `consultable(action)` for what a consultation may keep besides reading. `gate.allowed` and `gate.reach` answer for a caller; the gate also bounds what a run may do over the API.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          |
-| `conversations.sources.register(source)`                              | A place conversations start from besides the panel (`POST …/chat/start` takes `source` and the first message as the agent should read it).                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       |
-| `conversations.contextKinds.register(kind, resolver)`                 | A kind of object a page context may reference, resolved for the message's owner.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |
-| `conversations.rules.provide(rules)`                                  | Rules and sections added to the system layer of conversation runs.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               |
-| `conversations.deliver(tx, id, news)`, `conversations.lock(conn, id)` | A `news` notice (`type`, English `title`, `params`) written to a conversation, with input that wakes its agent.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  |
-| `people.provide(source)`                                              | The application's directory: names, whom to pick from, and who can no longer act (`inactive`: their runners stop).                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               |
-| `events.on('agent.removed', listener)`                                | An agent was archived or deleted (`agentId`, `name` then, `reason`, `byUserId`), after the transaction that withdrew its queued runs commits: the application lets go of the work it gave the agent. The assembling application clears it as executor of unfinished issues (`server/agents/removal.ts`).                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                         |
-| `events.on('notice', listener)`                                       | People the plugin wants told (`AgentsNotice`: `key`, `type`, `userIds`, `subject`, English `title` and `body`, `params`): runner notices to their owner, `run_secrets_not_allowed` to a run's actor and owner, and `run_request_expired` to its requester. Subjects are `runner`, `run` or `runRequest`; `notice.cleared` names one that no longer holds.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        |
-| `jobs.register(kind, registration)`                                   | A kind of build job, for the off-by-default runner build method (see Jobs above).                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                |
-| `reporting.usage`, `reporting.runFigures`, `reporting.range`          | What runs used and cost, grouped by agent, person, `group`, `subject`, day, model, tool or agent `type`, and how the runs of a range went with their usage by type (`usageByType`) and day by day (`daily`: runs by outcome, cost by type), for the application's report pages. The plugin serves usage over HTTP for its usage page (`GET /api/agents/usage`, behind the `usage` page grant; every run for a reader of agents, else the caller's own; `series=true` breaks each day of `daily` down by the grouping).                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           |
-| `briefs.sections.register(provider)`                                  | Sections added to every brief's context layer after the subject's own context (`key`, `order`, `section(conn, claim, assembly)` answering Markdown or null), in claims and in brief previews. The context layer is outside the session fingerprint, so a section that changes does not end a resumable session. Database reads only.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             |
-| `mounts.register(provider)`                                           | Directories of files placed beside the agent (`name`, `forRun(conn, { claim, assembly, session, sessionKey })` answering `{ hash, target, note?, resumeNote? }` or null, and `bundle(conn, { runId })`). Offered at claim only to runners announcing the `mounts` feature, never required, so an older runner runs without them; served at `GET /api/agents/runners/runs/:runId/mounts/:name` while the runner holds the run. A mount's hash stays out of the session fingerprint: a resumed run gets its `resumeNote` in the turn instead.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      |
-| `repoAccess.register(provider)`                                       | Per run, in the claim's transaction: who the run's commits name and the short-lived credentials its checkouts push with (`forRun(conn, { claim, repos })` answering `RunGit` or null). It may read from elsewhere in an optional `prepare(run)` before the transaction.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          |
+| Extension point                                                       | What the application gives                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                     |
+| --------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `subjects.register(binding)`                                          | A kind of subject runs work on: `kind`, `title`, `triggers` (what `input.payload.trigger` values mean, for the run panel), `preview` (a `SubjectSample`: the assembly of a made-up subject of the kind, its values marked with `sampleValue`, offered as a scenario of "Preview full prompt"), `context.assemble` (the brief's task and context, the turn, the working directories, the scopes, and `guidance`: the subject's own lines of the rules and of the environment check), `sink.onRunFinished`, `queuedExpiryMs` (how long a run may wait for a runner; forever without it), `reports.describe` (a subject's label, whether the person may see it, and its `group`), and `agentTypes` (`['runner']` by default; a kind whose runs need no working directory adds `online`). The claim tells `assemble` how the agent reaches the commands (`claim.dialect`, `cli` or `tools`): name them with `commandRef(dialect, cli, id, flag?)` (`acme issue get` in both: an online agent runs the CLI in its shell, writing files under `/tmp`).                                                                                               |
+| `scopes.register(kind)`                                               | A scope of variables and default skills (`key`, `title`, `description`, `access(scopeId, userId)`). `agent` is reserved; `workdir` is a core key the application registers to decide who may see and change a working directory's.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             |
+| `actions.provide(source)`                                             | The business actions an agent may be configured with (`key`, `group`, `title`, `groupTitle`, `description`, `defaultOn` for the new-agent dialog), and those never granted to an agent, listed only to show the boundary (`grantable: false` with a `reason`).                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |
+| `presets.register(preset)`                                            | A role a new agent can start from (`name`, `nameText`, `description`, `descriptionText`, `instructions`, `actions`).                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           |
+| `gate.set(gate)`                                                      | Who holds which business actions: an `ActionGate` answering `allowed(identity)` for a person or a run, and optionally `consultable(action)` for what a consultation may keep besides reading. `gate.allowed` and `gate.reach` answer for a caller; the gate also bounds what a run may do over the API.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        |
+| `conversations.sources.register(source)`                              | A place conversations start from besides the panel (`POST …/chat/start` takes `source` and the first message as the agent should read it).                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                     |
+| `conversations.contextKinds.register(kind, resolver)`                 | A kind of object a page context may reference, resolved for the message's owner.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               |
+| `conversations.rules.provide(rules)`                                  | Rules and sections added to the system layer of conversation runs.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             |
+| `conversations.deliver(tx, id, news)`, `conversations.lock(conn, id)` | A `news` notice (`type`, English `title`, `params`) written to a conversation, with input that wakes its agent.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                |
+| `people.provide(source)`                                              | The application's directory: names, whom to pick from, and who can no longer act (`inactive`: their runners stop).                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             |
+| `events.on('agent.removed', listener)`                                | An agent was archived or deleted (`agentId`, `name` then, `reason`, `byUserId`), after the transaction that withdrew its queued runs commits: the application lets go of the work it gave the agent. The assembling application clears it as executor of unfinished issues (`server/agents/removal.ts`).                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       |
+| `events.on('notice', listener)`                                       | People the plugin wants told (`AgentsNotice`: `key`, `type`, `userIds`, `subject`, English `title` and `body`, `params`): runner notices to their owner, `run_secrets_not_allowed` to a run's actor and owner, and `run_request_expired` to its requester. Subjects are `runner`, `run` or `runRequest`; `notice.cleared` names one that no longer holds.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      |
+| `jobs.register(kind, registration)`                                   | A kind of build job, for the off-by-default runner build method (see Jobs above).                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              |
+| `reporting.usage`, `reporting.runFigures`, `reporting.range`          | What runs used and cost, grouped by agent, person, `group`, `subject`, day, model, tool or agent `type`, and how the runs of a range went with their usage by type (`usageByType`) and day by day (`daily`: runs by outcome, cost by type), for the application's report pages. The plugin serves usage over HTTP for its usage page (`GET /api/agents/usage`, behind the `usage` page grant; every run for a reader of agents, else the caller's own; `series=true` breaks each day of `daily` down by the grouping).                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                         |
+| `briefs.sections.register(provider)`                                  | Sections added to every brief's context layer after the subject's own context (`key`, `order`, `section(conn, claim, assembly)` answering Markdown or null), in claims and in brief previews. The context layer is outside the session fingerprint, so a section that changes does not end a resumable session. Database reads only.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           |
+| `mounts.register(provider)`                                           | Directories of files placed beside the agent (`name`, `forRun(conn, { claim, assembly, session, sessionKey })` answering `{ hash, target, note?, resumeNote? }` or null, and `bundle(conn, { runId })`). Offered at claim only to runners announcing the `mounts` feature, never required, so an older runner runs without them; served at `GET /api/agents/runners/runs/:runId/mounts/:name` while the runner holds the run. A mount's hash stays out of the session fingerprint: a resumed run gets its `resumeNote` in the turn instead.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    |
+| `repoAccess.register(provider)`                                       | Per run, in the claim's transaction: who the run's commits name and the short-lived credentials its checkouts push with (`forRun(conn, { claim, repos, onDemand })` answering `RunGit` or null). It may read from elsewhere in an optional `prepare(run, { onDemand })` before the transaction. For a runner with the `gitCredentials` feature (`onDemand`), a provider that implements `issue(request)` lists its repositories in `RunGit.onDemand` instead of minting credentials at the claim: the runner then asks `POST /api/agents/runners/runs/:runId/gitCredentials` whenever git needs one, and the plugin calls `issue` outside any transaction (15 s at most) only while that runner holds that attempt of the run under a live lease, for a URL the claim listed, compared exactly. `issue` answers `{ username, password, expiresAt }`, null when the repository is not its own, or throws `RepoAccessError('unavailable' \| 'denied', message)` with a message safe to show; with `refresh` it issues a new credential rather than a cached one. Issued credentials are never stored and are redacted from what the run reports. |
 
 `GET /api/agents/vocabulary` hands the browser what the application contributed: subjects (title, triggers, preview), conversation sources, and scopes (title, description).
 
@@ -125,7 +127,14 @@ const agents = container.resolve(agentsToken);
 agents.subjects.register({
   kind: 'ticket',
   title: { key: 'subjects.ticket', ns: '@acme/app' },
-  context: { assemble: (conn, claim) => /* task, context, working directories; database reads only */ },
+  context: {
+    // Optional: the subject's current policy, in the claim transaction. Rejecting cancels without consuming a retry.
+    // Also asked before input joins a working run or is delivered to it; rejected input is kept from that run.
+    admit: (conn, claim) => /* null, or { reason, detail? }; database reads only */,
+    // Optional: the inputs a working run should act on; the rest are marked handled instead of delivered.
+    selectInputs: (conn, claim) => /* a subset of claim.inputs; database reads only */,
+    assemble: (conn, claim) => /* task, context, working directories; database reads only */,
+  },
   sink: { onRunFinished: (tx, run) => /* tell people how the run ended */ },
 });
 await agents.runs.enqueue({ agentId, subject: { kind: 'ticket', id }, actorUserId, priority: -2, input });
@@ -189,6 +198,8 @@ agents:
     dir: /srv/runners-dist # relative to the application root; storage/runners/dist by default
     channel: stable
     versions: { acme: 0.1.0 } # pin a product instead of the channel's highest
+    npm: # optional; a product with no tarball in dir is named on npm instead, to callers that understand it
+      nocobase-runner: { package: '@nocobase/agent-runner', version: 1.0.0 } # an exact version, never a range
   server: # optional; online agents' runs, which every instance runs itself
     enabled: true # false leaves them to the other instances
     maxSteps: 16 # model calls an online run may make
@@ -214,7 +225,7 @@ The plugin registers no routes of its own: an application mounts its pages and j
 
 - `@nocobase/app-plugin-agents/client/routes` exports `agentsRoute` (`/agents`, with the `new` dialog and the `:agentId` page), `runtimesRoute` (`/runtimes`, with the `connect` dialog), `skillsRoute` (`/skills`, with `new` and `:skillId`) and `usageRoute` (`/usage`: what runs used and cost over a date range, filtered by group, agent and person and summed by one of the groupings (`?groupBy=`, agent by default), with a daily chart of tokens or cost above the table, stacked by the top five agents or models when grouped by those (the usage route's `series`), its group and subject named and linked by the vocabulary's `groupTitle`, `path` and `groupPath`; for who reads `agents.prices` a "Set prices" header button opens the prices sheet, `?prices=1`: online models by service and model, coding tools by the models their runs report, each tool with its subscription switch and price rules, changed by who manages it; the note on missing prices links to it). Each page renders its own heading, and stands behind a page grant of the same id as its route name (`agents`, `runtimes`, `skills`, `usage`, exported as `PAGES` from `shared/access`); a page grant only opens the page, and what it shows is decided by the admin API on the settings items. It also exports `modelsRoute` (`/models`), which stands behind `agents.services` read instead: the model services (a page header with "Add service", the system default chat model's select, then a table with one row per service: its name and host, provider type, status and a menu to edit it, turn it on or off or delete it; "Add service" and clicking a row open one dialog with a single form saved at once: provider type when adding, name, base URL, the write-only key as a `SecretInput` (`client/components/secret-input.tsx`: a password field whose empty value keeps the saved key), an OpenCode base URL's note on which provider type serves which of its model families (its session header is sent automatically), connection test, models fetched from the provider or added by id and checked, each with its kind, changeable before and after it is checked, and a Test that checks it as that kind, and an on/off switch), changeable by who manages `agents.services`.
   - Runtimes (on `/api/agents/runners`): one overview row per runtime — its name with its system, its state with the slots in use ("Busy 1/1", "Offline · 3 hours ago"), its coding tools by sign-in, personal or team, its runner version (marked "Upgradable" when a newer version of the product it runs as is served, with `nocobase-runner update`, or `<cli> runner update` for a CLI that carries the runner; the runner also updates itself) and when it was last seen — with a "…" menu (Edit, then revoke or delete). A row opens the runtime's sheet: General (name, concurrent runs, personal or team after a warning, and "Allow build jobs" only when the application gives runners jobs, as an application's off-by-default runner build method does), Tools (a switch per reported tool with its version, sign-in and, when the API sent it, its path as small text), Local policy (read only: what its owner's policy on the machine lets it take) and Recent runs (`GET /agents/runners/:runnerId/runs`). Only its owner changes it (the managers of runners only a runner whose owner can no longer act); a manager of runners sees someone else's read only, with revoke or delete as the only menu items. Its owner, the managers of runners and anyone who may use an agent get its host name and its tools' paths from the API, everyone else neither. "Add runtime" asks who it works for (team only for managers of runners), which coding tools it may run (all by default) and its max concurrent runs (1 by default, carried by the token; a runner registered with its own `--slots` keeps that), then shows the one-line install and the `nocobase-runner register` command with a one-time token (copy buttons, expiry), and waits until the runtime connects, then shows the coding tools it reported.
-  - Agents: the list (type, tools, the default model and how many more, where it runs with the runners online for it, or "on the server" and whether its model is offered, active runs, visibility; a type filter; archived ones on request; agents everyone can use first, the application's own in the order it added them, then the viewer's own (`AgentSummary.owned`), then the ones shared with them, each group by the name shown) and an agent's page, whose header sums it up in one line (type, tool or model, where it runs, free or busy, owner), with four tabs kept in `?tab=`; the new-agent dialog asks for the type first, then the fields of that type (its tools and models, model services and models for an online agent from `GET /api/agents/models`; with none, the agent uses the system default chat model, which the dialog names with a link to change it, or says none is offered). General: basics, avatar and instructions with "Preview full prompt" (a scenario switch among the subject kinds that offer a sample, the application's first and a conversation, `?scenario=` on the API; it shows the system prompt in one, with the agent's own prompt marked at its end, and the first message, all rendered on a made-up subject whose values are marked `[sample]`), and who may use it. Capabilities: the tools and models, a compact ordered list (one header row, then one row per entry) whose first row is the default, with rows added, removed and moved up or down (a runner agent's rows a coding tool, a model typed freely with the tool's common models suggested, and an effort among the tool's; an online agent's rows a model service, a model and an effort, each with a Test button; the new-agent dialog uses the same list), skills, the business capabilities grouped by the application's groups with a description each, and the ones never granted to an agent greyed out with the reason (`AgentActionOption.grantable: false`), and whether it confirms before changing data. Runtime (runner agents only): where it runs (any runner, or named ones, and concurrency), the command allowlist and denied patterns, and its environment variables (write-only, revealing them is audited, saved row by row). Editable when the agent says `canEdit`; a bar appears while a tab has unsaved changes and saves them in one request against the revision the page shows, and switching tabs or following a link away asks first. When someone else saved the agent meanwhile, the page reloads and a dialog shows what they changed. History: who changed what and when, long text as a line diff, lists as what was added and removed, variables named without values.
+  - Agents: the list (type, tools, the default model and how many more, where it runs with the runners online for it, or "on the server" and whether its model is offered, active runs, visibility; a type filter; archived ones on request; agents everyone can use first, the application's own in the order it added them, then the viewer's own (`AgentSummary.owned`), then the ones shared with them, each group by the name shown) and an agent's page, whose header sums it up in one line (type, tool or model, where it runs, free or busy, owner), with four tabs kept in `?tab=`; the new-agent dialog asks for the type first, then the fields of that type (its tools and models, model services and models for an online agent from `GET /api/agents/models`; with none, the agent uses the system default chat model, which the dialog names with a link to change it, or says none is offered). General: basics, avatar and instructions with "Preview full prompt" (a scenario switch among the subject kinds that offer a sample, the application's first and a conversation, `?scenario=` on the API; it shows the system prompt in one, with the agent's own prompt marked at its end, and the first message, all rendered on a made-up subject whose values are marked `[sample]`), and who may use it. Capabilities: the tools and models, a compact ordered list (one header row, then one row per entry) whose first row is the default, with rows added, removed and moved up or down (a runner agent's rows a coding tool, a model typed freely with the tool's common models suggested, and an effort among the tool's; an online agent's rows a model service, a model and an effort, each with a Test button; the new-agent dialog uses the same list), skills, the business capabilities grouped by the application's groups with a description each, and the ones never granted to an agent greyed out with the reason (`AgentActionOption.grantable: false`), and whether it confirms before changing data. Runtime (runner agents only): where it runs (any runner, or named ones, and concurrency) and its environment variables (write-only, revealing them is audited, saved row by row). Editable when the agent says `canEdit`; a bar appears while a tab has unsaved changes and saves them in one request against the revision the page shows, and switching tabs or following a link away asks first. When someone else saved the agent meanwhile, the page reloads and a dialog shows what they changed. History: who changed what and when, long text as a line diff, lists as what was added and removed, variables named without values.
   - Skills: the library (each skill's name, description, compatibility and whether it holds scripts), and a skill as a directory: its files in a tree beside the selected one (`client/pages/skills/workbench/`), SKILL.md rendered, other text shown, images and PDFs previewed. Editing uses the same workbench: files and folders are created (in a folder chosen from the skill's and the conventional `scripts/`, `references/`, `assets/`), uploaded (also by dropping files onto a folder), renamed and deleted from the tree, never by typing a path; SKILL.md and other Markdown are written beside their preview (in tabs on a narrow pane), with the front matter's problems listed above the source as it is typed. A new skill (`/skills/new`, a covering page) starts from a template of front matter and suggested sections. Versions can be compared with the current one and restored, and the page shows where the skill is attached. When someone saved a version while the editor was open, the draft stays and a banner offers to load the latest version. A scope's default skills list the scripts of the chosen skills, which online agents do not run (`SkillScriptsNotice`).
   - The new agent, new skill and variable dialogs ask "Discard unsaved changes?" before closing with input in them (NP-200), through `@nocobase/app-client`'s unsaved-changes guard.
 - `@nocobase/app-plugin-agents/client/kit` exports `VariablesSection` and `DefaultSkillsSection` for a scope's settings on the application's pages (`scope` `workdir` or a registered key, with an optional `description`), `useRunnerOptions` for picking the runner a directory is on (with how many runners are `online`), and `useAgentOptions` for picking an agent.
@@ -225,3 +236,9 @@ The plugin registers no routes of its own: an application mounts its pages and j
 - `@nocobase/app-plugin-agents/client/config` exports `AgentActionCatalogContext`: the agent editor's business actions come from the server (`GET /api/agents/actions`: what the application offers, none without it) unless an application gives another catalog.
 
 Each exported component brings the plugin's translations and its own query cache, so it works inside another plugin's tree.
+
+A subject assembly may return `inputs` to select the effective claim inputs. Use the same selection when rendering its task and turn; runner and online claims deliver that selection and pass it to brief sections and mounts. Omitting `inputs` preserves delivery of all queued input. Omitted inputs are resolved in the claim transaction and stay in the audit history; they cannot reappear during polling or prevent completion.
+
+### Scoped work summaries
+
+`agents.runs.workingOn(subjectKind, subjectIds)` returns each subject/agent pair with a `dispatched` or `running` run once, as `{ subjectId, agentId, working: true }`. Empty scopes return nothing. Reads are restricted to the supplied kind and IDs, without the workload board's global limit; queued and terminal runs are excluded. This service exposes no run details and does not enforce viewer permissions or approval rules: the consuming application must filter visible subjects first and apply its own waiting rules.

package/dist/client/chat.d.ts

@@ -29,6 +29,8 @@ export { AgentAvatar, type AgentAvatarSize, } from './components/agent-avatar.js
 export { useAgentText, type AgentText } from './hooks/use-vocabulary.js';
 export { useFormatters, type Formatters } from './lib/format.js';
 export { chatKeys } from './chat/keys.js';
+/** The cache used by the chat data hooks, for application-owned submission coordinators. */
+export { agentsQueryClient } from './query.js';
 export { ChatExtensionsContext, type ChatExtensions, type ChatTimelineItem, } from './chat/extensions.js';
 export { buildPageContext, contextChips, filterText, itemKey, selectionPreview, SOURCE_ATTRIBUTE, type ChatContextChip, type ChatContextFilter, type ChatContextInput, type ChatContextItem, type ChatSelection, } from './chat/context-model.js';
 export { liveStepsView, newConversationAgent, noticeText, stepLineText, timelineOrder, type LiveStepsView, type MessagesAction, type MessagesState, type NewsNotice, type PendingMessage, type StepLine, type Translate, } from './chat/message-model.js';

package/dist/client/chat.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"chat.d.ts","sourceRoot":"","sources":["../../client/chat.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;GAoBG;AACH,OAAO,KAAK,EAEV,4BAA4B,EAC7B,MAAM,8BAA8B,CAAC;AAEtC,OAAO,EACL,oBAAoB,EACpB,aAAa,EACb,cAAc,EACd,YAAY,EACZ,oBAAoB,EACpB,mBAAmB,EACnB,mBAAmB,EACnB,YAAY,EACZ,cAAc,EACd,KAAK,SAAS,EACd,KAAK,gBAAgB,EACrB,KAAK,cAAc,EACnB,KAAK,gBAAgB,EACrB,KAAK,eAAe,GACrB,MAAM,oBAAoB,CAAC;AAC5B,OAAO,EACL,YAAY,EACZ,mBAAmB,EACnB,aAAa,EACb,UAAU,EACV,eAAe,EACf,eAAe,EACf,sBAAsB,EACtB,mBAAmB,EACnB,uBAAuB,EACvB,kBAAkB,EAClB,cAAc,EACd,KAAK,eAAe,EACpB,KAAK,mBAAmB,EACxB,KAAK,qBAAqB,EAC1B,KAAK,oBAAoB,EACzB,KAAK,SAAS,GACf,MAAM,oBAAoB,CAAC;AAC5B,YAAY,EAAE,OAAO,EAAE,MAAM,eAAe,CAAC;AAC7C,OAAO,EACL,sBAAsB,EACtB,gBAAgB,EAChB,KAAK,wBAAwB,GAC9B,MAAM,oBAAoB,CAAC;AAC5B,iGAAiG;AACjG,OAAO,EACL,WAAW,EACX,KAAK,eAAe,GACrB,MAAM,8BAA8B,CAAC;AACtC,OAAO,EAAE,YAAY,EAAE,KAAK,SAAS,EAAE,MAAM,2BAA2B,CAAC;AACzE,OAAO,EAAE,aAAa,EAAE,KAAK,UAAU,EAAE,MAAM,iBAAiB,CAAC;AACjE,OAAO,EAAE,QAAQ,EAAE,MAAM,gBAAgB,CAAC;AAC1C,OAAO,EACL,qBAAqB,EACrB,KAAK,cAAc,EACnB,KAAK,gBAAgB,GACtB,MAAM,sBAAsB,CAAC;AAC9B,OAAO,EACL,gBAAgB,EAChB,YAAY,EACZ,UAAU,EACV,OAAO,EACP,gBAAgB,EAChB,gBAAgB,EAChB,KAAK,eAAe,EACpB,KAAK,iBAAiB,EACtB,KAAK,gBAAgB,EACrB,KAAK,eAAe,EACpB,KAAK,aAAa,GACnB,MAAM,yBAAyB,CAAC;AACjC,OAAO,EACL,aAAa,EACb,oBAAoB,EACpB,UAAU,EACV,YAAY,EACZ,aAAa,EACb,KAAK,aAAa,EAClB,KAAK,cAAc,EACnB,KAAK,aAAa,EAClB,KAAK,UAAU,EACf,KAAK,cAAc,EACnB,KAAK,QAAQ,EACb,KAAK,SAAS,GACf,MAAM,yBAAyB,CAAC;AACjC,OAAO,EACL,eAAe,EACf,iBAAiB,EACjB,sBAAsB,EACtB,UAAU,EACV,cAAc,EACd,cAAc,EACd,gBAAgB,EAChB,cAAc,EACd,KAAK,aAAa,EAClB,KAAK,cAAc,EACnB,KAAK,aAAa,GACnB,MAAM,uBAAuB,CAAC;AAU/B;;;GAGG;AACH,wBAAgB,cAAc,CAC5B,IAAI,EAAE,MAAM,EACZ,IAAI,SAAc,GACjB,SAAS,4BAA4B,EAAE,CAkBzC"}
+{"version":3,"file":"chat.d.ts","sourceRoot":"","sources":["../../client/chat.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;GAoBG;AACH,OAAO,KAAK,EAEV,4BAA4B,EAC7B,MAAM,8BAA8B,CAAC;AAEtC,OAAO,EACL,oBAAoB,EACpB,aAAa,EACb,cAAc,EACd,YAAY,EACZ,oBAAoB,EACpB,mBAAmB,EACnB,mBAAmB,EACnB,YAAY,EACZ,cAAc,EACd,KAAK,SAAS,EACd,KAAK,gBAAgB,EACrB,KAAK,cAAc,EACnB,KAAK,gBAAgB,EACrB,KAAK,eAAe,GACrB,MAAM,oBAAoB,CAAC;AAC5B,OAAO,EACL,YAAY,EACZ,mBAAmB,EACnB,aAAa,EACb,UAAU,EACV,eAAe,EACf,eAAe,EACf,sBAAsB,EACtB,mBAAmB,EACnB,uBAAuB,EACvB,kBAAkB,EAClB,cAAc,EACd,KAAK,eAAe,EACpB,KAAK,mBAAmB,EACxB,KAAK,qBAAqB,EAC1B,KAAK,oBAAoB,EACzB,KAAK,SAAS,GACf,MAAM,oBAAoB,CAAC;AAC5B,YAAY,EAAE,OAAO,EAAE,MAAM,eAAe,CAAC;AAC7C,OAAO,EACL,sBAAsB,EACtB,gBAAgB,EAChB,KAAK,wBAAwB,GAC9B,MAAM,oBAAoB,CAAC;AAC5B,iGAAiG;AACjG,OAAO,EACL,WAAW,EACX,KAAK,eAAe,GACrB,MAAM,8BAA8B,CAAC;AACtC,OAAO,EAAE,YAAY,EAAE,KAAK,SAAS,EAAE,MAAM,2BAA2B,CAAC;AACzE,OAAO,EAAE,aAAa,EAAE,KAAK,UAAU,EAAE,MAAM,iBAAiB,CAAC;AACjE,OAAO,EAAE,QAAQ,EAAE,MAAM,gBAAgB,CAAC;AAC1C,4FAA4F;AAC5F,OAAO,EAAE,iBAAiB,EAAE,MAAM,YAAY,CAAC;AAC/C,OAAO,EACL,qBAAqB,EACrB,KAAK,cAAc,EACnB,KAAK,gBAAgB,GACtB,MAAM,sBAAsB,CAAC;AAC9B,OAAO,EACL,gBAAgB,EAChB,YAAY,EACZ,UAAU,EACV,OAAO,EACP,gBAAgB,EAChB,gBAAgB,EAChB,KAAK,eAAe,EACpB,KAAK,iBAAiB,EACtB,KAAK,gBAAgB,EACrB,KAAK,eAAe,EACpB,KAAK,aAAa,GACnB,MAAM,yBAAyB,CAAC;AACjC,OAAO,EACL,aAAa,EACb,oBAAoB,EACpB,UAAU,EACV,YAAY,EACZ,aAAa,EACb,KAAK,aAAa,EAClB,KAAK,cAAc,EACnB,KAAK,aAAa,EAClB,KAAK,UAAU,EACf,KAAK,cAAc,EACnB,KAAK,QAAQ,EACb,KAAK,SAAS,GACf,MAAM,yBAAyB,CAAC;AACjC,OAAO,EACL,eAAe,EACf,iBAAiB,EACjB,sBAAsB,EACtB,UAAU,EACV,cAAc,EACd,cAAc,EACd,gBAAgB,EAChB,cAAc,EACd,KAAK,aAAa,EAClB,KAAK,cAAc,EACnB,KAAK,aAAa,GACnB,MAAM,uBAAuB,CAAC;AAU/B;;;GAGG;AACH,wBAAgB,cAAc,CAC5B,IAAI,EAAE,MAAM,EACZ,IAAI,SAAc,GACjB,SAAS,4BAA4B,EAAE,CAkBzC"}

package/dist/client/chat.js

@@ -6,6 +6,8 @@ export { AgentAvatar, } from './components/agent-avatar.js';
 export { useAgentText } from './hooks/use-vocabulary.js';
 export { useFormatters } from './lib/format.js';
 export { chatKeys } from './chat/keys.js';
+/** The cache used by the chat data hooks, for application-owned submission coordinators. */
+export { agentsQueryClient } from './query.js';
 export { ChatExtensionsContext, } from './chat/extensions.js';
 export { buildPageContext, contextChips, filterText, itemKey, selectionPreview, SOURCE_ATTRIBUTE, } from './chat/context-model.js';
 export { liveStepsView, newConversationAgent, noticeText, stepLineText, timelineOrder, } from './chat/message-model.js';

package/dist/client/chat.js.map

@@ -1 +1 @@
-{"version":3,"file":"chat.js","sourceRoot":"","sources":["../../client/chat.ts"],"names":[],"mappings":"AA0BA,OAAO,EACL,oBAAoB,EACpB,aAAa,EACb,cAAc,EACd,YAAY,EACZ,oBAAoB,EACpB,mBAAmB,EACnB,mBAAmB,EACnB,YAAY,EACZ,cAAc,GAMf,MAAM,oBAAoB,CAAC;AAC5B,OAAO,EACL,YAAY,EACZ,mBAAmB,EACnB,aAAa,EACb,UAAU,EACV,eAAe,EACf,eAAe,EACf,sBAAsB,EACtB,mBAAmB,EACnB,uBAAuB,EACvB,kBAAkB,EAClB,cAAc,GAMf,MAAM,oBAAoB,CAAC;AAE5B,OAAO,EACL,sBAAsB,EACtB,gBAAgB,GAEjB,MAAM,oBAAoB,CAAC;AAC5B,iGAAiG;AACjG,OAAO,EACL,WAAW,GAEZ,MAAM,8BAA8B,CAAC;AACtC,OAAO,EAAE,YAAY,EAAkB,MAAM,2BAA2B,CAAC;AACzE,OAAO,EAAE,aAAa,EAAmB,MAAM,iBAAiB,CAAC;AACjE,OAAO,EAAE,QAAQ,EAAE,MAAM,gBAAgB,CAAC;AAC1C,OAAO,EACL,qBAAqB,GAGtB,MAAM,sBAAsB,CAAC;AAC9B,OAAO,EACL,gBAAgB,EAChB,YAAY,EACZ,UAAU,EACV,OAAO,EACP,gBAAgB,EAChB,gBAAgB,GAMjB,MAAM,yBAAyB,CAAC;AACjC,OAAO,EACL,aAAa,EACb,oBAAoB,EACpB,UAAU,EACV,YAAY,EACZ,aAAa,GAQd,MAAM,yBAAyB,CAAC;AACjC,OAAO,EACL,eAAe,EACf,iBAAiB,EACjB,sBAAsB,EACtB,UAAU,EACV,cAAc,EACd,cAAc,EACd,gBAAgB,EAChB,cAAc,GAIf,MAAM,uBAAuB,CAAC;AAE/B,MAAM,QAAQ,GAAkC,KAAK,IAAI,EAAE;IACzD,MAAM,CAAC,EAAE,OAAO,EAAE,QAAQ,EAAE,EAAE,EAAE,UAAU,EAAE,IAAI,EAAE,CAAC,GAAG,MAAM,OAAO,CAAC,GAAG,CAAC;QACtE,MAAM,CAAC,oBAAoB,CAAC;QAC5B,MAAM,CAAC,YAAY,CAAC;KACrB,CAAC,CAAC;IACH,OAAO,EAAE,OAAO,EAAE,IAAI,CAAC,QAAQ,CAAC,EAAE,CAAC;AACrC,CAAC,CAAC;AAEF;;;GAGG;AACH,MAAM,UAAU,cAAc,CAC5B,IAAY,EACZ,IAAI,GAAG,WAAW;IAElB,OAAO;QACL;YACE,IAAI;YACJ,IAAI,EAAE,IAAI;YACV,IAAI,EAAE,UAAU;YAChB,mDAAmD;YACnD,KAAK,EAAE,MAAM;YACb,eAAe,EAAE,QAAQ;SAC1B;QACD;YACE,IAAI,EAAE,GAAG,IAAI,eAAe;YAC5B,IAAI,EAAE,GAAG,IAAI,kBAAkB;YAC/B,IAAI,EAAE,UAAU;YAChB,KAAK,EAAE,MAAM;YACb,eAAe,EAAE,QAAQ;SAC1B;KACF,CAAC;AACJ,CAAC"}
+{"version":3,"file":"chat.js","sourceRoot":"","sources":["../../client/chat.ts"],"names":[],"mappings":"AA0BA,OAAO,EACL,oBAAoB,EACpB,aAAa,EACb,cAAc,EACd,YAAY,EACZ,oBAAoB,EACpB,mBAAmB,EACnB,mBAAmB,EACnB,YAAY,EACZ,cAAc,GAMf,MAAM,oBAAoB,CAAC;AAC5B,OAAO,EACL,YAAY,EACZ,mBAAmB,EACnB,aAAa,EACb,UAAU,EACV,eAAe,EACf,eAAe,EACf,sBAAsB,EACtB,mBAAmB,EACnB,uBAAuB,EACvB,kBAAkB,EAClB,cAAc,GAMf,MAAM,oBAAoB,CAAC;AAE5B,OAAO,EACL,sBAAsB,EACtB,gBAAgB,GAEjB,MAAM,oBAAoB,CAAC;AAC5B,iGAAiG;AACjG,OAAO,EACL,WAAW,GAEZ,MAAM,8BAA8B,CAAC;AACtC,OAAO,EAAE,YAAY,EAAkB,MAAM,2BAA2B,CAAC;AACzE,OAAO,EAAE,aAAa,EAAmB,MAAM,iBAAiB,CAAC;AACjE,OAAO,EAAE,QAAQ,EAAE,MAAM,gBAAgB,CAAC;AAC1C,4FAA4F;AAC5F,OAAO,EAAE,iBAAiB,EAAE,MAAM,YAAY,CAAC;AAC/C,OAAO,EACL,qBAAqB,GAGtB,MAAM,sBAAsB,CAAC;AAC9B,OAAO,EACL,gBAAgB,EAChB,YAAY,EACZ,UAAU,EACV,OAAO,EACP,gBAAgB,EAChB,gBAAgB,GAMjB,MAAM,yBAAyB,CAAC;AACjC,OAAO,EACL,aAAa,EACb,oBAAoB,EACpB,UAAU,EACV,YAAY,EACZ,aAAa,GAQd,MAAM,yBAAyB,CAAC;AACjC,OAAO,EACL,eAAe,EACf,iBAAiB,EACjB,sBAAsB,EACtB,UAAU,EACV,cAAc,EACd,cAAc,EACd,gBAAgB,EAChB,cAAc,GAIf,MAAM,uBAAuB,CAAC;AAE/B,MAAM,QAAQ,GAAkC,KAAK,IAAI,EAAE;IACzD,MAAM,CAAC,EAAE,OAAO,EAAE,QAAQ,EAAE,EAAE,EAAE,UAAU,EAAE,IAAI,EAAE,CAAC,GAAG,MAAM,OAAO,CAAC,GAAG,CAAC;QACtE,MAAM,CAAC,oBAAoB,CAAC;QAC5B,MAAM,CAAC,YAAY,CAAC;KACrB,CAAC,CAAC;IACH,OAAO,EAAE,OAAO,EAAE,IAAI,CAAC,QAAQ,CAAC,EAAE,CAAC;AACrC,CAAC,CAAC;AAEF;;;GAGG;AACH,MAAM,UAAU,cAAc,CAC5B,IAAY,EACZ,IAAI,GAAG,WAAW;IAElB,OAAO;QACL;YACE,IAAI;YACJ,IAAI,EAAE,IAAI;YACV,IAAI,EAAE,UAAU;YAChB,mDAAmD;YACnD,KAAK,EAAE,MAAM;YACb,eAAe,EAAE,QAAQ;SAC1B;QACD;YACE,IAAI,EAAE,GAAG,IAAI,eAAe;YAC5B,IAAI,EAAE,GAAG,IAAI,kBAAkB;YAC/B,IAAI,EAAE,UAAU;YAChB,KAAK,EAAE,MAAM;YACb,eAAe,EAAE,QAAQ;SAC1B;KACF,CAAC;AACJ,CAAC"}

package/dist/client/lib/install.js

@@ -1,5 +1,5 @@
 /**
- * The commands a page shows to install what this application serves (standalone builds with their own Node): the
+ * The commands a page shows to install what this application serves (the host needs Node.js 24 or newer): the
  * runner, `nocobase-runner`, and the application's CLI. "Add runtime" shows one line with `--runner` and a registration
  * token (Cloudflare-Tunnel-style onboarding) that installs both, registers the runner and starts it as a user service;
  * the trust level and the coding tools it may run travel with the token, so the command carries nothing else. Without

package/dist/client/lib/tool-policy.d.ts

@@ -1,5 +1,3 @@
-export declare const DEFAULT_ALLOWED_COMMANDS: readonly string[];
-export declare const DEFAULT_DENIED_PATTERNS: readonly string[];
 /** 30 minutes. */
 export declare const DEFAULT_IDLE_TIMEOUT_MS: number;
 //# sourceMappingURL=tool-policy.d.ts.map

package/dist/client/lib/tool-policy.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"tool-policy.d.ts","sourceRoot":"","sources":["../../../client/lib/tool-policy.ts"],"names":[],"mappings":"AAMA,eAAO,MAAM,wBAAwB,EAAE,SAAS,MAAM,EACjB,CAAC;AAEtC,eAAO,MAAM,uBAAuB,EAAE,SAAS,MAAM,EACjB,CAAC;AAErC,kBAAkB;AAClB,eAAO,MAAM,uBAAuB,EAAE,MACH,CAAC"}
+{"version":3,"file":"tool-policy.d.ts","sourceRoot":"","sources":["../../../client/lib/tool-policy.ts"],"names":[],"mappings":"AAGA,kBAAkB;AAClB,eAAO,MAAM,uBAAuB,EAAE,MACH,CAAC"}

package/dist/client/lib/tool-policy.js

@@ -1,10 +1,5 @@
-/**
- * The tool policy an agent starts from, as the server applies it (`DEFAULT_TOOL_POLICY` in `shared/agents.ts`), shown
- * in the agent's advanced settings so people see what they override.
- */
+/** The idle timeout an agent starts from, as the server applies it (`DEFAULT_TOOL_POLICY` in `shared/agents.ts`). */
 import { DEFAULT_TOOL_POLICY } from '../../shared/agents.js';
-export const DEFAULT_ALLOWED_COMMANDS = DEFAULT_TOOL_POLICY.allowedCommands;
-export const DEFAULT_DENIED_PATTERNS = DEFAULT_TOOL_POLICY.deniedPatterns;
 /** 30 minutes. */
 export const DEFAULT_IDLE_TIMEOUT_MS = DEFAULT_TOOL_POLICY.idleTimeoutMs;
 //# sourceMappingURL=tool-policy.js.map

package/dist/client/lib/tool-policy.js.map

@@ -1 +1 @@
-{"version":3,"file":"tool-policy.js","sourceRoot":"","sources":["../../../client/lib/tool-policy.ts"],"names":[],"mappings":"AAAA;;;GAGG;AACH,OAAO,EAAE,mBAAmB,EAAE,MAAM,wBAAwB,CAAC;AAE7D,MAAM,CAAC,MAAM,wBAAwB,GACnC,mBAAmB,CAAC,eAAe,CAAC;AAEtC,MAAM,CAAC,MAAM,uBAAuB,GAClC,mBAAmB,CAAC,cAAc,CAAC;AAErC,kBAAkB;AAClB,MAAM,CAAC,MAAM,uBAAuB,GAClC,mBAAmB,CAAC,aAAa,CAAC"}
+{"version":3,"file":"tool-policy.js","sourceRoot":"","sources":["../../../client/lib/tool-policy.ts"],"names":[],"mappings":"AAAA,qHAAqH;AACrH,OAAO,EAAE,mBAAmB,EAAE,MAAM,wBAAwB,CAAC;AAE7D,kBAAkB;AAClB,MAAM,CAAC,MAAM,uBAAuB,GAClC,mBAAmB,CAAC,aAAa,CAAC"}

package/dist/client/locales/en-US.d.ts

@@ -290,11 +290,6 @@ declare const pages: {
         none: string;
         notGrantable: string;
         notGrantableBecause: string;
-        allowedCommands: string;
-        allowedCommandsHint: string;
-        deniedPatterns: string;
-        deniedPatternsHint: string;
-        patternInvalid: string;
         confirmChanges: string;
         confirmChangesHint: string;
         confirm: {
@@ -303,10 +298,6 @@ declare const pages: {
             largerHint: string;
         };
     };
-    commandPolicy: {
-        title: string;
-        hint: string;
-    };
     placement: {
         title: string;
         online_one: string;
@@ -606,6 +597,7 @@ declare const pages: {
         idleTimeout: string;
         setupFailed: string;
         cliUnavailable: string;
+        workspaceBusy: string;
         checkoutFailed: string;
         toolAuth: string;
         toolQuota: string;
@@ -618,6 +610,8 @@ declare const pages: {
         stepLimit: string;
         policyRefused: string;
         prepareNetwork: string;
+        repoAccessUnavailable: string;
+        repoAccessDenied: string;
         unknown: string;
     };
 };

package/dist/client/locales/en-US.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"en-US.d.ts","sourceRoot":"","sources":["../../../client/locales/en-US.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,cAAc,EAAE,MAAM,gBAAgB,CAAC;AAErD,OAAO,UAAU,MAAM,sCAAsC,CAAC;AAC9D,OAAO,QAAQ,MAAM,iBAAiB,CAAC;AACvC,OAAO,UAAU,MAAM,mBAAmB,CAAC;AAC3C,OAAO,UAAU,MAAM,mBAAmB,CAAC;AAC3C,OAAO,YAAY,MAAM,qBAAqB,CAAC;AAC/C,OAAO,YAAY,MAAM,qBAAqB,CAAC;AAC/C,OAAO,WAAW,MAAM,oBAAoB,CAAC;AAE7C,QAAA,MAAM,KAAK;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;QAqkBP,6FAA6F;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAyEhG,CAAC;AAEF,2FAA2F;AAC3F,QAAA,MAAM,IAAI,EAAE,OAAO,KAAK,GACtB,OAAO,YAAY,GACnB,OAAO,UAAU,GACjB,OAAO,QAAQ,GACf,OAAO,YAAY,GACnB,OAAO,UAAU,GACjB,OAAO,UAAU,GACjB,OAAO,WASR,CAAC;AAEF,qEAAqE;AACrE,MAAM,MAAM,cAAc,GAAG,cAAc,CAAC,OAAO,IAAI,CAAC,CAAC;AAEzD,eAAe,IAAI,CAAC"}
+{"version":3,"file":"en-US.d.ts","sourceRoot":"","sources":["../../../client/locales/en-US.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,cAAc,EAAE,MAAM,gBAAgB,CAAC;AAErD,OAAO,UAAU,MAAM,sCAAsC,CAAC;AAC9D,OAAO,QAAQ,MAAM,iBAAiB,CAAC;AACvC,OAAO,UAAU,MAAM,mBAAmB,CAAC;AAC3C,OAAO,UAAU,MAAM,mBAAmB,CAAC;AAC3C,OAAO,YAAY,MAAM,qBAAqB,CAAC;AAC/C,OAAO,YAAY,MAAM,qBAAqB,CAAC;AAC/C,OAAO,WAAW,MAAM,oBAAoB,CAAC;AAE7C,QAAA,MAAM,KAAK;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;QA0jBP,6FAA6F;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA+EhG,CAAC;AAEF,2FAA2F;AAC3F,QAAA,MAAM,IAAI,EAAE,OAAO,KAAK,GACtB,OAAO,YAAY,GACnB,OAAO,UAAU,GACjB,OAAO,QAAQ,GACf,OAAO,YAAY,GACnB,OAAO,UAAU,GACjB,OAAO,UAAU,GACjB,OAAO,WASR,CAAC;AAEF,qEAAqE;AACrE,MAAM,MAAM,cAAc,GAAG,cAAc,CAAC,OAAO,IAAI,CAAC,CAAC;AAEzD,eAAe,IAAI,CAAC"}

package/dist/client/locales/en-US.js

@@ -283,11 +283,6 @@ const pages = {
         none: 'No capability can be granted here.',
         notGrantable: 'Cannot be granted to an agent',
         notGrantableBecause: 'Cannot be granted to an agent: {{reason}}',
-        allowedCommands: 'Allowed commands',
-        allowedCommandsHint: 'Regular expressions, one per line; a shell command must match one. The defaults are shown.',
-        deniedPatterns: 'Denied patterns',
-        deniedPatternsHint: 'Regular expressions, one per line; a command matching one is refused even when allowed.',
-        patternInvalid: 'Not a valid regular expression: {{pattern}}',
         confirmChanges: 'Changes on your behalf in conversations',
         confirmChangesHint: 'When the agent changes projects and issues in your name in a conversation, which changes it first proposes as a plan for you to confirm. This is not a permission: what the agent may change is set by its capabilities above.',
         confirm: {
@@ -296,10 +291,6 @@ const pages = {
             largerHint: 'Small: at most two objects per turn, and none that finishes or closes an issue, changes its owner, makes an agent its executor, wakes an agent or creates a project.',
         },
     },
-    commandPolicy: {
-        title: 'Command policy',
-        hint: 'Which shell commands the agent may run on the runtime’s machine.',
-    },
     placement: {
         title: 'Where it runs',
         online_one: 'Runtimes with {{tool}} enabled and signed in: {{count}} online.',
@@ -594,6 +585,7 @@ const pages = {
         idleTimeout: 'The agent stopped making progress.',
         setupFailed: 'The run could not be prepared.',
         cliUnavailable: 'The runtime could not install the application CLI.',
+        workspaceBusy: 'The working directory is busy; waiting for another attempt.',
         checkoutFailed: 'The repository checkout failed.',
         toolAuth: 'The coding tool is not signed in on the runtime.',
         toolQuota: 'The coding tool ran out of quota.',
@@ -606,6 +598,8 @@ const pages = {
         stepLimit: 'The agent called tools too many times without answering.',
         policyRefused: 'No runtime’s policy lets it take this work.',
         prepareNetwork: 'The runtime could not reach the repository host while preparing the run.',
+        repoAccessUnavailable: 'A repository’s credential could not be issued just now; the run will be tried again.',
+        repoAccessDenied: 'The application will not issue a credential for one of the run’s repositories.',
         unknown: 'The run failed.',
     },
 };