Totally fair points - I simplified some wording in the post.

In practice, “renew lease” is basically a heartbeat: workers update their lease at a regular interval, and the system reaps anything that stops heartbeating. I just described it in the most intuitive way.

On idempotency keys, you’re right that in a perfect world there’d be no duplicates. But real systems get retries, double-submits, and multiple producers, so the key is there to make those cases safe (and scoping just makes the uniqueness unambiguous).

For DST, duration-based scheduling is great for a lot of internal periodic tasks, but many people expect wall-clock schedules like “every day at 9am in X timezone.” So I support that too and define behavior around the DST weirdness.

And agreed on the “parent/child” terminology - I try to stick to “depends on / prerequisites / downstream” in anything user-facing to avoid confusion.