Radar Repo Watch

---
name: radar-repo-watch
description: |
  Watch GitHub every daily run for behind-the-scenes movement — across watched REPOS (releases, merged PRs, hot issues), watched PROFILES/USERS (what a key author ships next), and FORK TREES (notable forks up to depth 3, scored by a notability metric). Releases and merges are citable artifacts; profile/issue/fork movement is a queue signal until it lands. Default to GitHub's public Atom feeds + Tavily; the REST API is optional. Use during the daily scan, after the lab sweep. Source lists live in SOURCES.md → "GitHub watch".
---

# GitHub watch — repos, profiles, and fork trees

In big projects, important changes show up as PR/issue/fork activity well before
the headline release. Watching repos, the people behind them, and their fork
trees surfaces that build-up early.

## How to fetch (feeds first, no auth, no rate-limit worries)

Prefer GitHub's public Atom feeds and plain pages — the same RSS pattern as the
lab sweep, readable via `tvly` with no API key and no rate limit:
- Releases: `https://github.com/<o>/<r>/releases.atom`
- Tags: `https://github.com/<o>/<r>/tags.atom`
- Commits on default branch: `https://github.com/<o>/<r>/commits.atom`
- A user's public activity: `https://github.com/<u>.atom`
- PR list / issues / a fork's page: extract the HTML via `tvly` (no feed exists).

The REST API (`api.github.com`) is OPTIONAL — use it only if it is reachable
and authenticated in this environment (it may not be: the network often routes
through Tavily only, and unauthenticated API is 60 req/hr). When available it
gives cleaner structured data (exact `ahead_by`, merged_at); when not, the feeds
and page extraction above are sufficient. Never let the watch block on the API.

Check activity since the last scan (previous date in `logs/source_rotation.md`).
Log the watch every run, even when quiet ("github-watch: no movement").

## 1. Watched repositories

For each repo in SOURCES.md → "Watched repositories":
- **Releases / tags** (releases.atom / tags.atom) — a new release is a citable
  artifact (evidence-eligible against a trend).
- **Merged PRs** — extract the PRs page (`/<o>/<r>/pulls?q=is:pr+is:merged`);
  a notable merge (feature, format, kernel, model support) is a citable artifact.
- **Hot issues / discussions** — extract `/<o>/<r>/issues?q=is:open+sort:comments`;
  a suddenly high-activity thread is a QUEUE signal until it lands.

## 2. Watched profiles / users

For each user in SOURCES.md → "Watched profiles/users", read their activity feed
(`https://github.com/<u>.atom`) to see where they're heading: brand-new repos, a
repo getting heavy pushes, a new release on any of their repos. New repos/releases
are citable; early push activity on an unreleased repo is a queue signal
("watch <user>/<repo>, pre-release").

## 3. Fork-tree analysis (depth 3) + Fork Notability Score

For each project in SOURCES.md → "Fork-tree analysis", walk the fork tree up to
depth 3 (the repo's forks page / `/network/members`, then forks of the active
ones, etc.). Prune aggressively: only descend into a fork that is itself active
(updated in the last ~30 days) — dead forks have no live children worth chasing.

Compute the **Fork Notability Score (FNS)** per fork. Read the values from the
fork's page ("This branch is N commits ahead", star count, Releases tab) — or
from the REST API if it's available:

```
gate:   updated within last 30 days          (else skip — stale)
FNS  =  commits_ahead_of_upstream            (the "N commits ahead" figure)
      + 2 × (fork's own stars)
      + 20 if the fork has its own releases/tags
      + 15 if the fork has an open PR back to upstream
```

**Surface a fork under the project's trend when FNS ≥ 50 AND commits_ahead ≥ 20.**
- A fork that clears the bar AND ships a release/artifact → citable evidence
  under that project's trend (cite the fork repo/release).
- A fork that clears the bar but is still pre-release (just diverging fast) →
  `observation_queue` signal ("fork <o>/<r> diverging, N commits ahead").
- Name the fork in the trend's notes/evidence ("fork X carries feature Y not yet
  upstream"). Tune the threshold over time and log changes in the report.

Rationale: in this ecosystem the real innovation often lives in an active,
far-ahead fork (performance/quant variants) months before it merges upstream —
FNS is meant to catch exactly those, not the thousands of bookmark forks.

## Self-maintenance (agent owns this)

Add repos/users/projects that become central to a tracked trend; drop ones that
go silent or off-scope (one-line reason in the report). Adjust the FNS weights
and threshold as you learn what they surface — record any change. Keep all lists
in `SOURCES.md`.