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 wiki for Pizarra 1.1.23
Document Pizarra 1.1.22
Build complete project wiki