Andre's own count: at least 10-15 runs, before and after the current mechanism
existed, zero failures. Both notes had it as "hours, this session".
Recorded as a correction because it is a different class of claim. "It worked for
hours tonight" supports a decision; "it has never failed across a dozen runs and two
surrounding mechanisms" supports not revisiting it — which matters, because
self-re-arm looks fragile on paper and the instinct of anyone reading it cold is to
add a safety net the evidence says is unnecessary.
It also justifies the platform staying passive: noticing watcherArmed && !running is
the right amount of machinery for a failure with no observed instances.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The flag was right: apps/commandhq has its own composer and ships a verbatim copy of
background-job-prompt.ts, so handoffContract was still promising "the harness re-arms
you". Worse than stale — a mobile-armed watcher would have waited for a re-arm that
was never coming, firing once and silently stopping. Re-copied and diffed.
That is the third re-sync in one session, each caught only because I happened to be
reading the diff. A stale preamble typechecks, builds, and produces a job that runs,
so nothing catches it.
Proposes the fix: build the preamble on the server. It is a pure function of the
spec, both clients already assemble that spec locally, and the create endpoint could
take the spec instead of a finished prompt — one implementation, on the side that
owns the mechanism the text describes. displayText and cwd both drop out as things
the server can derive rather than be told.
Cost stated too: it puts prompt text behind a round trip. Not asked for tonight.
Also records why the mechanism changed, because it generalises: the synthetic turn
lost to the fact that this session's own watcher had been self-re-arming for hours
with zero failures. A measurement beat a hypothesis.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
pastilhasandClaude Opus 5