Done-when has a clock in itReview

Phase 1 of RESET-2026 is merged, pushed, and working — and unverified. Its acceptance bar needs seven consecutive mornings; you have two. The test finishes Aug 21, not at the commit.

Most acceptance criteria are checkable the moment the code lands. Does the function return the right value, does the page render, does the route dispatch. You run it, you see it, you're done. But some criteria have a clock in them — seven consecutive mornings, no failures for a month, survives a restart — and those cannot be checked at merge no matter how carefully you read the diff.

Time-bearing criteria are the ones that quietly go unverified, and the reason is psychological rather than technical. The commit produces the feeling of completion. The satisfaction arrives, the branch merges, attention moves to phase 2 — which is exactly what happened Saturday, when phase 2 landed about an hour after phase 1. Nothing was left to do that felt like doing, so the criterion just sat there.

The fix is to make the clock someone else's job. If the seven-morning check lives in your head, it depends on you remembering on Aug 21 that you cared on Aug 15. If it lives in job_health_check.py, it runs whether you remember or not, and it stays red until it's genuinely satisfied. A criterion you can't automate is a criterion you'll assume was met.

Worked example

Turn the prose criterion into a check that stays red until it's true:

# Where you are right now
ls /Users/tom/Claude/PDB/output/brief/
#   2026-08-15.html  2026-08-16.html  index.html   -> 2 of 7

# The criterion, as code (sketch for job_health_check.py):
def consecutive_days_check(name, dirpath, days, recover):
    from datetime import date, timedelta
    import os
    def _check():
        today = date.today()
        want = [(today - timedelta(days=i)).isoformat() for i in range(days)]
        have = [d for d in want
                if os.path.exists(os.path.join(dirpath, f"{d}.html"))]
        if len(have) == days:
            return True, f"{name}: {days} consecutive days present"
        missing = [d for d in want if d not in have]
        return False, f"{name}: missing {missing}. Recover: {recover}"
    return _check

• Two files is the honest current state. Phase 1's own bar is seven, so the earliest possible pass is Aug 21 — and only if every morning between now and then lands.
• The check builds the list of dates it expects rather than counting files. Counting would pass on seven scattered days; the criterion says consecutive.
• It returns the same (bool, message) tuple as every other check in that file, so it slots into the existing registry with no other changes.
• The failure message names the missing dates. A monitor that says 'failed' makes you investigate; one that says which mornings are missing makes you fix.

Gotchas

• Seven consecutive days including LLM-failure days is the actual bar — the fallback_brief.py path is the interesting half. A week with no failures doesn't prove the fallback works.
• Don't backfill the directory to make the check pass. The dates are evidence; writing them by hand converts a test into a decoration.
• If you retire the check on Aug 21, note in the commit that the criterion was met and when. Otherwise the next person to read the roadmap can't tell verified from assumed.