Best possible solution:

Close this branch and consolidate the final fix on the canonical cron catch-up issue, using the proof-positive candidate plus any needed boundary coverage from the sibling boundary-preserving PR.

Do we have a high-confidence way to reproduce the issue?

Yes, source-level: startup catch-up evaluates persisted due cron slots before maintenance recompute, and this PR's new branch can skip before the previous-slot guard runs. I did not run a live Gateway restart in this read-only review.

Is this the best way to solve the issue?

No. The branch changes the right decision point, but the early return false is too broad; the better solution is the canonical boundary-aware scheduler fix with real CronService proof.

Security review:

Security review cleared: The diff only changes cron scheduler selection logic and a focused test; I found no concrete security or supply-chain concern.

AGENTS.md: found and applied where relevant.

What I checked:

• Current PR head over-skips: At the current PR head, the due-nextRunAtMs branch returns false as soon as lastRunStatus is ok and lastRunAtMs >= next, so it bypasses the later previous-slot comparison that protects legitimate missed cron slots. (src/cron/service/timer.ts:1651, d5be0aa1263b)
• Main still has the original runnable gap: Current main returns true for any finite due nextRunAtMs before reaching the cron previous-slot versus lastRunAtMs guard, which is the linked bug this cluster is repairing. (src/cron/service/timer.ts:1642, 4ae8d735bf54)
• Startup catch-up runs before maintenance recompute: Cron startup calls runMissedJobs before the later maintenance recompute, so stale persisted due slots can be evaluated by startup catch-up first. (src/cron/service/ops.ts:269, 4ae8d735bf54)
• Existing invariant belongs in the scheduler path: Maintenance recompute already advances an expired slot only when lastRunAtMs covers nextRunAtMs, which supports a boundary-aware fix rather than this PR's early false return. (src/cron/service/jobs.ts:785, 4ae8d735bf54)
• Proof-positive sibling candidate: The open sibling candidate keeps the due branch from returning true only for already-completed cron slots and falls through to the existing previous-slot guard; it also carries a proof: sufficient label and real CronService terminal proof in its body. (src/cron/service/timer.ts:1642, 5870f97ec24c)
• Related open PR search: Live GitHub search found fix(cron): skip completed restart catchup slots #101998 as the open proof-positive candidate for the same linked cron catch-up issue.

Likely related people:

• Takhoffman: Authored and merged the restart catch-up replay semantics PR that established the relevant missed-run guard behavior. (role: feature-history contributor; confidence: high; commits: 79d00ae39860, d659a8ebb028, 1df8e5b2cfd6; files: src/cron/service/timer.ts, src/cron/service/jobs.ts, src/cron/service.restart-catchup.test.ts)
• vincentkoc: Current blame for the central runnable function points to a recent cron localization refactor, and recent adjacent cron commits touched execution and catch-up behavior. (role: recent area contributor; confidence: medium; commits: 3dbe98a1f737, 44ae2fd93601, c716e1b8acf4; files: src/cron/service/timer.ts, src/cron/service/jobs.ts, src/cron/service/ops.ts)
• steipete: Recent cron event-trigger work changed the same scheduler files and startup catch-up outcome path. (role: recent cron scheduler contributor; confidence: medium; commits: a6768d9de567, 91edf1a83736, ce1219159858; files: src/cron/service/timer.ts, src/cron/service/jobs.ts, src/cron/service.restart-catchup.test.ts)
• RichChen01: Authored recent startup catch-up deferral persistence work in the same scheduler state path. (role: adjacent startup catch-up contributor; confidence: medium; commits: 808e8f09bab3, 7be62779dd79, 16e7d24e3cd8; files: src/cron/service/timer.ts, src/cron/service/jobs.ts, src/cron/service/state.ts)

Codex review notes: model internal, reasoning high; reviewed against 4ae8d735bf54.