foldrun 2.6.0 → 2.8.0

package/docs/evals.md

@@ -35,7 +35,9 @@ satisfy. The heading is the case's name, so make it the thing being checked.
 | `agent` **or** `flow` | what runs. A flow eval runs the whole flow per case |
 | `model` | the **judge's** tier, not the subject's — cases run the agent on its own model. Unset, the workspace's `judge:` in `AGENTS.md` (see [The four jobs](four-jobs#judge--the-evaluation-default)), else the fast tier |
 | `effort` | the judge's effort. PASS/FAIL against one sentence is not deep work |
-| `trigger` | `deploy` (default) or `manual` |
+| `trigger` | `deploy` (default), `manual`, or `runs` — grade real finished runs instead of running cases (see [Grading live runs](#grading-live-runs)) |
+| `sample` | `trigger: runs` — the percent of finished runs graded, 0 to 100 (default 25) |
+| `improve` | `trigger: runs` — `true` (5) or a count: once that many graded runs failed, a fix is proposed for a person to review (see [Proposed fixes](#proposed-fixes)) |
 | `inputs` | `true` makes the file a flow's saved inputs, not a test: its cases are named tasks for [Run with…](flows#run-with-saved-inputs) and `foldrun invoke --inputs`, and nothing runs them as an eval |
 | `live` | an eval's runs are [test runs](runs#test-runs) — nothing outward, `state/` untouched — unless this says `true`. A flow eval that must really send to prove itself opts in; nothing opts in by accident |
 
@@ -69,6 +71,154 @@ so it counts against the account's `concurrency:` and waits its turn.
 eval runs the entire flow once per case, so a three-case eval on an hour-long
 flow is three hours and the full cost, on every deploy.
 
+## Grading live runs
+
+An eval tests the cases someone wrote. A grader tests the runs that actually
+happened: the 3am desk run nobody watched, held to the same checks. It is an
+eval with `trigger: runs` and no tasks — each `##` heading is a check, with
+only an `expect:` list:
+
+```markdown
+---
+name: digest-quality
+flow: weekly-digest      # or agent: writer — that agent's steps, in any flow
+trigger: runs
+sample: 25               # percent of finished runs graded
+model: fast              # the judge
+---
+
+## cites its sources
+expect:
+  - judge: every claim names the source it came from
+
+## no placeholders
+expect:
+  - not-contains: lorem ipsum
+```
+
+- **What it grades.** For `flow:`, every step's reply joined; for `agent:`,
+  that agent's replies, in whichever flow it ran. The judge is also given
+  the run's task, so it grades the reply against what was asked.
+- **Which runs.** Completed ones — a crash is already an
+  [issue](runs#issues). Not test runs, not eval runs, and only those that
+  finished after the grader was first deployed: a new grader starts from
+  now, it does not grade a week of runs at once. The sample is chosen by a
+  hash of the run id, so the same run is always in or out.
+- **When.** The platform grades a few runs every five minutes, at most four
+  per account a pass, so a backlog drains steadily rather than spending at
+  once. A paused account or workspace is not graded.
+- **The checks.** `contains:`, `not-contains:` and `judge:`, cheap ones
+  first; the judge only runs when they pass. `file:` and `run:` are refused
+  (`foldrun check` and the deploy say so): a finished run's sandbox is gone,
+  and they would act on the platform's host instead. `matches:` is refused
+  too — a regular expression over whatever a run said, on the platform's
+  scheduler, could stall it. A `task:` in a grader does nothing and is
+  refused as well.
+- **A judge that does not answer** (a spent usage cap, a provider outage)
+  leaves the run *not decided*, which is not a failure. It is tried again
+  after an hour, three times at most.
+- **What it costs.** One judge call per `judge:` line per graded run — at
+  most five lines in a grader — on the account's own model key like any
+  eval judge. A paused account or workspace is not graded, by the pass or
+  by **Grade a run**. The card shows what the
+  judges cost; the runs' own cost is on the runs.
+
+The grades are on the Evals page: each grader's card has its pass rate over
+7 and 30 days, a bar per day, the recent failures with the check that failed
+and the judge's reason, and **Grade a run** to grade any finished run now,
+sampled or not (a run graded again shows its newer grade). A run's own page
+lists every grade it got. From the CLI, `foldrun eval grades <eval> --to
+<workspace>` (`--status fail`, `--days 7`) and `foldrun eval grade <eval>
+--run <id> --to <workspace>`; the API is `GET …/evals/<eval>/grades` and
+`POST …/evals/<eval>/grade`. Grades live in `evals/.results/grades/`, kept
+90 days; a deploy never touches them.
+
+A grader never runs as cases: not on deploy, not from Run, not from
+`foldrun eval`.
+
+## Proposed fixes
+
+A failure that keeps happening should turn into a change someone can look
+at, not sit on a card. A grader with `improve: true` (or `improve: 3` — how
+many failures) opens a **proposal** on its own once that many graded runs
+have failed and no proposal has covered them, or once the oldest such failure
+is a week old:
+
+```yaml
+trigger: runs
+improve: true        # 5 failed grades nobody has looked at → a proposal
+```
+
+- **The assistant drafts it.** It is given a short digest of the failures —
+  at most ten, each the run, the check and the judge's reason — and reads
+  the agent, the flow, their skills and the runs themselves. It is asked for
+  the smallest change that fixes the cause, never to loosen a check, and to
+  propose nothing when the fault is not in the files (a missing secret, an
+  outage).
+- **Only agents, flows and skills.** A proposal may change
+  `agents/<name>/agent.md`, `flows/<name>.md` and `skills/<name>/…`; anything
+  else the assistant proposes is left out, and the proposal says so.
+- **Nothing is written until you apply it.** Apply checks that every file
+  still reads what the proposal was drawn against and can be written, then
+  writes them all, each a revision by you (so History can take it back). A
+  file someone changed since is refused — dismiss it and propose again. A
+  check error the deploy would refuse blocks Apply.
+- **At most one open proposal per eval**, and the automatic ones at most one
+  a day per grader. A failure is *looked at* once a proposal covers it —
+  drafting, ready, applied or dismissed; a draft that failed releases its
+  failures so they count again. A draft that has not finished in half an
+  hour has failed.
+- **What it costs**: one assistant reply, paid the way Ask AI is.
+
+They are on the eval's card under **Proposed fixes**: what failed, the
+assistant's reasoning, a diff per file, and Apply or Dismiss. **Propose a
+fix** asks for one now — for a grader, from the failures no proposal has
+covered; for an eval that runs cases, from its last result's failed cases.
+Ready proposals are in your [inbox](runs#your-inbox). From the CLI: `foldrun
+eval improve <eval> --to <workspace>` asks for one and waits for the draft;
+`foldrun proposals --to <workspace>` (`--status ready`), `foldrun proposals
+show|apply|dismiss <id> --to <workspace>`. The API: `POST
+…/evals/<eval>/improve`, `GET …/proposals`, `GET`/`POST …/proposals/<id>`.
+
+## Comparing models
+
+"Could this step run on the fast model?" is answered from the cases you
+already have. **Compare models** on an eval's card runs every case under two
+to four settings — a model (`fast`, `default`, `max`, or a model id), an
+effort, and for a flow eval either every step or one agent's — and puts them
+side by side: how many passed, what the runs and their judges cost, the cost
+and time per run, and each case under each setting, so you see where they
+differ.
+
+- **The model is forced on the steps**, so it wins over the agent's own
+  `model:` and the flow's defaults. "every step" forces all of a flow's
+  steps; naming an agent forces only that agent's.
+- **Every run is a test run**, whatever the eval or the flow says about
+  `live:` — a comparison is never the reason something was sent.
+- **The judge is the eval's own** and the same for every setting: what
+  changes is the subject, never the grader.
+- **`repeat`** (1–5) runs each case more than once; one run each tells you
+  little where the model is not deterministic. Repeats interleave — each
+  setting once, then again — so a provider that slows down mid-way slows
+  every setting alike.
+- **Bounded twice**: at most 60 runs (cases × settings × repeat), and a spend
+  limit (default $5, at most $100) — once the runs and judges have spent it,
+  the rest are recorded as not run and the result says it stopped early.
+- **Time per run** is from a worker picking the run up to its end; time in
+  the queue is left out, so a busy account does not read as a slow model.
+- **What it writes**: the comparison's own result, kept with the last 20 —
+  never the eval's latest result or its history. One comparison of an eval
+  at a time.
+
+It runs on the platform and can take as long as its runs do; leave the page
+and come back. From the CLI: `foldrun eval compare <eval> --models
+fast,default,max --to <workspace>` (`--models fast:low,max:high` for
+efforts, `--agent <name>`, `--repeat 3`, `--max-usd 10`; `--list` and `--run
+<id>` read the kept ones). The API is `POST …/evals/<eval>/compare`, then
+`GET …/compare?run=<id>`. A grader (`trigger: runs`) has no cases, so it
+cannot be compared, and neither can an eval with a `run:` check — a
+comparison repeats every check many times, and `run:` executes a command.
+
 ## Promoting a run
 
 A run is a case you already have — the task is on record. A run that worked

package/docs/flows.md

@@ -106,7 +106,7 @@ begins.
 | `schema:` | with `output: json` — the JSON Schema the value must satisfy: one-line JSON, a YAML block under the key, or a file under the workspace |
 | `model:` | override the tier for this step |
 | `effort:` | override how hard it thinks for this step |
-| `retry:` | attempts after the first, clamped to 5. Each retry waits — 15 s, 30 s, 1 m, 2 m, 4 m, jittered — holding no sandbox while it waits; a stop ends the wait. An attempt the cluster ended for want of memory or disk (OOMKilled, Evicted) is retried one `size:` class up. An `outward` step whose check failed after its tools ran is not retried — the retry would send again; `check` and `deploy` warn on `retry:` on an outward step, because a failure mid-send is still retried |
+| `retry:` | attempts after the first, clamped to 5. Each retry waits — 15 s, 30 s, 1 m, 2 m, 4 m, jittered — holding no sandbox while it waits; a stop ends the wait. An attempt the cluster ended for want of memory or disk (OOMKilled, Evicted) is retried one `size:` class up. A step refused because the model usage cap is reached is not retried: the window resets in hours, not within the waits. An `outward` step whose check failed after its tools ran is not retried — the retry would send again; `check` and `deploy` warn on `retry:` on an outward step, because a failure mid-send is still retried |
 | `timeout:` | seconds, or `90s` / `15m` / `4h` / `3d` — **the only clock there is** |
 | `max_turns:` | the most model turns before the step is stopped (1 to 500) — the third bound beside `budget:` and `timeout:` |
 | `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)) |
@@ -115,7 +115,7 @@ begins.
 | `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` — 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 — and, for a gated step, the person's approval and answer, which it acts within. The rescuer owes what the step owed: its `verify:`, its `output:`, and a `loop:` step's `until:` marker (a loop that runs out of cycles goes to its rescuer too). A `verify:` that accepts `BLOCKED` never fails, so it never reaches the rescuer |
+| `on-fail:` | another agent takes the step over, with the failure as context — and, for a gated step, the person's approval and answer, which it acts within. The rescuer owes what the step owed: its `verify:`, its `output:`, and a `loop:` step's `until:` marker (a loop that runs out of cycles goes to its rescuer too). A `verify:` that accepts `BLOCKED` never fails, so it never reaches the rescuer. A step refused by the model supply itself — a spent usage window, a credential refused — is not handed to a rescuer on the same supply (the same `provider:`, or both on the workspace's): it would be refused the same way, and the issue is filed as the cap or the credential |
 | `delegate:` | the step's agent picks who runs next, from this set |
 
 ### What is retried without a `retry:`
@@ -329,6 +329,7 @@ normal outcome, recorded as one.
 | `path` | the `storage/` prefix to watch, for `trigger: storage` |
 | `url` / `every` | what to poll and how often (default 15m), for `trigger: watch` |
 | `signature` / `signing_secret` | `github` \| `stripe` \| `slack` \| `hmac`, and the vault entry to check it against |
+| `filter` | for a `webhook`, `email`, `flow` or `storage` trigger: the fields a delivery must have to start a run — see [Which deliveries start a run](#which-deliveries-start-a-run) |
 | `model` / `effort` | defaults for every step |
 | `budget` | the most one run may spend, in USD — a number, or `unlimited`; unset is no limit |
 | `overlap` | `skip` or `queue` when a run is already live |
@@ -398,6 +399,66 @@ A flow may not chain on itself. First sightings for `watch` record without
 firing, and a `once` instant more than six hours gone at first sighting is
 recorded and never fired.
 
+### Which deliveries start a run
+
+`filter:` says which deliveries are this flow's. A GitHub hook for pull
+requests posts for drafts, bot pushes and label changes alike; without a
+filter each one is a run whose first step only says "not this one". With
+one, a delivery that does not match starts nothing — no sandbox, no model
+call — and the Triggers page lists it as *did not match the filter*, with the
+condition that held it back.
+
+```yaml
+trigger: webhook
+filter:
+  action: [opened, reopened]        # any of these values
+  pull_request:
+    draft: false                    # exactly this value
+    base:
+      ref: { starts_with: release/ } # text tests: starts_with, ends_with, contains
+  sender:
+    type: { not_in: [Bot] }         # none of these
+```
+
+What it is matched against depends on the trigger:
+
+| trigger | the fields |
+|---|---|
+| `webhook` | the request's JSON body — a body that is not JSON matches no filter |
+| `email` | `from`, `to`, `subject`, `text` |
+| `flow` | `run`, `flow`, `status`, `ending` (`completed`, `failed` or `blocked`), `verdict`, `summary` |
+| `storage` | `by` (who wrote), `paths` (the files that landed under `path:`) |
+
+The rules, all of them:
+
+- Every key must match. A nested map matches the nested field.
+- A list is the values allowed — any of them. A plain value is the one value.
+- An operator map says it explicitly: `in`, `not_in`, `exists` (`true` or
+  `false`), and the text tests `starts_with`, `ends_with` and `contains`.
+  There are no regular expressions: a sender controls the body, and a
+  pattern it could make backtrack has no place before a run starts.
+- Strings compare exactly and case-sensitively; numbers numerically (`1`
+  equals `1.0`; the text `"1"` does not); `true`, `false` and `null` as
+  themselves.
+- A missing field fails a value, `in` and the text tests, and passes
+  `not_in`. `exists: false` passes only when it is missing.
+- A list in the delivery: a nested map matches when any element does;
+  `in` when any element is allowed, `not_in` when none is.
+- It fails closed. A filter `foldrun check` cannot read is a check error,
+  and if one reaches the platform it matches nothing — a typo holds
+  deliveries back instead of letting all of them through. At most 10 levels
+  deep, 64 conditions, 32 values in a list.
+
+A filtered delivery counts toward nothing: not `idempotency:`, not
+`throttle:`, not `debounce:`, not `disable_after:`. A paused account or
+workspace is still told it is paused first. `filter:` on a `schedule`,
+`once`, `watch` or `manual` flow does nothing, and `foldrun check` says so.
+
+Try a delivery without sending one: the Triggers page has a **Test filter**
+box for each filtered flow, `foldrun flow filter <flow> --payload body.json`
+reads the local file (add `--to <workspace>` for the deployed one), and the
+API is `POST …/flows/<flow>/filter { payload }`.
+
 ### How many of those starts are real
 
 A trigger says what happens. These four say how much of it becomes a run,

package/docs/hooks.md

@@ -105,8 +105,8 @@ hook can narrow what an agent does but never widen it.
 ## What a hook does not see
 
 Tools the model provider runs on its own side never pass foldrun's dispatch.
-With `web: {search: anthropic}` (or another provider's search, or
-`fetch: anthropic`) the search runs at the provider, and a `tool.call` hook
+With `web: {search: anthropic}` (or another provider's search) the search
+runs at the provider, and a `tool.call` hook
 cannot refuse or rewrite it. foldrun's own `web` tool, the default, goes
 through hooks like every other tool. `foldrun check` warns when an agent with
 a `tool.call` hook uses a provider's own search.

package/docs/introduction.md

@@ -32,12 +32,14 @@ The design bets on three things:
 | | you need | what runs where |
 |---|---|---|
 | **Locally** | `npm install -g foldrun` and a model key | everything on your machine; no account, no server |
-| **Hosted** | an account | ours: schedules, sandboxes, a vault, a team |
+| **Your own server** | Docker and the public repositories | the whole platform on one machine of yours, for you or your organisation |
+| **Hosted** | an account | ours: schedules, sandboxes, a vault, a team — nothing to run |
 
 The same workspace moves between them with `foldrun deploy`.
-Start locally; that is where every workspace should be born. The CLI and
-runtime are free from npm; the platform is not distributed — see
-[Running it yourself](self-hosting).
+Start locally; that is where every workspace should be born. foldrun is
+source-available under the Functional Source License: free for your own
+use and your organisation's, not for offering it to others as a service —
+see [Running it yourself](self-hosting).
 
 ## Where to go
 

package/docs/network.md

@@ -110,8 +110,12 @@ Every program in the sandbox reaches the internet through the **egress
 proxy**: the pod's `HTTPS_PROXY` and `HTTP_PROXY` name it, with the step's
 own lease as the password, and `NODE_USE_ENV_PROXY=1` turns that on for Node.
 curl, Python's `requests` and `httpx`, pip, npm, git, apt and the Agent SDK
-all read those variables. The proxy holds the step's list and checks every
-connection against it:
+all read those variables. A browser your own script launches does not:
+Chromium ignores a password written in the proxy variable, so every page
+fails `ERR_INVALID_AUTH_CREDENTIALS`. Hand Playwright the proxy yourself —
+read `HTTPS_PROXY` with `new URL()` and pass `proxy: { server, username,
+password }` to `launch()` (the `web` tool's browsers already do). The proxy
+holds the step's list and checks every connection against it:
 
 - a site **off the list** is refused — `403`, saying which site and what to
   add — and the refusal is a line in the run trace;

package/docs/runs.md

@@ -266,6 +266,34 @@ Each agent also has an **Activity** page: every step it has ever run, across
 flows and direct runs, with that step's own headline. It is where "how has
 this agent been going" is answered without opening runs one at a time.
 
+## Your inbox
+
+**Inbox**, top right and under View in the account's sidebar, is what waits
+on *you*, across every workspace you may see, in one list: gates to approve,
+questions agents are asking, open [issues](#issues), [proposed
+fixes](evals#proposed-fixes) to review, and your own runs that went wrong.
+
+Three tabs that never mix:
+
+| tab | what is in it |
+|---|---|
+| **For me** | assigned to you: you are named in the flow's `approvers:`, you own the flow or agent (`owner:`, down to the workspace's and the account's), or you asked for the proposal |
+| **Started by me** | runs you started: one that failed or ended BLOCKED or BAD in the last week, a gate on one (someone else must decide it — your own approval is refused), a question one is asking |
+| **Team** | everything else waiting in your workspaces, for whoever picks it up — a gate anyone may decide, an issue nobody owns |
+
+Nothing is kept in it: each item is read from where it lives and leaves on
+its own when it is done there — the gate decided, the issue resolved, the
+fix applied. A gate you may not decide (`approvers:` names others) is not in
+yours at all. What *is* kept is what you did to your own view: an item you
+opened is read, and **Set aside** hides one from you — it is still waiting
+for everyone else, and the gate is not decided. An item names its occurrence,
+so an issue that happens again after you set it aside comes back. The count
+on the top bar is what is unread in For me and Started by me.
+
+`foldrun inbox` prints the same (`--team`, `--all`, `--kind approval`); a key
+reads the inbox of the person who minted it, within the key's own workspaces.
+The API is `GET /api/me/inbox`.
+
 ## Gates
 
 A step marked `2!` or carrying `approve: true` / `ask: <question>` parks the

package/docs/self-hosting.md

@@ -1,20 +1,58 @@
 # Running it yourself
 
-There are two places a workspace runs, and the same folder moves between
+There are three places a workspace runs, and the same folder moves between
 them unchanged.
 
 | shape | for | what is yours |
 |---|---|---|
 | **your machine** | one person, no server — the foldrun CLI and runtime, free from npm | everything: the files, the runs, the model bill |
-| **the hosted platform** | a team; schedules, sandboxes, gates, a vault, a dashboard | your workspaces and their records; we run the machines |
-
-The framework — the format, the runner, the checks, the CLI — is free to
-install from npm (`foldrun`, `@foldrun/core`) and use under foldrun's
-licence, which ships in each package. The platform that runs it
-for other people (the queue and its worker, per-step sandboxes on a cluster,
-metering, tenancy) is ours and is not distributed: there is no self-hosted
-platform. If you need it inside your own network, that is a conversation —
-write to hello@foldrun.io.
+| **your own server** | you or your organisation on one machine: the dashboard, schedules, sandboxes, gates, a vault and a team, with Docker Compose | everything, and the machine |
+| **the hosted platform** | a team that would rather not run anything | your workspaces and their records; we run the machines |
+
+foldrun is **source-available** under the Functional Source License 1.1
+(FSL-1.1-ALv2): the format, the runner, the checks, the CLI, the engine and
+the dashboard are free to use, change and run for yourself and inside your
+own organisation, at any size. What needs a commercial licence is offering
+foldrun to others as a product or service that competes with it. Each
+release becomes Apache 2.0 two years after it ships. The licence and a
+plain-English summary are in each repository (`LICENSE`, `LICENSING.md`);
+for a commercial licence, write to hello@foldrun.io.
+
+A self-hosted server has no billing: nothing is charged, and spend budgets
+(`budget:`) still hold.
+
+## Your own server
+
+One machine with Docker. The platform runs in one container — the dashboard,
+the API, the scheduler and the queue — and every agent step runs in a
+throwaway container beside it, started through the Docker socket.
+
+```sh
+mkdir foldrun && cd foldrun
+for r in foldrun-core foldrun-platform foldrun-web foldrun-docs; do
+  git clone https://github.com/foldrun-io/$r
+done
+cd foldrun-web/self-hosting
+echo "FOLDRUN_SECRET_KEY=$(openssl rand -hex 32)" > .env
+echo "FOLDRUN_PUBLIC_URL=http://<host>:3900" >> .env   # the address people open
+docker compose up -d --build
+```
+
+Then open `http://<host>:3900/signup` (the first account needs no flag),
+sign the CLI in to it, and deploy an account folder:
+
+```sh
+npm install -g foldrun
+foldrun login --url http://<host>:3900   # approve in the browser; or --token <a key from Settings>
+foldrun deploy                           # from the account folder
+```
+
+`docker-compose.yml` beside the Dockerfile lists every setting with what it
+does: the install's model key (or none, and each account brings its own),
+open sign-up (off), retention. `FOLDRUN_PUBLIC_URL` is required: CLI sign-in,
+approve links, password resets and shares are made with it, so it must be
+the address people actually open. Back up the `foldrun-data` volume and `FOLDRUN_SECRET_KEY` and
+you have backed the install up.
 
 ## Your machine
 

package/docs/tools.md

@@ -594,7 +594,7 @@ web:
 | `parallel` | extract | full-page markdown; handles JavaScript pages and PDFs | up to 20 | `PARALLEL_API_KEY` |
 | `zyte` | **unblocker** | the page rendered in a real browser behind a proxy pool; pays per success | 1 | `ZYTE_API_KEY_BASIC` |
 | `scrapingbee` | **unblocker** | the page rendered in a real browser (`render_js`) behind a proxy pool; credits per call | 1 | `SCRAPINGBEE_API_KEY` |
-| `anthropic` | model provider | a small model's reading of the page, on Anthropic's servers | 1 | — |
+| `anthropic` | ours | accepted, and answered by foldrun's own fetch: Claude Code's `WebFetch` it used to hand over to fails its domain check behind the egress proxy | 1, or up to 20 with `urls=` | — |
 
 A provider answers `markdown`, `text` and `html`. The modes only a raw read
 can answer — `meta`, `links`, `raw` — are always read directly, and the tool

package/docs/versions.md

@@ -119,8 +119,8 @@ whatever `FOLDRUN_VERSION` it was started with.
 ## The API version
 
 `api` in `/api/version`, and the `X-Foldrun-Api` header, is a date —
-`2026-10-01` — that changes only when a route changes in a way an existing
-caller would break on. A new route or a new field in an answer does not move
+`2026-10-26` now, after `2026-10-01` — that changes only when a route changes
+in a way an existing caller would break on ([the list](api-usage#versions)). A new route or a new field in an answer does not move
 it. Breaking changes are announced in the release notes of the version that
 makes them.
 

package/package.json

@@ -1,8 +1,8 @@
 {
   "name": "foldrun",
-  "version": "2.6.0",
+  "version": "2.8.0",
   "description": "Agents are just folders. Write them, check them, run them — on your machine.",
-  "license": "SEE LICENSE IN LICENSE",
+  "license": "FSL-1.1-ALv2",
   "type": "module",
   "bin": {
     "foldrun": "bin/foldrun.mjs"
@@ -11,17 +11,18 @@
     "node": ">=22"
   },
   "dependencies": {
-    "@foldrun/core": "^2.8.0"
+    "@foldrun/core": "^2.12.0"
   },
   "files": [
     "bin",
     "src",
     "README.md",
+    "LICENSING.md",
     "docs"
   ],
   "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/model-credential.test.ts tests/cli-approvals.test.ts tests/cli-issues.test.ts tests/cli-capture.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-agent-link-isolated.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-report-cache.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 tests/cli-hooks.test.ts tests/cli-release.test.ts tests/cli-terminal.test.ts tests/cli-network.test.ts tests/cli-assistant.test.ts tests/cli-check-scan.test.ts tests/cli-published.test.ts tests/cli-init-target.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-issues.test.ts tests/cli-capture.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-agent-link-isolated.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-report-cache.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 tests/cli-hooks.test.ts tests/cli-release.test.ts tests/cli-terminal.test.ts tests/cli-network.test.ts tests/cli-assistant.test.ts tests/cli-check-scan.test.ts tests/cli-published.test.ts tests/cli-init-target.test.ts tests/cli-flow-filter.test.ts tests/cli-eval-grades.test.ts tests/cli-eval-compare.test.ts tests/cli-proposals.test.ts tests/cli-inbox.test.ts",
     "release": "node scripts/release.mjs",
     "typecheck": "tsc -p tsconfig.json",
     "docs:sync": "node scripts/sync-docs.mjs",
@@ -47,5 +48,8 @@
     "@types/node": "^26.6.4",
     "gray-matter": "^4.0.3",
     "typescript": "^6.0.3"
+  },
+  "overrides": {
+    "zod": "4.6.7"
   }
 }