Changelog

What changed in Vatio, newest first. One entry per released version.

One changelog for the CLI and the platform, keyed by the version vatio version prints. They are released together, and the CLI never carries a copy of the platform's rules, so a release note describes both at once.

This page is also served as plain markdown at /changelog.md, for reading it somewhere other than a browser.

This changelog starts at 0.27.0. Earlier versions shipped without one rather than being reconstructed after the fact.

0.46.0 — 2026-09-25

The docs are their own site: docs.vatio.ai.

They used to be one 1,700-line page built into the platform's Docker image. That cost two things worth losing. Fixing a typo paid for an image build and a rollout, and every reader — person or agent — got all of it or none of it.

Now there is a page per topic, with a search field, four tabs — Documentation, CLI, SDK, API Reference — and Spanish alongside English. Everything that pointed at vatio.ai/docs still works: it redirects, including the anchors of the old single page.

For agents, the contract is still one fetch. vatio docs is unchanged and still prints the whole thing, because vatio.ai/docs.md redirects to docs.vatio.ai/docs.md — no upgrade was needed for that. What is new is that every page is also Markdown on its own path plus .md, indexed at /llms.txt, so an agent working on one thing can read the one page about it instead of spending a context window on the whole contract.

Where the CLI prints a docs link — vatio --help, vatio auth --new-key, the message when vatio docs cannot reach the host — it now names the new site.

0.45.0 — 2026-09-25

vatio issue sends the workspace, not just the sentence.

Run from a workspace, the command now attaches the directory — the same files vatio push sends. A report about a tool arrives with the tool, and a report about a manifest that will not push arrives with the manifest that will not push, which is precisely the one Vatio could not see before: what it held was the last version that pushed successfully.

Vatio keeps vatio.yml and everything under tools/, lists the rest of the directory by name, and records what its own checks made of it at that moment. Anything a check complained about comes along too, so the tools/*.js and lib/*.js that 0.42.0 stopped accepting arrive with the report that asks how to port them.

Hidden files are never included, so .env and .git/ stay where they are. The command prints what it is attaching before it sends, and --no-source sends the report on its own.

0.44.0 — 2026-09-24

vatio issue list shows your issues. It reported that you had sent none while vatio issue show <id> returned those same issues, because the command read the wrong key off the response and got an empty list every time. list is the only way back to a report whose number you did not keep, and an empty one reads as "it never went through" — which is how the same problem gets filed twice.

Each row now says where the report stands — sent, in progress, with us, answered or closed — and prints the pull request when there is one, so a coding agent can watch the fix land instead of waiting to be told.

vatio kb create takes several names. A first push that declares two knowledge bases refused twice and cost a round trip per name. It now refuses once, for all the missing bases at once, and names the single command that creates them:

knowledge: no knowledge base named "docs" or "policies" on this workspace.
Create them with `vatio kb create docs policies`, then push again.

Still nothing implicit: a base exists because someone typed its name. That is what keeps knowledge: [defualt] a failed push rather than an empty base the agent searches forever, quietly answering with nothing.

Docs: the root-key table listed identity, knowledge and links, all three of which were removed in 0.41.0 and 0.43.0 and now fail the push. It lists auth, agents and entry instead.

All three were reported through vatio issue.

0.43.0 — 2026-09-24

A workspace can run several agents, and the manifest says which one answers.

Key them under agents: instead of agent:, and add an entry: table:

agents:
  home:
    name: Ana
    instructions: Answer product questions. Nobody here is signed in.
    tools: [knowledge_lookup]
  portal:
    name: Ana
    instructions: You are talking to a signed-in customer.
    tools: [my_orders, knowledge_lookup]
    knowledge: [portal_kb]

entry:
  - { authenticated: false, agent: home }
  - { claims: { role: staff }, agent: staff }
  - { agent: portal }

The table is ordered and the order is the rule: the first row whose conditions hold wins, and the last row is the fallback. Letting each agent declare its own entry condition was the other design, and it loses on precedence — two agents that both say "authenticated" need a specificity rule nobody wants to reason about. Here the whole policy reads top to bottom in one place, and a reviewer can check it without knowing how Vatio works.

This is for the marketing site and the customer portal that embed the same widget. The anonymous visitor asking about prices and the signed-in customer asking about their own records are not the same conversation, and one set of instructions serving both serves neither. Until now that meant two workspaces: two manifests, two knowledge bases and two tokens to keep in step.

agent: still means exactly what it did — one agent, keyed main.

knowledge: and links: move onto the agent. They used to sit at the root and apply to the workspace; now each agent states its own, and there is no inherited default. A manifest that still declares either at the root fails the push and says where to put it — one edit, and vatio diff shows nothing else changed.

The repetition is the point. What an agent knows and which urls it may hand out are the two things you check when it answers wrongly, and an inherited value means looking somewhere else and then working out whether this agent overrode it. It also matters in the prompt: every declared url is listed there, so a portal agent would otherwise carry a marketing agent's whole link list around without ever handing one out. Duplication you can see beats inheritance you have to reconstruct.

Which agent you get is settled before the first reply, on every channel: Vatio verifies the token as the conversation opens, so the choice happens before the first message is answered rather than after. Sign in mid-conversation and identify() runs the table again — same thread, same history, and from the next message on, the agent for who you now are.

entry: is not a security control and is not built as one. A visitor with no valid token has no verified identity, so no access: private tool runs for them whatever agent they land on: a wrong row shows the wrong prompt, never someone else's data. Protect data with access: private on the tool, as before.

No migrations. A workspace with one agent needs one edit: move knowledge: and links: inside the agent: block.

0.42.0 — 2026-09-24

A tool is one HTTP call to your backend. JavaScript tools are gone.

tools/*.js ran in a sandbox Vatio operated, and lib/*.js were the helpers bundled with them. Both are removed, along with the runtime behind them.

The reason is the same one that removed auth/*.js in 0.41.0: the file you wrote was never really the point. Every JavaScript tool deployed on Vatio was either a call to a backend the workspace already ran, or the scaffold nobody edited. Meanwhile the platform was carrying a bundler, a sandbox, a deploy step and a second execution model so that code with somewhere better to live could live here instead.

So it lives there. Describe the call in tools/<key>.yml with request: and respond:, and put whatever the call needs to do — branching, a second request, composing a response — in the endpoint it hits. That endpoint is yours: it can already read your database, and it does not have to be redeployed through us to change.

vatio push and vatio tools check refuse a tools/*.js or lib/*.js and name the file. Nothing else in a manifest changes, and access: private, $auth, $env and the result contract all work exactly as they did.

Also gone: the 301 from /vatio-widget.js to the CDN, which no page still used, and a route: field documented on tool results that was never implemented.

0.41.1 — 2026-09-23

vatio auth --new-key told you to keep identity.pem secret and stopped there, which left the one question a developer actually has unanswered: secret where. It says it now, and so do the docs — the private half goes into your own backend, because your backend is what signs, and then out of the workspace directory.

Explicitly not into vatio secrets. That store is read by Vatio, and a private key in it would let Vatio mint tokens for your users rather than only check them, which is the property the whole design is built around.

0.41.0 — 2026-09-23

Authentication is one JWT you sign, on every channel.

There used to be two ways to tell Vatio who a visitor is: an identity: block that verified a token your page signed, and auth/*.js — a JavaScript file you wrote, deployed and maintained, whose whole job turned out to be one HTTP call. The second existed because WhatsApp carries a phone number and nothing else, so someone has to ask your backend whose it is. Asking is fine. What was wrong is what came back: a plain answer Vatio then asserted to your own API. The platform ended up being something you had to trust about identity.

Now it carries proof instead. You sign a JWT, Vatio verifies it with your public key, and your tools get it as $auth.token. On the web your page puts it on the widget. On WhatsApp Vatio posts the phone number to your mint: endpoint and you sign one back — the same token, verified the same way. Vatio holds only a public key, so it can check a token and never mint one, and that is now true on every channel rather than only on the web.

auth:
  public_key: identity.pub
  mint:                                  # only for channels with no session
    url: $env.API_URL/api/vatio/identity

vatio auth --new-key generates the pair, gitignores the private half, and prints the exact claims to sign.

Also: the token's expiry means something now. The old design resolved a visitor once and cached the answer for the life of the conversation, so a twelve-hour token stopped being checked after the first minute of a chat that ran longer. Verifying a signature costs microseconds, so it happens on every tool call. On WhatsApp an expired token re-mints itself and the conversation carries on.

Signing in no longer costs you the conversation. Someone asks a question, the agent tells them to sign in, they do, and they come back: the chat they already had is still there, now with a name on it. Whether they signed in through identify() or by navigating away and reloading the page with a token makes no difference.

It used to start over — and a visitor who was already signed in lost their conversation on every page reload, because the SDK's session key was computed over the whole token and a backend signs a fresh one on each render. The key is the subject now.

What is never carried over is somebody else's conversation: a chat that belonged to sub A never passes to sub B, so signing in as a different person looks exactly like arriving for the first time. The server decides that, not the page.

Breaking. identity: is auth:. authentication.schemes and auth/*.js are gone, and so are scheme names: a tool is access: private or public. audience is no longer declared — it is your workspace slug, and it is now required in the token, so a JWT you signed for something else cannot be replayed as an identity. A private tool that declares user_id (or customer_id, account_id, member_id, patient_id, subject) as a parameter now fails the deploy instead of warning: the model fills parameters, so that one was always a way to ask for someone else's data. Every error names what to do instead.

0.40.0 — 2026-09-23

A knowledge base holds entries, and an entry is Markdown.

It used to hold "sources", and a source was either a crawl — which produced documents you could not open, let alone fix a typo in — or an upload, which kept only the chunks it was cut into. Three words for two things, and you had to know which was which to read the screen. Now there is one kind of content: an entry, written by you or written by a site.

A site is one URL. No include or exclude lists: the URL says it, and a URL is that URL while a pattern is every page that matches it.

What you write	What it reads
acme.com	the home page, and only it
acme.com/help	that one page
acme.com/**	every page of the site
acme.com/help/**	that section, however deep

Vatio reads each site again every night and rewrites the entries it owns, so a base keeps up with the pages it mirrors without anyone pressing a button. A page whose Markdown has not changed costs one request and nothing else — it is not re-indexed and not re-embedded. An entry a site wrote is not editable: the next read would overwrite it without a word, so you change the site.

Same actions everywhere. vatio kb write BASE ENTRY [FILE] puts Markdown under a name — creating it or replacing it, reading stdin when no file is given — vatio kb cat prints exactly what Vatio holds, and vatio kb follow, unfollow and refresh manage sites. add-source, upload, rm-source and reindex are gone, along with the two kinds of source they addressed. In the API, entries live at /knowledge_bases/:name/entries/:entry (PATCH to write, GET for the Markdown) and sites at /knowledge_bases/:name/sites.

Redirects are followed. A site that answers 301 or 302 — an apex sending you to www, a / sending you to /home — used to index nothing at all and report that it had completed. So did a sitemap behind a redirect. And a page that produces no text now says why, instead of disappearing from a run that claims success.

Accents survive. A page whose charset lives only in its HTTP header was parsed as Latin-1, so "Narváez" was indexed as "Narváez" and nobody searching for the name would find it.

0.39.0 — 2026-09-23

One API, one view, and environment said out loud.

The docs used to describe two chat APIs under one heading, as though you got to pick. You never did: one is you holding a vat_ token, the other is a stranger's browser. The browser one is now documented as what it is — methods of the SDK, its only client — and the API section is what your developer token opens, each group naming the vatio command that does the same thing.

view is gone from the chat endpoints. It took visitor or developer and quietly turned anything else into visitor, so view=debug — the guess almost everyone made — returned a smaller payload with no error and looked complete. Holding the developer token is the developer view, so both reads now answer in full: deleted messages, tool calls with their results, attachments, delivery receipts, and the identity block. Print what you need. vatio chat transcript is unchanged for you; it filters the visitor's half of the thread itself now instead of asking the server for less.

environment is required on POST /chats and POST /chats/:id/reset. It was the one field in the API that defaulted to live — leave it out of a hand-written request and you were holding a real conversation with your published agent: billed, in your inbox, tools running against live secrets. A missing or unparseable environment is now 422 and creates nothing. The CLI always sent preview, so nothing changes if you talk to Vatio through it.

0.38.0 — 2026-09-22

The SDK is on npm, and the widget is the only thing you paste into a page. Two changes with one shape: everything Vatio ships is now either a package you install or a page you visit, and the list of scripts that go into somebody else's HTML is one item long.

npm install @vatio-ai/sdk

import { Vatio } from "@vatio-ai/sdk";

cdn.vatio.ai/v1/sdk.js is gone, and so is the /sdk/1.js redirect to it. Nothing fetches the SDK at runtime any more: widget.js bundles it, which is a little larger and one whole failure mode smaller. That mode was worth losing — a dynamic import() is a module fetch, so it was a CORS request from every page that wasn't vatio.ai, and when it failed all the browser said was "Failed to fetch dynamically imported module", which reads like a 404 and never was one. It cost a production afternoon once.

No bundler is still fine — https://cdn.jsdelivr.net/npm/@vatio-ai/sdk/+esm serves the same module. Pin the major the ordinary way, "^2.0.0": a semver range in your package.json is what the /v1/ in the old URL was reaching for, and says it better.

The inbox is a page in Vatio, and there is no credential anywhere near it. It used to be a second embeddable script (inbox.js) you mounted in your own product and authenticated by signing a JWT against an inbox: block in vatio.yml. All of it is gone: the script, the block, and the API behind them. vatio push refuses inbox: now, so delete it and the key file it names.

Invite supervisors from Team in the console. They sign in with a code to their email and land on /workspaces/<id>/inbox — every conversation, replies, human takeover, ratings, the runtime trace. Remove them from the same page and the next request they make is refused, including a socket they already had open.

That is the whole access model, and it is deliberately the smallest one available: being signed in to Vatio, as someone this workspace invited. No token to mint, nothing to sign, nothing that expires on its own schedule, and no second place that can grant access to a conversation.

The old design asked every developer to build and run a small authentication system — generate a keypair, guard the private half, pick an algorithm, pick an expiry, remember to rotate — to answer a question Vatio can already answer, and the answer granted read-and-reply on every conversation in the workspace. The version that replaced it had Vatio issue the credential instead, which was better, and it was still a credential, an exchange endpoint, a token table and a CLI command in service of a supervisor UI nobody outside Vatio had built. Withdrawing the option is what actually removed the cost.

Building a supervisor UI inside your own product is not supported for now. If that is something you want, say so — reopening it means adding a credential back to a client that already works, not rebuilding the feature.

https://vatio.ai/vatio-inbox.js no longer redirects anywhere, because there is no longer anything to redirect to. vatio-widget.js still does, and will.

0.37.2 — 2026-09-22

The package is @vatio-ai/cli. The command is still vatio — a package's name and the binary it installs are separate things:

npx @vatio-ai/cli init my-agent           # nothing installed
npm install -g @vatio-ai/cli && vatio push

Two reasons for the scope. The first is forced: npm will not publish a package called vatio, because it reads as a typo of valtio, an unrelated state library, and the registry refuses names close enough to an existing one to be mistaken for it. That rule is worth respecting rather than routing around.

The second is the one that decided it. The CLI will not be the only thing Vatio publishes — a frontend built on the SDK wants npm i @vatio-ai/sdk, not a script tag — and a scope claimed now is one name that stays coherent instead of two that have to be reconciled later.

Nothing else changed: same commands, same flags, same ~/.vatio/config.json.

0.37.1 — 2026-09-22

vatio whatsapp connect opens the browser too. It printed the link and stopped, while vatio instagram connect printed it and opened it — two sibling commands behaving differently for no reason a developer could see.

The link is still printed first and still printed in full, so nothing is lost where there is no browser to open: over SSH, in a container, on a headless machine, the call quietly does nothing and the URL is there to paste.

0.37.0 — 2026-09-21

vatio whatsapp connect prints a link, and pasted credentials are gone. The command took --phone-number-id, --waba-id and --token. It takes no flags now: it prints a URL and stops, the same shape as vatio instagram connect and vatio login.

This is not a CLI preference, it is what connecting a number actually is. Meta's Embedded Signup is a consent screen a person has to read, and the three ids the flags wanted only exist after it has run — so for the case that matters most, a number sitting in the WhatsApp Business app on someone's phone, the flags could never have worked at all. That number can now be connected and stay in the phone app, which only this flow can do.

The form in the app is gone with it, along with "Enter details manually instead". An expired access token is renewed by running the same connect flow again: Meta hands back a fresh token for the same number and it replaces the old one in place. Connecting a different number still has to be a disconnect first.

If you were scripting vatio whatsapp connect with flags, it now exits telling you the option is unknown. Everything else about the command group — status, check, activate, deactivate, disconnect, and all of numbers — is unchanged.

0.36.0 — 2026-09-21

The CLI is an npm package now. There is nothing to install:

npx @vatio-ai/cli init my-agent
npx @vatio-ai/cli push

If you have Node 20 or newer you have the CLI. The Ruby one that curl … /install.sh | bash put in ~/.vatio-cli/ is gone, and so is /install.sh itself.

Why: Node is the runtime this audience already has, and Ruby is the one some of them do not. A CLI that asks you to find a runtime before it can help you is a CLI that loses the people it was written for.

What carries over: your login. It is the same ~/.vatio/config.json, with the same keys — run npx @vatio-ai/cli push and you are already authenticated. Every command keeps its name, its flags and its output.

To migrate: delete ~/.vatio-cli/ and the vatio symlink in ~/.local/bin/, then use npx @vatio-ai/cli (or npm install -g @vatio-ai/cli). Nothing else to do.

vatio update is gone with it: npx @vatio-ai/cli runs the current release every time, so there is no version of the CLI that can fall behind the platform. A global install updates with npm install -g @vatio-ai/cli@latest.

vatio pull is removed. It overwrote your local files from a deployed manifest, and the reason to stop is that it could never tell you anything your repository did not already contain.

A deployed manifest is only ever produced by a push. Nothing else writes one — no screen in the Vatio app edits your agent, your tools or your widget, because vatio.yml owns all of it. So what pull handed back was your own repository, one round trip later, and less: the logo it admitted it could not restore, because a revision keeps that file's name and digest and never its bytes.

If you want to see what is actually deployed:

vatio diff --env live    # what your directory would change there
vatio diff --full        # both manifests in full

And the manifest itself is one request: GET /api/v1/:slug/deploy/manifest.

The CLI test suite is removed too, along with the Ruby 2.6 CI job that ran it. It tested a CLI that is being replaced, and the drift guard it carried — the one that reconciled the command dispatch against vatio help and against these docs — is gone with it. Adding or renaming a command now needs those three read against each other by hand.

0.35.0 — 2026-09-21

A chat is you, and vatio chat can talk to live. vatio chat --channel whatsapp --from +56912345678 let you arrive at your own agent as a simulated WhatsApp visitor. It is gone, on both sides — the CLI no longer sends it and the platform no longer accepts it.

It was a fake version of something that exists for real. The shared WhatsApp preview number and Instagram test accounts put a genuine message through a genuine channel, with the real verified phone number attached; the simulation only ever produced something channel-shaped, and it had to be kept in step with the real path forever. It drifted instead: the same module decided which contact a chat attached to, in two places at once.

What replaces it: nothing, for identity. A chat belongs to the token you are holding, on the cli channel. What you gain instead is the deployment:

vatio chat "Hi"              # preview, as before
vatio chat "Hi" --env live   # the published agent
vatio chat reset             # a visitor this workspace has never met

A chat against live is a real conversation. It lands in your inbox next to the ones visitors started, and nothing downstream knows it came from a terminal. The CLI says so when it opens one; it does not ask twice.

Breaking

• vatio chat --channel and --from are removed, and so are vatio config set channel / from. A config file carrying them is cleaned up on next use.
• --sandbox-url is now --api-url, and VATIO_SANDBOX_URL is gone. Nothing else is called sandbox any more: the word was already preview everywhere else.
• .vatio-sandbox.json is now .vatio-chat.json, and holds one open chat per deployment instead of one overall — switching to --env live and back no longer loses your place. The old file is deleted, not migrated: half of what it stored was the simulated identity.
• POST /api/v1/:slug/chats and /reset take environment and nothing else. channel, from, session_id, reply_style, email, phone_number and as are all refused with removed_field and a message saying to run vatio update. A CLI older than this one sends channel and session_id on every chat, so vatio chat stops working until you update — deliberately, rather than accepting fields it would ignore and letting the next request, the one that actually meant something, be the one that breaks.
• Nothing is called sandbox any more. Instagram's shared test surface now reads the way WhatsApp's always did: the shared Instagram preview, not "the sandbox". Same change in the CLI help, the docs, the console labels and the API error messages. The JS sandbox that tools run in keeps its name, because that is what it is.

Also fixed

The one-time nudge after a workspace's first push — the one pointing at the free WhatsApp preview number — never printed. The server renamed the field to whatsapp_preview_hint when sandbox became preview and the CLI kept reading whatsapp_sandbox_hint.

0.34.0 — 2026-09-21

One flag picks the deployment: --env. Saying which deployment a command was about used to depend on the command. push and publish took --as NAME, pull took --preview, tokens and widget took --environment or -e, and diff took nothing at all — it compared against preview and there was no way to ask it anything else.

Now every command that touches a deployment takes --env NAME, where NAME is live, preview, or a named preview like pr-42:

vatio diff --env live           # what would publishing change?
vatio pull --env pr-42          # bring that preview's manifest down
vatio tokens create --env pr-42 # a publishable token for it

Two things this unlocks that were not possible before:

• vatio diff --env live. The question "what does publishing actually change" had no CLI answer; you had to push, then read the console.
• Named previews outside push. tokens and widget rejected anything but live or preview, so a workspace could deploy to pr-42 and then have no way to mint the publishable token that makes it embeddable. The CLI refused a name the platform had just accepted.

Nothing is removed. --as, --preview, --environment and -e all still work, and every default is the one it was: push writes a preview, pull brings down live.

0.33.0 — 2026-09-21

The CLI stopped parsing your workspace; Vatio does it. vatio tools check, vatio diff and vatio push used to read vatio.yml, your tools/, auth/ and lib/ files and build the manifest on your machine, against rules compiled into whichever CLI version you happened to have installed. They now send the directory to the platform, which builds the manifest, validates it and answers with the errors, the warnings and the diff.

What this fixes: the rules are the platform's, so a workspace that checks clean is a workspace that deploys, and a contract change reaches you without an upgrade. vatio diff and the console no longer disagree about links: — they were two implementations of the same comparison, and one of them had drifted.

What it costs, and you should know before upgrading:

• vatio tools check and vatio diff need the network and a login. They were local commands; they are not any more. Run vatio login first, and expect a round trip where there used to be none.
• They also need the workspace to exist on Vatio. vatio push still creates it for you; a check before your first push will say the remote is missing.

Nothing about vatio.yml, tools/, auth/ or lib/ changed. The same directory that deployed on 0.32.0 deploys on 0.33.0.

Your workspace is sent as files, so the usual exclusions apply: anything hidden (.env, .git/) and node_modules/, tmp/ and log/ are never uploaded. A workspace is capped at 500 files, 2 MB per file and 8 MB in total.

0.32.0 — 2026-09-20

vatio.yml owns the whole widget, and the snippet drops to two attributes. The widget: block set the accent, the logo, the locale and the about text; everything else about how the widget looked — its corner, its colour scheme, its radius, its font, its greeting, the suggestions on the empty state — could only be said as a data-* attribute on every page that embedded it. A workspace with the same widget on five pages repeated the same ten attributes five times, and changing one meant a website deploy.

All of it is widget: now:

widget:
  accent_color: "#2563eb"
  position: right
  scheme: light
  font: inherit
  radius: 20px
  greeting: What can I help you with?
  suggestions:
    - Where is my order?
    - How do returns work?

The precedence is the host page's data-*, then vatio.yml, then the platform default — field by field, so a page that has to differ still can, and the snippet only carries what is specific to it:

<script async src="https://cdn.vatio.ai/v1/widget.js"
        data-workspace="acme" data-token="vatpub_..."></script>

data-display and data-mount have no widget: key on purpose: they say where the widget goes in one page's DOM, which is the part a page really does own.

A key widget: does not recognise fails the push. possition: right validated, pushed, exited 0 and did nothing — the only signal was a bubble that had not moved. It is an error now, and the message names what the block accepts.

0.31.0 — 2026-09-20

A source name belongs to one kind of source, permanently. An upload whose filename matched an existing crawl used to win, without saying so: the crawl's site_url and globs were overwritten, the pages it had already indexed stayed underneath answering lookups for a source that no longer said where they came from, and the command exited 0. Declaring a crawl over an existing upload did the same in reverse, which is worse — a crawl can be rebuilt from the site, an upload is the only copy of what it holds.

Both directions are refused now, and the error names what is already there:

$ vatio kb upload default kb/ayuda.md
Error: default already has a source named "ayuda", and it is a crawl of
https://home.saludtech.cl include=/ayuda/pacientes/**. An upload cannot
take over a crawl -- rename the file, or drop the crawl first with
`vatio kb rm-source default ayuda`.

Refusing beats merging or renaming for you: upload ayuda.md onto a crawl named ayuda reads as both "replace my crawl" and "I did not realise the names collide", and only you know which one you meant.

A batch upload is all-or-nothing. vatio kb upload BASE kb/*.md now checks every file against the base before it sends the first one, so a collision on file twenty no longer leaves nineteen uploaded and the rest refused.

0.30.0 — 2026-09-17

vatio issue --template is prompts now, not a form. A written-up issue used to have to carry four headings — Motivation, Proposal, Open questions, Prior art — and a document that skipped one came back rejected. That asked for an RFC. It mostly produced either an RFC-shaped wrapper around one real sentence, or nothing at all, because the person with something to tell us did not feel like filing a proposal.

There are no required sections any more. --template prints prompts you are free to keep, delete or answer out of order, and the platform asks only for a one-line title of your own and a body that says something — so a document that came back untouched is still refused, and a rough one is not:

vatio issue --template > issue.md   # prompts, not a form
vatio issue --file issue.md

"I don't know what the right fix is" is a fine thing to send.

The mail around an issue says less, and the thread says it instead. The acknowledgement used to promise that a person reads every one and invite a reply — which made the inbox look like the channel when it is not. It is now a short confirmation that the issue was submitted, plus where to read it. Two mails go out per issue, submitted and answered; the notes while it is worked on and the pull request are posted to the thread and never mailed, and a reply to either mail does not reach the thread. vatio issue show prints the whole of it.

0.29.0 — 2026-09-17

An issue is now a conversation, and it lives in the CLI. vatio issue was one-way: you sent something, we replied by email, and the reply landed in a mail client — the wrong place for it, because the thing that has to act on the answer is the coding agent in the repo the issue came from.

vatio issue list                     your issues, and who owes a reply
vatio issue show 4                   the whole thread, as markdown
vatio issue show 4 --save            write it beside your code, for your agent
vatio issue comment 4 "still broken" add to the thread

show prints the same document our own triage reads — the problem, the diagnostics the CLI attached, and every message either side has written — so your agent can pick up the answer and implement it without anyone retyping a summary. comment adds to it; a person reads it and answers into the same document. Replying to an issue we already handled reopens it.

Comment rather than opening a second issue: a follow-up that arrives as a new report throws away everything the first one established. You see your own issues and nothing else, and email still carries every message — it is a mirror of the thread now, not the only copy.

links: now survives a push. A block the platform could not store used to be dropped in silence — a successful push, a vatio diff reporting it as added forever, and an agent behaving as if you had never written it. links:, identity: and inbox: were all affected. They now deploy, and a root block the platform does not understand fails the push instead of vanishing.

0.28.0 — 2026-09-16

An unknown key in vatio.yml is now an error. Before this, a key the CLI did not recognize was dropped on the way to the platform: a typo deployed a workspace missing whatever you meant to configure, and a block from a newer version of the manifest deployed as if you had never written it. Both were silent. Now the push stops and names the key, and says to run vatio update if the key is one you expect to exist — which is the case this is really for:

vatio.yml: unknown key `links:`
If this is a newer manifest feature, your CLI is behind — run `vatio update`.

vatio update says what it is about to install. It prints the changelog entries between the version you have and the one being installed, so an update is a decision rather than a version number going up.

0.27.0 — 2026-09-16

links: — the URLs your agent is allowed to share. A URL written into instructions: never reached a visitor: the no-unauthorized-links safeguard allows only URLs the agent was actually given, and instructions: is text the model may rephrase, so the draft was discarded and the link stripped. links: is where a URL is given:

links:
  login: https://saludtech.cl/login
  agendar:
    url: https://saludtech.cl/{especialidad}
    when: The visitor wants to book an appointment
    values:
      especialidad: [nutricion, kinesiologia, psicologia]

A {placeholder} always lists the values it can take, and a deploy expands the link into one concrete URL per value. Those are what the agent is shown and what the safeguard allows: it copies one, it never assembles one. Leaving values: out is an error — an open template would have the agent fill in the slug itself, and nothing downstream could tell a real one from a plausible one.

See Links for the full field reference.