metric-watch

Spec §3.5's minimal metric-watch: "one routine watches budget ceiling, memory growth rate, classifier fail-closed events, backup unconfigured and writes findings to the journal for the next wake-up." Six independent checks (the post-0.8.0 no_llm-with-candidates signal joined the original four; the 0.8.7 fan-out-silent signal made six), one journal line per run.

What it watches

Each check is isolated — one crashing produces a check-error finding ({"kind": "check-error", "check": "<name>", "error": "<str>"}) instead of preventing the other five from running.

• fan-out silent — every fanout_event in the last 7 days landed with zero candidates. Items DO get related to other pages; a week of zeroes means the candidate scorer or the link walk is broken, not that the wiki has nothing in common with itself. Fires once per new batch of events, never on a run with nothing new.

When to use this skill

• Friend invokes /ren:metric-watch for an on-demand check
• Recommended cadence: weekly, registered as an actual scheduled routine via whatever the friend's harness uses for cron-like scheduling (this skill is the CHECK; registering it as a live cadence is the friend's harness-level choice — see skills/routine-init for the routine-spec declaration a scheduled invocation of this skill would need, including its own allowlist: _metric-watch as a NOOP page needs no wiki-write allowlist entry at all, since it never proposes a memory write).

When NOT to use this skill

• Watching a SPECIFIC routine's own health (not the framework's aggregate signals) — that's the routine's own state.md/run-log, surfaced by wake-up's read_live_routines (Task 5.1), not this skill

Behavior

1. Call importlib.import_module("skills.metric-watch.lib").watch(session).
2. watch runs all six checks (see table above), each wrapped so a crash becomes a check-error finding rather than an exception.
3. Findings are appended to the JOURNAL via lib.memory.journal.append — a routine-writer Provenance (op="NOOP", page="_metric-watch") carrying extra={"findings": [...]}. Never a wiki page write — wake-up already surfaces live routine state; the journal is the notify channel this check needs, and _metric-watch isn't a real page (no allowlist entry is needed for it — it's not a lib.memory.queue.propose call at all, op="NOOP" never touches a page).
4. Cross-run state (the memory-growth snapshot, the classifier high-water mark) persists at state_dir()/"metric-watch.json" — this is the one piece of state that must survive between runs; everything else is recomputed fresh each time from collect.read.

What this skill does NOT do

• Write to wiki pages. Findings live in the journal only.
• Auto-remediate anything. A backup-unconfigured finding doesn't run /ren:backup; a memory-growth finding doesn't prune anything. This is observation, not action.
• Require a routine-spec allowlist entry for itself. Its own op="NOOP"/page="_metric-watch" journal write never goes through lib.memory.queue, so check_proposal_against_allowlist never gates it.

Failure-degradation modes

References

• Task 3.1/3.3 (lib/instrument/collect.py, lib/instrument/miss_log.py) — the metrics surface this routine reads
• Task 6.1 (lib/governance/tiers.py) — the risk-tier model; metric-watch's own journal write is routine+NOOP, outside the tier gate entirely (no page write)
• Task 5.1 (hooks/wake-up/wakeup/__init__.py's read_live_routines) — where a friend sees this routine is live, not this skill's own output
• docs/data-flow.md — the local-only instrumentation surface this routine reads from and writes findings to