foldrun 0.7.2 → 0.9.0

package/docs/feature-flags.md

@@ -0,0 +1,63 @@
+# Feature flags
+
+Some changes ship dark: the code is deployed, and whether an account gets
+the new behaviour is a decision made afterwards, by the platform team, one
+account or a share of accounts at a time. That decision is a feature flag.
+
+An account cannot change its flags. It can see them: **Settings → Feature
+flags** in the dashboard, `foldrun flags` in a terminal, or
+`GET /api/account/flags`. Each flag says whether it is on for this account
+and why.
+
+## What decides a flag
+
+The flags themselves are code — a name, what it changes, who owns it, a
+default, and sometimes a rollout percentage. A name the code does not
+register is not a flag; asking for one is a 404. What the platform's super
+admin sets on top is checked in this order, and the first that has an
+answer wins:
+
+| | source | |
+|---|---|---|
+| 1 | `account` | this account's own override — on or off whatever else says |
+| 2 | `global` | the install-wide setting — on or off for every account without an override |
+| 3 | `rollout` | a percentage of accounts. Each account falls in a fixed bucket from 0 to 99, a hash of the account and the flag's names, so the same account gets the same answer on every server and every day, and raising the percentage only adds accounts — nobody who had it loses it |
+| 4 | `default` | what the code says when nothing else does |
+
+A change is seen at once on the server that made it, and on every other
+within ten seconds.
+
+## The example
+
+`example-flag` is registered, off by default, and read by nothing: turning
+it on changes no behaviour. It is there to try the console, the API and the
+CLI against without risk.
+
+```sh
+foldrun flags              # every flag, on or off for this account, and why
+foldrun flags --json
+```
+
+```json
+{ "flags": [ { "name": "example-flag", "description": "The registered example. …",
+               "owner": "platform", "default": false, "on": false,
+               "source": "default", "rollout": null } ] }
+```
+
+## Running the platform yourself
+
+On a hosted install the super admin changes flags at **/admin → Flags**:
+the install-wide on/off and rollout, and an override per account. The same
+is `PUT`/`DELETE /api/admin/flags/<flag>` and
+`/api/admin/flags/<flag>/accounts/<account>` (see the API reference's
+super admin section). Every change is on the platform's audit as
+`operator.flag.global`, `operator.flag.global_cleared`,
+`operator.flag.account` or `operator.flag.account_cleared`, with who made
+it and what it was before. The settings are rows in Postgres
+(`feature_flags`), or `<data>/.feature-flags.json` without a database; an
+account's overrides go when the account is deleted, and their audit stays.
+
+A flag is added by a line in `foldrun-platform/src/flags.ts` and asked with
+`flagOn(account, "<name>")`. Retire it by deleting the line and the code
+that asks, once it is on for everyone; a row left behind for a name the
+code no longer registers is ignored.

package/docs/flows.md

@@ -109,12 +109,31 @@ begins.
 | `limits:` | this step's call limits, on one line — `limits: {web.search: 10, calls: 50}` — over the agent's, key by key. A call past one is refused, never run ([Tools](tools#limits--how-many-calls-a-step-may-make)) |
 | `verify:` | a shell command, or an assertion (`contains:`, `matches:`, `file:`, `judge:`). The shell runs in the agent's folder and gets the step's final turn in the file `$FOLDRUN_REPLY_FILE`; `workspace/…` reaches the workspace root there, and in `file: workspace/storage/x.md`; `node workspace/tools/x/check.mjs` runs as its own main module, so a check it makes counts ([Agents](agents#where-files-live-from-the-agents-point-of-view)). The check runs on what is left of the step's `timeout:` (at least 30 s of it); with no `timeout:` it has no clock either. A stop ends it |
 | `approve:` | park until a person releases it |
-| `ask:` | the same gate carrying a question; the typed answer reaches the prompt |
+| `ask:` | the same gate carrying a question; the typed answer reaches the prompt (a plain approval with no note reaches it as "approved with no note") |
 | `preview:` | what the gate shows: paths under `storage/` (a `workspace/storage/` prefix is accepted), comma-separated, globs allowed — `draft/*.mdx, draft/images/*.webp`; at most 12 files |
-| `wait:` | `3d` (`s`/`m`/`h`/`d`, capped at 30 days) or `event` |
-| `on-fail:` | another agent takes the step over, with the failure as context |
+| `wait:` | `3d` (`s`/`m`/`h`/`d`, capped at 30 days) or `event` — the run page shows the event URL and can release it with a payload, recorded as released by you (approve with `payload`) |
+| `on-fail:` | another agent takes the step over, with the failure as context. The rescuer owes what the step owed: its `verify:` and its `output:` |
 | `delegate:` | the step's agent picks who runs next, from this set |
 
+### What is retried without a `retry:`
+
+Some failures are the platform's or the network's, not the step's, and are
+tried again whoever wrote the flow:
+
+| what went wrong | what happens |
+|---|---|
+| the step's model connection was cut (the worker or the egress proxy restarted) | the step runs again, up to twice |
+| the model wrote a tool call out as text instead of making it, so nothing ran | the step runs again once, told what went wrong |
+| a connected account's token (`oauth2` secret) could not be refreshed for a network blip, a 5xx or a 429 | tried three times, about 1 s and 3 s apart; a refusal (revoked, wrong client) is not retried and mails the reconnect link |
+| a `web` provider timed out or answered busy | tried three times, about 2 s and 6 s apart (see the web tool) |
+
+None of the step-level ones runs again once a tool that can act outside the
+workspace has run in that attempt: the post may already be up. When a step
+still fails, the run says so — `notify:` sends `failed` (and `blocked`, for a
+run that finished but refused), and the run page's **Re-run from here**,
+`foldrun rerun <run-id> --from <n>` or `POST …/runs/<id>/rerun` start it
+again once the cause is fixed.
+
 ### Routing
 
 ```markdown
@@ -272,10 +291,10 @@ decided by a number belongs in a command that can be tested:
 `contains:`, `not-contains:` and `matches:` test the step's **conclusion** —
 its final reply, the same text the run's headline is read from — so a step
 that narrated between tool calls and then opened its answer with `BAD — …`
-passes `matches: ^BAD\b`. `judge:` grades the whole result.
+passes `matches: ^BAD\b`. `judge:` grades the same conclusion as "the reply", with everything the step wrote before it shown alongside as context, so a claim about the work can still be checked.
 
 The command sees what the step's scripts saw — its secrets, `FOLDRUN_RUN_ID`,
-`FOLDRUN_AGENT`, `FOLDRUN_WORKSPACE`, `FOLDRUN_DATE`, `TZ` — so a marker a step leaves on disk can
+`FOLDRUN_AGENT`, `FOLDRUN_WORKSPACE`, `FOLDRUN_DATE`, `TZ`, and `FOLDRUN_API_URL` (this install's own API, when it has a public address) — so a marker a step leaves on disk can
 be checked to name *this* run. That matters: a run's copy-back never
 propagates a deletion, so a marker from an earlier run rides into every later
 sandbox. `judge:` is a toolless fast-tier grading call; the other four cost

package/docs/getting-started.md

@@ -8,6 +8,7 @@ files are the program — so the loop is edit, check, run, deploy.
 ```sh
 npm install -g foldrun
 export ANTHROPIC_API_KEY=sk-ant-...     # an API key from console.anthropic.com
+# or: export CLAUDE_CODE_OAUTH_TOKEN=...  from `claude setup-token` (see the CLI reference)
 
 foldrun init my-account
 cd my-account

package/docs/providers.md

@@ -1,5 +1,31 @@
 # Providers, by name
 
+## Your account's own model key
+
+The simplest way to bring a key: **Settings → Model provider**, or
+`foldrun account model set <provider> --key <api key>`, or
+`PUT /api/account/model`. Pick a name from the table below (or `custom`
+with a base URL and a format), paste an **API key**, and every step in
+every workspace runs on it. No `provider:` block is needed; one written in
+an agent, a workspace or the account's AGENTS.md still wins over it.
+
+The key is stored in the account's vault, encrypted under the account's own
+key, as `FOLDRUN_MODEL_PROVIDER`, `FOLDRUN_MODEL_API_KEY` and, for a custom
+endpoint, `FOLDRUN_MODEL_BASE_URL` and `FOLDRUN_MODEL_FORMAT`. The dashboard
+and the API show only its last four characters.
+
+**On a hosted platform every account brings its own key.** The platform's
+own model credential is for the operator's accounts
+(`FOLDRUN_PLATFORM_KEY_ACCOUNTS`); a step in any other account with no key
+of its own is refused before it starts — "no model key: …" on the run — and
+an eval's judge or "draft with AI" says the same. A **Claude login token**
+(`sk-ant-oat…`, from `claude setup-token`) is refused as a customer's key:
+Anthropic's terms do not let a third-party product run its customers on
+claude.ai logins. Use an API key from the provider.
+
+Tokens on your own key are billed by your provider, not by the platform
+([budgets and billing](budgets-and-billing.md)).
+
 What `provider: { name: … }` resolves to. Mirrors `foldrun-core/src/providers.ts`,
 checked against each provider's own documentation on 2026-09-02 and again on
 2026-09-06; the table below is what the runtime believes, and
@@ -178,6 +204,8 @@ what would be checked; `POST` forces one, for the minute after rotating a
 key. From the terminal, `foldrun account providers` prints the same table
 (✓, ✗ with the verdict, or · for never checked) and `--check` forces one;
 a dead key is a non-zero exit, so a deploy script can refuse to continue.
+In the dashboard, Settings → Model provider shows the same check per
+provider, with **Check now** (editor and above, since it spends a request).
 
 ## When a provider says no, the run says why
 

package/docs/runs.md

@@ -87,7 +87,11 @@ run until a person decides. Three doors open it, and the trace says which:
 - **the emailed link** — the notification carries approve and reject links
   when the install has a public URL;
 - **an external event** — a `wait: event` step is released by a POST to the
-  run's event URL, and what was posted reaches the next step.
+  run's event URL, and what was posted reaches the next step. A person can
+  release it the same way from the run page (or `approve` with a `payload`):
+  the payload reaches the step just the same, and the trace names them, not
+  "an external event". The approvers and self-approval rules below are for
+  gates that ask a person; a `wait: event` release asks for `run:start`.
 
 The answer typed at an `ask:` gate reaches the next step's prompt, so "GO,
 but skip the third one" is an instruction the publisher reads.
@@ -132,7 +136,7 @@ What the platform does on a test run, in the order a step meets it:
 | the egress proxy | any `POST`, `PUT`, `PATCH` or `DELETE` to a host that is not a model provider or a read-only service is **refused** with `403` and a JSON body `{ "test_mode": true, "would_have": { method, host, path, to, body } }`. A Resend `POST /emails` is instead **redirected**: the recipients become `delivered@resend.dev` (Resend's sink), the subject is prefixed `[TEST] `, and the call goes through — so a desk still gets a real message id. Reads (`GET`, `HEAD`, `OPTIONS`) pass. A host with no granted secret is refused as always |
 | the sandbox | secrets whose name says they can send — `RESEND_API_KEY`, `TWILIO_*`, `GETREACH_API_KEY`, `GITHUB_TOKEN`, `MONDAY_API_TOKEN`, `OI_CRM_API_KEY`, `CLOUDFLARE_*`, `LINKEDIN_*`, `MEDIUM_COOKIES`, `TIKTOK_*` — are **withheld**: the env var reads `TEST_MODE_WITHHELD`, so a script that never checked fails at the provider with an auth error rather than sending. A step granting a script tool marked `outward: true` gets no real secret at all; one granting a tool marked `test_mode: allow` gets them all. The sandbox also has `FOLDRUN_TEST_MODE=1` and `FOLDRUN_RUN_TEST=1`, for scripts that branch on it. The http tools still go through the proxy, where the table above applies |
 | the browser | the step is handed no account [browser pod](tools#where-the-browser-runs): the tool launches Chromium inside the run pod, which the run namespace's policy denies the internet, so a `web action=browse` call fails closed rather than fetching the world through a pod the policy does not select |
-| the write-back | `state/` and `storage/` go into the sandbox as they are; what the step wrote there comes out under `runs/<id>/test-writes/state/…` and `…/storage/…`, and the workspace's copies are untouched. Nothing is harvested to the file store and nothing under `storage/public/` is published |
+| the write-back | `state/` and `storage/` go into the sandbox as they are; what the step wrote there comes out under `runs/<id>/test-writes/state/…` and `…/storage/…`, and the workspace's copies are untouched. Each later step of the run gets those writes laid over its copy, times kept, so a flow that hands work on through `storage/` is tested as it runs live — the step's log says how many files it sees. Nothing is harvested to the file store and nothing under `storage/public/` is published |
 | the record | `test: true`; the summary opens with `[test]`; a **TEST** badge beside the status in the runs list and on the run page; every refusal, redirect, diversion and withheld secret is an event carrying an `effect`, and the run page's **Test run** panel lists them — "would have written state/sends.md, +3 lines" |
 | the rest | gates still park, and the approve page says it is a test run; notifications go out only for `failed`; a `trigger: flow` chained on a test run starts as a test run |
 
@@ -155,7 +159,8 @@ flow, a time window, or an explicit list of ids. It is the tool for the
 morning when one broken thing failed seventy runs. A call naming no filter is
 refused rather than treated as everything, `dryRun: true` shows what would be
 touched, and each run is its own outcome so one that cannot be stopped does
-not abort the rest.
+not abort the rest. On the runs pages, tick runs and choose **Stop** or
+**Rerun**: the bar makes this call, once per workspace in the selection.
 
 **Re-run from a group** (`from: N`) starts a new run at group N with the
 earlier groups recorded as skipped, not invented — the step reads what earlier

package/docs/tools.md

@@ -54,7 +54,7 @@ headers:
 
 | field | |
 |---|---|
-| `base` | the URL every call is relative to |
+| `base` | the URL every call is relative to. `${FOLDRUN_API_URL}` is this install's own API (`base: ${FOLDRUN_API_URL}`), so a tool that reads the account's runs never names a host; a base naming it on an install that has no public address is reported unavailable |
 | `methods` | the verb allowlist — a tool that declares none is read-only |
 | `headers` | `${SECRET}` placeholders, resolved host-side at call time |
 | `query` | query parameters appended to every call — for an API that carries its key in the query string; a `${SECRET}` is resolved host-side |
@@ -63,6 +63,13 @@ headers:
 | `openapi` | a URL or file; turns one generic tool into typed ones, one per operation |
 | `operations` | only these operations, by `operationId` or `METHOD /path`; the generic tool is withheld. It fails closed: if the document does not load or none of them resolve, the API has no tools that run, never the generic one. Keep an allowlisted document in the workspace, so a vendor renaming an operation cannot empty it |
 
+**The body is the manual.** Everything under a `tool.md`'s frontmatter goes
+to the model with the tool, after `description:` — how to call it, what it
+refuses, what its output means, examples of a call (up to 6,000 characters;
+a longer body is cut there and says so). A single-file tool's fenced program
+is code, not guidance, and stays out. This holds for script and HTTP tools
+alike, workspace or library.
+
 The model never sees a credential — the host substitutes it as the request
 goes out. The method allowlist protects against the agent; the key's own scopes
 protect against everyone else, so pair a read-only tool with a read-only key.
@@ -221,6 +228,14 @@ the agent — which is already the model — to answer from; `extract` by
 `schema=` or `prompt=`, which needs a model to read the page, needs a
 provider.
 
+Granting `web` grants **Read** with it: several actions write what they
+found to a file and say so (a screenshot, a crawl, a page saved whole), and
+an agent told to read a file it could not open was refused. `disallowedTools:
+[Read]` takes it away again. A provider that times out or answers busy (429,
+5xx) is asked twice more, about 2 s and 6 s apart, before the action reports
+it unreachable — a fan-out of many steps asking one provider at once is the
+usual cause.
+
 ```yaml
 tools: [web]
 web:

package/docs/versions.md

@@ -25,6 +25,31 @@ dashboard and the API), `docs` and `infra` — recorded when it was deployed.
 The `foldrun` CLI and `@foldrun/core` on npm are packages a person publishes,
 and keep ordinary semver (`0.6.0`).
 
+## Rollback and the database
+
+A rollback redeploys older code, but not an older database: the schema stays
+where the newest release left it, because migrations only run forwards. So
+every migration has to work with the code of the release before it — the
+expand/contract rule. A release only expands: a new table, a nullable column,
+a column with a `DEFAULT`, an index. Taking something away that released code
+still uses — dropping or renaming a table or column, changing a column's
+type, making a column `NOT NULL` with no default, dropping a constraint or a
+default, `TRUNCATE`, a `DELETE` with no `WHERE` — is the contract half, and
+ships a release later, once no deployed version reads it. A migration that
+has been released is never edited; the next change is a new file.
+
+The platform enforces this. `scripts/migration-guard.mjs` in
+`foldrun-platform` reads the migrations added since the deployed version (in
+CI, since the commit a push or pull request started from) and refuses those
+statements, in CI and in the pre-push hook. A deliberate contract step says so
+on the line above the statement, with a reason, and is reported rather than
+refused:
+
+```sql
+-- migration-guard: contract api_keys.label unread since v2026.09.30.1
+ALTER TABLE "api_keys" DROP COLUMN "label";
+```
+
 ## Where to see it
 
 | Where | What |

package/docs/workspaces.md

@@ -54,6 +54,85 @@ pulled, only edited in Settings.
 A single folder with `agents/` and `flows/` at its root is still a workspace
 and still works everywhere; `foldrun init --flat` makes one.
 
+## A new workspace starts blank
+
+**Create workspace** on the dashboard, `POST /api/workspaces` with
+`template: true`, and `foldrun new <name>` all make a workspace with nothing in
+it to delete: an `AGENTS.md` (plus, on a laptop, the `.gitignore` that keeps
+its secret key out of git and a `CLAUDE.md` for your coding tool). No example
+agents, no flow. `foldrun new <name> --starter` and `starter: true` still make
+the example researcher, writer and `publish` flow; `foldrun init` makes it for
+an account's first workspace, which the getting-started guide runs.
+
+A workspace with no agents yet deploys; `check` and the deploy say so as a
+warning. A flow that names an agent the workspace lacks is still an error.
+
+### Importing an agent you already have
+
+The agents worth having in a new workspace are often ones already written in
+another: **Import agent** on the Agents page (and in the empty state of a blank
+workspace) lists every agent in the account's other workspaces you can read,
+and copies the one you pick. From a terminal, `foldrun agent import
+<workspace>/<agent>` does it between workspaces of an account folder, or on the
+platform with `--to <workspace>`; the route is `POST
+/api/workspaces/<ws>/agents/import` with `{ from, agent, as? }`.
+
+What is copied is what the agent **is**: `agent.md` and its own `skills/`,
+`scripts/` and `knowledge/`. What it **accumulated** stays where it was learned:
+`memory/`, `outputs/`, `state/` and session files. A name already taken is
+refused — import it under another name with `--as` / `as`, which rewrites its
+`name:`. The import then says what the copy uses that this workspace lacks —
+tools, skills, scripts, secrets — without refusing: set the secret, import the
+tool, and it runs. The copy is independent; editing one does not change the
+other.
+
+### Export and import
+
+Agent import works inside one account. To move a desk to another account or
+installation — or to hand someone a flow — export it as a `.zip`:
+
+- **A workspace:** Settings → **Export and import** → **Export workspace**.
+- **A flow:** **Export** on its card on the Flows page. The package holds the
+  flow, every flow it runs as a step, every agent those steps name (with
+  `on-fail:`, `delegate:` and the colleagues those agents consult or delegate to),
+  and the workspace tools, skills and scripts they grant — including the
+  script a single-file tool's `run:` names.
+- **An agent:** **Export** on its page: its folder (what agent import copies)
+  and the workspace tools, skills and scripts it grants. Colleagues it consults
+  are named, not carried.
+
+A package is authored source only: `AGENTS.md` and the `agents/`, `flows/`,
+`evals/`, `knowledge/`, `skills/`, `tools/` and `scripts/` folders. It never holds
+`memory/`, `state/`, `outputs/`, storage, runs, `.env` files or a secret's
+value. The secrets it uses travel by **name**, so the importer knows what to
+set. An agent with no `skills:` line gets every skill in scope at run time, so
+its package carries every workspace skill.
+
+Anything else in a zip — memory, state, a `.gitignore` or `CLAUDE.md` beside a
+folder you zipped yourself — is **not imported**, and the preview lists it.
+
+To import, use **Import .zip** on the Flows or Agents page or in Settings, or
+**Add new → Import workspace** on the home page. You pick the file and first
+see a preview, with nothing written yet:
+
+- what it adds;
+- what is already identical;
+- which files it would **replace** (only with a tick);
+- what it needs that this account lacks: secrets, library tools and skills,
+  scripts, agents and flows it names.
+
+An import never deletes anything, and it is all or nothing: a file it cannot
+write (a folder already in its place, a link on the way) refuses the whole
+import before anything is written. It lands as one revision, so History can
+restore what it replaced. A workspace package imported under a new name makes
+that workspace. A `.zip` of a workspace folder made by hand (a Mac's
+Compress included) imports the same way.
+
+From a terminal: `foldrun export [workspace] [--flow <name> | --agent <name>]`
+and `foldrun import <file.zip> --to <workspace> [--dry-run] [--overwrite]`.
+The routes are `GET /api/workspaces/<ws>/export` and
+`POST /api/workspaces/<ws>/import` (`?dryRun=1`, `?overwrite=1`).
+
 ## `AGENTS.md` — context and defaults
 
 The body is prose every agent in the workspace sees before its own prompt.
@@ -147,6 +226,14 @@ memory an agent wrote that your push does not mention. Those belong to the
 platform, not to git, and a deploy that reverted what an agent learned would
 make every run a little dumber.
 
+The agent engine's own files are not workspace content either. Each step
+runs in a sandbox on the Claude Agent SDK — the engine, whichever model
+answers — and the engine writes its settings and session transcripts in the
+agent's folder there (`agents/<name>/.claude.json`, `agents/<name>/.claude/`).
+They stay in the sandbox: never copied back, never copied in. (Your own
+`.claude/agents/*.md` at the workspace root is different — a Claude Code
+subagent you wrote, deployed as an agent.)
+
 A push while a run is in flight is accepted and applied when the run
 finishes; git tells you so at push time. A run parked at an approval gate
 counts as in flight. See [Deploying](deploying).

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "foldrun",
-  "version": "0.7.2",
+  "version": "0.9.0",
   "description": "Agents are just folders. Write them, check them, run them — on your machine.",
   "license": "Apache-2.0",
   "type": "module",
@@ -11,7 +11,7 @@
     "node": ">=22"
   },
   "dependencies": {
-    "@foldrun/core": "^0.5.0"
+    "@foldrun/core": "^0.7.0"
   },
   "files": [
     "bin",
@@ -21,7 +21,7 @@
   ],
   "scripts": {
     "e2e": "FOLDRUN_E2E=1 FOLDRUN_DATA=$(mktemp -d /tmp/foldrun-e2e-XXXXXX) node --test --test-timeout=300000 tests/e2e.test.ts",
-    "test": "FOLDRUN_DATA=$(mktemp -d /tmp/foldrun-test-XXXXXX) node --test tests/cli-account.test.ts tests/cli-approvals.test.ts tests/cli-stop.test.ts tests/cli-account-settings.test.ts tests/cli-schedule.test.ts tests/cli-billing.test.ts tests/cli-storage.test.ts tests/cli-scaffold.test.ts tests/cli-secrets.test.ts tests/cli-site-login.test.ts tests/cli-check-library.test.ts tests/cli-check-timezone.test.ts tests/cli-check-subagents.test.ts tests/cli-connect.test.ts tests/cli-accounts.test.ts tests/cli-remote.test.ts tests/cli-stream.test.ts tests/cli-doctor.test.ts tests/cli-tool-test.test.ts tests/cli-agent-run.test.ts tests/cli-check-remote.test.ts tests/cli-shares.test.ts tests/cli-triggers.test.ts tests/cli-providers.test.ts tests/cli-rerun-put.test.ts tests/cli-guide.test.ts tests/cli-runtimes.test.ts tests/cli-deploy-safety.test.ts tests/cli-operator.test.ts tests/cli-flow-patterns.test.ts tests/cli-flow-rm-step.test.ts tests/cli-flow-dup-step.test.ts tests/cli-flow-write-stale.test.ts tests/cli-agent-link-stale.test.ts tests/cli-parity.test.ts tests/cli-invoke-inputs.test.ts tests/cli-audit-keys.test.ts tests/cli-version.test.ts tests/cli-check-web-warnings.test.ts tests/cli-report-image.test.ts tests/cli-check-workspace-paths.test.ts tests/cli-parity-dashboard.test.ts tests/cli-api-standards.test.ts tests/cli-backups-onboarding.test.ts tests/cli-check-limits.test.ts tests/cli-gallery.test.ts tests/cli-status-platform.test.ts tests/cli-webhooks-notifications.test.ts",
+    "test": "FOLDRUN_DATA=$(mktemp -d /tmp/foldrun-test-XXXXXX) node --test tests/cli-account.test.ts tests/model-credential.test.ts tests/cli-approvals.test.ts tests/cli-stop.test.ts tests/cli-account-settings.test.ts tests/cli-schedule.test.ts tests/cli-billing.test.ts tests/cli-storage.test.ts tests/cli-scaffold.test.ts tests/cli-secrets.test.ts tests/cli-site-login.test.ts tests/cli-check-library.test.ts tests/cli-check-timezone.test.ts tests/cli-check-frontmatter.test.ts tests/cli-agent-import.test.ts tests/cli-check-subagents.test.ts tests/cli-connect.test.ts tests/cli-accounts.test.ts tests/cli-remote.test.ts tests/cli-stream.test.ts tests/cli-doctor.test.ts tests/cli-tool-test.test.ts tests/cli-agent-run.test.ts tests/cli-check-remote.test.ts tests/cli-shares.test.ts tests/cli-triggers.test.ts tests/cli-providers.test.ts tests/cli-rerun-put.test.ts tests/cli-guide.test.ts tests/cli-runtimes.test.ts tests/cli-deploy-safety.test.ts tests/cli-operator.test.ts tests/cli-flow-patterns.test.ts tests/cli-flow-rm-step.test.ts tests/cli-flow-dup-step.test.ts tests/cli-flow-write-stale.test.ts tests/cli-agent-link-stale.test.ts tests/cli-parity.test.ts tests/cli-invoke-inputs.test.ts tests/cli-audit-keys.test.ts tests/cli-version.test.ts tests/cli-check-web-warnings.test.ts tests/cli-report-image.test.ts tests/cli-check-workspace-paths.test.ts tests/cli-parity-dashboard.test.ts tests/cli-api-standards.test.ts tests/cli-backups-onboarding.test.ts tests/cli-check-limits.test.ts tests/cli-gallery.test.ts tests/cli-status-platform.test.ts tests/cli-webhooks-notifications.test.ts tests/cli-flags.test.ts tests/cli-api-coverage.test.ts",
     "release": "node scripts/release.mjs",
     "typecheck": "tsc -p tsconfig.json",
     "docs:sync": "node scripts/sync-docs.mjs",
@@ -47,7 +47,7 @@
     "access": "public"
   },
   "devDependencies": {
-    "@types/node": "^22.20.2",
+    "@types/node": "^26.6.4",
     "gray-matter": "^4.0.3",
     "typescript": "^5.9.3"
   }