feat(scripts): add roadmap issue-drift check (#8390)

[jsdevninja]

Summary

• Add scripts/check-roadmap-issue-drift.ts + npm run roadmap:drift-check to fail when /roadmap ROADMAP_ITEMS with shipping-soon/planned status reference GitHub issues closed as completed.
• Pure comparison + parser covered in test/unit/check-roadmap-issue-drift-script.test.ts (no network); live check is manual/scheduled only — not wired into test:ci.
• Does not change roadmap page content (maintainer content refresh stays out of scope).
• Closes Add a drift check: /roadmap presents 7 issues as active/upcoming that are all actually closed as completed #8390.

Test plan

• npx vitest run test/unit/check-roadmap-issue-drift-script.test.ts (14 tests)
• npx tsc --noEmit
• npm run roadmap:drift-check fails loudly on current roadmap(phase 0): stabilize while shipping #233–roadmap(phase 3): repo owner intake console #236 completed active items and does not flag exploring roadmap(phase 4): adoption analytics and launch system #237/roadmap(phase 5): ecosystem distribution #238
• CI green on the PR

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 92.42%. Comparing base (712836f) to head (4e364c3).
⚠️ Report is 7 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #8413   +/-   ##
=======================================
  Coverage   92.42%   92.42%           
=======================================
  Files         791      791           
  Lines       79259    79259           
  Branches    23948    23948           
=======================================
  Hits        73252    73252           
  Misses       4868     4868           
  Partials     1139     1139           

Flag	Coverage Δ
shard-1	57.75% <ø> (+4.41%)	⬆️
shard-2	47.71% <ø> (-4.74%)	⬇️
shard-3	56.55% <ø> (+0.40%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

[loopover-orb]

Tip

✅ LoopOver review result - approve/merge recommended

_{Review updated: 2026-07-24 12:43:24 UTC}

3 files · 1 AI reviewer · no blockers · readiness 93/100 · CI green · clean

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
Adds a new standalone script + npm script that parses ROADMAP_ITEMS from roadmap.tsx via regex and flags active/upcoming items whose linked GitHub issue is closed as completed, mirroring the existing check-stuck-required-checks.ts pattern (injected GithubApi, pure logic separated from a guarded main()). The pure comparison and parser are well covered by 14 unit tests with no network calls, and the regex-based parser is validated against the real roadmap.tsx source in-repo. This is a manual/scheduled-only diagnostic tool deliberately not wired into test:ci, so its risk surface is low; the `any`-typed GithubApi and console-based CLI output are consistent with the sibling script's established conventions in this repo.

Nits — 5 non-blocking

• The brace-matching regex in parseRoadmapItems (scripts/check-roadmap-issue-drift.ts:64) uses `[^{}]+` per object, which would silently break parsing if a roadmap item's description ever contains a nested `{}` — worth a comment noting that assumption since it's a hand-rolled parser rather than a real TS/AST parse.
• console-based logging in main() (scripts/check-roadmap-issue-drift.ts:151-159) is fine for a manual CLI but mirrors debug-style output; consistent with check-stuck-required-checks.ts convention so not a real concern.
• The `any`-typed GithubApi (scripts/check-roadmap-issue-drift.ts:32) is explicitly justified in a comment and matches the existing sibling script's convention, so this is a deliberate, documented choice rather than a slip.
• Hardcoded `api.github.com` host (scripts/check-roadmap-issue-drift.ts:36) matches the same hardcoded host in check-stuck-required-checks.ts, so it's consistent with existing convention rather than a new pattern to flag.
• Consider extracting the shared makeGithubApi implementation (identical between this file and check-stuck-required-checks.ts) into a small shared module to avoid drift between the two copies over time.

Decision drivers

• ✅ Code review — No blockers (1 reviewer)
• ✅ Gate result — Passing (No configured blocker found.)

Context & advisory signals — never blocks the verdict

Signal	Result	Evidence
Linked issue	✅ Linked	#8390
Related work	✅ No active overlap found	No same-issue or scoped active PR overlap found.
Change scope	✅ 20/20	Low review scope from cached public metadata (1 linked issue).
Validation posture	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 215 registered-repo PR(s), 130 merged, 39 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	jsdevninja; Gittensor profile; 215 PR(s), 39 issue(s).
Improvement	✅ Minor	risk: clean · value: minor · LLM: moderate

Linked issue satisfaction

Addressed
The PR adds scripts/check-roadmap-issue-drift.ts which parses ROADMAP_ITEMS, checks issue state/stateReason via the GitHub API, and fails loudly only for shipping-soon/planned items closed as COMPLETED (exploring items are excluded), plus a roadmap:drift-check npm script and a network-free unit test covering the comparison and parsing logic, matching the issue's requirements without touching CI or

Review context

• Author: jsdevninja
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: not available
• Official Gittensor activity: 215 PR(s), 39 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Start here: Triage stale or unlinked PRs.

Signal definitions

• Related work = same linked issue, overlapping active PRs, or title/path similarity.
• Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
• Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
• Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
• Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

🧪 Chat with LoopOver

Ask LoopOver a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.

• @loopover ask <question> answers contribution-quality Q&A with source citations and freshness.
• @loopover chat <question> answers in natural prose from cached decision-pack facts via local inference (maintainer/collaborator; read-only).
• A plain-language @loopover mention with a real question is routed to the closest matching read-only command automatically — no exact syntax required.

Full command reference: https://loopover.ai/docs/loopover-commands

🧪 Experimental — new and may change.

_{🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed}

---

💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →.

Checked by LoopOver, a quiet PR intelligence layer for OSS maintainers.

• Re-run LoopOver review

[loopover-orb]

LoopOver approves — the gate is satisfied and CI is green.