C.W.K.
Stream
Lesson 02 of 04 · published

The Quiet Daily Loop

~10 min · scheduling, backups, unattended, honest-failure

Level 0Open Gate
0 XP0/36 lessons0/12 achievements
0/100 XP to next level100 XP to go0% complete
"Once a day, before anyone's awake, the stronghold takes an honest snapshot of itself and files a fresh backup. If it can't, it says so — quietly."

What runs at 06:31

Every day at 06:31 Asia/Seoul, the single process runs its daily loop. In one pass it: does a strict-primary quote and FX refresh (no fallback — this is the unattended path from Track 4), regenerates both Markdown exports, appends one portfolio_value_history row per writable owner (giving the snapshot its time axis), and rotates SQLite-consistent backups, keeping the newest fourteen. It's the heartbeat that turns a live snapshot system into one with a durable, dated history and a safety net of recent backups — all without anyone touching it.

Strict-primary, because nobody's watching

Notice the refresh is strict-primary: it uses the primary provider only and never falls back. This is the unattended rule from the provider-boundaries track, showing up in its natural home. At 06:31 there's no human to confirm a provider substitution, so the loop refuses to substitute — it either gets clean primary data or it records an honest failure. The daily snapshot is durable and canonical; the last thing you want is a silently-swapped fallback source getting written into it permanently with no one aware.

Unattended work must fail honestly, never fail silently or fake success. A scheduled job with no human watching has to be more conservative, not less — it can't ask for confirmation, so it must refuse anything that would need one, and it must record what it couldn't do rather than papering over it. The absence of a watcher raises the bar for honesty, it doesn't lower it.

Failure becomes a visible chip, not a crash

When the loop can't complete — a provider is down, the network's out — it doesn't crash the process or silently skip. It records the failure honestly (an ok:false marker with the details) and that surfaces in the UI as a stale chip: a calm, visible indicator that the last refresh didn't succeed and the data you're seeing is older than it should be. Old observations stay intact; nothing is destroyed. You learn the truth ("this is stale, the refresh failed") in the same low-trigger, labelled way Keep handles every other kind of staleness.

Crash-safe backups are the loop's quiet insurance. Rotating SQLite-consistent backups — snapshots taken so they're never mid-write — and keeping the newest fourteen means there's always a recent, restorable copy of the family's records. Combined with forward-only recovery from Track 1, this is the whole disaster story: restore a good backup, pick a good revision, restart the one process. The daily loop keeps that safety net freshly woven.

Code

The daily loop: refresh, record, back up — honestly (illustrative)·python
def daily_loop():                  # 06:31 Asia/Seoul, in-process
    try:
        refresh_quotes(strict_primary=True)   # NO fallback (unattended)
        refresh_fx(strict_primary=True)
        regenerate_markdown_exports()
        for owner in writable_owners():
            append_value_history(owner, today())  # the time axis grows
        rotate_backups(keep=14)                   # crash-safe snapshots
        set_setting("last_daily_refresh", {"ok": True, "at": now()})
    except Exception as e:
        # Do not crash, do not fake success. Record it honestly.
        set_setting("last_daily_refresh", {"ok": False, "error": str(e)})
        # The UI reads this and shows a calm 'stale' chip. Data stays intact.

External links

Exercise

Design an unattended daily job for some system (a backup, a sync, a report). Decide three things: what it does on the happy path, what it refuses to do because no human is present to confirm, and how it records a failure so a human learns about it later WITHOUT the job crashing or faking success. Then describe how that failure should surface — loud alert, or calm visible marker? Justify the choice against the system's temperament.
Hint
Two traps for scheduled jobs: silent failure (nobody ever learns it broke) and fake success (it writes something wrong and moves on). The honest middle is a recorded ok:false that a surface can display later. For a calm tool, a visible 'stale' marker beats an alarm — but the non-negotiable part is that the truth is recorded somewhere a human will see it.

Progress

Progress is local-only — sign in to sync across devices.
Spotted a bug or have feedback on this page?Report an Issue

Comments 0

🔔 Reply notifications (sign in)
Sign inPlease sign in to comment.

No comments yet — be the first.