149 lines
8.6 KiB
Markdown
149 lines
8.6 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.83.0 · web 0.104.0 — 2026-08-21
|
|
|
|
**Jarvis no longer needs a licence key to be useful.** An instance without one now runs the
|
|
**community edition** — 1 organization, 3 users, 5 agents, 10 assets — perpetually, free, with every
|
|
feature working and nothing reported to anybody. Install it, connect it to something real, and see
|
|
what it does before there is anyone to talk to. A licence raises those limits; it does not switch the
|
|
product on.
|
|
|
|
This replaces the behaviour of the last three days, where an instance with no key came up, accepted
|
|
its first administrator account and then refused everything else. **If you installed Jarvis and found
|
|
it would not let you create anything, this is the release that fixes it** — upgrade, and the
|
|
allowances above apply immediately. Nothing needs to be reset, re-run or re-entered.
|
|
|
|
**A licence that stops applying now falls back to the same allowances**, instead of refusing every
|
|
creation. Expired, withdrawn, or a key that will not verify: your instance keeps running everything
|
|
already set up and may still create up to the community numbers. There is no state left in which
|
|
Jarvis stops being usable over a billing question.
|
|
|
|
**Fixed: an unreadable licence key blocked every creation.** The licence screen said nothing was
|
|
being withheld, and something was — a key that lost a character in a paste resolved every limit to
|
|
zero. It now falls back to the community allowances, which is what the screen always claimed.
|
|
|
|
**On the licence screen**, a fresh install no longer shows a red "No licence" badge. It says
|
|
Community edition, lists what that allows against what you use, and states plainly that nothing is
|
|
reported. The refusal you get when a limit is full names the edition and what raises it.
|
|
|
|
Nothing else changes. No configuration, no migration, no new variable — `JARVIS_LICENSE_KEY` is now
|
|
documented as optional, and it always could be left empty.
|
|
|
|
## 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.
|