Note the fake CLI that exercises the process lifecycle

From the ai-app-2 session, which used it to find a clock bug the tests did
not have. A `claude_cli` provider pointed at `#!/bin/sh` / `cat > /dev/null`
behaves the way the lifecycle code cares about -- holds the fifo open, records
a real pid, writes nothing, dies on a signal -- so adopt, stop, restart and
start are drivable without a real `--resume` and without spending a turn on
somebody's account.

Written down beside `debug-transcript.sh` because the two answer different
questions and the wrong one is expensive: this for whether a process is
running, that for what the transcript draws.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

AGENTS.md

@@ -238,6 +238,17 @@ first if a remote spawn ever mangles an argument.
   faults live entirely in what the app does *while* one is outstanding. On
   a loopback server those windows close before anything can be observed,
   so the bug looks like it is not there.
+- **A fake CLI exercises the process lifecycle without a token.** Point a
+  `claude_cli` provider's `command` at a two-line script — `#!/bin/sh` and
+  `cat > /dev/null` — and it behaves the way the lifecycle code cares
+  about: it holds the fifo open, records a real pid, writes nothing, and
+  dies on a signal. So adopt, stop, restart and start are all drivable
+  without a real `--resume` and without spending a turn on somebody's
+  account. Sibling to `debug-transcript.sh`, and the two cover different
+  halves: reach for this when what is under test is *whether a process is
+  running*, and for the script when it is *what the transcript draws*.
+  (From the ai-app-2 session, 2026-08-30, which found a clock bug with it
+  that the tests did not have.)
 - Prefer exercising the server directly over going through the UI:
   `curl --cacert ~/.config/ai-app/certs/ca.pem -H "Authorization: Bearer …" https://127.0.0.1:8443/sessions`.
   The CA is wherever `--certs` put it — by default under