No way to wait for a reply #31

Motivation

Replies landed in v0.2.0, and that turned waiting into a real step — one the tool doesn't know about. A message goes out, and the sender is left writing an ad-hoc loop to notice the answer.

From one day of real use across four machines, I wrote that loop four times, slightly differently each time. One of them judged wrongly: it grepped for a marker string that also appeared in an error message echoing the session name, so a blocked injection attempt was reported as successful. The check was wrong, not the code under test.

That's the argument for putting it in the tool — not convenience, but that everyone reinventing the wait writes a slightly different, occasionally wrong, version of it.

Sketch

cc-peer wait --from ontology --timeout 300

Blocks until a message from that session arrives in this session's inbox, or the timeout expires. Exit 0 on arrival, 2 on timeout, so it composes.

Open questions, in rough order of difficulty:

• How does it know a message arrived? The transcript is the only observable record, and it's append-only JSONL — tailing for a new record with origin.kind == "peer" and a matching sender is plausible, but reading another session's transcript is a different kind of coupling than writing to a socket. Worth checking whether something cleaner exists before committing to it.
• --from matching: session name, or anything?
• Does it print the reply, or just return? Printing makes it useful in a pipeline; returning keeps it a pure synchronisation primitive.

Scope

This is the least defined item here and the only one that adds a subcommand rather than fixing something. If the transcript-tailing turns out to be fragile, the right answer may be to document the pattern rather than ship it. Don't force it in to have shipped something.

Acceptance criteria

• A decision recorded on how arrival is detected, with the alternatives considered
• If implemented: timeout behaviour and exit codes tested without a real peer
• If not implemented: the working pattern documented in SKILL.md so the next person doesn't rewrite it wrongly