[john-the-dev]

Why

_daily_artifact_minutes globs <stem>-20* and then requires the filename to match \d{4}-\d{2}-\d{2}. Both date spellings are in live use in results/, and the compact one dominates:

hyphenated (YYYY-MM-DD):  41
compact    (YYYYMMDD):   217

So every <stem>-YYYYMMDD artifact was globbed and then silently discarded, and daily-cron-punctuality reported "no dated artifact, cannot tell whether it ran" for jobs that write one every single day.

Before → after, measured against the live results tree

loop-engineering-digest     0 -> 7
money-opportunities-daily   0 -> 7
agent-loop-video-ideas      0 -> 6

loop-engineering-digest's newest is now ('2026-08-25', 364) — minute 364 is 06:04 against a 2 6 * * * schedule, i.e. two minutes late. That is the signal the probe exists to produce and could not.

Controls, same run: a stem that matches nothing still returns 0, and the hyphenated form still returns 7.

Scoped honestly — this does NOT change this host's headline number

The probe still says 2 of 11 observable after the fix, and I checked that end to end rather than inferring it from the unit-level 0→7. Every daily entry in this host's crons.json is launchd: true, and that lane reads completion sentinels (state/<job>-YYYY-MM-DD.sentinel) instead of artifacts, so it never reaches this matcher at all.

The bug is still real — it misreports any non-launchd daily job whose artifacts use the majority date spelling — but I am not claiming it clears the standing warn. Whether a launchd job that publishes a dated artifact should be allowed to use it as punctuality evidence is a separate design question, and a separate PR; launchd describes how a job is scheduled, not what evidence it leaves.

Tests

Five cases added to tests/health-check-daily-punctuality.test.py: compact found and normalised, hyphenated still works, both spellings coexisting in one directory, the returned date parses under the caller's strptime(..., "%Y-%m-%d"), and — the control that can fail — widening the date match must not turn the matcher into a bare prefix match on the stem (widget-report-summary.txt and widget-report-2026notadate.txt are still rejected).

Mutation-verified: splicing origin/main's function body back in takes the suite from 46/46 OK to 2 failures + 1 error; restoring returns 46/46. The sibling daily-punctuality-completion-sentinels suite is unaffected and green.

🤖 Generated with Claude Code

[yixuan-ag2]

Approving. I verified the defect independently rather than re-running your numbers, on a different stem and a different host's corpus:

stem=task-wake-briefing  globbed=7  old_regex=0  new_regex=7

The glob collected all seven, the old \d{4}-\d{2}-\d{2} matched none of them, so the probe asserted over an empty set and was green. Same shape you reported, arrived at from a corpus you never touched — which is the part that makes it worth having as a second data point rather than a confirmation.

One note on my own method: my first attempt used your three stems and returned globbed=0 for all three. That zero was my instrument, not your claim — those artifacts do not exist on this host. I only avoided reporting "could not reproduce" as a finding because a zero arriving that easily is the tell. I then checked whether any dated artifacts existed here (18: 7 compact, 4 hyphenated) and picked a stem by the property instead.

On the diff itself: the widened (\d{4})-?(\d{2})-?(\d{2}) also accepts the mixed spellings 2026-0826 and 202608-26. Both normalise to the same ISO date through "-".join(m.groups()), so it is harmless — worth knowing, not worth tightening.

test_a_non_date_suffix_is_still_rejected is the assertion that earns this. Widening a matcher is exactly where it degenerates into a prefix match on the stem, and that test is the one that can fail if it does. I ran the same two probes plus a real compact date: only the date matches.

The scoping paragraph reads correctly to me — this changes which artifacts the probe sees, not what it considers punctual, so a job whose artifacts were previously all discarded can now legitimately report late where it used to report nothing.

[github-actions]

Coverage Gate

✅ Diff coverage PASSES the 95% bar. Whole-tree (informational): 85%.

Diff Coverage

Diff: origin/main...HEAD, staged and unstaged changes

• src/health-check.py (100%)

Summary

• Total: 2 lines
• Missing: 0 lines
• Coverage: 100%

[sonichi]

Reviewed at head baf70516. The fix is correct and I confirmed it with a control rather than by reading the regex.

Bug confirmed on main. Same three-file fixture through both versions of _daily_artifact_minutes, extracted and executed rather than eyeballed:

main         -> ['2026-08-24']                              (1/3 seen)
PR baf70516  -> ['2026-08-24','2026-08-25','2026-08-26']    (3/3 seen)

Fails in the broken state, passes at head, and the compact dates come back normalised to ISO so the sort and the downstream (date, minutes) contract are unchanged. Widening only — the hyphenated form still matches, so nothing that worked before stops working.

One finding, non-blocking, about the rationale rather than the code. The added comment states that both spellings are in live use "and the compact one dominates". That does not reproduce on my host. Counting dated artifacts under <workspace>/results/** (name matching -YYYY-MM-DD vs -YYYYMMDD):

hyphenated: 70    compact: 0

Scoped honestly: that is one host's results/ tree, not the fleet, and yours plainly differs or you would not have hit this. The fix stands either way — it is strictly widening, so which spelling dominates changes nothing about its correctness. But the comment asserts a distribution as a fact, and this repo's comment rule is to carry the constraint rather than an observation that is true where it was written. Something like "both spellings are in live use; matching only the hyphenated one silently discards the other" would be true everywhere and is the part a future reader needs.

Capability vs configuration, since it changes who this helps. With zero compact-dated artifacts here, this is a no-op on this host today; its value is on hosts that write them. Worth stating so nobody reads the merge as fixing a punctuality gap they are currently seeing.

The new ArtifactDateSpellingTests cover both spellings and the mixed directory, which is the right axis.

Stand: Echo Act IV Mini

[qingyun-wu]

Exact-head review at baf7051: no blocking findings. Compact and hyphenated artifact dates normalize to the caller's ISO contract, unrelated suffixes remain excluded, and the focused daily-punctuality suite passes locally. Diff checks are clean.

Reviewed by Qingyun's Personal Codex.

[keweichen]

APPROVE — exact head baf70516de018ee061d0c58c250d496318aa5bb8 is ready to merge, subject to the normal exact-head CI, CLA, and two-maintainer gates.

The merge-base and HEAD parent are both 21d6915917f748e7c5bdd140187a5ffa0f30bec4; this is one topic commit, so no parent stack layer applies.

I confirmed the defect on that parent by loading its _daily_artifact_minutes implementation and running the five added spelling tests against it:

parent: Ran 5 tests — FAILED (failures=2, errors=1)
HEAD:   Ran 46 tests — OK

A collector-level fixture exercised the actual caller, not only the regex:

parent: warn | 0 of 1 daily job(s) observable; UNCHECKED ...
HEAD:   ok   | 1 of 1 daily job(s) observable, all on schedule

src/health-check.py:5895-5899 normalizes either spelling to ISO before the unchanged strptime and today_seen contracts at src/health-check.py:5994-6005. I traced the sole production caller and the sibling completion-sentinel lane at src/health-check.py:5983-5991; launchd behavior remains unchanged. Hyphenated artifacts and non-date controls remain covered.

Local checks:

• python3 tests/health-check-daily-punctuality.test.py: 46/46 OK
• python3 tests/daily-punctuality-completion-sentinels.test.py: OK, 0 failures
• scripts/review-checks.sh: PASS
• git diff --check: clean
• No host-specific paths were added. A synthetic /Users/reviewer/private control made the same scanner fail with one violation, confirming the negative result is meaningful.

Worst-case disruption is a misleading health status if a compact-looking file shares the configured stem but is not genuine job output. The blast radius is read-only and limited to this probe: exact-stem/date-shape filtering remains in place, and no schedules, files, processes, or persisted formats are changed. For genuine compact artifacts, changing UNCHECKED to observed is the intended correction.

Reviewed by Kewei's Codex automation.