Greptile Summary

This PR fixes a long-standing gap where isolated cron job deliveries were never written back into the main agent's session transcript, making the agent unable to recall what it had already sent. The fix adds a best-effort "awareness mirror" step: after a successful direct delivery, persistCronAwarenessMirror calls updateLastRoute to seed delivery context and then appends an assistant transcript entry into the routed main or thread session.

The implementation is clean and the refactor is well-scoped:

• session-key.ts gains two new pure utility functions (resolveCronRoutedSessionKey, resolveCronSessionStoreAgentId) that centralise session key and store-path resolution.
• delivery-target.ts now canonicalises thread/routed session keys and routes the store lookup through the running agent's store path.
• run.ts computes routedSessionKey once from baseSessionKey and passes it consistently to both resolveCronDeliveryContext and dispatchCronDelivery, replacing the stale params.job.sessionKey reference.
• The previously-flagged concern (awareness write failure silently gating the dedup cache) is fully resolved — rememberCompletedDirectCronDelivery is now called unconditionally after a successful delivery.

Key notes:

• The dedup idempotency key was bumped from v1 (keyed on runSessionId) to v2 (keyed on jobId + runStartedAt). In-memory v1 entries cached by old instances won't be found by new instances during a rolling deploy, creating a brief window for duplicate deliveries. This is bounded and self-healing but worth noting operationally.
• updateLastRoute is called before appendAssistantMessageToSessionTranscript in persistCronAwarenessMirror. If the transcript write fails, the route fields are still updated in the store. This is intentional per the PR design (delivery context seeding), and the caller treats awareness as best-effort.
• Test coverage is comprehensive — integration tests cover main session, thread session, global scope, cross-agent isolation, dedup-on-failure, and delivery-failure-does-not-poison-route scenarios.

Confidence Score: 5/5

• Safe to merge. The change is additive and best-effort; awareness failures degrade gracefully without blocking delivery.
• The previously blocking concern (dedup gated on awareness success) is fully fixed and verified by a new test that validates the inverse behavior. The core delivery path is unchanged. New awareness logic is isolated behind if (awarenessMirror) / if (delivered) guards and returns void on failure with only a logWarn. The idempotency key version bump is the only operational wrinkle, but it affects only the in-memory dedup window during a rolling deploy — not correctness in steady state.
• No files require special attention beyond the deployment note on the v2 idempotency key bump in delivery-dispatch.ts.

This is a comment left during a code review.
Path: src/cron/isolated-agent/delivery-dispatch.ts
Line: 242-243

Comment:
**Idempotency key version bump may cause transient double-delivery on rolling deploy**

The key scheme was changed from `v1` (keyed on `runSessionId`) to `v2` (keyed on `jobId + runStartedAt`). Because `COMPLETED_DIRECT_CRON_DELIVERIES` is an in-memory module-level map, any v1 entries cached by old-binary instances will be invisible to new-binary instances after a zero-downtime rolling deploy. If a new instance picks up a retry or re-fire of a job that was already delivered by an old instance, it will not find the cache entry and will re-deliver.

The window is bounded by the time it takes to drain old instances, and the cache resets on restart anyway — so this is a minor operational concern rather than a persistent data hazard. Worth noting in a deployment runbook if rolling deploys are used for this service.

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

_{Reviews (2): Last reviewed commit: "cron: decouple delivery dedup cache from..." | Re-trigger Greptile}

@codex review