Radar Ledger Update

---
name: radar-ledger-update
description: |
  Safely update TRENDS.md (the AI Radar ledger): append evidence, move stages, manage observation_queue, source_rotation and strategy_notes without breaking the file contract. Use every time TRENDS.md is edited, before committing radar updates, and when promoting or archiving trends.
---

# Update the ledger safely

`TRENDS.md` is the single source of truth and later sessions parse it. The
structure is a contract.

## File contract (do not change)

- Header: `# Trend ledger — AI Radar`, then `Last updated: YYYY-MM-DD`, then the
  stage legend.
- Sections, in this order: `## Active trends`, `## observation_queue`,
  `## source_rotation`, `## strategy_notes`, `## study_shelf`, `## calibration`.
- `## source_rotation`, `## strategy_notes` and `## calibration` are POINTER stubs only: their real
  append-only content lives in `logs/source_rotation.md` and `logs/calibration.md`
  respectively. Keep the two stub headers (the section order is the contract) but
  NEVER inline log lines back into TRENDS.md — appends go to the `logs/` files.
- Trend block: `### [id: slug-NNN] Title` with fields `alias`, optional
  `pinned: true`, `stage`, `confidence`, `first_observed`, `last_evidence`,
  `evidence:` (list), `notes:`.
- Evidence line: `- YYYY-MM-DD — URL — one line of context`.

## Rules

- Match findings to existing trends via id and `alias` before creating a new
  trend. New trends take the next free NNN and start at `seed` or `emerging`.
- ROUTE a captured primary, don't default to "queue it": (a) if it lands on an
  EXISTING trend's axis, append it as EVIDENCE there — a single primary suffices
  for an existing trend; the ≥3-source bar is only for CREATING a trend; (b) if
  the queue now holds ≥3 independent groups on one untracked sub-theme, promote
  that cluster to a `seed` trend; (c) else it stays a queue item. Leaving an
  on-axis primary in the queue (hoarding evidence) or a named primary in report
  prose only is a routing failure.
- Max 10 evidence items per trend — drop the oldest. Keep `last_evidence` equal
  to the newest evidence date.
- **`notes` is STATE, not an archive (bounded — APPLIED 2026-09-19, W38, was W37
  Proposal R; cooling period held, signal persisted: TRENDS.md reached ~468 KB with
  the single largest `notes` field ~55 KB (agentic-attack-surface-001), a full
  day-by-day running narrative that bloats every future run's context although its
  substance is already preserved write-once in the daily/weekly reports + git).** A
  trend's `notes` holds only: (1) the seed/promotion rationale (why it is a trend and
  its current stage), (2) the last ~6–8 dated appends, and (3) open promotion levers +
  current rotate-candidates. When appending would push `notes` past this — as a soft
  guide, keep a single `notes` field under ~4 KB — COMPRESS: drop the oldest dated
  narrative (the citable artifacts already live in `evidence:`; the full day-by-day
  story lives in the reports) and replace it with a one-line pointer ("full append
  narrative in the daily/weekly reports + git history"). Compressing `notes` this way
  is CURATION of a state field, not rewriting published history (which applies to
  `evidence:` lines, ARCHIVE.md and the append-only logs — those are never rewritten).
  Trim a bloated `notes` on the next run that touches that trend.
- Stage moves: at most ONE stage up per trend per day, only on new independent
  evidence, justified in `notes`. Demotions are always allowed. 21+ days without
  evidence → `dormant`; at 45+ days the weekly pass moves the entry to
  `ARCHIVE.md` as a one-line post-mortem.
- Pinned trends (`pinned: true`): NEVER auto-archived, no matter how long
  without evidence — they are the curator's standing-watch axes. They still
  follow the normal stage rules, INCLUDING going `dormant` when quiet (the
  ledger stays truthful about activity); they simply never leave the board.
  Only the curator adds/removes a pin (or the agent proposes it via amendment).
- `observation_queue` items are dated and marked "unverified" unless opened. It
  is a WORKING SET (signals pending verification), not a knowledge store — keep it
  bounded to a soft cap of ~25 live items by a CAP-DRIVEN burndown that runs every
  session, including quiet/no-evidence passes: while the queue is OVER the cap,
  resolve the oldest items toward the cap that run regardless of what the scan
  found; at/under the cap it stops on its own (resolve only the 1–2 oldest if
  stale). This is owed every run, never deferred to the weekly — a no-evidence
  pass is not a no-op for the queue. Items leave ONLY by resolution: promoted to a
  trend (the signal is captured there) or dropped with a one-line reason in the
  day's/week's report (write-once, permanent). NEVER silently delete — because
  every removal is either a promotion or a recorded drop, shrinking the queue
  loses no knowledge. Re-date an item only if it is genuinely still worth watching.
- Append one dated line per session to `logs/source_rotation.md` (the coverage
  log; not the TRENDS.md stub). Append dated corrections to `logs/strategy_notes.md`
  (the strategy log; not the TRENDS.md stub); never delete curator entries.
- `study_shelf`: newest first, format `date — [name](url) — one line of why`;
  single-artifact items allowed (the trend bar does not apply), opened primary
  sources only.
- `calibration` (now `logs/calibration.md`) is append-only and written by weekly
  runs only (see the `radar-self-eval` skill); daily runs never touch it.
- Update the `Last updated` line. Keep everything in English.

## Validate before commit

```bash
grep -n '^## ' TRENDS.md
# expected, in order: Active trends, observation_queue, source_rotation, strategy_notes, study_shelf, calibration
grep -c '^### \[id: ' TRENDS.md          # trend count matches expectations
grep -nE '^  - [0-9]{4}-[0-9]{2}-[0-9]{2} — ' TRENDS.md | head -3   # evidence format
grep -n '^Last updated:' TRENDS.md       # date is today
# the three externalized logs must exist and only grow (append-only):
for f in source_rotation strategy_notes calibration; do
  test -f logs/$f.md && printf '%-16s ' $f && tail -1 logs/$f.md | head -c 70 && echo
done
# TRENDS.md must NOT have regrown a log body — all three stay short POINTER stubs.
# A stub over ~10 lines means a run wrote the log INTO the ledger instead of logs/:
awk '/^## /{if(s)printf "  %-16s %d lines%s\n",s,n,(n<10?"  ok":"  <- REGROWN, move it to logs/");s="";n=0}
     /^## (source_rotation|strategy_notes|calibration)/{s=substr($0,4)} {n++}
     END{if(s)printf "  %-16s %d lines%s\n",s,n,(n<10?"  ok":"  <- REGROWN, move it to logs/")}' TRENDS.md
```

If a check fails, fix the file before committing. Commit and push per the
conventions in AGENTS.md.