Greptile Summary

This PR widens the WhatsApp reconnect retry window (3→5 attempts, 500ms→1000ms base backoff, max ~10 s of wait) and surfaces final delivery failures as structured system events so agents get a signal when a message is permanently undelivered. The changes are targeted and well-tested.

Key observations:

• The retry constants (SEND_RETRY_MAX_ATTEMPTS, SEND_RETRY_BACKOFF_MS) are a clean extraction and align with the new test expectations.
• vi.clearAllMocks() in beforeEach for deliver-reply.test.ts is a welcome hygiene fix that prevents cross-test mock state leakage.
• The enqueueSystemEvent call inside onError fires unconditionally for all info.kind values ("tool", "block", "final"). The PR description and the new test only target the "final" case; if the dispatcher invokes onError for non-final kinds (e.g., internal errors), misleading system events would be emitted. A guard on info.kind === "final" would align runtime behaviour with stated intent.

Confidence Score: 3/5

• Mostly safe to merge; one logic gap where enqueueSystemEvent fires for all error kinds rather than only final delivery failures as the PR intends.
• The retry window changes are correct and well-tested. The system event plumbing is valuable, but calling enqueueSystemEvent unconditionally inside onError — without a guard for info.kind === "final" — could emit confusing or spurious events if the dispatcher invokes onError for non-final kinds. The test coverage only validates the final case, so this gap is unverified by the test suite.
• src/web/auto-reply/monitor/process-message.ts — the onError handler should guard enqueueSystemEvent to info.kind === "final" only.

This is a comment left during a code review.
Path: src/web/auto-reply/monitor/process-message.ts
Line: 440-453

Comment:
**`enqueueSystemEvent` fires for all error kinds, not just `"final"`**

The `onError` callback can be invoked for `info.kind === "tool"`, `"block"`, or `"final"`, but `enqueueSystemEvent` is called unconditionally for all three. The `deliver` function early-returns for non-final kinds (no network operation is attempted), so a delivery failure for `"tool"` or `"block"` cannot happen through the `deliver` path — but the dispatcher may invoke `onError` for internal/model-level errors independently of `deliver`, which would produce a misleading system event like `"WhatsApp block update delivery failed to +1555: ..."`.

The PR description says *"enqueue a system event when WhatsApp **final** delivery fails"*, and the new test only exercises `{ kind: "final" }`. Consider adding a guard so `enqueueSystemEvent` is only called when `info.kind === "final"`, bringing the runtime behaviour in line with the stated intent and the test coverage.

How can I resolve this? If you propose a fix, please make it concise.

_{Last reviewed commit: 91a9a55}