Opus finding
Atomic write claim is unverifiable from spec; concurrent runs could clobber seen-list
lowconcurrencylow
- skills/fork-first-run-alert/SKILL.md:226-230
- aeon.yml:95-96
`tmp + mv` on the same filesystem is atomic for the rename itself, but does not prevent a concurrent run (e.g. workflow_dispatch invocation while the cron is mid-run) from racing on read-modify-write. Two concurrent runs both reading the same `seen` and both writing back would lose updates from whichever lost the rename race — the lost run's NEW_ACTIVE entries would re-fire next time. Given workflow_dispatch is a documented mechanism for `dry-run` overrides, the race is plausible.
Recommendation
Either guard with a GitHub Actions `concurrency:` group on the workflow, or use `flock` around the read-modify-write of state files, or document that concurrent invocations are unsupported and rely on Actions concurrency to enforce it.