Keys

Three keyboards, depending on what is happening: the prompt, a turn in flight, and a card waiting for an answer. The card has its own page.

At the prompt

alt-enter is the only Enter chord a terminal does not collapse onto plain Enter, which is why it is the newline key. A lone esc is flushed after 50 ms rather than prompt_toolkit's default second and a half, so esc reads as a key that works instead of one that pairs with whatever you type next.

History lives in ~/.kotoba/cli_history and outlives the session; a greyed-out suggestion from it appears as you type. A home that will not take a write falls back to in-memory history rather than refusing to talk to her.

ctrl-r is bound deliberately, so reverse-i-search cannot open on top of the frame; it means what it means inside a turn. With nothing running it does nothing at all rather than opening an empty box.

@ is jailed, /attach is not

@ completes inside her workdir (~/.kotoba/files by default) and nowhere else. A fragment pointing outside says so — that's outside her workdir — instead of showing an empty list, and taking that row deletes the fragment. @~/ would otherwise paint your whole home directory into the box on one keystroke, onto a terminal that gets screenshotted.

/attach ~/Downloads/trace.png reaches anywhere, because that is a path you typed out in full, once, knowingly.

Pasting

Anything the box could have held goes in verbatim. Anything taller than half the window (minus the frame and the bar, never below 3 rows) goes in as a reference:

› [Pasted text #1]
  40 lines pasted — paste again to expand

The text is kept and put back before the line is ever accepted, so the transcript, the history entry and the turn are all the same bytes. Paste the same thing again and the reference turns back into it in place. Edit or delete the reference and its text does not travel.

The question is size, never "was that a real paste": a paragraph typed at her by tmux send-keys or an ssh client arrives with no paste markers at all, and a fast typist is indistinguishable from either. A multi-line burst is one message, not one per line — the Enter inside a burst is a line break, not a send.

While she works

The line editor is gone for the length of a turn; the keyboard is read raw instead. Nothing you type is swallowed.

Typing while she works never kills the turn in flight — a second message would. What you typed is still in the box when she is free, and a line you pressed Enter on is sent on its own, in the order you typed it.

esc with more than one thing running does not stop anything on the first press. It arms for three seconds and the bar names the blast radius, recomputed every frame so the count cannot run down to that stops all 0 of them:

esc again — that stops all 3 of them
esc again — that stops the long job
esc again — that stops this turn

ctrl-c cuts the turn and never the process. Whatever she had already said is kept — a half answer is still something the next turn has to know she said — and the transcript closes with ◇ stopped.

Complete escape sequences are stripped before any of this, so an arrow key pressed while she works is not read as an esc that throws her work away, and neither is an arrow key that lands in the same 1024-byte read as the letters around it.

Where these are advertised

The header's KEYS row carries /help · @file · alt-enter. /help keys prints the rest:

alt-enter               start a new line without sending
enter on an empty line  show me whatever's waiting out here
@                       name a file in her workdir — completes as you type
type while she works    it's still in the box when she's free
y n ? a t               answer an approval — no enter, the card draws its keys
ctrl-c                  stop her — twice on an empty box leaves
ctrl-d                  leave