fleetd #365: a reply reports whether anything was waiting for it
The REST reply endpoint's response shape changed: 'delivered' is no longer
always true, and an 'outcome' field names which of three things happened.
15-REST-API-Reference.md still documented the old constant.
Adds the Features entry the charter requires for a visible behaviour change,
covering both doors and the nudge-counter rename (delivered -> sent).
REST surface: add the route that drifted, and a Features entry that points here
Chapter 15 was written on 2026-08-31 and was correct for all 14 routes that
existed then. GET /member-credentials shipped three days later (#111) and the
page did not follow it.
- ch.15: route count 14 -> 15, a table row for GET /member-credentials, and a
per-route detail section (field meanings, and that blockedCount is the
policy's own blocked set, not knownCount - allowedCount).
- ch.11: a short entry for the REST face — what it is for, the bind: knob, why
it exists, the drain-on-read gotcha — linking to ch.15. Deliberately no route
table: a second copy is the defect, not the errors it collects.
The "not an agent channel" point is stated accurately: REST does not skip the
authorization gate. 14 of 15 routes resolve the caller through the same
CallerResolver and Authz table MCP uses, and /healthz is open on purpose as a
liveness probe. The real reason is that identity comes from the connection, and
a member's own child process is a connection the daemon must reason about —
which was wrong before (#161).
fleetd #252. A test in the repo now enumerates FleetApp's registrations and
fails when they no longer match, naming this page as the one to update.
Three pages the audit asked for that did not exist.
14 Fleet Manager — fleet-manager had zero coverage in this wiki, so an
operator had no way to learn it exists. Written from its own source: the
fleets.json shape from the parser rather than the example file, what each
command does, and how the probe decides working vs stalled by comparing
worktree modification times twice. It also records the two limits that come
from fleetd rather than from the tool: two daemons sharing one herdr session
tear down each other's members, and a session inside a pane is resolved as a
worker, which is why the manager sits outside and speaks REST.
15 REST API Reference — the 14 routes were documented nowhere as a set. The
page leads with why that matters: MCP and REST are sibling adapters over one
shared MessageService, so REST behaviour cannot be inferred from the MCP
contract. fleet_ack and fleet_whoami have no route at all.
It also records a trap found while writing it: GET /members returns its
rows under a "workers" key (FleetApp.java:322). The route was renamed from
/workers in CB-557 and the body key was left behind, so a caller reading
body["members"] sees an empty fleet instead of an error.
16 Security & Trust Boundary — the guard, the role table, the member
credential scrub and token scope were spread across three pages. Collected,
with the limits stated rather than glossed: the effective allow-list is a
union and so a strict superset of what an operator writes under allow:; the
ZDOTDIR scrub is zsh-only; blocking SSH_AUTH_SOCK does not stop a member
reaching a passphrase-free key file; and argv is world-readable, which
bypasses every environment control described on the page.
Home and _Sidebar link all three.
Dai Ha