v0.5.63

Five fixes, and four of them are things the tool says to an operator. None changes how a run is driven; all of them change what you are told while driving one. Worth installing for that reason rather than in spite of it — three of these cost someone real time before they were found.

events --follow waits for a run instead of losing the race to it (#350, #360)

--help and the operator skill both teach a two-line start — the session and the follower, together — and say to prefer following over polling. But a follower could lose that race twice over:

• in a fresh project, nothing is recorded yet, so it printed no sessions have been recorded and exited
• in a project that already has runs, no id meant "most recent", which during the startup window is the run that just finished. It drained that one, saw ended, and exited 0

Both end the same way: a dead follower tailing a file that will never grow, and silence from a dead follower is indistinguishable from silence from a busy run. The second is worse, because events.ndjson is full of plausible events from the wrong run.

Now --follow with no id takes the newest run that has not ended, and waits when there is none — saying so once, on stderr, with Ctrl-C named. stdout stays machine-clean. Measured at ~75s from launch to first registration in a fresh project, which is why this bit reliably.

An explicit id is still explicit intent: --follow <ended-id> attaches and reads it out. events without --follow still reads the most recent run, ended or not.

A session id is found wherever it sits (#359)

status --json <id>    described the NEWEST session, silently
status <id> --json    described the one asked for

An agent polling status --json <id> watched a different run and nothing said so. events had the same defect; it was fixed there and this was the copy that survived. Both commands now share one reader, so they cannot disagree again about where an id may go.

The send-timeout diagnostic reads the journal instead of describing it (#352)

It used to hand you a rule: if attempts.ndjson EXISTS the handler ran and could not deliver; if ABSENT it never executed. The rule was right about those two states and wrong about the file, because the journal is per-agent rather than per-delivery. A run ended at its first turn with a journal holding exactly one entry — SessionEnd, the child leaving — and the rule sent its operator to trust and to the broker while the file was saying the child was gone.

It reads the file now. A fourth state is named: the child's session ended before the prompt was accepted, which points at the child rather than at conclave's plumbing. An unrecognised journal is not forced into a reading — it says which events it does hold.

The broker says when its address is one the glasses cannot reach (#345)

device  http://127.0.0.1:3456   token 3a3438…
        the glasses cannot reach this address; CONCLAVE_EVEN_HOST moves that

The line labelled device is the address to type into the glasses, and on the default bind it is one they can never dial. The default is deliberate and unchanged — widening a bind is an exposure decision — but the notice now says what the code already knew. Said on broker status too, and silent when the bind is reachable.