Splitting this out of #100 rather than doing it mid-session on the rig.
What prompted it
While reading the new process console during a production session, the agent log
appeared to be full of TUI activity:
gently.ui.web.routes.agent_ws INFO agent_websocket:985 TUI client disconnected
That was misleading, not evidence. The line fired on every agent-websocket
disconnect, including ordinary browser tabs. Already relabelled in #100 — but it
prompted the real question: is the TUI still carrying its weight?
What is actually dead
gently/tui/ — an Ink/TypeScript client, 35 files, 244 KB.
Nothing in the Python tree imports it. grep -rn "from gently.tui\|gently\.tui"
over gently/ and launch_gently.py returns zero hits. It is not launched, not
packaged, and not referenced by the desktop shell. Outside its own directory it
appears only in prose: docs/guides/hardware-setup.md and
notes/biologist-readiness-plan.md.
What is NOT dead — do not delete this
gently/ui/web/routes/agent_ws.py is live and shared. The browser agent panel
and the TUI connect to the same endpoint:
gently/ui/web/static/js/agent-chat.js:1090 → new WebSocket(.../ws/agent)
gently/tui/src/index.tsx:27 → ws://localhost:8080/ws/agent
agent-chat.js:4 says so outright: "Connects to the same /ws/agent bridge the
TUI uses." So /ws/agent stays. This is why it is not a delete-the-folder job,
and why the naming throughout that module ("Send a JSON message to the TUI
client", "Tell TUI we're entering wizard mode") is now actively misleading — it
describes the browser.
The trimmable delta
The server handles 8 message types; the browser sends 6. The gap is the
candidate TUI-only surface:
msg_type |
browser sends |
notes |
chat, command, cancel, choice_response, take_control, pong |
yes |
shared — keep |
browse |
no |
agent_ws.py:1041 — "Handle browse requests from the TUI browser panel" |
ping |
no |
browser answers pings, never initiates one |
Verify before cutting: browse may have a non-TUI caller (mesh peer? a future
panel?), and ping may be worth keeping as a generic liveness affordance even
with no current sender.
Proposed work
- Delete
gently/tui/ and its package.json / package-lock.json.
- Remove the TUI references from
docs/guides/hardware-setup.md and
notes/biologist-readiness-plan.md.
- Confirm
browse has no remaining caller; remove the handler and
handle_browse_request if so.
- Decide on
ping — keep as generic liveness, or drop.
- Rename the TUI-era vocabulary in
agent_ws.py to say "agent client", since
the browser is now the only one.
Why not now
The only consumer that matters (the browser agent panel) runs through this
module continuously during a live session. Cutting handlers out of it while a
sample is mounted is not worth the risk for a 244 KB saving. After Ryan's first
session is the right time.
Found while preparing #100.
Splitting this out of #100 rather than doing it mid-session on the rig.
What prompted it
While reading the new process console during a production session, the agent log
appeared to be full of TUI activity:
That was misleading, not evidence. The line fired on every agent-websocket
disconnect, including ordinary browser tabs. Already relabelled in #100 — but it
prompted the real question: is the TUI still carrying its weight?
What is actually dead
gently/tui/— an Ink/TypeScript client, 35 files, 244 KB.Nothing in the Python tree imports it.
grep -rn "from gently.tui\|gently\.tui"over
gently/andlaunch_gently.pyreturns zero hits. It is not launched, notpackaged, and not referenced by the desktop shell. Outside its own directory it
appears only in prose:
docs/guides/hardware-setup.mdandnotes/biologist-readiness-plan.md.What is NOT dead — do not delete this
gently/ui/web/routes/agent_ws.pyis live and shared. The browser agent paneland the TUI connect to the same endpoint:
gently/ui/web/static/js/agent-chat.js:1090→new WebSocket(.../ws/agent)gently/tui/src/index.tsx:27→ws://localhost:8080/ws/agentagent-chat.js:4says so outright: "Connects to the same /ws/agent bridge theTUI uses." So
/ws/agentstays. This is why it is not a delete-the-folder job,and why the naming throughout that module ("Send a JSON message to the TUI
client", "Tell TUI we're entering wizard mode") is now actively misleading — it
describes the browser.
The trimmable delta
The server handles 8 message types; the browser sends 6. The gap is the
candidate TUI-only surface:
msg_typechat,command,cancel,choice_response,take_control,pongbrowseagent_ws.py:1041— "Handle browse requests from the TUI browser panel"pingVerify before cutting:
browsemay have a non-TUI caller (mesh peer? a futurepanel?), and
pingmay be worth keeping as a generic liveness affordance evenwith no current sender.
Proposed work
gently/tui/and itspackage.json/package-lock.json.docs/guides/hardware-setup.mdandnotes/biologist-readiness-plan.md.browsehas no remaining caller; remove the handler andhandle_browse_requestif so.ping— keep as generic liveness, or drop.agent_ws.pyto say "agent client", sincethe browser is now the only one.
Why not now
The only consumer that matters (the browser agent panel) runs through this
module continuously during a live session. Cutting handlers out of it while a
sample is mounted is not worth the risk for a 244 KB saving. After Ryan's first
session is the right time.
Found while preparing #100.