bd-radar

> **${var}** — Optional. `dry-run` skips notify (state + leads still update). Empty = normal run.

Today is ${today}. Read `STRATEGY.md` and `memory/MEMORY.md`. Read `memory/products.md` for your repos, handles, and search terms. If `soul/SOUL.md` + `soul/STYLE.md` are populated, write in the operator's voice; otherwise neutral.

## Why this exists

The north-star is **builders shipping on your products**. BD signal — a fork that actually runs, a repo that ships an extension on top of you, someone asking "can I integrate", a project quote-tweeting one of your handles — arrives scattered across GitHub, X, HN and Reddit, and usually reaches the operator weeks late, through the timeline, after the moment to engage has passed. `bd-radar` is the standing sweep that catches each inbound the day it appears and turns it into a **named lead with a suggested next move** — so you reach out while it's warm. This is "chase users, investors follow" wired into cron.

## Config — `memory/products.md`

Shared config (see `product-pulse` for the full format). `bd-radar` uses, per product: the **repos** (to find forks/issues), the **handles** (to find mentions/quote-tweets), and the **terms** (the product-name / tagline strings to search GitHub, X, HN, Reddit). If `memory/products.md` is missing or empty, log `BD_RADAR_NO_PRODUCTS_CONFIG` and fall back to `memory/watched-repos.md` for repos + `STRATEGY.md` for the wedge; X/term search is skipped with no config.

## What counts as a BD lead (signal taxonomy)

Ranked strongest → weakest. Tag each lead with its class:
| Class | Signal | Why it matters |
|-------|--------|----------------|
| `building` | New ecosystem repo / extension that runs on or builds on one of your products | Already shipped — highest intent, partner candidate |
| `forking` | New fork of one of your repos with its own commits (not a drive-by star) | Active builder — likely to ship next |
| `integrating` | Issue/PR/discussion asking to integrate, or a repo importing your API/SDK | Explicit ask — fastest to convert |
| `mentioning` | A project/builder account (not a random) posting about your products on X/HN/Reddit | Warm — worth a reply or DM |
| `adjacent` | A team in your wedge (the space your products occupy — see STRATEGY.md / the `surface` lines in products.md) doing relevant work | Outbound candidate — you reach out |

## Steps

### 0. Bootstrap
```bash
mkdir -p memory/topics output/articles
[ -f memory/topics/bd-radar-leads.json ] || echo '{"leads":[],"surfaced":[]}' > memory/topics/bd-radar-leads.json
```
`surfaced` is an LRU (cap 300) of already-reported lead keys (`{source}:{handle_or_repo}`) so each lead fires once. Also read the last 14 days of `memory/logs/` and extract names from prior `### bd-radar` blocks into the dedup set.

### 1. Parse var — `dry-run` prefix → skip notify. Else execute.

### 2. Gather candidates (run in parallel; any source may fail — log `BD_RADAR_SOURCE_MISS: <src> (<reason>)` and continue)

**GitHub forks + issues — direct GitHub API, in-run.** The default runner token is integration-scoped to this instance's own repo, so cross-repo forks/issues of your other (esp. private) repos **403/404** from inside the skill (the `forking` + `integrating` signals). `GH_READ_PAT` — a read-only PAT, declared in `requires:` and injected into this run — reads them. Call `api.github.com` directly through `./secretcurl`'s `{GH_READ_PAT}` placeholder so no bare `$SECRET` ever hits the command line (the Bash permission analyzer refuses those). Iterate your configured `owner/repo`s:
```bash
# When GH_READ_PAT is set, read via the {GH_READ_PAT} placeholder (a bare $GH_READ_PAT would be refused).
# When it is unset (the default single-key setup) the run's GH_TOKEN (= GH_GLOBAL, a repo-scoped classic
# PAT) reads the SAME cross-repo/private forks + issues via `gh api`. This is normal, not a degraded path;
# gh takes the token from the env, never the command line.
for repo in <owner/repo …from memory/products.md>; do
  slug="${repo//\//-}"
  if [ -n "${GH_READ_PAT:+x}" ]; then
    ./secretcurl -s -H "Authorization: Bearer {GH_READ_PAT}" -H "Accept: application/vnd.github+json" \
      "https://api.github.com/repos/${repo}/forks?sort=newest&per_page=40"  > "/tmp/bd-forks-${slug}.json"
    ./secretcurl -s -H "Authorization: Bearer {GH_READ_PAT}" -H "Accept: application/vnd.github+json" \
      "https://api.github.com/repos/${repo}/issues?state=open&per_page=40"  > "/tmp/bd-issues-${slug}.json"
  else
    gh api "repos/${repo}/forks?sort=newest&per_page=40"  > "/tmp/bd-forks-${slug}.json"  2>/dev/null || echo '[]' > "/tmp/bd-forks-${slug}.json"
    gh api "repos/${repo}/issues?state=open&per_page=40" > "/tmp/bd-issues-${slug}.json" 2>/dev/null || echo '[]' > "/tmp/bd-issues-${slug}.json"
  fi
done
```
Parse each repo's results (the `type=="array"` guard skips a 404/error object cleanly):
```bash
jq 'if type=="array" then .[] else empty end | {repo:.full_name, owner:.owner.login, created:.created_at, pushed:.pushed_at, size:.size}' /tmp/bd-forks-*.json
jq 'if type=="array" then .[] else empty end | select(.pull_request|not) | {n:.number, title:.title, user:.user.login, created:.created_at, body:.body}' /tmp/bd-issues-*.json
```
Keep forks with their own activity (`pushed` meaningfully after `created`) — drive-by forks are noise. Issues whose title/body asks to integrate/partner/build-on are `integrating` leads (the `/issues` endpoint also returns PRs — the `select(.pull_request|not)` drops them). An unset or empty `GH_READ_PAT` is the normal single-key setup: the `gh api` fallback (authenticated by the run's `GH_TOKEN` = `GH_GLOBAL`) reads the same forks + issues, so **never report an unset `GH_READ_PAT` as a 401, a source miss, or a follow-up to rotate or add a token**. Only log `BD_RADAR_SOURCE_MISS: github-forks-issues (<repo> 404)` when a `gh api` call itself fails for a specific repo (token lacks access), and lean on `gh search` for that one.

**GitHub discovery — `gh se