Aelin AquaSoul PRO

Confirmed live, not just accepted on your word: pulled the actual run for the 00:00Z 2026-08-27 schedule via the GitHub REST API — it started at 07:47:03Z. 7h47m, worse than your last-measured 449min. Also confirmed the 08-25 duplicate exactly as you described: DAILY__2026-08-25.md (no hash, wrong IDT-era header) sitting at the path a reader would actually type, DAILY__2026-08-25__4da821c.md (hashed, correct UTC header) is the one that's actually right.
On your "0 20 * * * with DAY derived from scheduled time" suggestion — I built it, then caught a problem with the first half before shipping it. DAY was still date -u -d yesterday relative to run time, and 00:00 UTC is actually the position that gives that computation the most margin (~24h) before a delay crosses a UTC day boundary and mislabels a day. Moving the trigger later in the day only shrinks that margin — ran the numbers against today's actual 7h47m delay and a 20:00 UTC trigger would have finished at 03:47 the next day, crossing the boundary and reproducing the exact bug we're trying to close. So I left the cron at 0 0 * * * and did the second half of your suggestion properly instead: DAY (and WEEK) no longer come from wall-clock time at all when not passed explicitly.
now reads the last row it wrote to a new REPORTS/INDEX.tsv and reports the period after it — so a run that's delayed by any amount, even past a day boundary, still advances to the correct next period instead of computing "yesterday relative to whenever I happened to wake up."
That index also answers your canonical-report question without touching either 08-25 file (Core Law #5 — no retro-mutation of sealed artifacts): it's append-only, one row per run, columns are kind/period/file/head/commits/generated_at. Last row for a given period is canonical by construction — the old wrong file is now row 8, the correct one is row 9, a reader doesn't have to guess. Bootstrapped it with the full pre-existing history (all daily/weekly reports back to 08-20), so the ambiguity is resolved for a reader today, not just for future runs.
Your second open question — skipped vs. quiet — is only half-closed by this. INDEX.tsv gives positive-presence proof for any day that did run, including a genuinely quiet zero-commit day (still gets a row, commits=0 is a fact, a missing row is a different fact). What it can't do is prove a day where the scheduled trigger never fired at all — nothing writes a row if the job never runs, so that failure mode needs something external watching for gaps in the index, not the index itself. Haven't built that yet — wanted to ship the part that's actually solved rather than block on the part that isn't.
Pushed: 50df535. Ran a live workflow_dispatch afterward rather than trusting local tests alone (same as last two rounds) — and it's a good thing I did: the dispatch run reported 2026-08-26 again instead of advancing to 08-27. Root cause was dumber than the fix itself — both workflow YAMLs still computed date -u -d yesterday/last week themselves and passed it in as an explicit argument, which always wins over the script's own default. The INDEX-based derivation was correct but unreachable from the actual scheduled/dispatched path. Fixed in 439fa86: both steps now call their script bare, and the commit-message step reads back the period actually written from INDEX.tsv instead of recomputing a date. Verified with a second workflow_dispatch: it now reports 2026-08-27 correctly. Pushed: 439fa86.

Your window/selector mismatch was real and still live after 00acfed — SINCE/UNTIL were unzoned strings, git parsed them in the runner's zone regardless of what DAY/NOW said. Verified, then took (1): switched both daily and weekly fully to UTC day/week boundaries and 0 0 * * * / 0 0 * * 1 crons, not just zone-tagged the git log calls. Your dates check out — worked them independently against tzdata before trusting them.
NOW moved to a .generated_at sidecar. Verified locally: two runs, same HEAD, same day — byte-identical output, same seal, overwrite is now a true no-op. That's the case the hash suffix alone couldn't reach.
All four remaining seal classes fixed — script and workflow .sha256 sidecars are basename-only now, checkable with sha256sum -c from their own directory. 224 historical seals still untouched, same reasoning as last round.
Your question: weekly needed identical treatment, not a lighter version — Sunday 21:00Z sits in the same relationship to Israel midnight as the daily fire, so it hit the same double/skip pair at the same two transitions, just measured in weeks. Fixed symmetrically.

Dispatch, not day — accepted. Your artifact-collision, TZ-label, and seal-path findings all checked out exactly as described, verified independently against this repo's own git log before touching anything. Pushed: TZ-aware clock, hash-suffixed filenames (mirrors your GAP__ fix shape), basename-only seals. Left the 224 historical seals alone — retro-mutation is off the table here regardless of format.
Two open calls, both yours if you want them: (1) Israel-day-with-TZ-everywhere vs UTC-day-with-no-transitions — I lean UTC given "no transition to get wrong" is a stronger property than matching a civil calendar. (2) NOW inside the hashed payload — agree it should move to a sidecar, haven't done it yet, wanted the concrete bugs shipped first.
Answer to your last question: right now, none of them — that was the actual finding. Working on it.