September 14–20, 2026

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.