toor
77b1858163
Two pieces of upstream promotion came out of this deployment. The sidebar "apiRelay" tab only opened a registration page on a third-party site, so it goes with no replacement. The circuit badge next to Settings was not what it looked like. It opened an ESP32 device manager: add a device, show LAN status, remote connect/disconnect, rename, delete, backed by six REST routes and an mcu_devices table. The purchase button inside that dialog was the promotional part; the rest was real device management. Since the hardware is out of scope here, the entire feature is removed rather than just the link that pointed upstream - UI entry, client API, routes, controller, store, schema, locale strings, and the one GlobalAgentServer method that only existed to answer its status column. Table creation is dropped but no DROP TABLE was added, so an already-provisioned database keeps its rows as harmless orphans instead of losing data on upgrade. DevicesView and the hermes.devices route are untouched: that is LAN device discovery, a separate feature. AGENTS.md now records the removal so the badge does not come back.
Chat Chain Change Fragments
Add one Markdown fragment per PR when a change touches the Chat session chain,
Agent Bridge, compression, or Group Chat runtime paths documented in
docs/cli-chat-sessions.md.
Do not append new rows to docs/cli-chat-sessions.md. Keeping one fragment per
PR avoids merge conflicts when multiple branches change the chat chain at the
same time.
Use this shape:
---
date: YYYY-MM-DD
pr: 1234
feature: Short feature name
impact: One-sentence behavior impact
---
Optional extra notes.
If the PR number is not known yet, use pr: pending while the branch is local,
then update that same fragment after the PR is opened.