The settings screen, the command that updates a machine, and the firewall over the API Seven tabs in `warden setup` and `warden settings` opening the same screen, so Configuration and Command-line no longer describe one long scroll. The Embed tab and `warden webhook --all` in Events and webhooks, because the way to see what thirteen messages look like is now to send them. Updates says what fetches a newer warden rather than only that one exists, per way of installing, and that a copy installed under the name `warden` has to be replaced rather than upgraded. Firewall grows a section on driving it from another machine: the endpoints, the client, `--on`, and the switch that has to be set before any of it changes anything. The bounds it still cannot get round are listed there rather than implied.
The colour and the words are both settable, one event at a time
Thirteen events, three scopes, and what each one actually looks like
The project file has its own name, and setup asks about the firewall
The firewall: four backends, the rollback, and what a rule from the registry may never do
Bring the wiki up to 0.2.0: events, webhooks, projects, proxy export, groups
Document running programs, holders, doctor, autostart, history, metrics and Docker
Document why a node cannot change its own address A name is pinned to the address it first announced, and the reason is worth stating rather than leaving as a surprising refusal: the hub sends a person's token to whatever address a node gave it.
Document setup, settings, and the Python client Configuration opened with fifteen environment variables and a .env in whatever directory the process started in, which stopped being sensible advice the moment the command could be installed globally. It now opens with `warden setup`, and explains the source order rather than pretending there is only one. The Python client had a table of method names on the API page and nothing that showed anyone how to use it. It gets a page: asking for a port at startup, finding a neighbour, leases and heartbeats, every method, what comes back, which exception means what, and reading the machine with no warden running at all.
Add a footer, and drop the links the sidebar duplicated
Bring the wiki up to the current warden Installing by name works now, so the pages say so instead of explaining why it does not. Adds what the fleet gained since they were written: pool and listeners across every node, a name two machines both hold, --node forwarding on register, release and heartbeat, the dashboard's fleet mode, and the new heartbeat command. Records that forwarding takes a person's token rather than the cluster one, and why. Also that the dashboard shows this machine's ports with no warden running at all, which was the last place the two ways of asking the same question still disagreed.
Document updates and rolling them across a fleet A page of its own, plus the settings, the endpoints, and a section of troubleshooting built around the messages an update actually prints. States plainly why the hub sends an intent rather than a command, and that restarting the service is the operator's command's job.
Document the fleet-wide view warden ls --all, warden get node/service, and the two new endpoints. Also corrects the token model: the cluster token now opens read endpoints too, because a hub asking its nodes what they hold is exactly that. The pages said reading took the human token, which is no longer true.
Write the wiki Nine pages: what warden is, how to install it, running it on one machine, seeing and freeing ports without a server, running a cluster, and three reference pages. Plus a troubleshooting page built around the messages warden actually prints, so a reader can search for what they saw.
Initial Home page