08 — Step E: Worker / Cursor Simulation on Clone

Verdict: PASS — cursor advancement monotonic + idempotent; no daemon; bounded. SQL sql/E_worker_cursor_sim_clone.sql sha256 f97b99d387062513c13ab210ce1f799ffc63661551c7ec89bcf3bd414f9d4c38.

Design: gov_worker_cursor PK(worker_name,source_name). Advance via ON CONFLICT DO UPDATE … WHERE excluded.last_watermark_ts > gov_worker_cursor.last_watermark_ts (only when incoming watermark strictly newer); events_seen/attempts_written accumulate only on real advance. No loop/daemon — 4 explicit bounded invocations.

Runs: A create wm-1(10:00) insert events=10; B advance wm-2(11:00)>wm-1 update events=20 cumulative; C retry same wm-2(11:00)=current → INSERT 0 0 (guard false) events stay 20; D stale wm-0(09:00)<wm-2 → INSERT 0 0 (guard false) events stay 20 no regression.

Asserts passed: watermark=wm-2, events_seen=20, cursor rows=1, dead_lettered=0 → "retry & stale were no-ops."

Properties proven: idempotency (replay = no-op, no double count); monotonicity (stale cannot move cursor backwards); boundedness (one cursor row per worker/source, no growth from reruns); no external effect. A real worker would replace the manual invocations with a bounded fetch loop; the guarded advance + single-row cursor are what make such a loop safe. No daemon started.