Give every window a verb, and answer what the terminal asks

The socket carried a bare word and said nothing back, so a script could press
the buttons but never learn what was said. A request is JSON now, it can ask to
be answered when the run ends rather than when it starts, and the reply carries
the transcript, the agent's answer, or why nothing happened. The verbs that do
not need the microphone run in the caller's own process, which is what makes
transcribing a file or reading a setting work over ssh.

README.md

@@ -59,6 +59,13 @@ A dictation and a command to the agent do wait on each other for the microphone,
 which is one device, but for nothing else: each has its own indicator, and the
 second one stacks above the first while both are up.
 
+Everything the settings window holds has a verb of its own too, so a script or
+an agent can work the whole thing: `dikte record --seconds 8` says back what was
+said, `dikte transcribe talk.mp4 --srt` writes subtitles, and the settings, the
+history and the meetings are there beside them. `dikte --help` lists them, they
+all take `--json`, and only the ones needing the microphone need the application
+running.
+
 ## What it does
 
 - **Silence never reaches the API.** Handed near-silence, a transcription model
@@ -124,7 +131,9 @@ needs your user in the `input` group: `sudo usermod -aG input $USER`.
 ## Layout
 
 ```
-dikte.py          entry point, tray icon, state machine, IPC
+dikte.py          entry point, tray icon, state machine
+cli.py            the command line: every verb, and what it answers with
+ipc.py            one request and one reply over the local socket
 audio.py          PCM capture: pw-record for dictation, ffmpeg for a meeting
 meeting.py        channel split, speaker labelling, cleanup, minutes
 assistant.py      running a dictation through Claude Code, Codex or OpenRouter