Read open GitHub issues on one repo (paginated - big repos are never silently truncated), skip the ones already queued, launch a detached Codex run per new issue (write-tier, approval-gated), and queue each as an open codex_queue row for the sweeper. Attach a schedule to this recipe's dish per repo: 10 repos = 10 dishes of this one template. Stage 1 of the Codex workflow - sweep-codex-results reconciles outcomes and the handler dishes react to them.

D-179 worked example, stage 2 (the sweeper; the scheduled-operate shape). Reconciles queue rows against completion-marker evidence with no dynamic-key reads: it lists rows still in play (state open OR fail_timeout - the latter so a marker that lands just after a timeout still upgrades the row on a later sweep, before the failure handler finalizes it) and the <result_key>.exit.<code> marker files, joins them by result_key membership, and flips each matched row to success (exit 0) or fail (non-zero). A result_key with both a 0 and a non-zero marker (a rare double launch) resolves to success - success wins. Matched markers are consumed here (deleted) so the next sweep is idempotent and downstream handlers stay file-free. An OPEN row past the timeout with no matched marker becomes fail_timeout; a young open row with no marker is left open (skip - reclassified next cycle). A marker that arrives before its row (codex faster than the next kickoff tick) is an orphan this cycle and is left for the next. Once a row is finalized (done / failed_notified by a handler) it is terminal; a marker arriving after that is an accepted orphan.

D-179 worked example, stage 3 (the success handler). Lists codex_queue rows in state=success, emails the issue link plus the log path, and finalizes each row to done. The sweeper already consumed the completion marker, so this stage is file-free. Notify-then-mark is at-least-once: a crash between them re-notifies next cycle. Run this as ONE scheduled dish - the scheduler serializes a schedule's runs, so the list-notify-mark sequence is not raced by a concurrent copy of itself.

D-179 worked example, stage 4 (the failure/stall handler). Lists codex_queue rows in state fail or fail_timeout, emails the failure kind (non-zero exit vs no evidence before the timeout - the silent/stalled case), and finalizes each row to failed_notified. File-free: the sweeper owns marker consumption. A late marker after a timeout would be reconciled by a later sweep, so an occasional follow-up success notification is expected (at-least-once by design). Run this as ONE scheduled dish - the scheduler serializes a schedule's runs, so the list-notify-mark sequence is not raced by a concurrent copy of itself.