docs: say what queued actually means Two pages described `queued` as meaning the destination was temporarily unavailable. That is the same misreading the interactive console had encoded, which is how it came to tell operators a host was down while their message was arriving instantly. The flag covers four situations: an older message still pending for that team, the team being held, a real delivery failure, and - for every dial-in team - the ordinary path, because the acknowledgement that marks such a delivery arrives later on the reverse channel the host holds open. A dial-in destination is therefore reported queued on every message it ever receives. Both pages now say so, and say the reason belongs in the reply's note rather than being inferred from the flag. The FAQ entry is left alone: its question is specifically about an offline worker, where the old wording is correct in context. Version references updated across the affected pages.
docs: update the wiki for 1.1.40 - what undo does not restore The pages showed `app project` and `app undo` side by side without saying they operate on different things. A project link is a record of its own, not a field of the application, so undo rolls back fields and leaves links untouched. That distinction costs most right after an assignment goes wrong, which is precisely when undo looks like the repair and is not. Both the command reference and the organization model now say it, and point at `app project` and `app unproject` as the commands that actually move a link. Version references updated across the affected pages.
docs: update the wiki for 1.1.38 - comma lists from the console and with spaces The pages described multi-destination sends as though they worked everywhere. They did not: the feature reached the hub and neither of the two places a person actually types a destination. The command line lost the list to the shell, so `tiza a, b msg` arrived as the destination "a," with the rest swallowed into the message text, and the interactive console refused a list outright because it validated a single name before the hub ever saw the line. Both pages now show the spaced form and say plainly that it was broken until 1.1.38, since a reader who tried it earlier and gave up deserves to know it was the tool and not their syntax. Version references updated across the affected pages.
docs: update the wiki for 1.1.37 - receipt directory created before the check The configuration reference described the 1.1.36 behaviour, which was only half the story. The daemon did create the receipt directory at startup, but the writability check ran before it, so a first start still printed a warning that a completed delivery might be repeated after a restart - already untrue by the time it could be read, because the directory was created moments later and the receipt saved normally. 1.1.37 moves the creation ahead of the check, and the page now says so, since a reader who met that warning on a fresh endpoint deserves to know it was a false alarm rather than go looking for a broken path. Version references updated across the affected pages.
docs: update the wiki for 1.1.36 - the daemon creates its receipt directory The configuration reference said the directory holding the delivery receipt must be writable by the daemon, which was true but left out who was supposed to create it. Nobody was: the daemon relied entirely on the shipped service unit's StateDirectory, so a stock install was fine while a hand-written unit, a launch agent, or a state path pointed elsewhere left the directory missing. The daemon then logged that it could not save the receipt every few seconds and ran with no persisted delivery position at all, which is the case that lets a restart inject an already-delivered message a second time. Since 1.1.36 it creates the directory itself at startup, mode 0700, and reports a failure once at startup naming that consequence rather than repeating the symptom. Readers pointing the state path somewhere unusual no longer have to create the parent themselves. Version references updated across the affected pages.
docs: update the wiki for 1.1.35 - remote terminals, remote shells, multi-destination The wiki still described 1.1.23 and did not mention either terminal capability, though they are the most consequential grants the system offers. Command reference and messaging pages now cover a comma-separated destination: elements may be teams, groups, @group or all, everything is resolved before anything is stored, and one unresolvable name refuses the whole send rather than delivering a partial broadcast that reads as complete. A new security section covers remote terminals and remote shells honestly, because each of these points was established by measuring a host rather than by reading its configuration: opening a shell as an ordinary account describes which user id is spawned and is not a barrier where that account may elevate without a password; attaching is usually the MORE direct grant, because it spawns no account and joins a session that runs as whoever created it; restricting the shell account does not contain attaching, and neither does moving a session out of a service's control group; an unprivileged session is still not containment; where a session runs an autonomous agent, writing into it injects into that agent's instruction stream rather than merely executing on the host; and audit differs between the two, because an attach into an already-privileged session has no elevation event to record. Version references updated across the affected pages.
docs: update wiki for Pizarra 1.1.23
Document Pizarra 1.1.22
Build complete project wiki