kernel-radar

name	kernel-radar
description	Build an on-demand RL-Kernel roadmap, dependency, gap, document-plan, and competitor radar dashboard from live GitHub evidence. Use for "kernel-radar", roadmap dashboard, done vs missing, dependency flow, competitor progress, vexact comparison, 文档梳理, 竞品进展, or direction-review requests.

kernel-radar

Run the complete pipeline without asking the user to choose a mode. Produce the roadmap dashboard, gap narrative, competitor narrative, and optional document plan in one dated report folder.

Pause only when no GitHub token is available or every requested mode fails. Do not run or create scheduled automation.

{{ENGINE}} below is the installed engine directory on this machine (the installer resolved it). Every command runs from there.

1. Check the token

Check GITHUB_TOKEN or GH_TOKEN in the environment.

• If present, continue.
• If absent, ask for a fine-grained GitHub token with Public Repositories read-only access.
• Run without a token only when the user explicitly accepts degraded accuracy.

Never echo the token or write it to reports.

2. Gather data

Run:

python3 {{ENGINE}}/radar.py

When the user provides documents, pass files, directories, or globs:

python3 {{ENGINE}}/radar.py --docs <path-to-docs-or-file-or-glob>

Use paths from the printed ===KERNEL_RADAR_SUMMARY===; never hardcode output paths. Outputs live under <repo>/kernel-radar-reports/<DATE>/, with <repo>/kernel-radar-reports/latest.html as the stable local entry. Override the location with --output-root DIR or $KERNEL_RADAR_OUTPUT_ROOT.

Target a different project with python3 {{ENGINE}}/roadmap.py --repo OWNER/NAME (radar.py defaults to RL-Align/RL-Kernel).

The dashboard must contain:

• phase progress and status counts;
• the sprint critical path;
• explicit dependency edges parsed from depends on, blocked by, or requires references;
• merged/open, done/unticked, untracked, unresolved, and closed-unmerged gaps;
• live competitor activity and evidence quality;
• document-derived candidates when documents were supplied.

Do not invent dependency edges. If the roadmap has no explicit dependency reference, state that the graph is incomplete and recommend adding one.

3. Write the roadmap report

Read outputs.roadmap_data_json and write outputs.roadmap_report_md.

Use these status rules:

• done: roadmap checkbox checked;
• likely_done: every primary tracking reference is a CLOSED issue or MERGED PR;
• in_progress: partial primary evidence exists, or a merged PR references an open primary tracking issue;
• todo_tracked: primary tracking issue remains open, is unresolved, or is a closed-unmerged PR;
• todo_untracked: no tracking issue exists.

Treat dependency_refs as prerequisites, not completion evidence for the dependent item. Treat low-confidence PR body mentions as progress signals requiring review, not proof of completion.

Report shape:

1. ## Gap analysis — <DATE>
2. Snapshot with strict and evidence-adjusted completion
3. Merged PR / open issue gaps
4. Done / unticked gaps
5. Untracked directions
6. Marked done / open issue gaps
7. Unresolved or closed-unmerged evidence
8. Dependency and critical-path status
9. Recommended next actions
10. Copy-pasteable backfill checklist when actionable

Cite issue and PR links. Never recommend ticking a closed-unmerged PR without replacement evidence.

4. Write the competitor report

Read outputs.competitors_data_json and write outputs.competitor_diff_md.

For every tracked repository:

• map releases, merged PRs, linked commits, changed files, and technical_signals onto RL-Kernel themes;
• judge ahead, behind, complementary, or low relevance;
• distinguish complete data from fallback/lower-bound data using data_quality;
• list deep-analyzed and retained discovered repositories;
• end with concrete direction adjustments.

Every shipped claim must link to release, PR, or commit evidence in the JSON. Prefer PR body and changed-file evidence. Do not infer absence of work from an API failure.

Position RL-Kernel as first reproducible end-to-end RL train-inference consistency. Never claim first batch-invariant kernels. Watch verl-project/vexact as the closest operator-level competitor.

5. Reconcile document candidates

When doc_plan_json exists:

• treat extracted items as candidates, not committed truth;
• use primary_theme, secondary_themes, and confidence;
• reject generic benefit statements and duplicated items;
• distinguish developer-tooling requests from RL-Kernel product roadmap work;
• recommend GitHub issues only for high-signal, near-term untracked work;
• compare document candidates with roadmap gaps and competitor evidence.

6. Deliver

Validate that dashboard.html, latest.html, both narrative reports, source JSON, and optional document-plan files exist. Confirm reports contain no token.

Publish the dashboard with the Artifact tool when available using favicon 📡, title RL-Kernel Radar Dashboard, and the run date as label. Otherwise provide clickable local paths to latest.html and each report.

Report briefly:

• done/total and gap counts;
• dependency count and the critical blocker;
• two to four highest-priority gaps;
• the strongest competitor movement and any data-quality caveat;
• document candidate counts when present;
• dashboard and report paths.

Configuration

Use {{ENGINE}}/references/watchlist.yaml to tune seeds, discovery queries, filters, lookback, PR detail depth, and retained local runs. Keep seeds short; live discovery is the primary source.