Sync the self-hosting stack

2026-10-12 14:38:23 +02:00
parent dfce1b252b
commit 3d57ae9ff5
1 changed files with 36 additions and 0 deletions
@@ -9,6 +9,42 @@ one of them changed. An entry says which artefact and which version, so `web 0.1
 Every version published to a channel appears here. Nothing is written from memory afterwards: a build
 cannot be published without its entry.
 ## 2026-10-12 — You see the machines your access reaches `api 0.139.0` `web 0.169.0`
 **The machine list was the last place that still answered organization-wide.** Somebody whose only
 line was posed on one folder was offered the pages that line reaches — that part is deliberate — but
 the inventory inside them listed every machine in the organization, and the boundary only showed up
 at the gate, one refusal at a time. The list, the search, a machine's own page, its saved connections
 and the assistant's capabilities panel now all answer on the descent: you see the machines your lines
 reach, and a machine out of reach answers exactly like one that was never there, so the list cannot
 be used to find out what exists.
 - **A right posed on a branch now carries the sight of that branch.** Giving somebody a shell on one
  folder no longer needs a second tick for "see assets": the box is ticked for you and marked
  _implied_, because a shell on a branch you cannot list is a right that cannot be used. Only what
  you chose is stored, so taking the shell away later takes the sight with it.
 - **Credentials keep the two apart, on purpose.** Seeing that a credential exists and revealing it
  are separate rights at the same node, in both directions, and an upgrade preserves both shapes
  rather than tidying them.
 - **Folder names are still the same for everybody.** The folder tree, and the number of machines
  under each node, is served whole inside an organization — the shape the credential tree keeps as
  well. It is said here as a choice and as the next piece of work, rather than left to be found.
 **And one act now asks for one permission, whichever door it came through.** Editing, running and
 deleting a schedule, deciding an approval, and creating, editing and deleting a document asked for
 `conversation:view` over the API and `conversation:create` over the live connection — one capability,
 two answers. The built-in **Viewer** confers the first and not the second, so on a stock instance a
 read-only member could delete somebody else's document through the API, and the audit trail recorded
 it as the act that declares the stronger right. Both doors now ask what the act itself declares, and
 a build fails if a route and its act ever disagree again. Two consequences you will see: the delete
 entry leaves the documents row menu for a reader instead of being offered and then refused, and a
 read-only member is no longer listed as somebody to send an approval to.
 Update the API and the web image. No agent update is required, and no table changes: the schema is
 the one `api 0.138.0` introduced, and the pass that translates older grants runs again without moving
 anything it has already moved. The old columns are still present and still unread — the release that
 removes them will say so here, and will ask for `SCHEMA_ACCEPT_DATA_LOSS=true` for that one run.
 ## 2026-10-12 — One line answers who can do what, and where `api 0.138.0` `web 0.168.0`
 **Access needed two locks open at once, and only one of them was visible.** Giving somebody the