# Kindgi 0.4.0 > What's new, fixed and changed in Kindgi 0.4.0, and the steps to upgrade to it from 0.3.1. Released November 3, 2026. For the docs of this version, see [docs.kindgi.com/v0.4.0](https://docs.kindgi.com/v0.4.0/index.md). ## Security fixes - **An erasure now reaches a test run's stored results, and a test run still going.** Before, erasing a person's words cleared a test run's case results as it ran, but not the copy in the finished run's result (`perCase`), which reads serve once it ends. Now both copies are cleared. A test run still going with a case of that person's is waited for, and the erasure shows `waiting-on-run`, with `waitingOn` naming it, then cancels it at the deadline: `KINDGI_ERASURE_SHARED_WAIT_MS`, 7 days by default, or sooner when a tenant admin forces it (`kindgi memory erasures resume --force`). A failed model call in Improve's drafter now records "The drafter's model call failed." in place of the provider's message, which could quote corrections and which an erasure couldn't reach. ## New - **Files in an S3 bucket.** `KINDGI_ARTIFACTS`, `KINDGI_ERASURE_LEDGER_EXPORT`, `KINDGI_TENANT_PURGE_RECORD`, and the `tenants` and `erasures` commands' `--record`, `--from`, `--ledger` and `--out`, take `s3:[/]`, on AWS S3 or a store that speaks S3, such as MinIO or R2. `KINDGI_S3_REGION` names the buckets' region. On AWS the runtime signs in as its AWS identity (`KINDGI_AWS_IDENTITY`); a compatible store takes `KINDGI_S3_ENDPOINT`, `KINDGI_S3_PATH_STYLE` and its own key in `KINDGI_S3_CREDENTIALS_PATH`. A delete removes every version of a file and its unfinished uploads. The runtime checks a `KINDGI_ARTIFACTS` bucket on `s3:` at start, and refuses one with MFA Delete on, or an Object Lock default retention, since a tenant purge couldn't delete from it, and one it can't list unfinished uploads in (`s3:ListBucketMultipartUploads`), or versions in, when it keeps them (`s3:ListBucketVersions`). The erasure ledger and purge records need a store that honors `If-None-Match` ([Choose where the runtime keeps files](https://docs.kindgi.com/v0.4.0/deploy/self-hosted/store-files.md)). - **The Azure Container Apps module has an `upgrade.sh`.** A deployment of the module on runtime 0.1.8 or later, in either network shape, can run it to upgrade to 0.2.0 or later, as the Cloud Run module's does. It copies the new image into the module's registry, runs the upgrade checks against the database as Container Apps jobs in the module's environment, checks that the database server keeps at least 7 days of backups, and changes the running deployment only when you type `yes` at a plan it has checked. If the new revision doesn't come up, it prints the way back, which restores the database server as of just before the apply, into a new server, rather than rolling back on its own. `--dry-run` lists what a real run would change. Use it as of the `@kindgi/sdk@0.4.0` tag. The module's new `database_url_version` pins the version of the `database-url` secret the server reads: the way back sets it, and `upgrade.sh` refuses to start while it's set ([Azure Container Apps](https://docs.kindgi.com/v0.4.0/deploy/self-hosted/azure-container-apps.md#upgrade)). - **Retired blocks, policies and release gates can be found.** `GET /v1/blocks`, `/v1/policies` and `/v1/release-gates` take `?includeRetired=true`, as the lists of agents, flows, tools and test sets do: one whose every version is unregistered is listed as its highest version, with `unregisteredAt`, so you can reinstate a version. In the TypeScript client, `blocks.list`, `policies.list` and `releaseGates.list` take `includeRetired`, and in the Python client `include_retired`. In the CLI, `kindgi blocks list` and `kindgi release-gates list` take `--include-retired`. `kindgi exports create` now includes them too ([Agent and tool versions](https://docs.kindgi.com/v0.4.0/guides/agents/agent-and-tool-versions.md)). - **On Cloud Run, each deployment gets a pack service of its own.** The module runs the pack orchestrator, a Cloud Run Job that Cloud Scheduler starts once a minute: each pass makes a service for each deployment that needs one, gives running ones their changed env, and retires what should go. A service scales to zero when it's idle, and its first call after that waits for an instance to start. The pack's env comes from Kindgi, with `kindgi env set`, and a secret of yours in Secret Manager can be one of its values, as a cloud secret pinned to a version ([Run a pack service for each deployment on Cloud Run](https://docs.kindgi.com/v0.4.0/deploy/self-hosted/pack-orchestrator.md)). - **Correcting an agent, its test set, and Improve work as one loop.** - A correction says what was wrong and who fixes it: Improve, a developer, or the agent's owner, which each agent now has. Its status is Open, Being fixed, With the owner, Fixed, Won't fix or Removed, and it says where it went: an Improve run, a suggested change or a pull request. - Each agent has a test set of its own: its corrections that have something to check, and cases added by hand. A case can be retired, with a reason; a retired one isn't tested again. The project-wide test sets are gone. - A test run grades each case's answer with a judging model, through the tenant's providers, and its cost counts under the test run. An answer with no model to judge it is `unchecked`, never a pass. - Checking a suggested change runs it on a frozen copy of the project's test set for that agent. Its card offers Check it, Pin it, Add as Latest and Withdraw, and says how many corrections it fixes, past 100 too. - A pin, or a move of Latest, marks the corrections its test run checked Fixed in that version, and going back reopens them. - An Improve run works in one project: it starts from the version the project runs, takes the agent's open corrections handed to Improve, and learns from cases with an answer or decisions marked wrong. It tries changes on part of the test cases and checks the best on the rest, cases it didn't learn from, and keeps a change only when it passes more cases than the version it started from and fails none that passed. The cheaper path that kept a settings change for costing less is gone. - Each block version and suggested change records who made it, as Made by in the console. - **Agents can read files: photos, PDFs and text.** A run's input, a tool's result and a conversation message can carry stored files (`files`, each a `FileValue`), and the model call sends them inline: JPEG, PNG and WebP images (5 MB each) and PDFs (10 MB) to a model that declares `vision`, and text, Markdown and CSV files (1 MB) to any model, each under a line that says it comes from outside: data, not instructions. A file that can't be shown becomes a line that names it and why, and the call goes on. A call the provider refuses for its files is sent once more without them, with a `file-refused` warning. `GET /v1/conversations/{conversationId}/messages` answers each message's `files`. Files need `KINDGI_ARTIFACTS`, and the runtime checks each file a run is started with (its type and its size) before the run starts: a bad one is refused as `bad-input`, naming it. `KINDGI_FILE_MEMORY_MIB` sets the memory, in MiB, a server keeps for the bytes of the files its agents read (512, or a quarter of the server's memory when that's less), and `KINDGI_FILE_CACHE_MIB` how much of it keeps them for later calls: half by default, or 0 for none. - **A tool can store the files it fetches, and read the files it's given.** A tool that declares `storesFiles: true` gets `ctx.files.store({ name, contentType, bytes })`, and one that declares `readsFiles: true` gets `ctx.files.read(artifactId)`. Only a tool with a handler can declare them. In a pack (protocol 2.10.0), they go through `POST /v1/tool-files` and `GET /v1/tool-files/{artifactId}`, with the call's own token. The mail tools `gmailAttachmentGet` and `outlookAttachmentGet` store a mail's attachment for the agent to read. - **An agent's corrections are its test set, in each project.** `/v1/agents/{agentId}/test-set` (`client.agents.testSet`) reads it: every correction of the agent's runs is a case, except won't-fix and removed ones. Add a case by hand with `POST .../test-set/cases`, and retire one with `.../test-set/cases/{caseId}/retire`. A test run of `agent..` freezes the project's active cases as a version first. It grades what each case expects: its decisions exactly, and its answer with a judging model. `passRate` counts those parts, so a test set of cases that expect only an answer has a `passRate` where it had `null`. A comparison says in `unchecked` why a case's answer wasn't checked ([An agent's test set](https://docs.kindgi.com/v0.4.0/guides/improve/build-a-test-set.md)). - **A pin's test run fixes or reopens its project's corrections.** When a pin, an unpin or Latest moving changes the version a project runs, and the project's test set has cases, Kindgi starts a test run of that version. When it ends, each correction it checked is `fixed` in that version, or reopened, with `reopenedIn` (`{ version, how, by?, at }`). A pin that names a finished test run of the same version, test set version and project uses that one. A release gate takes a `cases` rule: `minPassing`, and `noNewFailures`, which refuses a version that fails a case that passed before ([Release an agent version](https://docs.kindgi.com/v0.4.0/guides/improve/release-an-agent-version.md)). - **An agent has an owner.** `PUT /v1/agents/{agentId}/owner` with `{ "userId": "..." }` (`client.agents.setOwner`), with admin on the agent, names the person who owns it, and `GET /v1/agents/{agentId}` answers `owner: { userId, name }`. A correction's wrong decisions go to the owner. `kindgi agents owner ` shows it, and `--set=` sets it. - **Corrections export, and come from your users' thumbs.** `GET /v1/corrections/export?agentId=` streams an agent's corrections as CSV, or as JSON lines with `format=jsonl`, and the audit log records each export. `client.corrections.export` and `kindgi corrections export --agent=` give it, and `--out=` writes it to a file. `client.corrections.thumbs` records an end user's thumbs up or down from your app's server, as a correction of the run's answer; a thumbs down needs `why`. A suggested change says how many corrections it fixes in `correctionCount` ([Record your users' thumbs](https://docs.kindgi.com/v0.4.0/guides/improve/record-your-users-thumbs.md)). - **A reviewer can approve a fact with their own text.** `POST /v1/approvals/{approvalId}/complete` takes `factText`, with `decision: approve` on a `fact` approval only (any other answers `400 bad-input`), and the fact holds that text in place of the agent's. It's checked as the agent's own text is: not empty or only spaces, and at most 2,000 characters. The decision carries it as `decision.factText`, and `approvals.decide` takes it. The `remember` tool no longer stores a text of only spaces. - **A block version says who published it, where it came from, and where it runs.** A block version has `publishedBy`, and `source`: `api`, `deploy` with the deployment's id, or `suggested-change`. `GET /v1/blocks/{blockId}/runs-in` (`client.blocks.runsIn`) lists each project, and each segment pin, whose running agent version uses a version of the block, and whether the pack's files have it (`inYourFiles`). `kindgi blocks pull` writes the newest running version of each block into the pack's block files, and never over a file that's newer. Publishing, unregistering and reinstating a block version, and registering and unregistering a provider, are in the audit log. - **A deployment records where its pack lives in git, and a project can open pull requests.** `kindgi deploy`, in a git work tree, sends `source`: the `origin` remote as `host/owner/name`, the pack's folder, the commit, the branch, and whether the folder had changes the commit doesn't hold. `PUT /v1/projects/{projectId}/repo-connection` (`client.projects.setRepoConnection`) sets the company-wide GitHub connection a project opens its block changes' pull requests through. That connection's GitHub App needs Contents and Pull requests, read and write. - **A block change opens a draft pull request in the project's repo.** When a block version is pinned in a project, or added as its Latest, Kindgi opens a draft pull request with the new block files, through the project's repo connection: a company GitHub connection, for github.com, that a project admin picks on the project's Connections page, under Pull requests for block changes. Its first paragraph says where the change came from ("From an Improve run.", or "From a scheduled Improve run."), how many corrections it fixes, and its test set score, such as "Test set: 25 of 27, up from 23.". One that can't be opened is logged, not retried; `kindgi blocks pull` brings the version into your files instead. None is opened under `kindgi dev`. A block's versions show where each runs, and whether your files hold it. - **A suggested change is pinned, or added as Latest, for its project.** `POST /v1/suggested-changes/{suggestedChangeId}/pin` pins its version through the project's release gate. `.../add-as-latest` (`client.suggestedChanges.addAsLatest`, `kindgi suggested-changes add-as-latest`) makes it the Latest of a project on Latest, with no gate. One built on a version its project no longer runs is built again on the version it runs now, with a new check: pinning it, or adding it as Latest, first answers `409 suggested-change-out-of-date` and starts that (`details.rebuilding`). One the project's version already has, or whose block that version no longer uses, isn't built again (`rebuilding: false`). A deploy makes a suggested change in each project that pins another version of the agent (`madeBy: deploy`). It's never built again: once its project moves, pinning it answers the same 409 with `rebuilding: false`. Making, pinning, adding as Latest and withdrawing one are audit events. - **`kindgi suggested-changes pull ` writes a suggested change into the pack's files.** With `--pr`, it commits them on a new branch and opens a pull request (with `gh`), and marks the corrections it fixes that are still `open` as `being-fixed`. Both `pull` commands refuse a block file that holds edits the runtime doesn't have, naming it, and write nothing ([Suggest a change, and test it](https://docs.kindgi.com/v0.4.0/guides/improve/suggest-a-change.md)). - **`kindgi flows` and `kindgi tools` pin versions.** Each has `pinned`, `pinned-versions`, `pin`, `unpin` and `pin-history list`, as `kindgi agents` has, per project, org or tenant ([Pin a flow's version](https://docs.kindgi.com/v0.4.0/guides/flows/pin-a-flow-version.md)). - **Under `kindgi dev`, Improve runs, and a pin keeps what it writes over in your pack's files.** A pin for the whole workspace writes the version into your pack's files, as making a version live did before. It now keeps what it writes over, so pinning the version before undoes it, where before the way back was git, and an edit made since the check is no longer written over: the pin answers `409 pin-superseded`, which was `promotion-superseded`. An unpin is still refused. Before a pin writes, `kindgi agents pin` and `kindgi suggested-changes pin` say which files git hasn't committed (`uncommittedFiles` and `notInGit` on the pin check), as the console's pin dialog does, and the pin still goes. `POST /v1/improve-runs`, Suggest a change and Check again work there, and an Improve run's suggested change is for the whole workspace. Improve schedules are off there: start Improve by hand. The `returns-helper` template's README walks the loop end to end. - **Calendar tools.** `@kindgi/connections/google/tools` has `googleCalendarEventsList`, `googleCalendarFreeBusy`, `googleCalendarEventCreate` and `googleCalendarEventUpdate`, and `@kindgi/connections/microsoft/tools` has the four `outlookCalendar*` tools. Create and update invite people, so they wait for a yes in a run no person started. A connection made for mail only needs the calendar permissions added ([Calendars](https://docs.kindgi.com/v0.4.0/guides/connections/calendar.md)). - **A WooCommerce store connects with its owner's approval.** In a pack made with `kindgi init --template=woocommerce`, `pnpm connect-store https://shop.example.com` opens the store's WordPress Authorize Application page (WordPress 7.0 or later). Once one of its administrators approves, it makes the `kindgi-agent` user a Shop Manager and saves `WOO_STORE_URL`, `WOO_USER` and `WOO_APP_PASSWORD` in the pack's env, with no password copied by hand. `--hosted --env= --scope=project:` saves them for a deployed pack. - **`kindgi init --template=returns-helper`, and skills that teach the correcting loop.** The template is one agent with a find-order and a refund tool on sample orders, and three blocks. The `kindgi-fix-corrections` skill reads the open corrections sorted to a developer and fixes each where it belongs. The authoring skills say how an agent takes its instructions and settings from blocks, and what a tool call's deadline does: the pack service aborts the handler's signal at `KINDGI_PACK_CALL_TIMEOUT_MS`. - **The pack orchestrator's routes and settings.** `kindgi-runtime packs orchestrate` runs one pass of the pack orchestrator and exits, for a Cloud Run Job once a minute, with a system key that has `system:deployments` and `system:pack-env`. It reads `KINDGI_ORCHESTRATOR_RUNTIME_URL`, `KINDGI_ORCHESTRATOR_SYSTEM_KEY`, `KINDGI_ORCHESTRATOR_PROJECT`, `KINDGI_ORCHESTRATOR_REGION`, `KINDGI_ORCHESTRATOR_PACK_SERVICE_ACCOUNT` and `KINDGI_ORCHESTRATOR_PACK_SERVICE`, and gives each pack service `KINDGI_PACK_SERVICE_MAX_CONCURRENCY`, its concurrency. For a runtime behind Cloud Run IAM, `KINDGI_ORCHESTRATOR_RUNTIME_AUTH=google-id-token` adds a Google ID token to its calls. Each pass claims the round (`POST /v1/system/deployments/round`), and a deployment still waiting for its pack service carries its last `problem`. A new code, `pack-env-name-too-long`, there or on a ready one's `packEnvProblem`, means a name set as a secret is too long for the secret it's kept in, which is named after the pack service. The logs name the subsystems `pack-orchestrator` and `block-version-prs` ([Run a pack service for each deployment on Cloud Run](https://docs.kindgi.com/v0.4.0/deploy/self-hosted/pack-orchestrator.md)). - **Per-deployment pack routing works on a runtime that serves one tenant, and can seal under a key of yours.** `KINDGI_PACK_ROUTING=per-deployment` needed `KINDGI_TENANCY=multi` and `KINDGI_SECRETS_BACKEND=postgres`. A one-tenant runtime now takes it too, with `KINDGI_PACK_ENDPOINT_HOSTS` naming the hosts a deployment's endpoint may be on, and each endpoint's token can be sealed under `KINDGI_PACK_ENDPOINT_KMS_KEY`, a Cloud KMS key or a Key Vault key, in place of the secrets' own. - **Only the operator sets a pack's env name to a cloud secret.** With `KINDGI_ENV_CLOUD_SECRETS=on` (it needs `KINDGI_PACK_ROUTING=per-deployment`; off, the default, its routes answer `501 cloud-secrets-unsupported`), a system key with `system:env-refs` sets a name to `projects//secrets//versions/`, as `kindgi env set NAME --cloud-secret --tenant=` does. A tenant's own key is refused (`403 cloud-secret-system-only`). The tenant sees the names, never the path: `GET /v1/env/cloud-secrets`, and `kindgi env list` prints `NAME (cloud secret)`. - **`kindgi deploy --hosted` says how many builds are kept, and `kindgi deployments get` what keeps each.** A build's pack service stays while something a call can still ask for needs it, and no newer deployment into its project serves that. `kindgi deploy` prints `Builds kept in this project: N` (`workspace`, when the deploy names no project), and `kindgi deployments get` lists what keeps the build under `Kept for:` (`endpoint.keptFor`, and `keptBuilds` on `GET /v1/deployments`). `kindgi deployments` says why a `superseded` one was taken down ([Deploy your agent to Kindgi Cloud](https://docs.kindgi.com/v0.4.0/hosted/deploy-your-agent.md)). - **Every union in `openapi.json` maps its tags.** Nine unions, among them `AgentPinScope`, `PinScope`, `ImproveRunOutcome` and `MCPEndpointAuth`, now have a `discriminator.mapping`, so a client generated from it types each tag as the value the server sends, such as `suggested`. Nothing on the wire changes. - **In the console:** - On a runtime that serves many tenants, the runtime card says Kindgi Core is run for you, with nothing to set up or upgrade. - An empty list says what goes in it, and how to add one. - The project's Approvals card also counts approvals that belong to no project. - An agent's corrections can be exported, as CSV or JSON lines, and each export is recorded in the audit log. - An agent's tools list the version each tool's runs call. - A reviewer can approve a fact an agent wants to remember in their own words. - A run's corrections form says what to judge, and who fixes it. - Corrections, and each Cost report, have a page for each of what were their tabs: To review, To fix, Who corrects, Rules and Trends, and By agent and the like. The trail's last crumb lists them, and their addresses are the same. - Correcting links each next step. A saved correction links To fix while it isn't fixed, Run Improve on its agent when it's Improve that fixes it (for whoever may run Improve), and its case in the test set. Next run to review opens the next run's Corrections page, and a run's header has Correct this run. - An agent's and a flow's Corrections page is the project's To fix list for that agent or flow, with its filters in the page's link. A test set's case opens its run's Corrections page, an Improve run links the test set it ran on, and a pinned version links the suggested change it came from. Correction lists name each run, which opens its Corrections page, and a rule's open count opens To review for that rule. Saving over a correction on its way to a fix says which one it replaced. - A pin that would take a project off Latest warns first: pin and stop following Latest, or cancel. On a suggested change, you can add it as Latest instead. - An agent's Projects section shows the version each project runs, whether it's pinned or follows Latest, and when a pin took it off Latest or an unpin put it back. Its highest version links to the suggested change waiting in each pinned project. - An Improve start that isn't ready says how to fix each thing it's missing, and one refused while another run is going links to that run. An Improve run's page shows the check of its change on every case of the test set, against the version as it is. - Approvals come in two groups, Tool calls and turns, then Versions to pin, and the Inbox names each approval's group and filters by it. An approval with no project says why: it's for the whole workspace or an org, or it's from before Kindgi 0.1.3. - The new suggested change form keeps Suggest it off, and says so, until the content differs from what the version pins. - On the tool, flow, block and agent pages, a version's link keeps the versions table's Show retired, sort and page. - **The WordPress plugin 0.2.0 has a Kindgi menu.** Inbox, Activity, Ask and Settings are pages of their own, in the person's admin color scheme. The Inbox lists what waits for you, what waits for someone else and why, and the project's decided approvals. A card reads in words, and its buttons say what each decision does, such as **Approve and send** on a reply. A count of what waits for you shows on the menu and in the admin bar. Activity is a feed of the project's runs by day. Ask reads as a chat, and a call that didn't go through says why: it wasn't allowed, a guardrail or a connection stopped it, a reviewer rejected it, or it failed. Settings, once the site is connected, opens on a status card. The WordPress dashboard has a Kindgi box, and on a WooCommerce store an order's screen has one too, with a Kindgi column on the Orders list. Upload `kindgi-0.2.0.zip` from the 0.4.0 release over the plugin you have ([Let a store's staff ask and approve in WordPress](https://docs.kindgi.com/v0.4.0/sites/wordpress.md)). - **A site person's Ask can use the site project's tools, behind an approval floor.** A person the site signs in, whose role may ask, now has the project's tools in their own agent turns. There, every call of a tool that isn't declared read-only (`mutating: false`) in every one of its versions waits for a yes, and so does every `kindgi_remember`. An MCP tool always counts as one that changes things, so each of a store's actions waits, product lookups included. The person who asked may approve their own call when their role reviews approvals, unless the agent sets `separateApprover`. They still can't run a flow or call a tool directly ([What an Ask may do](https://docs.kindgi.com/v0.4.0/sites/wordpress.md#what-an-ask-may-do)). ## Fixed - **The runtime image has a directory for uploaded files.** `/var/lib/kindgi/artifacts` belongs to the server's user (uid `10001`), so a Docker named volume mounted there takes that owner, for `KINDGI_ARTIFACTS=local:/var/lib/kindgi/artifacts`. Each `local:` target is checked at start, and a directory the server can't write in stops it, naming the server's user id. - **A `gcs:` bucket is checked at start.** The runtime refuses to start when the server's identity lacks a permission it needs, naming each one, or when the artifacts bucket has a retention policy or a default event-based hold, since no tenant purge could delete a file there. It warns when the bucket keeps deleted files restorable (soft delete) or has a lifecycle rule that can delete files it still names. `STORAGE_EMULATOR_HOST` works in development only (`KINDGI_DEV`). - **The WordPress plugin's Ask page opens a conversation.** Since the plugin came out in Kindgi 0.1.9, a question to one of the site's own agents was refused for everyone the site signs in. The plugin named the site's project when it opened the conversation, and naming a project needs `write` on it, which a site's people never get. Now it names no project for the site's own agents, so Kindgi opens the conversation in the agent's own project, the site's. For an agent another project shares with the site's, it names the site's project, where calling the agent is enough. To get the fix, upload `kindgi-0.2.0.zip` from the 0.4.0 release over the plugin you have. - **Two fixes in the WordPress plugin's Ask and Inbox pages.** A saved conversation no longer opens with "nullnull" above it. An approval opened from its email link after it was decided no longer shows twice, under **From your link** and again under **Decided by you lately**: it opens in the Inbox under the list that holds it, **Waits for you**, **Waits for others** or **Decided**, and **From your link** shows only one that none of them holds. Both fixes are in the same `kindgi-0.2.0.zip`. - **A test run's replays no longer send `run.finished`.** Before, an endpoint that takes `run.finished` got one for each replay of a test run. A run inside another run still sends none ([Webhook events and deliveries](https://docs.kindgi.com/v0.4.0/guides/webhooks/webhook-events.md)). - **A pin's release gate reads only a completed test run.** A comparison cancelled or failed part way kept the summary of the cases it got through, and the gate checked it as if the run had completed. Now `POST /v1/agents/{agentId}/pinned/pin` and `.../pinned/check` refuse a `testRunId` whose run didn't complete (`400 bad-input`). - **OpenAI-compatible providers send a model's registered `maxOutputTokens` when the call sets none.** Before, a cap registered on a model didn't apply on OpenAI, OpenRouter, Groq or a self-hosted OpenAI-compatible server. The `openai`, `groq` and `openrouter` presets register their models with a cap, so calls through them now send it. - **The CLI runs git, and `kindgi dev`'s Linux sandbox its helpers, by their full path on `PATH`.** A `git`, or an `sh`, `bwrap`, `mktemp`, `sed` or `rm`, in the pack's folder no longer runs in their place. When one isn't on `PATH`, `kindgi dev` stops with `spawn ENOENT`. - **`kindgi deploy` says when nothing new was deployed.** When the server answers from its record of an earlier request with the same `Idempotency-Key`, it says nothing new was deployed, where it printed "Deploy complete." under its replay note. Its JSON adds `idempotentReplay: true`. - **The deploy banner and `KINDGI_PACK_ROUTING`'s description say a call goes to the newest deployment in the run's project**, not the tenant's newest. - **The Azure Container Apps guide keeps the registry login token off the command line.** It pipes the token to `docker login`'s stdin in place of a plain `az acr login`, as the module's `upgrade.sh` does ([Azure Container Apps](https://docs.kindgi.com/v0.4.0/deploy/self-hosted/azure-container-apps.md)). - **The woocommerce template's README starts with a question about your orders**, and its refund example uses a test order, since a refund of up to 100 runs with no approval when you ask for it. - **A rotated secret's old version resolves until its grace period ends.** With `kindgi secrets rotate --revoke-old-after`, the old version stopped resolving at once, as if revoked then. It now resolves until the time the rotation set, and revoking it in that window ends it at once. - **Under `kindgi dev`, a pack tool marked `resultIsOutsideData` has its results treated as outside data again.** `kindgi dev` dropped the mark, so the model got the tool's results as plain text. A deployed pack had it right. - **The Retire dialogs say where a retired one is listed.** They, and the notice on a flow, agent or tool whose every version is retired, say it's listed under Show retired. They said it stayed listed as retired, while the tables and lists hid it. ## Changed - **0.4.0 renames its ideas, and keeps no old name.** A judgment is a correction, a judge class a corrector group, the judging queue the expert queue, an eval suite a test set, an eval run a test run, choosing what a project runs a pin, an improvement pass an Improve run, a proposal a suggested change, and a gate policy a release gate. Routes, fields, values, error codes, schemas, the clients' names, the CLI's commands and flags, and the docs' addresses all change, as the lists below say. Environment promotion keeps its name: `kindgi promote`, `POST /v1/deployments/{deploymentId}/promotions` and `client.deployments.promote`. - **A judgment is now a correction.** - `/v1/judgments` is `/v1/corrections`, and `/v1/judgments/{judgmentId}/unregister` is `/v1/corrections/{correctionId}/remove`. The retention domain `judgment` is `correction` (`POST /v1/retention/sweep/correction`). - `judgmentId` and `judgmentIds` are `correctionId` and `correctionIds`. `judgmentCount`, `runsWithJudgments` and `anyJudgment` are `correctionCount`, `runsWithCorrections` and `anyCorrection`. An answer's `judgments` is `corrections`, a comparison summary's `corrections.judgments` is `corrections.results`, a comparison case's `judgedItems` is `correctedItems`, and a `changes.new` entry's `judged` is `corrected`. - The error code `judgment-not-found` is `correction-not-found`. - `Judgment` and `JudgmentWithCopies` are `Correction` and `CorrectionWithCopies`. The `{ calls, notCalled }` value that was called `Correction` is `ExpectedDecisions`, graded as `ExpectedDecisionsResult`. `Judged*` names are `Corrected*`, and `UnregisterJudgmentResult` is `RemoveCorrectionResult`. - `client.judgments` is `client.corrections`, and its `unregister` is `remove`. `kindgi judgments add|list|show|unregister` is `kindgi corrections add|list|show|remove`. - **Judge classes are now corrector groups, the judging queue is the expert queue, and judging rules are queue rules.** - `/v1/judge-classes` is `/v1/corrector-groups`, with `{correctorGroupId}` in its paths. `/v1/projects/{projectId}/judging-queue` is `/v1/projects/{projectId}/expert-queue`, and `/v1/projects/{projectId}/judging-rules` is `/v1/projects/{projectId}/queue-rules`, with the same paths below them. The retention domain `judge_class` is `corrector_group`. - `judgeClassId` is `correctorGroupId`. A correction, a corrected item and a test case's item say `expert` where they said `restricted`. `classWeights` is `groupWeights`, and its value `restricted-only` is `experts-only`. A release gate's `onlyRestrictedClasses` is `onlyExpertGroups`, and its check is named `groupWeights.expertsOnly`. The expert queue's state `judged` is `corrected`, as is a rule result's `judged` count; progress `byClass` is `byGroup`, and `wantedClassIds` is `wantedGroupIds`. - Error codes starting `judge-class-` start `corrector-group-`, codes starting `judging-rule-` start `queue-rule-`, and the other `judging-` codes start `expert-queue-`. - `JudgeClass*` names are `CorrectorGroup*`, `JudgingRule*` names are `QueueRule*`, and the judging queue's `Judging*` names are `ExpertQueue*`. In the Python client, `Restricted` is `Expert`. - `client.judgeClasses` is `client.correctorGroups`, `client.projects.judgingQueue` is `client.projects.expertQueue`, and `client.projects.judgingRules` is `client.projects.queueRules`. - `kindgi judge-classes` is `kindgi corrector-groups`, `kindgi judging-queue` is `kindgi expert-queue`, and `kindgi judging-rules` is `kindgi queue-rules`. `--class` is `--group`, `--clear-class` is `--clear-group`, and `--class-weights` is `--group-weights`. - **Eval suites are now test sets.** - `/v1/eval-suites` is `/v1/test-sets`, with `{testSetId}` in its paths and the same paths below it, `runs` too. - `suiteId` is `testSetId` wherever it names a test set, and `suiteVersion` is `testSetVersion`. A test set's and a test run's kind `judged` is `corrections`. A release gate's `comparison.suite` is `comparison.testSet`, and so is its check's name; a comparison's summary says `testSet` where it said `suite`. The retention domain and the authorization resource type `eval_suite` are `test_set`. A `reference-out-of-scope` issue names a test set with the kind `test-set`, where it said `suite`. - Error codes starting `eval-suite-` start `test-set-`. - `EvalSuite*` names are `TestSet*`, `EvalKind` is `TestSetKind`, `EVAL_KINDS` is `TEST_SET_KINDS`, and `JudgedEvalCase`, `JudgedEvalCaseCollectionPage` and `JudgedEvalCaseCorrection` are `CorrectedTestCase`, `CorrectedTestCaseCollectionPage` and `CorrectedTestCaseCorrection`. - The test set file's schema is `@kindgi/specs/test-set.schema.json` (was `eval-suite.schema.json`). A file whose `$schema` names `https://kindgi.com/schemas/v1/eval-suite.schema.json` needs `https://kindgi.com/schemas/v1/test-set.schema.json`. Its `kind` takes `corrections`, as the API does, and its reference page is [Test set](https://docs.kindgi.com/v0.4.0/reference/schemas/test-set.md). - `client.evalSuites` is `client.testSets`. `kindgi eval-suites` is `kindgi test-sets`, `--suite` is `--test-set`, and `--suite-version` is `--test-set-version`. `kindgi exports create` writes them as `test-sets` and `test-set-versions`. - **Eval runs are now test runs.** - `/v1/eval-runs` is `/v1/test-runs`, with `{testRunId}` in its paths; `cancel`, `events` and `rescore` keep their paths. `POST /v1/test-sets/{testSetId}/runs` still starts one. - A test run's own id is `testRunId` where it was `runId`: in the start and rescore answers, the run view and the list rows. Ids of agent runs, such as a case's `runIds`, keep their names. `evalRunId` is `testRunId` wherever it names a test run: in an agent pin's body, in a run's replay marker (`{ of, testRunId }`), in a replay's provenance, and in the `/v1/runs` filter. - The stream's events `eval-run.completed`, `eval-run.failed`, `eval-run.cancelled`, `eval-run.case-completed` and `eval-run.case-failed` are `test-run.*`, with the same endings. The compliance evidence kind `eval-run` is `test-run`, and `GET /v1/compliance/evidence?kind=` answers `400` for a kind that is neither built in nor named by the classifier, such as `eval-run`, where it answered an empty page. - Error codes starting `eval-run-` start `test-run-`. - `EvalRun*` names are `TestRun*`. `EvalComparison`, `EvalBaseline`, `EvalOverrides`, `EvalSample`, `EvalReads` and `EvalClassWeights` are `TestRunComparison`, `TestRunBaseline`, `TestRunOverrides`, `TestRunSample`, `TestRunReads` and `TestRunGroupWeights`. - `client.evalRuns` is `client.testRuns`. `kindgi eval-runs` is `kindgi test-runs`, and `--eval-run` is `--test-run`, on `kindgi agents pin` and `kindgi runs list`. `kindgi exports create` writes them as `test-runs`. - **Choosing what a project runs is a pin, for agents as for flows and tools.** - An agent's `/promotions` is `/pinned/pin`, `/promotions/check` is `/pinned/check`, its list of promotions and `/promotions/{promotionId}` are `/pin-history` and `/pin-history/{changeId}`, `/live` is `/pinned`, `/live-versions` is `/pinned-versions`, and `/live/unpin` is `/pinned/unpin`. `/live/rollback` is removed: going back is a pin of an earlier version, through the same release gate and approval. - `promotionId` is `changeId`: on a pinned version, in a deployment's pin gate and in a refused pin's `details`. A pin's status `promoted` is `pinned`, and the check's outcome `would-promote` is `would-pin`; a pin's action is `pin` or `unpin`. - What an agent resolves to: `via: 'live'` is `'pinned'`, and `liveScope` is `pinnedScope`. So are a run's `via` and a queue rule's `when.versions` value; a `when.versions` entry that is neither an exact version, such as `1.2.0`, nor `pinned` is refused (`400`). A test run comparison's baseline `{ live: ... }` is `{ pinned: ... }`, a compared version's `via` value `live` is `pinned`, and the CLI's `--baseline live` is `--baseline pinned`. - Unregistering a pinned agent version answers `agent-version-pinned` (was `agent-version-live`), as for flows and tools, and lists the scopes it's pinned in under `pinned` (was `live`). The permission `promote` on an agent is `pin`. The audit kinds `agent-promotion`, `agent-promotion-refused`, `agent-live-unpinned` and `agent-live-pin-inactive` are `agent-pinned`, `agent-pin-refused`, `agent-unpinned` and `agent-pin-inactive`, and `agent-rollback` is gone. - `promotion-not-found`, `promotion-superseded` and `promotion-gate-unsupported` are `pin-not-found`, `pin-superseded` and `pin-gate-unsupported`, and `live-scope-spans-environments` is `pin-scope-spans-environments`, the code a flow or tool pin answers. `nothing-to-roll-back` is gone with the rollback route. Environment promotion's codes keep their names. - `Promotion`, `PromotionPage` and `PromotionCheck` are `Pin`, `PinPage` and `PinCheck`. `PromoteBody` and `UnpinBody` are `AgentPinBody` and `AgentUnpinBody`. `LivePin`, `LivePinList` and `LiveVersionResolution` are `AgentPinnedVersion`, `AgentPinnedVersionList` and `AgentPinnedVersionResolution`. An agent's pin scope is `AgentPinScope`, made of the `PinScope*` schemas flows and tools use, with `PinScopeSegment` for a segment. In `@kindgi/types`, `LiveScope` is `AgentPinScope`. In the Python client, `LiveScopeOrg`, `LiveScopeProject`, `LiveScopeSegment` and `LiveScopeTenant` are `PinScopeOrg`, `PinScopeProject`, `PinScopeSegment` and `PinScopeTenant`, and `LiveScopeUnrecognized` is `AgentPinScopeUnrecognized`. - `client.agents.pinned` has `resolve`, `list`, `pin`, `check`, `unpin`, `history` and `getChange`; `client.agents.promotions` and `client.agents.live` are removed. Its types are `AgentPinnedClient`, `AgentPinnedWhere`, `AgentUnpinInput` and `ListPinHistoryFilter`. - `kindgi agents promote` is `kindgi agents pin`, `promotions list|get` is `pin-history list|get`, `live` is `pinned`, and `live-versions` is `pinned-versions`. `kindgi agents rollback` is removed. `` is ``. - **A deployment promotion's make-live is now a pin.** A promotion's `makeLive` is `pin`: it pins each agent version the promotion carries in the target project, each through its scope's release gate, and each flow version it carries. The answer lists the carried agents under `pinned` (was `live`), beside `pinnedFlows`. A write error after some were pinned lists them in `error.details.pinned` (was `error.details.live`) and `error.details.pinnedFlows`. `DeploymentLivePin` and `DeploymentLivePinGate` are `DeploymentPinnedAgent` and `DeploymentPinGate`. `kindgi promote --make-live` is `kindgi promote --pin`, and `--wait` goes with `--pin`; its output lists the carried agents' pins under `Agent pins in :` (was `Live in :`). `kindgi dev`'s line for a block version pinned in the console says `pinned:` (was `made live:`). - **Improvement passes are now Improve runs.** - `/v1/improvement-passes` is `/v1/improve-runs`, with `{improveRunId}` in its paths, and `cancel` keeps its path. `POST /v1/proposals/improve` is `POST /v1/improve-runs`, and `POST /v1/proposals/improve/estimate` is `POST /v1/improve-runs/check`. - `passId` is `improveRunId` wherever it names an Improve run: on a schedule's fire and on a suggested change's `madeBy`. A suggested change's `drafter` is `madeBy` and its `hypothesis` is `why`, in the body that creates one and in an Improve run's comparisons too. An Improve run's outcome `proposed` is `suggested`. A test run's `passCount` keeps its name: it counts the cases that passed. - `improvement-pass-not-found` and `improvement-pass-finished` are `improve-run-not-found` and `improve-run-finished`. - `ImprovementPass*` names are `ImproveRun*`. The start body is `StartImproveRunBody` (was `ImproveBody`), for a start and a check, and the check's answer is `ImproveRunCheck` (was `ImprovementPassEstimate`). `SuggestedChangeDrafter` is `SuggestedChangeMadeBy`. - `client.improveRuns` has `start`, `check`, `list`, `get` and `cancel`; `client.improvementPasses` and `client.proposals` are removed. Their inputs are `StartImproveRunInput` and `CheckImproveRunInput`, and `@kindgi/sdk` exports `ImproveRunsClient` where it exported `ProposalsClient`. - `kindgi improve runs start` starts one (was `kindgi proposals improve`), and `kindgi improve runs list`, `get` and `cancel` replace `kindgi proposals passes`; `kindgi proposals` is removed. `` is ``. `kindgi exports create` writes them as `improve-runs`. - **Proposals are now suggested changes.** - `/v1/proposals` is `/v1/suggested-changes`, with `{suggestedChangeId}` in its paths. `.../request` is `.../pin`. `.../rollback` is removed: going back is pinning the agent's earlier version. - `proposalId` is `suggestedChangeId` wherever it names a suggested change: on a version's `derivedFrom`, on an Improve outcome, and in a refused gate's `details`. A suggested change's status `promoted` is `pinned`. The header `X-Proposal-Deduped` is `X-Suggested-Change-Deduped`. - Error codes starting `proposal-` start `suggested-change-`. - `Proposal*` and `FixProposal*` names that stay are `SuggestedChange*`, and `FixProposalId` is `SuggestedChangeId`. A suggested change rolled back by the removed route reads as `pinned`. - `client.suggestedChanges` holds suggested changes, and its `request` is `pin`. Its `rollback` is removed: pin the agent's earlier version with `client.agents.pinned.pin`. `kindgi proposals` commands are `kindgi suggested-changes`, whose verbs change too (below), and `rollback` is removed: `kindgi agents pin` with the earlier version puts it back. `kindgi exports create` writes them as `suggested-changes`. - **A gate policy is now a release gate.** - `/v1/gate-policies` is `/v1/release-gates`, with the same paths below it, and an agent's `/gate-policy` is `/release-gate`. The operation ids `gatePolicies.*` and `agents.gatePolicy.resolve` are `releaseGates.*` and `agents.releaseGate.resolve`, under the tag `release-gates`. - A release gate's `policyId` is `releaseGateId`. The release gate a pin names is `releaseGate` (was `policy`): on a pin and in the pin history, in a pin check's answer, in a refused pin's `details`, in a `pin-gate-unsupported` answer, in a deployment promotion's pin gate, and in the answer of `GET /v1/agents/{agentId}/release-gate`. - A test run comparison's `weightedYesShare` is `passRate`, and its `judgedCoverage` is `caseCoverage`. So are the metric names in a release gate's spec, and the `objective` of an Improve run, a schedule's Improve run and the Improve run webhook event (`passRate`, the default, or `weightedPrecisionAtK`); the CLI's `--objective` takes the same values. The gate's check `baselineIsLive` is `baselineIsPinned`. - `gate-policy-not-found`, `gate-policy-already-registered`, `gate-policy-scope-taken`, `gate-policy-scope-changed`, `gate-policy-scope-unpinned`, `gate-policy-needs-pin` and `gate-policy-descendant-unpinned` are `release-gate-not-found`, `release-gate-already-registered`, `release-gate-scope-taken`, `release-gate-scope-changed`, `release-gate-scope-unpinned`, `release-gate-needs-pin` and `release-gate-descendant-unpinned`, with the same statuses and bodies. - A spec's `approvals.forRollback` is gone, since going back is a pin, which the gate checks: the key is refused as any other unknown key is. - `GatePolicy`, `GatePolicyPage`, `GatePolicyRef`, `GatePolicyResolution`, `GatePolicySpec` and `PublishGatePolicyBody` are `ReleaseGate`, `ReleaseGatePage`, `ReleaseGateRef`, `ReleaseGateResolution`, `ReleaseGateSpec` and `PublishReleaseGateBody`. - `client.gatePolicies` is `client.releaseGates`, and `client.agents.gatePolicy` is `client.agents.releaseGate`, with the types `ReleaseGatesClient`, `ReleaseGateVersionsClient`, `AgentReleaseGateClient`, `ReleaseGateFilter` and `PublishReleaseGateInput`. - `kindgi gate-policies` is `kindgi release-gates`, `kindgi agents gate-policy` is `kindgi agents release-gate`, `` is ``, and `--policy-version` is `--release-gate-version`. In an export, the kinds `gate-policies` and `gate-policy-versions` are `release-gates` and `release-gate-versions`. Don't resume an export an earlier CLI started: run it again into a new folder, since resuming writes the new kinds beside the old ones. - **The improve guides moved, with no redirects.** The pages under `guides/evals/` are under `guides/improve/`, so old links to them don't open. Four have new names: `judge-a-runs-output` is [`correct-a-runs-output`](https://docs.kindgi.com/v0.4.0/guides/improve/correct-a-runs-output.md), `propose-a-change` is [`suggest-a-change`](https://docs.kindgi.com/v0.4.0/guides/improve/suggest-a-change.md), `judging-reference` is [`expert-queue-reference`](https://docs.kindgi.com/v0.4.0/guides/improve/expert-queue-reference.md), and `live-versions-reference` is [`pinned-versions-reference`](https://docs.kindgi.com/v0.4.0/guides/improve/pinned-versions-reference.md). The 0.3 pages stay under `/v0.3/`. - **For a runtime of your own, built on `@kindgi/api`: the bindings take the new names too.** - `createApp`'s inputs: `agentReleases` is `agentPins`, `judgmentRegistry` is `correctionRegistry`, `evalSuiteRegistry` is `testSetRegistry`, `evalRunBinding` is `testRunBinding`, `judgingQueue` is `expertQueue`, `improvementPasses` is `improveRuns`, and `evalCaseStore` is `frozenCaseStore`. Each is optional, so in JavaScript an old name is ignored without an error, and the runtime runs as if that binding were absent. New optional inputs serve what's new in 0.4.0: `toolFiles`, `pinFiles`, `testSetFreeze`, `blockUse`, `blockVersionPullRequests` and `envCloudSecrets`. Each one's type says what happens without it. For example, without `testSetFreeze`, making or checking a suggested change answers `501 suggested-change-check-unsupported`, and without `envCloudSecrets` the cloud secrets routes answer `501 cloud-secrets-unsupported`. - Pins: implement `AgentPinnedVersionBinding` (was `LiveVersionBinding`) and `PinBinding` (was `PromotionBinding`), with `AgentPinBindings` and `AgentPinGateDeps` (were `AgentReleaseBindings` and `AgentReleaseGateDeps`). `AgentPinBindings` holds them as `pinned` and `changes` (were `live` and `promotions`). Their types are `Pin`, `PinStatus`, `PinAction`, `PinError`, `PinErrorCode`, `PinRequestInput`, `ListPinHistoryInput`, `AgentPinInput`, `AgentUnpinInput`, `AgentPinnedVersion`, `AgentPinResolution` and `AgentPinResolveInput`; `PromotionActor` and `PinActor` are one `PinActor`, and `liveScopeCoordinates` is `agentPinScopeCoordinates`. `rollback` and `RollbackInput` are gone, and an unregister a pin refuses answers `pinned` (was `live`). A run's `liveScope` is `pinnedScope` in `@kindgi/runtime` and `@kindgi/agents`. - Release gates: implement `ReleaseGateBinding` (was `GatePolicyBinding`) as `AgentPinBindings`' `releaseGates` (was `gatePolicies`), with `ReleaseGateError`, `ReleaseGateErrorCode`, `ReleaseGateListInput`, `ReleaseGatePublishInput` and `ReleaseGateVersionInput`. - Latest: `AgentPinBindings.latest`, a `LatestBinding`, is required, and so are `AgentPublishInput.madeFor` and `AgentRegistryBinding.markLatest`. `whatRuns` and `whatRunsByProject` answer a scope's pin, else its Latest. - Test runs and test sets: `EvalSubjectInvoker` is `TestRunSubjectInvoker`, and `EvalCaseStoreBinding`, `EvalCasePutInput`, `EvalCaseListInput` and `EvalCasePage` are `FrozenCaseStoreBinding`, `FrozenCasePutInput`, `FrozenCaseListInput` and `FrozenCasePage`. - Corrections: `CorrectionRegistryBinding` gains `update`, `counts`, `correctionsByIds` and `applyRunOutcome`, and the test set's `testSet`, `listCases`, `getCase`, `runCopies`, `addCase` and `retireCase`, all required. Its class methods are group methods: `createGroup`, `listGroups`, `getGroup`, `updateGroup` and `unregisterGroup`. It loses `listJudgedRuns`, and its `unregister` sets the status to `removed`. `sortAtSave` and `planChange` are exported, so every store sorts and changes a correction by the same rules. - Suggested changes: `SupervisorBinding`'s `listProposals`, `getProposal`, `createProposal` and `recordProposal` are `listSuggestedChanges`, `getSuggestedChange`, `createSuggestedChange` and `recordSuggestedChange`. - Pack services: `SystemDeploymentsBinding.listReady` is new and required. It answers `GET /v1/system/deployments?endpoint=ready` (`client.systemDeployments.list('ready')`): the deployments whose endpoint is `ready` and whose pack service stays, across tenants, oldest first, with the same paging as `endpoint=missing` and `endpoint=retire`. - `@kindgi/tools`: `latestVersion` is `highestVersion`, since it answers the highest version, which isn't always what a project runs. - **A correction says whether a run's decisions and its answer were right, and no old field is kept.** `POST /v1/corrections` takes `decisions` and `answer`, each `right` or `wrong`, and `items`, at least one of the three. Wrong decisions need `shouldCall` (`[{ tool, args? }]`, with `args` only when the inputs matter) or `mustNotCall` (tool ids). A wrong answer needs `shouldSay` or `why`. `items` (`[{ key, pointer?, rank?, verdict }]`) is for an answer that is a ranked list. `item`, `verdict`, `reason` and `correction` are gone, and a body with one is refused (`400`), naming its new field. A second correction of a run by the same caller, for the same `participantId`, replaces the first ([Correct a run's output](https://docs.kindgi.com/v0.4.0/guides/improve/correct-a-runs-output.md)). - **A correction is sorted when it's saved, and moves until it's fixed.** Wrong decisions go to the agent's owner (`with-owner`), a wrong answer or item goes to Improve (`open`), and a correction with nothing wrong is `fixed`, as `recorded-right`. An app end user's correction (one with a `participantId`, and not an expert's) stays `open` and unsorted, unless a project admin sets `sortEndUserCorrections: true` on `PATCH /v1/projects/{projectId}`. A correction answers `status`, `sortedTo`, `sorted`, `link`, `fixedIn`, `statusNote` and `updatedAt`. `PATCH /v1/corrections/{correctionId}` (`client.corrections.change`) sorts it again, changes its status, or both: it needs `publish` on the agent, or, for an agent more than one project serves, `write` on the correction's project. A change its status doesn't allow answers `409 correction-status-change-not-allowed`, with `details: { from, to }`. Removing a correction, by its author or an admin of its project, makes it `removed`. `GET /v1/corrections` filters by `status` (`not-fixed` for `open`, `being-fixed` and `with-owner`), `sortedTo` (`none` for the unsorted), `from` (`experts`, `end-users` or `all`), `madeBy=me`, `since` and `until`, and `verdict` is gone. `GET /v1/corrections/counts` (`client.corrections.counts`) counts a project's corrections, or one agent's, by status. - **`kindgi corrections` takes a correction's parts as the API names them.** `kindgi corrections add` takes `--decisions=right|wrong`, with `--should-call=[:]` and `--must-not-call=` (each repeatable) for wrong ones, `--answer=right|wrong`, with `--should-say=` for a wrong one, `--why=`, `--group=`, and `--item=` with `--yes` or `--no` as before. `--correction`, `--reason` and `--item=answer` are gone. Each call still adds to your correction of the run: a part it gives replaces what you said about that part. The new `kindgi corrections set ` takes `--sorted-to=improve|developer|owner`, `--status=open|being-fixed|wont-fix`, `--link` for what fixes it, and `--reason`, which `wont-fix` needs. `kindgi corrections list` loses `--verdict`, and takes `--status`, `--sorted-to`, `--from=experts|end-users|all` and `--since=