radar-self-evallisted

# Self-evaluation The radar must measure whether it is winning, not assume it. Three parts: metrics (every week), retrospective (monthly), curator proposals (every week). ## 1. Weekly metrics Compute from the week's daily reports (primary source — they list ledger changes) and, where needed, `git log -p -- TRENDS.md` since the previous weekly commit: - **queue funnel**: items added / promoted to trend / dropped / older than 14 days and still unverified (stale) - **ledger**: evidence items added, stage moves (up and down) - **exploration compliance**: daily runs whose `logs/source_rotation.md` line contains a venue-exploration entry ÷ daily runs executed - **off-axis rate**: share of new queue items that do NOT match any axis in `strategy_notes` (judgment call — name them) - **discovery lag**: for each evidence item added this week, the days between its evidence-line date and the date it entered the ledger (commit date via `git log -p -- TRENDS.md`, or the daily reports). Report the median, split by channel — exploration finds vs queue promotions (backfill) — plus the backfill share of all new evidence. This is the daily-ness KPI. - **coverage** (the self-check that auto-detects the listed-but-never-swept failure class): for each "swept every run" heading in SOURCES.md (lab blogs, YouTube curators, pointer/digest blogs, discovery venues, tool-discovery channels), enumerate EVERY entry under it — INCLUDING bullets nested under a sub-label (e.g. a "non-Gi