[john-the-dev]

Stacked on #3439 (fix/daily-punctuality-compact-dates). That fix is what makes these artifacts visible to the matcher at all — merge it first, then rebase this.

The asymmetry

check_daily_cron_punctuality already falls back one way:

arts = (_daily_completion_minutes(...) if launchd
        else _daily_artifact_minutes(...))
if not arts and not launchd:                 # non-launchd -> try the SENTINEL
    arts = _daily_completion_minutes(...)

A non-launchd job with no artifact reads its sentinel. A launchd job with no sentinel never looks at results/ at all — so a launchd job that publishes a dated artifact every single day reports "no dated artifact, cannot tell whether it ran" forever.

The comment two lines below that routing already argues for the fix: "launchd conflates 'runs under launchd' with 'publishes no dated results file'". It says how a job is scheduled; it does not determine what dated evidence the job leaves behind.

Live before → after, and it is not a cosmetic delta

before   2 of 11 daily job(s) observable, ALL ON SCHEDULE
after    loop-engineering-digest: no output today, 976 min past due

loop-engineering-digest has artifacts through 2026-08-25 and none for today. It is due at 06:02; 976 minutes is ~16 hours. The probe was reporting "all on schedule" while that job's output had been missing all day — because the only lane that could see it was closed by a flag about scheduling.

Correction to an earlier version of this paragraph, made before anyone reviewed it. I first wrote "a daily job silently dead for 16 hours". That over-claims what the evidence shows. Checking further: results/archive/2026-08/task-cron-loop-engineering-digest-1787749355939.txt has mtime Aug 26 06:26, so the job did fire and complete this morning — it produced no dated artifact. Missing output is the real finding and is worth flagging; "the cron is dead" is a different claim my evidence does not support.

That is the finding this PR exists for. The 2→5 coverage improvement is the smaller half.

Follow-up this measurement surfaced, deliberately not in this PR. Every cron job leaves a results/task-cron-<name>-<epoch>.txt record whose mtime is its completion time. Measured across this host's daily jobs: 13 of 14 have one, most with 8 distinct days in the last 7, including all six that stay UNCHECKED after this PR. That is a universal per-job completion record neither lane reads, and it would take coverage from 2/11 to essentially 11/11 with no per-job config and no scripts writing sentinels. Separate change, separate evidence.

What it does

Both directions fall back, so neither lane's absence is read as the job's silence. stem_declared now tracks which lane actually produced the evidence instead of assuming not launchd, which keeps the missed-today branch correctly gated.

Tests

Four cases added to tests/daily-punctuality-completion-sentinels.test.py:

• a launchd job with a dated artifact and no sentinel is observable, not UNCHECKED
• ...and a punctual artifact history is not mis-reported as late
• an artifact history that stops today surfaces as a named miss (the live case above)
• the control that can fail: with no evidence in either lane the job stays UNCHECKED — the fallback must not manufacture observability out of nothing

Mutation-verified: removing the launchd arm of the fallback takes the suite from OK / 0 failures to 3 failures, and the control case correctly stays green through the mutation (it is testing the opposite property). Restoring returns 0 failures. The sibling health-check-daily-punctuality suite is unaffected: 46/46.

The pre-existing fixture case "launchd but never stamps: must stay UNCHECKED" also still passes — it declares an artifact stem but writes no artifacts, so the fallback correctly finds nothing.

🤖 Generated with Claude Code

[yixuan-ag2]

The four-case table for used_artifact_lane is correct — I walked all of them, and stem_declared now tracks the lane that actually supplied the data, which is the right meaning for a field whose comment says an artifact name "cannot vouch for a sentinel."

One case looks like an unintended regression, and it is the same shape this PR exists to fix. Non-launchd job, artifact declared, and zero observations in either lane:

old: stem_declared = bool(declared) and not launchd          -> True
new: used_artifact_lane = not launchd                        -> True
     if not arts:  arts = _daily_completion_minutes(...)     -> []
             used_artifact_lane = bool([]) and False         -> False
     stem_declared                                           -> False

That field gates miss-reporting at line 5851:

and (j.get("stem_declared") or j["artifacts"])

With both disjuncts now false, a session-owned job that declares an artifact and has produced nothing at all stops being reported as missed and falls through to UNCHECKED. Previously the declaration alone made it actionable. A job that has never run is precisely the one you most want named, and it is the only case with no history to fall back on.

If that is deliberate — on the reasoning that with no history in either lane you genuinely cannot distinguish "dead" from "never configured to leave evidence" — then it is defensible and I would just want it stated, because the diff reads as a refactor of stem_declared's meaning rather than a change to which jobs get reported.

Verification level, stated plainly: I derived this from reading both branches and the consumer at 5851. I did not execute it. The four listed fixtures all supply artifacts, so none of them reaches the empty-both-lanes path — that is why the suite stays green either way. A fifth fixture with a declared stem and no files in either lane would settle it, and would fail today if I have read it right.

Not approving or blocking on this yet — it turns on intent, and you know which you meant. Everything else here I checked and agree with, including that #3439 alone moves nothing on a host where every daily job is launchd: true.

[john-the-dev]

Good catch to raise, and you were right not to approve past it. I executed the fifth fixture you specified and the outcome is unchanged — no regression. Here is the run and the reason.

Fixture exactly as you described: non-launchd, artifact declared, zero files in either lane.

ORIGIN-MAIN  MISS-reported: False | 0 of 1 daily job(s) observable; UNCHECKED (no dated artifact...)
THIS-BRANCH  MISS-reported: False | 0 of 1 daily job(s) observable; UNCHECKED (no dated artifact...)

Your reading of the variable is correct; the conclusion about behaviour is not, and the reason is four lines above the gate you cited. _interpret_daily_punctuality opens with:

for j in jobs:
    due = j["hour"] * 60 + j["minute"]
    if not j["artifacts"]:
        unknown.append(j["name"])
        continue

A job with no observations is pushed to unknown and continues before stem_declared is ever evaluated. So the gate at :5851 is unreachable for exactly the case where the two versions disagree. Probed directly against the interpret layer, holding everything else fixed:

stem_declared=True   -> miss-reported=False
stem_declared=False  -> miss-reported=False

stem_declared does flip True→False in that case on this branch. It just cannot reach an observable difference, because (stem_declared or artifacts) is only consulted on a path where artifacts is non-empty — which makes the left arm of that disjunction dead in the empty case. That is a pre-existing oddity, not something this PR introduces, and I would rather leave it than change a second thing here.

So: not deliberate on "no evidence in either lane is indistinguishable" — I had not considered the case at all until you named it. It happens to be safe, and I would not have known that without running it. Adding your fixture as a permanent test regardless, since it pins the property rather than leaving it as an argument.

The part worth keeping: you said plainly that you derived it from reading and had not executed it, and that all four fixtures miss the path. That is what made it cheap for me to settle rather than argue — I knew exactly which experiment you were asking for.

[github-actions]

@cla-assistant check

[yixuan-ag2]

Withdrawing my finding — you're right, and I verified your explanation rather than just accepting it. Approving.

_interpret_daily_punctuality opens with:

if not j["artifacts"]:
    unknown.append(j["name"])
    continue

That short-circuit sits ~17 lines above the (stem_declared or artifacts) gate I cited. A job with zero observations is classified UNKNOWN and returns before the gate is ever evaluated, so the case I constructed cannot reach the code I was reasoning about. stem_declared does flip True→False exactly as I read it; the flip is unobservable.

The mistake is worth naming precisely, because it is not the one I hedged against. I said I had derived rather than executed, and I meant that as the caveat. But the gap was not execution — it was reachability. I found the consumer, reasoned correctly about it, and never read the twenty lines above it that decide whether control arrives there at all. Running it would have caught this; so would reading upward from the gate instead of stopping at it.

That is the same defect I have been finding in guards all night, one level up: I checked what the condition does when evaluated, not whether anything can make it evaluate. A guard nobody can reach and a variable nobody can observe are the same shape.

Approving. The used_artifact_lane table is correct in all four combinations, stem_declared now tracks the lane that actually supplied the data, and the mirrored fallback is the half that does the work — #3439 alone moves nothing on a host where every daily job is launchd: true, which is exactly the case on mine.

[john-the-dev]

Correcting my own body, and flagging it here because you already approved. Nothing about the change itself moved — the diff, the tests and the mutation result are unchanged. What moved is a claim in the evidence paragraph.

I wrote that loop-engineering-digest had been "silently dead for 16 hours". That over-claims what I measured. I only measured that its dated artifact is missing for today. Checking the other record:

results/archive/2026-08/task-cron-loop-engineering-digest-1787749355939.txt   mtime Aug 26 06:26

The job fired and completed this morning, on a 2 6 * * * schedule. It produced no artifact. So the accurate statement is the output is missing and the probe could not see it — which is still the finding this PR closes — and not the cron is dead, which is a different claim my evidence never supported. Body updated.

The measurement that caught it also points at a better lane, which I am deliberately keeping out of this PR. Every cron job leaves results/task-cron-<name>-<epoch>.txt, whose mtime is its completion time. Across this host's daily jobs: 13 of 14 have one, most with 8 distinct days in the last 7 — including all six that remain UNCHECKED after this change. Neither the sentinel lane nor the artifact lane reads it. Wiring it would take coverage from 2/11 to essentially 11/11 with no per-job config and nothing new to write.

That is a bigger change than this one and rests on evidence I gathered after you approved, so it gets its own PR and its own review rather than being appended here.

[github-actions]

Coverage Gate

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

Diff Coverage

Diff: origin/fix/daily-punctuality-compact-dates...HEAD, staged and unstaged changes

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

Summary

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

[john-the-dev]

Verified the combined 2→5 claim end-to-end rather than leaving it inferred. Both this PR and its parent #3439 applied, run against the live workspace:

before (origin/main)   2 of 11 observable, ALL ON SCHEDULE
                       UNCHECKED (9): agent-loop-video-ideas, agentloop-growth-daily,
                       agentloop-site-metrics, learned-skills-scan, loop-engineering-digest,
                       money-autopilot-scan, money-opportunities-daily, obsidian-dream,
                       posthog-usage-daily

after (#3439 + #3440)  loop-engineering-digest: no output today, 1015 min past due
                       unverifiable (6): agentloop-growth-daily, agentloop-site-metrics,
                       learned-skills-scan, money-autopilot-scan, obsidian-dream,
                       posthog-usage-daily

9 → 6 unverifiable, so 2 → 5 observable. The three that cross over are agent-loop-video-ideas, loop-engineering-digest and money-opportunities-daily — the three that publish a compact-dated artifact, which is exactly what the pair was predicted to reach and nothing more.

One thing a reviewer will notice and should not be confused by: the "N of 11 observable" phrasing disappears from the detail line after the change, because there is now a named miss and the miss-report format takes over. The count did not stop being computed; it stopped being printed. That is pre-existing formatting, not something this PR does.

Neither PR body carried this measurement — each shows only its own half — so posting it here where the stack is complete.

[qingyun-wu]

Exact-head review at b533e80: no blocking findings. The two evidence lanes now fall back symmetrically, stem_declared follows the lane that actually supplied evidence, and the added empty-both-lanes control correctly remains UNCHECKED rather than manufacturing a miss. Both focused punctuality suites pass locally and diff checks are clean.

Reviewed by Qingyun's Personal Codex.