Files
tty7/crates/tty7-cli
l0ng-ai df8432f0af fix(cli): one answer for a pane that is not there
Three verbs, one condition, three sentences:

  procs %99    no pane %99 on this machine — `tty7 pane ls --all` lists them
  capture %99  observing pane %99: daemon refused Observe: no such pane 99
  send %99 hi  sending input to pane %99: no such pane 99

The daemon's own refusal makes a fine diagnostic and a poor sentence: it
names the wire request rather than the verb that was typed, so `capture`
told the user about "Observe", a word that appears nowhere else they can
see. This is the CLI agents read stderr from, and it was reporting one state
of the world three ways.

They now all answer with the line `procs` already used. The registry is
consulted only once something has failed, so the ordinary path still costs a
single round trip, and a failure with the pane present keeps its own words --
this must not swallow a connection error and call it a missing pane.

`resolve::no_such_pane` is now that sentence's one definition; the copy in
`workspace_of_pane` had drifted to suggesting plain `pane ls`, which does not
list the orphaned pane most likely to be asked about.

Found by running the verbs against a live daemon rather than by reading:
every one of these paths looks right in isolation.
2026-08-15 21:55:10 +08:00
..