nodal-agents 0.9.1 → 0.9.3

package/docs-index.json

@@ -118,7 +118,7 @@
       "pageTitle": "Memory",
       "heading": "Memory",
       "url": "/nodal-agents/docs/concepts/memory",
-      "text": "How agents store, recall, and automatically use persistent facts across jobs. Agents accumulate facts in a persistent agent_memory table. These facts survive across sessions, restarts, and model swaps — whenever a job runs, relevant memories are already waiting in the system prompt before the first LLM call."
+      "text": "How an agent remembers something for later, and how the fact comes back next time it works. Agents accumulate facts in a persistent agent_memory table. These facts survive across sessions, restarts, and model swaps — whenever a job runs, relevant memories are already waiting in the system prompt before the first LLM call. When you tell an agent to remember this, to keep something for later, or to do it this way next time, a memory is what you are asking for: the fact is written once, and read back on its own every time it is needed."
     },
     {
       "page": "concepts/memory",
@@ -130,8 +130,8 @@
     {
       "page": "concepts/memory",
       "pageTitle": "Memory",
-      "heading": "Auto-injection into every job",
-      "url": "/nodal-agents/docs/concepts/memory#auto-injection-into-every-job",
+      "heading": "Auto-injection into every job — the fact is there next time",
+      "url": "/nodal-agents/docs/concepts/memory#auto-injection-into-every-job--the-fact-is-there-next-time",
       "text": "Before a job starts, the runner selects memories from the entity-wide pool and injects them as a frozen block inside the agent's system prompt. No tool call is needed — the agent already has context. Selection works in two stages: Candidate fetch — up to 200 non-archived, non-expired memories for the entity (MAX_CANDIDATES in packages/memory/src/inject.ts). The ordering depends on the current job: Task-relevant ranking. When the job's task is tokenizable, candidates are ordered by ts_rank against the task text (full-text relevance), with importance and recency only as a tie-break. A fact relevant to this task can surface even if it sits outside the importance/recency top tier. Fallback ranking. When the task has no usable tokens, candidates are ordered by importance DESC, then last_accessed_at DESC. Budget pack — a greedy selector fits as many as possible under a character budget derived from agents.memoryTokenBudget. In the relevance path, the FTS order is authoritative and is not re-sorted by importance. A single oversized fact is skipped rather than truncated. Memory is entity-scoped, not agent-scoped — every agent in the same entity sees the same pool. This matches the query_memory tool's behaviour: knowledge follows the user across agents, not the individual agent."
     },
     {
@@ -151,9 +151,9 @@
     {
       "page": "concepts/memory",
       "pageTitle": "Memory",
-      "heading": "Writing memories",
-      "url": "/nodal-agents/docs/concepts/memory#writing-memories",
-      "text": "Agents write memories with save_memory. Duplicate detection runs on a normalized hash of the fact text — an identical (non-archived) fact already in the store is rejected before it reaches the DB, so the pool stays clean. Content is sanitized before storage to guard against injection payloads being embedded into the entity-wide pool."
+      "heading": "Writing memories — remember this, for later",
+      "url": "/nodal-agents/docs/concepts/memory#writing-memories--remember-this-for-later",
+      "text": "Agents write memories with save_memory — the tool behind \"remember that I prefer short answers\" and \"keep that for later\". Duplicate detection runs on a normalized hash of the fact text — an identical (non-archived) fact already in the store is rejected before it reaches the DB, so the pool stays clean. Content is sanitized before storage to guard against injection payloads being embedded into the entity-wide pool."
     },
     {
       "page": "concepts/memory",
@@ -620,9 +620,9 @@
     {
       "page": "guides/coding",
       "pageTitle": "Coding with an agent",
-      "heading": "The daily budget",
-      "url": "/nodal-agents/docs/guides/coding#the-daily-budget",
-      "text": "Each agent has a daily cap, 10 USD by default, on the notional cost of its coding runs. Set it to 0 to remove the cap. Two things are worth knowing about that number, because it is easy to misread: It is notional. Claude Code reports a cost even when the work is covered by your subscription, and that reported figure is what the cap counts. It is a brake on runaway usage, not a bill. Codex reports no cost at all, so its runs count as zero against the cap. What bounds them is the per-call timeout, not the budget. When the cap is reached, code_task refuses to start and says so. It does not silently downgrade or wait."
+      "heading": "The budget",
+      "url": "/nodal-agents/docs/guides/coding#the-budget",
+      "text": "A coding run counts in the agent's budget, set on the agent's Settings tab: a daily and a monthly ceiling in USD (0 = none). The same ceilings count the agent's API calls to any provider, so one number says what the agent may spend, whatever does the work. Two things are worth knowing about what a coding run adds: It is notional. Claude Code reports a cost even when the work is covered by your subscription, and that reported figure is what counts. It is a brake on runaway usage, not a bill. Codex reports no cost at all, so its runs add nothing. What bounds them is the per-call timeout. An agent that already spent its day on API calls is still stopped, Codex or not. When a ceiling is reached, code_task refuses to start and says so, and the agent's runs stop between two turns, keeping what they wrote, until the day or the month ends. Before 0.9.3 this was a daily cap on coding runs only, on the Autonomy tab; an agent that had it keeps it as its daily ceiling."
     },
     {
       "page": "guides/coding",
@@ -902,7 +902,7 @@
       "pageTitle": "Shell commands",
       "heading": "Shell commands",
       "url": "/nodal-agents/docs/guides/shell-commands",
-      "text": "Let an agent run shell commands in its workspace — with a human-in-the-loop approval gate by default. The command-execution skill unlocks the run_command built-in tool, which runs a shell command in the agent's workspace and returns stdout, stderr, and the exit code. Use it for installing dependencies, running scripts, build steps, or any CLI tool. Every command requires your approval by default. The agent proposes the command; you approve or reject it in the dashboard before it runs. Nothing executes without passing that gate (or the Yolo exception below)."
+      "text": "Let an agent run shell commands in its workspace — with a human-in-the-loop approval gate by default. The command-execution skill unlocks the run_command built-in tool, which runs a shell command in the agent's workspace and returns stdout, stderr, and the exit code. Use it for installing dependencies, running scripts, build steps, or any CLI tool. By default, a command asks for your approval before it runs. The agent proposes the command; you approve or reject it in the dashboard. What can run without asking is set per agent, in two places on its Autonomy tab: whether ordinary commands need you at all, and what the agent may not do with a shell, kind of action by kind of action."
     },
     {
       "page": "guides/shell-commands",
@@ -914,30 +914,37 @@
     {
       "page": "guides/shell-commands",
       "pageTitle": "Shell commands",
-      "heading": "How approval works",
-      "url": "/nodal-agents/docs/guides/shell-commands#how-approval-works",
-      "text": "When the agent calls run_command, the runner creates an approval request and suspends the job. You see the exact command in the dashboard and approve or reject it. If you approve, the runner executes the command and the job resumes with the output. If you reject, the agent receives an error and can try a different approach. On a Telegram-bound agent, the agent gets a bounded number of turns to tell you via chat that it is waiting — so you are not left wondering why it went quiet."
+      "heading": "How approval works — you approve a command before it runs",
+      "url": "/nodal-agents/docs/guides/shell-commands#how-approval-works--you-approve-a-command-before-it-runs",
+      "text": "When the agent calls run_command, the runner creates an approval request and suspends the job. You see the exact command in the dashboard and approve or reject it. If you approve, the runner executes the command and the job resumes with the output. If you reject, the agent receives an error and can try a different approach. Where you approve a command: the Approvals page of the dashboard, which lists every command waiting for you. By default, nothing an agent proposes runs until you approve that call. Two things let commands through without that question: a Run without asking choice on the agent's Run commands row, optionally confined to one of its folders — the card's Approve for this project writes exactly that choice for one folder; and, when the agent has no choice set, the workspace's autonomy level set to Autonomous, gate destructive, under which an ordinary command runs unasked. In both cases, the agent's shell checklist still applies: a kind of action set to Ask me asks, one set to Never is refused. The Run commands section of the Autonomy tab says in one sentence what really happens for that agent, given its rule and the workspace level. On a Telegram-bound agent, the agent gets a bounded number of turns to tell you via chat that it is waiting — so you are not left wondering why it went quiet."
     },
     {
       "page": "guides/shell-commands",
       "pageTitle": "Shell commands",
-      "heading": "Yolo mode — auto-run without approval",
-      "url": "/nodal-agents/docs/guides/shell-commands#yolo-mode--auto-run-without-approval",
-      "text": "Yolo mode skips the per-command approval gate. The agent runs commands immediately. Commands are still logged. Turning it on Yolo is set per agent, in every auth mode: Open the agent's edit page and go to the Autonomy tab. Toggle Auto-run commands without approval (Yolo) on. Confirm. Commands now run without asking. Only the workspace owner can toggle it, both in the dashboard and on the approval card. That was already true on both sides, which is why the separate LAN-only master switch was removed in 0.8.7: it was a second lock for the same key, and it only existed outside local-trust — a red button that works in one auth mode is not a red button. The brake: Settings → Safety → Auto-run brake What survived, and became its only job, is the emergency brake. It is workspace-wide, inactive by default, and it applies in every auth mode. While it is engaged, on every job: any auto_approve rule on a code-execution tool is dropped, and if no tool-specific rule then remains, an explicit require_approval rule is injected, so a blanket wildcard (*) auto-approve cannot sweep the tool back in. Nothing is deleted from the database: releasing the brake re-arms your rules exactly as they were. The brake also outranks the agent's autonomy level — a fully_autonomous ROOT cannot auto-approve past it. The tools it covers are the ones that can end up spawning something on your machine: run_command, run_skill_script, skill_file_write, code_task, create_mcp and attach_mcp (a stdio server _is_ a local subprocess), and declare_verification — because declaring a proof command is causing it to run later, at finalisation, outside any approval flow. The list lives in one place in the code, so a tool added to the autonomy guard cannot be forgotten here."
+      "heading": "The Run commands row: three choices",
+      "url": "/nodal-agents/docs/guides/shell-commands#the-run-commands-row-three-choices",
+      "text": "On the agent's Autonomy tab, Run commands offers the same three choices as every other tool, in every auth mode: Run without asking: the agent runs commands immediately, after you confirm the choice once. Commands are still logged, and the kinds of action on the agent's shell checklist still follow their setting. Ask for approval: every command waits for you. Block: the agent cannot run commands. With no choice set, none is lit and the workspace autonomy decides; the sentence above the row says what that means for this agent. Let the workspace autonomy decide removes a choice. Before 0.9.3 this row was a \"Yolo\" switch, whose Off position could not block and did not always mean \"asks\". Only the workspace owner can change it, both in the dashboard and on the approval card. That was already true on both sides, which is why the separate LAN-only master switch was removed in 0.8.7: it was a second lock for the same key, and it only existed outside local-trust — a red button that works in one auth mode is not a red button. The brake: Settings → Safety → Auto-run brake What survived, and became its only job, is the emergency brake. It is workspace-wide, inactive by default, and it applies in every auth mode. While it is engaged, on every job: any auto_approve rule on a code-execution tool is dropped, and if no tool-specific rule then remains, an explicit require_approval rule is injected, so a blanket wildcard (*) auto-approve cannot sweep the tool back in. Nothing is deleted from the database: releasing the brake re-arms your rules exactly as they were. The brake also outranks the agent's autonomy level — a fully_autonomous ROOT cannot auto-approve past it. The tools it covers are the ones that can end up spawning something on your machine: run_command, run_skill_script, skill_file_write, code_task, create_mcp and attach_mcp (a stdio server _is_ a local subprocess), and declare_verification — because declaring a proof command is causing it to run later, at finalisation, outside any approval flow. The list lives in one place in the code, so a tool added to the autonomy guard cannot be forgotten here."
+    },
+    {
+      "page": "guides/shell-commands",
+      "pageTitle": "Shell commands",
+      "heading": "What an agent may not do with a shell",
+      "url": "/nodal-agents/docs/guides/shell-commands#what-an-agent-may-not-do-with-a-shell",
+      "text": "The agent's Autonomy tab lists, under What it may do with a shell, six kinds of action Nodal recognises in what the agent asks to run. Each one is Allowed, Ask me or Never: Kind of action Recognised by Run code written into a command python -c, node -e, bash -c, a script piped into an interpreter… Delete files or discard changes rm, del, Remove-Item, git reset --hard, git clean… Install software or packages npm, pip, winget, choco, brew install… Download files from the internet wget, curl -o, git clone, Invoke-WebRequest… Stop other programs or services kill, taskkill, Stop-Process, systemctl… Change system settings, permissions or disks icacls, chmod, format, diskpart… Ask me waits for you, and the approval card names the kinds of action it saw. Never refuses it. The agent is told what it may not do, so it does not look for a way around. The list applies at every autonomy level, and under Run without asking too: it only ever adds a question or a refusal, it never removes one. A rule that blocks the shell tool, and the hard floor below, still win. A new agent asks for all six. An agent already set to Run without asking everywhere when this list appeared kept what it could do. The checklist also judges a declared proof (declare_verification), because its steps run later without asking again. Nodal recognises each kind by the program started (rm, npm i, curl … > file), including what bash -c, cmd /c or $(…) wrap. A mention in an argument (git commit -m \"rm old refs\") is not the action. What this list does not do. It reads the text the agent asks to run, not what a program does once it runs. A script run from a file (python analyse.py) is not opened: it can read, delete or download anything your user account can reach without the list seeing it. The list does not keep the shell inside the agent's folders either; only the file tools are confined to them. Keeping a shell inside a folder takes an operating-system sandbox, which Nodal does not have yet. Folded under Advanced, the same tab keeps the older list of programs an agent may start, for people who know exactly what to write there."
     },
     {
       "page": "guides/shell-commands",
       "pageTitle": "Shell commands",
       "heading": "The safety floor — commands that never auto-run",
       "url": "/nodal-agents/docs/guides/shell-commands#the-safety-floor--commands-that-never-auto-run",
-      "text": "Shell commands split into two tiers of danger, and each tier is handled differently. The hard floor: refused even if you click Approve A small, fixed set of commands is machine-wide destructive: wiping the disk root, formatting a drive, repartitioning, or powering off/rebooting the machine. These patterns can never run, in Yolo mode or not, approved or not: rm -rf (or Remove-Item -Recurse -Force, del /s /q, rd /s /q) against /, ~, a Windows drive root, or a wildcard a fork bomb mkfs (any filesystem) dd ... of=/dev/... or a shell redirection to a raw device (> /dev/sda) a Windows format <drive>: diskpart, or a destructive PowerShell disk cmdlet (Format-Volume, Clear-Disk, Initialize-Disk) shutdown / reboot / halt / poweroff (or the PowerShell equivalents, Stop-Computer / Restart-Computer) init 0 / init 6 (Unix runlevel shutdown/reboot) Hiding one behind a wrapper (sudo, cmd /c, powershell -Command \"…\") does not help: the classifier unwraps those before checking. They always force a human decision, and even if you click Approve, the command still does not execute. A single tap should never be able to greenlight machine-wide destruction. When one is refused, the agent (and you) get a plain-language explanation of why, so nothing fails silently. Destructive or heavy: gated, but approvable Everything else dangerous is not on the hard floor. It stays governed by the normal approval gate and your Yolo setting: it requires approval by default, auto-runs under Yolo, and once you approve it, it actually runs. This class covers ordinary destructive actions (deleting files, killing a process, installing a package, a large download, recursive permission changes, force-pushing git) plus one opaque category worth calling out: Inline interpreter code. Running arbitrary code passed on the command line to a general-purpose interpreter, such as python -c \"…\", node -e \"…\", perl -e, ruby -e, php -r, sh -c, bash -c, or powershell -Command. The code inside the quotes is an opaque program that could do anything, so it cannot be safety-checked line by line. The same applies to piping code into a bare interpreter (curl … | bash, echo '…' | python) and to awk programs that shell out (awk 'BEGIN{system(…)}'). All of these require approval, but they are not refused: once you approve one, it runs, and under Yolo it auto-runs like any other command. This does not block scripts. To run a script, put it in a file and run the file: python my_script.py, node build.js, bash deploy.sh. Only the inline-code form (-c / -e / -Command …) falls into this gated class. Piping data into a script (cat data | python analyze.py) is unaffected. This floor is deliberately narrow: only the 8 machine-wide destroyers above are un-bypassable. The floor is the last-resort circuit breaker, not a general safety net."
+      "text": "Shell commands split into two tiers of danger, and each tier is handled differently. The hard floor: refused even if you click Approve A small, fixed set of commands is machine-wide destructive: wiping the disk root, formatting a drive, repartitioning, or powering off/rebooting the machine. These patterns can never run, with Run without asking or not, approved or not: rm -rf (or Remove-Item -Recurse -Force, del /s /q, rd /s /q) against /, ~, a Windows drive root, or a wildcard a fork bomb mkfs (any filesystem) dd ... of=/dev/... or a shell redirection to a raw device (> /dev/sda) a Windows format <drive>: diskpart, or a destructive PowerShell disk cmdlet (Format-Volume, Clear-Disk, Initialize-Disk) shutdown / reboot / halt / poweroff (or the PowerShell equivalents, Stop-Computer / Restart-Computer) init 0 / init 6 (Unix runlevel shutdown/reboot) Hiding one behind a wrapper (sudo, cmd /c, powershell -Command \"…\") does not help: the classifier unwraps those before checking. They always force a human decision, and even if you click Approve, the command still does not execute. A single tap should never be able to greenlight machine-wide destruction. When one is refused, the agent (and you) get a plain-language explanation of why, so nothing fails silently. Destructive or heavy: gated, but approvable Everything else dangerous is not on the hard floor. It follows the agent's shell checklist: Ask me by default, and once you approve it, it actually runs. This class covers ordinary destructive actions (deleting files, killing a process, installing a package, a large download, recursive permission changes, force-pushing git) plus one opaque category worth calling out: Inline interpreter code. Running arbitrary code passed on the command line to a general-purpose interpreter, such as python -c \"…\", node -e \"…\", perl -e, ruby -e, php -r, sh -c, bash -c, or powershell -Command. The code inside the quotes is an opaque program that could do anything, so it cannot be safety-checked line by line. The same applies to piping code into a bare interpreter (curl … | bash, echo '…' | python) and to awk programs that shell out (awk 'BEGIN{system(…)}'). All of these require approval by default (they count as Run code written into a command), but they are not refused: once you approve one, it runs. This does not block scripts. A script file (python my_script.py, node build.js, bash deploy.sh) runs like any ordinary command, whoever wrote it. This floor is deliberately narrow: only the 8 machine-wide destroyers above are un-bypassable. The floor is the last-resort circuit breaker, not a general safety net."
     },
     {
       "page": "guides/shell-commands",
       "pageTitle": "Shell commands",
       "heading": "Command environment",
       "url": "/nodal-agents/docs/guides/shell-commands#command-environment",
-      "text": "Shell: cmd.exe on Windows, /bin/sh on Unix. Shell features (&&, |, quoting) work. Working directory: the agent's workspace root. Pass a workspace-relative cwd to run somewhere else inside the workspace — the path cannot point outside it. Default timeout: 300 seconds. Pass timeout_seconds to override. On timeout the command and its child processes are killed. Output cap: approximately 100 000 characters per stream. For verbose commands, redirect output to a file in the workspace and read it back with the file tools. Non-interactive only: commands that wait for input will hang until the timeout. Use non-interactive flags (e.g. npm install --yes, --no-input)."
+      "text": "Shell: cmd.exe on Windows, /bin/sh on Unix. Shell features (&&, |, quoting) work. Working directory: the agent's workspace root. Pass a workspace-relative cwd to run somewhere else inside the workspace — the path cannot point outside it. That sets where the command starts, not what it can reach: see what this list does not do. Default timeout: 300 seconds. Pass timeout_seconds to override. On timeout the command and its child processes are killed. Output cap: approximately 100 000 characters per stream. For verbose commands, redirect output to a file in the workspace and read it back with the file tools. Non-interactive only: commands that wait for input will hang until the timeout. Use non-interactive flags (e.g. npm install --yes, --no-input)."
     },
     {
       "page": "guides/shell-commands",
@@ -1252,7 +1259,7 @@
       "pageTitle": "Dashboard reference",
       "heading": "Agents",
       "url": "/nodal-agents/docs/reference/dashboard#agents",
-      "text": "Agents — /agents The fleet, grouped under their orchestrators, with per-agent job counts and live activity. Drag a row to reorder it within its group. Create New Agent opens a modal that asks how to start: Customize a new agent — an empty form, you pick everything. Pre-filled agent profiles — a profile family pre-fills the name, the role, the model and the skills that fit. Recommended connectors are suggested, never imposed, and nothing is written to the database until you create the agent. One agent — /agents/<id>/edit Eight tabs: Tab What it holds Overview Name, persona, role, and the model — including Claude Code or Codex as the agent's whole runtime Channels Telegram, Discord, Slack and WhatsApp bindings Skills Assign and unassign skills Tools The built-in tools this agent holds Connectors Connectors and MCP servers, with the per-operation allowlist Runs This agent's runs Approvals Per-tool rule — Run without asking, Ask for approval or Block — plus the Yolo toggles Settings Workspaces, budgets, memory budget, team permissions, delete Tabs that mean nothing for an agent running on a coding CLI are disabled with a reason rather than hidden. Skills — /skills Two tabs: Workspace — every skill installed here, grouped by provenance: Community, Custom, Learned, Built-in. Built-ins are editable; Reset to default undoes the override. Community — the community catalog as category-filtered tiles, plus Install a community skill from GitHub or a skills.sh path. Learned Skills — /learned-skills Skills the agents wrote themselves through the learning loop. Review, archive, restore, delete, or assign to an agent. The two workspace-level controls live on this page: Reflection on or off. Assignment mode — auto-assign learned skills, or require approval. Memory — /memories Persistent facts, in two tabs (Active / Archived). Create, archive, restore, delete; filter by agent, search by fact text, and see each fact's category and last-access date. API Connectors — /connectors Third-party integrations in two tabs, Installed and Marketplace. Connect one (an OAuth flow or an API key), then enable it on an agent's Connectors tab. The OAuth round-trip reports its success or failure on this page. MCP Connectors — /mcp The same two-tab shape for Model Context Protocol servers, plus a custom MCP form for your own stdio or HTTP server. Credentials — /credentials The credential vault: stored API keys and OAuth tokens, reused across connectors. Create through a wizard, rename inline, delete, and read the account name and token expiry. The wizard also shows the authorized redirect URI to paste into your OAuth app, with a copy button."
+      "text": "Agents — /agents The fleet, grouped under their orchestrators, with per-agent job counts and live activity. Drag a row to reorder it within its group. Create New Agent opens a modal that asks how to start: Customize a new agent — an empty form, you pick everything. Pre-filled agent profiles — a profile family pre-fills the name, the role, the model and the skills that fit. Recommended connectors are suggested, never imposed, and nothing is written to the database until you create the agent. One agent — /agents/<id>/edit Eight tabs: Tab What it holds Overview Name, persona, role, and the model — including Claude Code or Codex as the agent's whole runtime Channels Telegram, Discord, Slack and WhatsApp bindings Skills Assign and unassign skills Tools The built-in tools this agent holds Connectors Connectors and MCP servers, with the per-operation allowlist Runs This agent's runs Approvals Per-tool rule — Run without asking, Ask for approval or Block, run_command included Settings Workspaces, budgets, memory budget, team permissions, delete Tabs that mean nothing for an agent running on a coding CLI are disabled with a reason rather than hidden. Skills — /skills Two tabs: Workspace — every skill installed here, grouped by provenance: Community, Custom, Learned, Built-in. Built-ins are editable; Reset to default undoes the override. Community — the community catalog as category-filtered tiles, plus Install a community skill from GitHub or a skills.sh path. Learned Skills — /learned-skills Skills the agents wrote themselves through the learning loop. Review, archive, restore, delete, or assign to an agent. The two workspace-level controls live on this page: Reflection on or off. Assignment mode — auto-assign learned skills, or require approval. Memory — /memories Persistent facts, in two tabs (Active / Archived). Create, archive, restore, delete; filter by agent, search by fact text, and see each fact's category and last-access date. API Connectors — /connectors Third-party integrations in two tabs, Installed and Marketplace. Connect one (an OAuth flow or an API key), then enable it on an agent's Connectors tab. The OAuth round-trip reports its success or failure on this page. MCP Connectors — /mcp The same two-tab shape for Model Context Protocol servers, plus a custom MCP form for your own stdio or HTTP server. Credentials — /credentials The credential vault: stored API keys and OAuth tokens, reused across connectors. Create through a wizard, rename inline, delete, and read the account name and token expiry. The wizard also shows the authorized redirect URI to paste into your OAuth app, with a copy button."
     },
     {
       "page": "reference/dashboard",
@@ -1264,9 +1271,9 @@
     {
       "page": "reference/dashboard",
       "pageTitle": "Dashboard reference",
-      "heading": "Approvals — /approvals",
-      "url": "/nodal-agents/docs/reference/dashboard#approvals--approvals",
-      "text": "Everything that needs your sign-off, and everything that got it. Tabs: pending, approved, rejected, expired, all. Each card shows the tool input, the agent's stated purpose and impact, and a link to the run that asked. Approve or reject, optionally with a note. ?show=<id> opens one request on its own, whatever its decision — it is what the sidebar's Recents rows link to. The list narrows to that card and the page says so in its subtitle. See the autonomy model in Agents."
+      "heading": "Approvals — approve or refuse a command, /approvals",
+      "url": "/nodal-agents/docs/reference/dashboard#approvals--approve-or-refuse-a-command-approvals",
+      "text": "Everything that needs your sign-off, and everything that got it. Tabs: pending, approved, rejected, expired, all. This is where you approve a command — or any other tool call an agent asked to make — and where you refuse one. Each card shows the tool input, the agent's stated purpose and impact, and a link to the run that asked. Approve or reject, optionally with a note. An approval covers that one call. To stop confirming every time, you allow the tool rather than the command: on the agent's Approvals tab, set run_command to Run without asking, for that agent, and — if you name one — only inside one of its folders. The card's Approve for this project writes that same rule for the folder the run is in. A rule never reads what the command says, so it cannot allow one command line and keep asking about another; set without a folder, it covers every command that agent runs. A second way does not come from that tab at all: with the workspace's autonomy level set to Autonomous, gate destructive and no rule on the tool, an ordinary command runs unasked, while a destructive or heavy one (deleting files, installing a package, killing a process, a disk operation) stays gated. See Shell commands. ?show=<id> opens one request on its own, whatever its decision — it is what the sidebar's Recents rows link to. The list narrows to that card and the page says so in its subtitle. See the autonomy model in Agents."
     },
     {
       "page": "reference/dashboard",
@@ -1357,7 +1364,7 @@
       "pageTitle": "Operating & observability",
       "heading": "Cost and budget caps",
       "url": "/nodal-agents/docs/reference/operate#cost-and-budget-caps",
-      "text": "The runner enforces two hard per-job backstops against runaway loops. Both have conservative defaults and are overridable per deployment via environment variables on the runner. Guard Env var Default Behavior Token budget MAX_TOTAL_TOKENS_PER_JOB 1500000 (1.5M) When a job's cumulative input + output tokens exceed this, the job fails with token_budget_exceeded. Dollar cost MAX_COST_PER_JOB_USD 2.0 When the provider-reported cumulative cost exceeds this, the job fails with cost_budget_exceeded. The cost cap only fires for providers that report per-call cost — today that means OpenRouter (with usage:{include:true}), and no other provider we support. For providers that don't, the cost stays $0 and the token budget is the fallback backstop. Both caps are deliberately set far above where legitimate jobs sit (typical jobs use tens of thousands of tokens) while staying below the multi-million-token burns that motivated the guards. These are last-resort backstops. The anti-loop guards baked into the runtime — max delegation depth, max tool calls per turn, max chain length, and a no-progress detector — stop most runaways long before a budget cap is reached."
+      "text": "The runner stops a run that crosses one of these ceilings, between two turns. It keeps what the run already wrote: the result holds that text, then a line such as [stopped: run budget — $2.40 spent, ceiling $2.00, turn 3]. Ceiling Where it is set Default Error code Cost of one run Settings → Safety → Run budget $2.00 (0 = none) cost_budget_exceeded Working time of one run Settings → Safety → Run budget none run_time_exceeded Tokens of one run MAX_TOTAL_TOKENS_PER_JOB on the runner 1500000 (1.5M) token_budget_exceeded What one agent spends in a day or a month the agent's Settings → Budget none agent_budget_exceeded The agent's budget counts every API call of that agent, whatever the provider, and the cost its coding CLI runs report. Days and months start at midnight and on the 1st in the workspace time zone. Once a ceiling is reached, each of the agent's runs stops before its next call until the window ends, and a coding CLI run does not start. The working time counts only the time the run spends working: waiting for an approval or for a delegated agent does not count. While a time ceiling is set, one model call never waits for its first token longer than half of what remains, with a 60 s floor. The cost is what the provider reports per call, or, when it reports nothing, the tokens times the model's list price from the catalogue. A model with neither stays at $0, and the token ceiling is then the backstop. Before 0.9.3 the cost ceiling was the MAX_COST_PER_JOB_USD environment variable. It is no longer read: a runner that still has it writes max_cost_env_ignored in its log. These are last-resort backstops. The anti-loop guards baked into the runtime — max delegation depth, max tool calls per turn, max chain length, and a no-progress detector — stop most runaways long before a budget cap is reached."
     },
     {
       "page": "reference/operate",
@@ -1504,7 +1511,7 @@
       "pageTitle": "Troubleshooting & FAQ",
       "heading": "Jobs",
       "url": "/nodal-agents/docs/troubleshooting#jobs",
-      "text": "token_budget_exceeded Symptom. A job fails with token_budget_exceeded. Cause. Cumulative tokens for the job crossed the per-job ceiling — a runaway loop or a very large context. The default is 1,500,000 tokens. Fix. Investigate the loop first (a job burning 1.5M tokens is usually stuck, not legitimately large). To genuinely raise the ceiling, set MAX_TOTAL_TOKENS_PER_JOB in the runner's environment. Leveraging prompt caching (supported models) also stretches the budget, since the budget counts effective input tokens. cost_budget_exceeded (cost cap killed the job) Symptom. A job fails with cost_budget_exceeded. Cause. The provider-reported dollar cost for the job crossed the cap. The default is $2.00 per job. (Only fires for providers that report cost — e.g. OpenRouter with usage cost; for providers that don't report cost this guard never fires and the token budget is the backstop.) Fix. Raise the cap by setting MAX_COST_PER_JOB_USD in the runner's environment (e.g. MAX_COST_PER_JOB_USD=5)."
+      "text": "token_budget_exceeded Symptom. A job fails with token_budget_exceeded. Cause. Cumulative tokens for the job crossed the per-job ceiling — a runaway loop or a very large context. The default is 1,500,000 tokens. Fix. Investigate the loop first (a job burning 1.5M tokens is usually stuck, not legitimately large). To genuinely raise the ceiling, set MAX_TOTAL_TOKENS_PER_JOB in the runner's environment. Leveraging prompt caching (supported models) also stretches the budget, since the budget counts effective input tokens. agent_budget_exceeded (the agent's budget stopped the job) Symptom. A job fails with agent_budget_exceeded, or code_task refuses to start with the same code. The result ends with [stopped: agent budget — …]. Cause. The agent spent its daily or monthly ceiling: API calls of every provider and coding CLI runs, counted together. Fix. Raise or clear the ceiling on the agent's Settings tab, in Budget (0 = none), or wait for the day or the month to end. cost_budget_exceeded or run_time_exceeded (the run budget stopped the job) Symptom. A job fails with cost_budget_exceeded or run_time_exceeded. Its result keeps what it wrote, then a [stopped: run budget — …] line. Cause. The run crossed the workspace's run budget: its cost (default $2.00 per run) or its working time (no limit by default). Fix. Raise or clear the ceiling in Settings → Safety → Run budget (0 = none). The MAX_COST_PER_JOB_USD environment variable is no longer read."
     },
     {
       "page": "troubleshooting",

package/migrations/0122_entities_drop_memory_curation_enabled.sql

@@ -0,0 +1,17 @@
+-- LA COLONNE QUE PERSONNE NE POUVAIT ATTEINDRE (issue #411).
+--
+-- `memory_curation_enabled` est née avec la 0.7.0 (migration 0052) pour
+-- découpler la curation de la mémoire de `reflection_enabled`, qui gardait la
+-- boucle d'apprentissage des skills éteinte. Le runner la lisait à chaque
+-- passage ; aucun écran ne l'a jamais montrée ni changée. Un réglage qu'on ne
+-- peut poser qu'en SQL n'est pas un réglage, c'est une colonne.
+--
+-- Décision de Quentin, 22/09 : la supprimer. Ce qui reste dit « ne touche pas
+-- à ça » est le geste que le produit propose déjà : l'épingle sur le fait
+-- (`agent_memory.importance_locked`), que le curateur respecte, et le
+-- coupe-circuit global `MEMORY_CURATION_ENABLED=false` côté runner.
+--
+-- Cette migration ne touche PAS `agent_memory` : aucun fait, aucune
+-- importance, aucune archive ne bouge. Seule la ligne de l'espace perd un
+-- booléen que rien ne lisait hors du cron.
+ALTER TABLE "entities" DROP COLUMN IF EXISTS "memory_curation_enabled";

package/migrations/0123_chat_messages_stopped.sql

@@ -0,0 +1,10 @@
+-- UNE RÉPONSE ARRÊTÉE EST UN FAIT, PAS UNE PHRASE (#456).
+--
+-- Le bouton Stop du chat coupe une réponse en cours d'écriture ; ce qui avait
+-- été écrit est gardé. La première version écrivait `[stopped by the user]` à
+-- la fin du texte — une phrase du runner montrée telle quelle, contraire à
+-- l'invariant #2 (revue Codex de #459). Le runner pose désormais ce FAIT, et
+-- c'est l'écran qui le dit avec ses propres mots.
+--
+-- Faux par défaut : toutes les réponses d'avant ont été rendues entières.
+ALTER TABLE "chat_messages" ADD COLUMN IF NOT EXISTS "stopped" boolean NOT NULL DEFAULT false;

package/migrations/0124_chat_messages_cut_reason.sql

@@ -0,0 +1,12 @@
+-- UNE RÉPONSE COUPÉE PAR UNE HORLOGE EST UN FAIT, COMME UNE RÉPONSE ARRÊTÉE (#458).
+--
+-- La réponse du chat passe désormais sous les deux horloges de silence des
+-- jobs (#440). Quand l'une d'elles coupe une réponse qui avait commencé à
+-- s'écrire, ce texte est gardé comme la réponse du tour, et la raison de la
+-- coupure est enregistrée ici : `idle_before_first_token`,
+-- `idle_between_tokens`, `absolute` ou `stream_error` — les raisons de
+-- `LLMTimeoutError`. L'écran le dit avec ses mots ; le runner n'écrit aucune
+-- phrase (invariant #2, même décision que `stopped`, migration 0123).
+--
+-- NULL par défaut : toutes les réponses d'avant ont été rendues entières.
+ALTER TABLE "chat_messages" ADD COLUMN IF NOT EXISTS "cut_reason" text;

package/migrations/0125_shell_checklist.sql

@@ -0,0 +1,31 @@
+-- CE QU'UN AGENT N'A PAS LE DROIT DE FAIRE AVEC UN SHELL, PAR SORTE D'ACTION (#464).
+--
+-- Run 06a949cb → b4b493e8 (23/09) : sous `destructive_gate`, un agent a lancé
+-- des commandes sans que personne soit consulté, et le seul réglage fin était
+-- une liste de programmes à écrire à la main.
+--
+-- `agents.shell_policy` porte, par agent, l'état de chaque sorte d'action :
+-- `allow`, `ask` ou `never` (liste dans packages/shared/src/shell-checklist.ts).
+-- NULL, ou une sorte absente, veut dire `ask`.
+--
+-- `approval_requests.gate_reasons` porte POURQUOI la liste a retenu une
+-- commande (les sortes d'action lues) : la carte d'approbation les montre.
+ALTER TABLE "agents" ADD COLUMN IF NOT EXISTS "shell_policy" jsonb;
+--> statement-breakpoint
+ALTER TABLE "approval_requests" ADD COLUMN IF NOT EXISTS "gate_reasons" jsonb;
+--> statement-breakpoint
+-- Un agent à qui le propriétaire a déjà donné le shell sans demander, PARTOUT
+-- (le toggle Yolo : une règle `run_command → auto_approve` sans condition)
+-- garde ce qu'il avait : chaque sorte d'action y est permise. Une règle
+-- confinée à un dossier (`condition_json.workspacePath`, #360) ne vaut que là :
+-- l'étendre à toute la liste rendrait `rm` permis hors de ce dossier (revue
+-- Codex de #464, P1). Ces agents-là, comme tous les autres, demandent pour tout
+-- (NULL).
+UPDATE "agents"
+SET "shell_policy" = '{"inline_code":"allow","delete_files":"allow","install_software":"allow","download":"allow","stop_programs":"allow","system_settings":"allow"}'::jsonb
+WHERE "shell_policy" IS NULL
+  AND "id" IN (
+    SELECT "agent_id" FROM "approval_rules"
+    WHERE "tool_name" = 'run_command' AND "action" = 'auto_approve' AND "agent_id" IS NOT NULL
+      AND ("condition_json" IS NULL OR "condition_json" = '{}'::jsonb)
+  );

package/migrations/0126_run_budget.sql

@@ -0,0 +1,57 @@
+-- UN BUDGET PAR RUN, ET UN DÉLAI D'ATTENTE PAR AGENT (issue #442).
+--
+-- 1. `entities.max_run_cost_usd` : ce qu'un run peut coûter avant d'être
+--    arrêté, par l'espace. Le plafond existait déjà (garde 1e du runner, 2 $),
+--    mais il ne se réglait que par la variable d'environnement
+--    `MAX_COST_PER_JOB_USD`, invisible depuis le produit, et il ARRÊTAIT le
+--    run sans livrer ce qui était déjà écrit. LE DÉFAUT EST 2, la valeur que
+--    le runner applique aujourd'hui : une migration ne change le comportement
+--    de personne. `0` = aucun plafond, un choix explicite.
+--
+-- 2. `entities.max_run_hours` : combien de temps un run peut TOURNER (les
+--    attentes d'approbation et de délégation ne comptent pas, c'est
+--    `agent_jobs.total_duration_ms`). `0` = aucune limite, le défaut, puisque
+--    rien ne limitait la durée avant.
+--
+-- 3. `agents.idle_timeout_seconds` : combien de temps un appel au modèle peut
+--    rester sans premier jeton pour CET agent (Researcher, qui réfléchit
+--    longtemps). NULL = la plateforme décide (120 s, relevé avec la taille du
+--    contexte et l'effort de raisonnement). Une valeur posée GAGNE toujours
+--    sur la valeur implicite (Hermes, `_stale_timeout_is_explicit`).
+--
+-- LES CHECK SONT ICI, pas seulement dans le formulaire : ces colonnes bornent
+-- une boucle du runner (invariant #8). Mille dollars, trois jours, une heure
+-- d'attente : au-delà, ce n'est plus un réglage, c'est une faute de frappe.
+ALTER TABLE "entities"
+  ADD COLUMN IF NOT EXISTS "max_run_cost_usd" real NOT NULL DEFAULT 2;
+ALTER TABLE "entities"
+  ADD COLUMN IF NOT EXISTS "max_run_hours" real NOT NULL DEFAULT 0;
+ALTER TABLE "agents"
+  ADD COLUMN IF NOT EXISTS "idle_timeout_seconds" integer;
+
+DO $$
+BEGIN
+  ALTER TABLE "entities"
+    ADD CONSTRAINT "entities_max_run_cost_usd_check"
+    CHECK ("max_run_cost_usd" >= 0 AND "max_run_cost_usd" <= 1000);
+EXCEPTION
+  WHEN duplicate_object THEN NULL;
+END $$;
+
+DO $$
+BEGIN
+  ALTER TABLE "entities"
+    ADD CONSTRAINT "entities_max_run_hours_check"
+    CHECK ("max_run_hours" >= 0 AND "max_run_hours" <= 72);
+EXCEPTION
+  WHEN duplicate_object THEN NULL;
+END $$;
+
+DO $$
+BEGIN
+  ALTER TABLE "agents"
+    ADD CONSTRAINT "agents_idle_timeout_seconds_check"
+    CHECK ("idle_timeout_seconds" IS NULL OR ("idle_timeout_seconds" >= 30 AND "idle_timeout_seconds" <= 3600));
+EXCEPTION
+  WHEN duplicate_object THEN NULL;
+END $$;

package/migrations/0127_agent_budget.sql

@@ -0,0 +1,86 @@
+-- UN BUDGET PAR AGENT, TOUS FOURNISSEURS CONFONDUS (issue #447).
+--
+-- Décision de Quentin, 23/09 : un budget par agent, dans l'onglet Settings de
+-- l'agent, qui compte ENSEMBLE les appels d'API de n'importe quel fournisseur
+-- (`llm_calls.cost_usd`) et les runs des CLI de code (`cli_runs.cost_usd`).
+--
+-- Avant : un seul champ, `agents.cli_daily_budget_usd` (défaut 10), qui ne
+-- bornait QUE les runs de CLI de code, vivait dans la carte « Call a coding
+-- CLI » de l'onglet Autonomy et n'apparaissait que si ce groupe d'outils était
+-- actif. Deux autres budgets existaient sans que rien ne les lise :
+-- `agents.max_tokens_per_job` et toute la table `agent_budgets` (0 ligne).
+--
+-- 1. Trois colonnes : plafond du jour, plafond du mois (0 = aucun), et le
+--    pourcentage à partir duquel l'écran prévient (80 par défaut, la valeur de
+--    l'ancienne `agent_budgets.alert_threshold_pct`).
+-- 2. Le plafond CLI d'un agent devient son plafond du jour SEULEMENT là où il
+--    s'appliquait (runtime CLI, ou outil code-task rattaché). Ailleurs il ne
+--    bornait rien, et en faire un plafond de 10 $ sur les appels d'API
+--    arrêterait des agents qui ne l'ont jamais eu. Il compte désormais aussi
+--    leurs appels d'API : c'est la décision, et l'écran le dit.
+--    UNE EXCEPTION, voulue : un agent au runtime Codex. L'ancienne garde
+--    l'exemptait, son plafond (10 $ par défaut) ne bornait donc rien ; il
+--    devient un plafond actif, puisque Codex n'est plus exempté (#447). Ces
+--    agents GAGNENT un plafond qu'ils n'avaient pas en pratique, visible dans
+--    leur onglet Settings (revue de la PR #496).
+-- 3. Les colonnes et la table mortes partent.
+--
+-- IDEMPOTENTE : le repli ne tourne que tant que la colonne CLI existe.
+ALTER TABLE "agents"
+  ADD COLUMN IF NOT EXISTS "budget_daily_usd" real NOT NULL DEFAULT 0;
+ALTER TABLE "agents"
+  ADD COLUMN IF NOT EXISTS "budget_monthly_usd" real NOT NULL DEFAULT 0;
+ALTER TABLE "agents"
+  ADD COLUMN IF NOT EXISTS "budget_alert_pct" integer NOT NULL DEFAULT 80;
+
+DO $$
+BEGIN
+  ALTER TABLE "agents"
+    ADD CONSTRAINT "agents_budget_daily_usd_check"
+    CHECK ("budget_daily_usd" >= 0 AND "budget_daily_usd" <= 1000);
+EXCEPTION
+  WHEN duplicate_object THEN NULL;
+END $$;
+
+DO $$
+BEGIN
+  ALTER TABLE "agents"
+    ADD CONSTRAINT "agents_budget_monthly_usd_check"
+    CHECK ("budget_monthly_usd" >= 0 AND "budget_monthly_usd" <= 10000);
+EXCEPTION
+  WHEN duplicate_object THEN NULL;
+END $$;
+
+DO $$
+BEGIN
+  ALTER TABLE "agents"
+    ADD CONSTRAINT "agents_budget_alert_pct_check"
+    CHECK ("budget_alert_pct" >= 1 AND "budget_alert_pct" <= 100);
+EXCEPTION
+  WHEN duplicate_object THEN NULL;
+END $$;
+
+DO $$
+BEGIN
+  IF EXISTS (
+    SELECT 1 FROM information_schema.columns
+    WHERE table_name = 'agents' AND column_name = 'cli_daily_budget_usd'
+  ) THEN
+    UPDATE "agents" a
+    SET "budget_daily_usd" = LEAST(a."cli_daily_budget_usd", 1000)
+    WHERE a."cli_daily_budget_usd" > 0
+      AND (
+        a."runtime" IN ('claude-code', 'codex')
+        OR EXISTS (
+          SELECT 1
+          FROM "agent_skill_assignments" x
+          JOIN "agent_skills" k ON k."id" = x."skill_id"
+          WHERE x."agent_id" = a."id" AND k."slug" = 'code-task'
+        )
+      );
+    ALTER TABLE "agents" DROP COLUMN "cli_daily_budget_usd";
+  END IF;
+END $$;
+
+ALTER TABLE "agents" DROP COLUMN IF EXISTS "max_tokens_per_job";
+DROP TABLE IF EXISTS "agent_budgets";

package/migrations/0128_shell_policy_retired_kinds.sql

@@ -0,0 +1,52 @@
+-- LES DEUX SORTES D'ACTION RETIRÉES DE LA LISTE DU SHELL (#464, PR #476).
+--
+-- La première version de la liste (PR #474, fermée) portait deux sortes que la
+-- version réduite n'a plus : `outside_folders` (lire des chemins dans la
+-- commande et les scripts) et `own_script` (un script écrit par l'agent). Une
+-- lecture du texte ne pouvait pas tenir ces promesses ; garder un agent dans
+-- ses dossiers demande un bac à sable de l'OS (#475).
+--
+-- Seule une base qui a fait tourner la première 0125 porte ces clés. Le schéma
+-- strict (`resolveShellPolicy`) les refuse, et un job s'arrêterait alors sur
+-- `shell_policy_invalid`. Ici : `own_script` couvrait aussi le code en ligne
+-- (`python -c`), son état passe donc à `inline_code` quand celui-ci n'est pas
+-- déjà réglé ; `outside_folders` disparaît, il ne correspond plus à rien.
+-- Ailleurs, ces deux ordres ne touchent aucune ligne.
+UPDATE "agents"
+SET "shell_policy" = ("shell_policy" - 'outside_folders' - 'own_script')
+  || CASE
+       -- `inline_code` absent OU à null JSON : dans les deux cas rien n'y est
+       -- réglé, et un null resterait refusé par le schéma strict (revue de la
+       -- PR #497).
+       WHEN "shell_policy" ? 'own_script'
+            AND jsonb_typeof("shell_policy" -> 'inline_code') IS DISTINCT FROM 'string'
+       THEN jsonb_build_object('inline_code', "shell_policy" -> 'own_script')
+       ELSE '{}'::jsonb
+     END
+WHERE "shell_policy" ?| ARRAY['outside_folders', 'own_script'];
+--> statement-breakpoint
+UPDATE "agents" SET "shell_policy" = NULL WHERE "shell_policy" = '{}'::jsonb;
+--> statement-breakpoint
+-- Les raisons déjà posées sur une demande : la carte ne sait plus les nommer.
+-- Ne restent que les raisons LISIBLES : une catégorie, et pas une des deux
+-- retirées. Un élément sans catégorie part aussi, et c'est voulu : la carte lit
+-- le tableau d'un bloc (`ShellGateReasonsSchema`), et un seul élément illisible
+-- lui faisait perdre toutes les raisons, les valides comprises (revue de la
+-- PR #497, passes 1 et 2).
+UPDATE "approval_requests"
+SET "gate_reasons" = (
+  SELECT jsonb_agg(e)
+  FROM jsonb_array_elements("gate_reasons") AS e
+  WHERE e ->> 'category' IS NOT NULL
+    AND e ->> 'category' NOT IN ('outside_folders', 'own_script')
+)
+-- Le CASE ordonne les deux tests : Postgres ne garantit pas l'ordre d'un AND,
+-- et `jsonb_array_elements` sur une valeur qui n'est pas un tableau lève une
+-- erreur (revue de la PR #497).
+WHERE CASE
+        WHEN jsonb_typeof("gate_reasons") = 'array' THEN EXISTS (
+          SELECT 1 FROM jsonb_array_elements("gate_reasons") AS e
+          WHERE e ->> 'category' IN ('outside_folders', 'own_script')
+        )
+        ELSE false
+      END;

package/migrations/meta/_journal.json

@@ -848,6 +848,55 @@
       "when": 1786001340000,
       "tag": "0121_entities_proof_repair_attempts",
       "breakpoints": true
+    },
+    {
+      "idx": 122,
+      "version": "7",
+      "when": 1786001400000,
+      "tag": "0122_entities_drop_memory_curation_enabled",
+      "breakpoints": true
+    },
+    {
+      "idx": 123,
+      "version": "7",
+      "when": 1786001500000,
+      "tag": "0123_chat_messages_stopped",
+      "breakpoints": true
+    },
+    {
+      "idx": 124,
+      "version": "7",
+      "when": 1786001600000,
+      "tag": "0124_chat_messages_cut_reason",
+      "breakpoints": true
+    },
+    {
+      "idx": 125,
+      "version": "7",
+      "when": 1786001700000,
+      "tag": "0125_shell_checklist",
+      "breakpoints": true
+    },
+    {
+      "idx": 126,
+      "version": "7",
+      "when": 1786001800000,
+      "tag": "0126_run_budget",
+      "breakpoints": true
+    },
+    {
+      "idx": 127,
+      "version": "7",
+      "when": 1786001900000,
+      "tag": "0127_agent_budget",
+      "breakpoints": true
+    },
+    {
+      "idx": 128,
+      "version": "7",
+      "when": 1786002000000,
+      "tag": "0128_shell_policy_retired_kinds",
+      "breakpoints": true
     }
   ]
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "nodal-agents",
-  "version": "0.9.1",
+  "version": "0.9.3",
   "description": "Local-first AI agent platform with a web dashboard — install in one command.",
   "license": "MIT",
   "repository": {