Move the storeMessage → enqueueMessageCheck side effect out of the delivery
callback into scheduleAutoContinueForPhantomFinal so the injection path is
directly unit-tested: an auto-continue outcome for a delivered final injects the
corrective nudge as an ipc_injected_human message and re-enqueues a turn, while
a non-auto-continue outcome or an undelivered final does nothing. Behavior is
identical to the inline version — this only adds test coverage and a no-op
refactor, so no redeploy is required.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Extends the phantom-notification guard: when a non-paired turn dead-ends on an
"I'll wait … I'll be notified" final with no watcher registered, re-invoke the
agent once (inject a corrective nudge as an inbound instruction + re-enqueue) so
it actually finishes the work in the foreground, rather than only appending a
"send a follow-up" notice. A hard per-chat cap (max 1 re-run per phantom streak,
reset on any clean final) makes it loop-safe — a model that keeps producing the
dead-end can never spin the bot. Paired rooms are excluded because they already
continue on their own (owner → reviewer → …). Pure cap/decision logic is unit-
tested; reuses the proven ipc_injected_human + enqueueMessageCheck path.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
An agent could end a turn with "I'll wait for the build to complete — I'll be
notified" without registering any watcher, so nothing ever resumed and the user
was left staring at a dead-end (observed in the tts_site room). The prompt rule
alone did not stop the model. At final-delivery time, when the final reads like
such a phantom-notification dead-end AND no CI watcher is active for the chat,
append an explicit notice telling the user no notification is coming and to send
a follow-up — turning a silent hang into an actionable prompt. Pure detector +
guard with unit tests; wired into the owner/reviewer final-delivery path.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
