DataRefresh

Registry-driven freshness engine for data-backed public sites. Each registered target carries its own fetch scripts, source-of-record dataset updater, build step, sanctioned deploy command, and live verify probe. One command reports staleness across the fleet; one command brings a target current.

Ideal State

• Every registered target's freshness is known against its own cadence, and a stale one is brought current from its real upstream sources, not from a cached or frozen copy.
• A target that passes its cadence reaches the principal without being asked, through a scheduled read-only status check that reports to Vigil; that check never refreshes or deploys.
• Nothing reaches production unless the principal's ask covered publishing, and a deployed refresh is proven on the live site.
• Narrative figures that the fresh data contradicts are found and fixed by hand; deterministic code never rewrites prose.
• Every refresh run leaves one line per target in the run log (status writes none), and every touched repo ends committed per its own conventions.

Intent Routing

Intent	Trigger	File
Status	"are our data sites stale", "data freshness", "status"	Intents/Status.md
Refresh	"update the data sites", "refresh <target>", "repull and redeploy"	Intents/Refresh.md

File	Read when
Setup.md	first install, registry fields, accounts and secrets, the throwaway-target proof

Data & Config

• Registry (private data, never in this skill): ~/.claude/LIFEOS/USER/CUSTOMIZATIONS/SKILLS/DataRefresh/Registry.json. $DATAREFRESH_REGISTRY overrides the path. With no registry, or one with no targets, the tool exits 1 and points at Setup.md.
• Run log: ~/.claude/LIFEOS/MEMORY/OBSERVABILITY/datarefresh.jsonl

Gotchas

• Registry validation is fail-loud by design. A missing repo path or malformed entry throws an InvariantViolation naming the entry — fix the registry, never wrap the load in a try/catch.
• Frozen upstream sources look alive. A source can keep serving 200s with years-stale data (a government feed that froze). When a target's record dates stop advancing across multiple refreshes while cadence says they should, check the source series itself before trusting the pull.

Examples

User: "are our data sites stale?"
→ Status intent
→ One table of every target with last pull, age vs cadence and STALE/FRESH, plus a one-line read and an offer to refresh what is stale

User: "refresh example-site"
→ Refresh intent, no --deploy (no publish intent)
→ Data repulled and rebuilt but not deployed; the report shows before → after record dates

User: "update the data sites"
→ Refresh intent with --all --deploy
→ Every target current, deployed through its sanctioned command, live freshness field shown advancing, repos committed