The radar reads upstream releases on a schedule and files an issue when an update is worth taking, with the reason and the risk #9609

The radar now runs every night at 05:07 UTC and files one issue per dependency that has a stable release above its pin. The new tests and the nightly, flows and resilience tests I ran pass. tsc, scripts/gate.ts and the design lint are clean. I did not run the full suite, because scripts/fast.ts named 1,261 files, which is too broad to run here.

• What it files: src/nightly/radar.ts runs each unarchived repository that pins packages through the existing registry read. It files issues titled Update <name> to <version>. The body says what changed, why it helps and what could break, worded by whether the jump is patch, minor or major. Prereleases, lookup errors and dev-only packages don't change this beyond a note in the body.
• No duplicates: a dependency with an open update issue gets nothing, and a version that was already filed gets nothing even if that issue was closed. A newer version after the old one closed files a fresh issue.
• Who it is for: the body says the crew takes it on an autonomous repository, and that it waits for a person otherwise. I did not add an assignee, label or hold to separate the two. The open issue is the only mechanism, so a non-autonomous repository relies on the wording.
• Schedule: the nightly service keeps a slot and a record for the radar like the other nights. A forge that was down at the slot runs it on waking, and it is off in a preview or without FORGE_TOKEN. Resilience (page and terminal) shows when it last ran and what it filed.
• Tests: test/radar-night.test.ts uses a fake registry and a real repository with a package.json. A new release files one issue per dependency and a second run files none. It also covers the "open issue means nothing new" and "closed issue doesn't refile the same version" cases, the autonomous wording, an unreachable registry, the end-to-end radarNight, and the service's slot and record.
• Docs: docs/features/flows.md has a short section on it.

Left out: a changelog fetch, so "what changed" is derived from the version gap rather than release notes. There is no per-repository opt-out or schedule setting.

Try it: in a test or console, startNightly(app, { forgeUrl, token })?.radar(), or call radarNight(app) directly.

Closes #9592

The radar now runs every night at 05:07 UTC and files one issue per dependency that has a stable release above its pin. The new tests and the nightly, flows and resilience tests I ran pass. tsc, scripts/gate.ts and the design lint are clean. I did not run the full suite, because scripts/fast.ts named 1,261 files, which is too broad to run here.

• What it files: src/nightly/radar.ts runs each unarchived repository that pins packages through the existing registry read. It files issues titled Update <name> to <version>. The body says what changed, why it helps and what could break, worded by whether the jump is patch, minor or major. Prereleases, lookup errors and dev-only packages don't change this beyond a note in the body.
• No duplicates: a dependency with an open update issue gets nothing, and a version that was already filed gets nothing even if that issue was closed. A newer version after the old one closed files a fresh issue.
• Who it is for: the body says the crew takes it on an autonomous repository, and that it waits for a person otherwise. I did not add an assignee, label or hold to separate the two. The open issue is the only mechanism, so a non-autonomous repository relies on the wording.
• Schedule: the nightly service keeps a slot and a record for the radar like the other nights. A forge that was down at the slot runs it on waking, and it is off in a preview or without FORGE_TOKEN. Resilience (page and terminal) shows when it last ran and what it filed.
• Tests: test/radar-night.test.ts uses a fake registry and a real repository with a package.json. A new release files one issue per dependency and a second run files none. It also covers the "open issue means nothing new" and "closed issue doesn't refile the same version" cases, the autonomous wording, an unreachable registry, the end-to-end radarNight, and the service's slot and record.
• Docs: docs/features/flows.md has a short section on it.

Left out: a changelog fetch, so "what changed" is derived from the version gap rather than release notes. There is no per-repository opt-out or schedule setting.

Try it: in a test or console, startNightly(app, { forgeUrl, token })?.radar(), or call radarNight(app) directly.

I merged main into the branch and pushed it; the only conflict was in docs/features/flows.md, and the merge commit is aaf0bab6.

• The conflict: I kept main's three bullets (Advisories, Forks, Forges that follow) and its "Left out" paragraph. After that I added this pull's "The nightly radar (#9592)" section.
• One edit to "Left out": I replaced "a schedule and the issue the crew files from a report" with "the nightly radar is below", because the nightly radar is now built.
• Checks: the gate and bun x tsc --noEmit ran with no errors. The nightly, flows and radar test files pass (105 tests). I did not run the full suite. scripts/fast.ts reported the diff was too broad to name tests, so I picked the nightly, flows and radar tests myself.

Box 3 is now met: the radar assigns each issue it files, and a new test fails if it doesn't. I ran only test/radar-night.test.ts (9 pass), plus the gate and bun x tsc --noEmit, both clean.

What changed

• Routing (box 3): src/flows/file.ts now routes each issue it files, using assignment, the same mechanism the crew already uses.

- Autonomous repository: the issue is assigned to a builder on the crew through assignIssue, marked as the crew's own pick, so the week's pace still holds it. If the crew has no builder it stays unassigned and the crew's normal pick-up can still take it. - Other repositories: the issue is assigned to the repository's owner, a person.

• Tests: test/radar-night.test.ts has two new tests. A non-autonomous repository's issue is assigned to the owner. An autonomous repository's issue is assigned to a crew builder.
• How to run it now (item 2): docs/features/flows.md says there is no button that files. Read upstream releases now only refreshes the readings; filing happens at the night's slot.

Where I kept my choice

• Author (item 1): the issues are still authored as the repository's owner. The flake hunt (src/checks/flake.ts), the culprit finder (src/checks/culprit.ts) and the throughput keeper (src/flow/keeper.ts) all file issues this way, and there is no separate forge actor. The doc now says so.
• Pipeline first (item 3): the issue named this as the radar's own work (#9592), so I had no grounds to defer it. I did not check how it ranks against the pipeline items, so I'm not claiming it should go first.