Fixed
- A server that has already exited is reported as
PROCESS_DIED, not as
RESPONSE_TIMEOUT. Found by the 0.8.33 numtide packaging PR failing on that
project's aarch64 builder while every x86_64 run passed:_stdio_requestwaits
on a queue that is resolved either by the pump thread delivering its EOF
sentinel (→PROCESS_DIED) or by the deadline (→RESPONSE_TIMEOUT), and on a
loaded machine the deadline wins that race. The timeout branch never asked
whether the process was still alive, so a server that had exited was reported
as merely silent — the reader then goes looking for a slow server instead of a
dead one. It now checkspoll()before deciding, which is the direct signal and
does not depend on the pump being scheduled; a server that is genuinely slow is
still alive, so it still reportsRESPONSE_TIMEOUT. The regression test forces
the ordering (the child keeps stdout open, so no EOF ever arrives) and fails
with the originalRESPONSE_TIMEOUT != PROCESS_DIEDon the previous code. - The self-heal path also printed an unlabelled skill count (issue #40). The
0.8.33 fix corrected the quickstart copy and missed the second call site in the
same file — the one that runs on every command. Two places print "Skill catalog
indexed"; the tests covering them asserted only the shared prefix, so nothing
could tell them apart andmcptoon liststill saidN skill(s) routable. Both
now sayN entry/entries routable, and the presence test pins the caliber
rather than the prefix so the two sites cannot drift again.
Docs
- The channel ledger tracked a winget obligation against a PR that had been
closed for eight days.AGENTS.mdnamed#443014(0.8.3) as the open
submission; verified against the live API,#443014and#450462(0.8.17) were
closed unmerged on 2026-10-21 and#457898(0.8.25) on 2026-10-24, leaving
#460772(0.8.27) as the only one open.release_sync.pyreads the live number
and was always right, which is exactly why nothing caught the prose drifting.