Handler: submit the line it types, and ask the agent before answering for it

[bharathm03]

The Handler was armed on two live sessions. Two symptoms were reported: its
auto-replies appeared in the agent's composer but were never sent, and it wrote
prescriptive how-to recipes instead of asking the agent that holds the session.
Both reproduce from the logs, and digging into them surfaced five more.

Every finding here was put to an adversarial skeptic before it was fixed. Two of
the original seven were partly refuted and are implemented in a different shape
than first proposed; that is called out below.

The reply never submitted

createPtyAdapter.injectReply was one PTY write of text + "\r". A coding-agent
TUI tokenizes a read as a whole — Claude Code emits a control character as its own
key event only while the entire read is under 64 characters — so at or above that
the CR is absorbed into the surrounding text run and inserted as literal text. The
prompt is typed and never sent.

The live log matches exactly: of seven injected replies (18, 294, 449, 497, 552,
782, 1014 chars) only the 18-character one could have submitted. Nothing detects
the failure — the engine records handle, banks its transitions, counts the
runaway guard and rests at watching, while the agent emits no turn-end and the
session goes quiet with the text stranded.

Submitting now goes through TerminalSession.submit: the line, a gap, then the CR
in a read of its own, serialized per terminal so a keystroke cannot land inside the
injected line. The seam sits below both the handler adapter and agent-core's
terminal:input, so the app's escalation chips (up to 400 characters) are covered
by the same mechanism rather than a second one — a chip previously typed without
submitting while the card latched disabled and both sides dropped the row.

A bare slash verb is padded with one trailing space. With the CR in its own read,
/compact reaches Claude Code's Enter handler while the suggestion list is open
and selection has settled on the exact match, which routes Enter to accept rather
than submit; any slash line containing a space clears the list first. This is a
regression introduced by the split itself, found by the audit, not a pre-existing
bug.

The judge had no way to ask

buildDecidePrompt offered two moves: answer with high confidence, or escalate to
the human. Nothing let it ask the AGENT — which holds the live session, the working
tree and write access, where the judge reads a bounded excerpt. The result was
294–1014 character command recipes, including a commit message the agent then used
verbatim.

The prompt gains the ask move and an altitude rule (the Handler decides what should
happen next and why; the agent decides how), placed immediately after the
escalate rule so a question cannot divert what belongs to the human. The
decision enum is unchanged — asking is a handle whose reply is a question — and
a test pins that a fourth enum value stays rejected.

Runaway guard and escalation gate

onUserReply reset the runaway guard on every inbound terminal:input byte,
before any test. Once an agent enables mouse tracking every pointer event is one
of those frames, so moving the mouse across the terminal restored the auto-reply
budget tens of times a second; one ordinary typed character did it too. The guard's
own header says it resets "on a human reply".

The same method's /[\r\n]/ test also matched alt+enter (\x1b\r) and a paste's
interior newlines — neither submits anything — and retired pending escalations
while the agent stayed blocked. Escalations never supersede, so a row cleared that
way is not re-raised.

Both collapse into one isSubmitKeystroke gate, kept above the session lookup so
guard state is still reclaimed for a terminal with no live session. The three input
predicates move to keystrokes.ts, a leaf module both agent-core and the handler
can import without a cycle.

Shape refusals (partly refuted)

The original claim was that the reply/action XOR left the judge no way to run a
command with instructions. That is wrong — the XOR never fired in the live log, and
it stays. The real defect is next to it: replyShape flattened reply but never
actionText, so a newline in a command's argument tail was refused by the
control-char rule; and because written = actionText || reply, the refusal was
reported as "reply contains control characters". That reason is fed verbatim to the
one retry, teaching the judge to edit the field it got right.

Destructive floor

The floor had no gh verbs at all. In the live run the Handler drove
gh pr merge --delete-branch into development twice with no warning and no
snapshot. Added at the DESTRUCTIVE tier: gh pr merge|close,
gh release|repo delete, forced branch delete, git tag -d, npm publish.

Advisory, never HARD — a HARD entry is liftable by nothing, and merging the pull
request is routinely the backlog's whole point. Nothing snapshots these, so they
now report that no undo exists rather than passing in silence, and the alias table
learns their prose so an authorized merge stops recurring as a reason to escalate.

Blocked-action push (partly refuted)

The original claim — that handler-activity.jsonl is unread and the push points at
a feed nothing can replay — is wrong: the activity feed is a live app screen fed by
the handler:activity push. The real gap is narrower. handler:status replays
sessions, escalations and snapshots but never activity rows, and blockedNote
rides an OS push, the one channel that reaches a phone whose app was not running
when those rows went out. So "N action(s) Handler could not take — see the activity
feed" could land on an empty feed. The push now says what was refused.

The claim that the synchronous append is a defect was dropped: the whole handler
persistence layer is sync, and every record() call site sits beside a strictly
larger sync write.

Verification

bun run --filter antgrid-bridge test — 3198 pass, 0 fail (baseline 3148, so +50
tests). tsc --noEmit clean. No files under app/ change, so the Flutter gates
are untouched.

Not yet verified against a live Claude Code PTY. The 20ms gap and the bare-verb
padding are reasoned from the 2.1.252 binary's tokenizer and covered by unit tests,
but not measured end-to-end. The underlying bug is intermittent — a read the OS
happens to split short submits fine today — so this is worth exercising at 64,
~500 and ~4000 characters plus a bare /compact, on Windows specifically, where
ConPTY is the coalescing layer.