120 lines
6.7 KiB
Markdown
120 lines
6.7 KiB
Markdown
# Changelog
|
|
|
|
What each published build changes for you, newest first.
|
|
|
|
The three images are versioned independently and their numbers are not meant to match — usually only
|
|
one of them changed. An entry says which artefact and which version, so `web 0.102.0` and
|
|
`api 0.81.0` sitting under the same date is the ordinary case, not a mismatch.
|
|
|
|
Every version published to a channel appears here. Nothing is written from memory afterwards: a build
|
|
cannot be published without its entry.
|
|
|
|
## api 0.82.0 · web 0.103.0 · agent 0.27.0 — 2026-08-21
|
|
|
|
**Nothing changes in what these builds do.** They are identical in behaviour to api 0.81.0,
|
|
web 0.102.0 and agent 0.26.0, rebuilt so that every published image carries the same set of
|
|
registry labels: what the image is, where its documentation lives, and a link to this file. The
|
|
package page in the registry now says something useful to somebody who lands on it without
|
|
context.
|
|
|
|
Upgrading is worthwhile only for that. If you are running the previous three and reading this,
|
|
you already have everything they do.
|
|
|
|
**The earlier version tags have been removed from the registry.** Every build before these three
|
|
is gone; the `stable`, `dev` and `latest` channels point at them. If you had pinned an exact
|
|
older version in `.env`, that pin no longer resolves and `docker compose pull` will fail — pin
|
|
one of the versions above instead, or drop the pin to follow `stable`.
|
|
|
|
## api 0.81.0 — 2026-08-21
|
|
|
|
**Approving a plan now actually authorises it.** When Jarvis asks for consent on a whole plan and you
|
|
approve it, the steps that touch the machines the plan names are no longer confirmed one at a time.
|
|
Previously the approval bound nothing at all — the assistant was asked to honour it and the executor
|
|
never checked — so an approved plan still stopped at every step, and a read-only conversation could
|
|
be granted a plan it had no way to carry out.
|
|
|
|
The clearance is deliberately narrow. It applies only in the conversation the plan was raised in,
|
|
only to the machines the plan names, only up to a risk ceiling, and only for four hours. Anything
|
|
outside it still asks. It can never be wider than the approver's own access to those machines.
|
|
|
|
**Two ways somebody could get more than they should, closed.**
|
|
|
|
- Approving used to lend the approver's own permissions to the plan for the rest of the turn. Work
|
|
now runs as whoever asked for it, which is what the audit trail already claimed.
|
|
- Deciding a plan asked nothing about whether the decider may touch the machines it names — the
|
|
per-command confirmation had checked this for months and this path had not. It does now, for every
|
|
machine in the plan. Refusing is never restricted: anyone who can see a plan is wrong may stop it.
|
|
|
|
**Wording that was not true.** A command that was waiting for a human when the server restarted used
|
|
to be reported as possibly having taken effect, and told you to go and check the machine. It never
|
|
ran — the confirmation happens before anything is sent — so it now says so.
|
|
|
|
If you have approval requests older than this release, they are recorded as expired. They were made
|
|
under the old behaviour, where approving authorised nothing; treating them as live permissions would
|
|
grant something nobody was asked for.
|
|
|
|
## web 0.102.0 — 2026-08-21
|
|
|
|
**The approval panel says what approving does.** It used to promise "Jarvis runs the steps below" and
|
|
"Nothing runs until you decide". Neither was true: a pending plan blocks nothing, and approving did
|
|
not run anything. It now describes the clearance you are actually granting — which machines, what
|
|
ceiling, how long — and the rejection notice no longer claims that nothing ran.
|
|
|
|
The per-command confirmation is unchanged. That one does hold the command until you answer.
|
|
|
|
## api 0.80.0 · web 0.101.0 — 2026-08-21
|
|
|
|
**The footer says which channel this instance follows**, beside the version numbers, when you set
|
|
`JARVIS_CHANNEL` in `.env`. Leave it empty if you pin exact versions — you then follow no channel,
|
|
and the footer shows nothing rather than a label that stopped being true.
|
|
|
|
## api 0.78.2 · web 0.100.2 — 2026-08-21
|
|
|
|
**Distribution channels.** Images now carry `stable` and `dev` tags as well as their version.
|
|
`stable` moves only after a build has run on the publisher's own instance; `dev` moves on every
|
|
build. `latest` is a second name for `stable`, so nothing that already used it has to change, and
|
|
the compose files default to `stable`.
|
|
|
|
A channel is a pointer and a version is a fact. Promotion copies the manifest of an image that has
|
|
already been published and run — it never rebuilds — so the bytes you receive are the bytes that were
|
|
tested, not a fresh build of the same source.
|
|
|
|
**Fixed: some builds reported their version as `dev`.** The version is stamped into the image and
|
|
shown in the footer; a build published without it said `dev` while being tagged, pinned and run
|
|
correctly. Affected api 0.78.0 and 0.78.1 and web 0.100.0 and 0.100.1.
|
|
|
|
## web 0.100.0 — 2026-08-21
|
|
|
|
**Recorded terminal sessions can be replayed** at the pace they happened, not only read as a finished
|
|
transcript. Idle time is compressed so a session that was mostly waiting is watchable, and how much
|
|
was skipped is stated. Sessions recorded before this release can still be read; they carry no timing,
|
|
so they cannot be replayed, and the panel says so rather than hiding the control.
|
|
|
|
## agent 0.26.0 — 2026-08-21
|
|
|
|
**The command is now `jarvis`.** `jarvis-agent` keeps working and will continue to: both names are
|
|
present on every machine, and an agent that updates itself gives itself the missing one. Uninstalling
|
|
is a verb — `jarvis uninstall` — beside `status`, `start` and `stop`. The old
|
|
`jarvis-agent-uninstall` command is unchanged.
|
|
|
|
`jarvis uninstall` refuses to run from inside a Jarvis terminal on the machine it is removing.
|
|
Stopping the service would kill the command mid-way, leaving the agent stopped and nothing
|
|
uninstalled, with no connection left to fix it through. Run it from an ordinary SSH session.
|
|
|
|
## agent 0.25.0 — 2026-08-21
|
|
|
|
Internal: the agent asks the machine which name its service is registered under rather than assuming
|
|
one. No visible change; it is what makes a later rename survivable.
|
|
|
|
## agent 0.24.0 — 2026-08-21
|
|
|
|
**Remote terminal on macOS.** Interactive shells now work on managed Macs, as they already did on
|
|
Linux and Windows. The session opens a login shell so the PATH matches what an administrator expects.
|
|
|
|
**Fixed: sessions were recorded as "closed" instead of "exited".** Typing `exit` ended the session
|
|
correctly but filed it as though it had been taken away, with no exit code. Sessions from before this
|
|
release keep the reason they were given.
|
|
|
|
**Fixed: a file descriptor and a thread leaked on every clean exit.** Only visible on machines that
|
|
stay up for a long time with many sessions.
|