[Feat] Record harness reconnect lifecycle as diagnostic breadcrumbs - #149
Conversation
A transcript that went strange mid-task gives no hint that the harness bounced underneath it. ReconnectableHarness now records durable diagnostic events at its lifecycle transitions: unexpected disconnect, restart requests (harness-initiated and external, with their reason), successful reconnect with the attempt count, and reconnect exhaustion. Together with the exit certificate this makes a process bounce fully reconstructable from task run events. Recording is optional and observer-only: the recorder is injected by create-harness, every call is fire-and-forget, and lifecycle behavior is unchanged. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
No code issues found. See task Reviewed the four reconnect breadcrumbs recorded by |
PR 3 of the observability plan (rail #140, death certificate #145/#147). Four breadcrumbs on the diagnostic rail, recorded by
ReconnectableHarness:harness_disconnectedharness_restart_requestedharness_reconnectedharness_reconnect_exhaustedPaired with the exit certificate, a process bounce is now fully reconstructable per task: certificate says why the process died, breadcrumbs say what the worker did about it. Deliberate restarts are labeled with their reason, so certificate-less restart breadcrumbs are self-explanatory.
Guarantees
Same discipline as the rest of the rail: recorder injected as an optional dependency, all calls fire-and-forget through the never-throw recorder, zero behavior change to reconnect logic (verified by the existing 11 reconnect tests passing untouched). Events fire only on lifecycle transitions — nothing per-message or per-tool.
Tests
3 new (disconnect→reconnect pair, exhaustion with attempt count, external request with reason). Full run-task + harnesses suites: 431 pass; typecheck / eslint / prettier / knip clean.
Waiting for bot review + Dan before merge.
🤖 Generated with Claude Code