diff --git a/docs/operations.md b/docs/operations.md
index 8b571e9..262ca1b 100644
--- a/docs/operations.md
+++ b/docs/operations.md
@@ -82,7 +82,6 @@ Vendor setup and protocol quirks are in [Claude Code](claude-protocol.md), [Code
 - A turn that asks a question has no summary; everything the human needs belongs in the question's context. Other turns use their final message as the summary; don't ask agents to write a second recap.
 - A review covers the whole task against the default branch, so a newer one makes older ones moot. Findings reach the task's agent together, once the whole review workflow finishes; an individual reviewer finishing is not a completed review.
 - An audit checks only the newest commit of the default branch, one at a time per project, so it doesn't run on every revision but the newest one is always audited eventually. byre never fetches for an audit, so a commit pushed outside byre is audited only once a byre merge has fetched it.
-- The lead's `show` is refused for a few seconds after the human moves the pane, and only a refusal arranges the "hold is over" signal, so the lead's prompt tells it to call `show` at once whenever it wants to show something, never holding back in expectation of a refusal.
 - A team task that comes up with some members failing to start isn't repaired; discard it and create it again.
 
 ## git
@@ -103,7 +102,6 @@ byre never signs with a key on the machine it runs on. When a project checkout's
 
 - The app pings every 10s and reconnects after 25s with no pong. That catches a socket byre dropped while the Mac slept: the close never reached the Mac, and without something sent on it the app would wait on it indefinitely.
 - `log show --info --last 10m --predicate 'subsystem == "run.fc.byre.mac"'` on a client shows `client request <id>: <op>` lines and `byre-hands` starts and exits, which are info level and kept only in memory, so they cover the last few minutes at most; connection drops (`client connection closed`, `client connection got no pong`) are notices, kept on disk, so `log show --start` reaches much further back for them. byre's log shows `client connected` and `client disconnected`.
-- The app acknowledges every request the moment it receives one; a client that hasn't within 2s fails the call, so a dead connection fails fast rather than at the request's own timeout.
 - `byre client-exec` (how to use it, and `byre screen`, is the `client-exec` knowledge-base article) calls `POST /api/clients/exec` on the loopback address with the loopback token, which byre exports as `BYRE_TOKEN` to everything it starts. byre's log has a `client exec` line per call with the client, command, exit status and duration, never the output, since it may hold credentials.
 
 ## Screen and app control