step 3 verified live: the whole estate re-registered with handles
`pm2 restart all`, and all six came back on the new protocol:
agent handles=[claude] opencode handles=[opencode]
proxy handles=[proxy] headscale handles=[headscale]
pty handles=[terminal] music handles=[music]
`pty` → `handles=[terminal]` is the case that makes the rename worth it: the
name and the handled kind were never the same string, and calling the list
"capabilities" hid that behind a word already doing three other jobs here.
The strongest evidence is not in the log. The session that wrote this change
runs on officer-claude-code, and `restart all` bounced it — so the conversation
continuing at all means `sendCommand('claude', …)` resolved through
findSidecarHandling against a freshly registered sidecar. The one path that
would have failed silently proved itself by working.
Checked besides: agent-status 200, chat/models 200 (both sendCommand paths),
music manifest 200 and offscale health 200 (port-announcement paths, which the
`<name>:server` generalisation touched earlier today). No "No sidecar handling
X is connected" anywhere in the log.
/api/terminal/* answers 404 rather than 503, which is the distinction that
matters: 503 is the proxy having no port for the sidecar, 404 is the sidecar
answering and having no such route. The pty proxy resolved its port.
Permissions unaffected across all three steps: 9 grants, {role, permission,
level}.
Step 4 — the last of the doc and comment surface — is all that remains.
This commit is contained in:
