fix(miner): wire policy_verdict_cache into purge/status/migrate local stores

[e11734937-beep]

Closes #6987

[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 93.75%. Comparing base (dfb3d23) to head (0416e14).
⚠️ Report is 4 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #7136   +/-   ##
=======================================
  Coverage   93.75%   93.75%           
=======================================
  Files         692      692           
  Lines       68851    68853    +2     
  Branches    18781    18781           
=======================================
+ Hits        64554    64556    +2     
  Misses       3302     3302           
  Partials      995      995           

Flag	Coverage Δ
shard-1	43.36% <50.00%> (-0.41%)	⬇️
shard-2	36.88% <100.00%> (-0.05%)	⬇️
shard-3	33.20% <50.00%> (+0.07%)	⬆️
shard-4	34.38% <50.00%> (-0.08%)	⬇️
shard-5	31.75% <50.00%> (-0.55%)	⬇️
shard-6	46.19% <100.00%> (+0.34%)	⬆️

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

Files with missing lines	Coverage Δ
packages/loopover-miner/lib/migrate-cli.js	100.00% <ø> (ø)
...ackages/loopover-miner/lib/policy-verdict-cache.js	100.00% <100.00%> (ø)
packages/loopover-miner/lib/purge-cli.js	100.00% <ø> (ø)
packages/loopover-miner/lib/status.js	94.53% <ø> (ø)
packages/loopover-miner/lib/store-maintenance.js	100.00% <100.00%> (ø)

[loopover-orb]

Tip

✅ LoopOver review result - approve/merge recommended

_{Review updated: 2026-07-18 00:06:36 UTC}

11 files · 1 AI reviewer · no blockers · readiness 75/100 · CI green · clean

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
This PR wires policy-verdict-cache.js into the purge/status/migrate CLI paths that #6987 says were missing it: it adds a `purgeByRepo` method (reusing the shared, identifier-guarded `purgeStoreByRepo`), a new `POLICY_VERDICT_CACHE_PURGE_SPEC`, and registers the store in `purge-cli.js`'s `REAL_PURGE_TARGETS`, `migrate-cli.js`'s `STORES`, and `status.js`'s `storeIntegrityChecks`, matching the exact pattern already used for `contribution-profile-cache` and the other repo-scoped stores. The change is well-scoped, closes the linked issue, and is backed by real regression tests (dry-run counts, real purge with cross-repo isolation, migrate/status store-count assertions) that exercise the actual new code path rather than fabricated scenarios. One thing worth a sentence of scrutiny: `purgeByRepo` deletes by exact match on `repo_scope`, but per the module's own doc comment `repo_scope` is a composite `apiBaseUrl + owner/repo` key for multi-tenant forges, while the purge CLI only ever passes a bare `owner/repo` — so non-default-forge cache rows won't be found by this purge. That limitation is pre-existing in every other repo-scoped store (run-state.js, contribution-profile-cache.js, etc. do the identical exact-match-on-plain-repoFullName), so it's not something this diff introduces or need fix here.

Nits — 3 non-blocking

• packages/loopover-miner/lib/policy-verdict-cache.js:104 — `purgeByRepo` matches `repo_scope` exactly, but that column can hold a composite `apiBaseUrl + owner/repo` scope for non-default forges while the purge CLI only ever passes a bare `owner/repo`; this mirrors the same pre-existing limitation in run-state.js/contribution-profile-cache.js so it's not new here, but worth a follow-up issue if multi-tenant purge correctness matters.
• packages/loopover-miner/lib/migrate-cli.js:6 — the module-level comment still says "same eleven stores `doctor` already covers (doctor's integrity sweep and migrate's proactive sweep both omit four real local stores #6768)" even though the list is now thirteen; this staleness predates this diff but you could tidy it while you're touching the neighboring array.
• Consider updating the stale "eleven stores" comment in migrate-cli.js:6 to avoid confusing the next contributor who counts entries in STORES.

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	#6987
Related work	✅ No active overlap found	No same-issue or scoped active PR overlap found.
Change scope	❌ 8/20	High review scope from cached public metadata (1 linked issue).
Validation posture	⚠️ 12/25	Preflight needs author follow-up before maintainer review.
Contributor workload	✅ 10/10	Author activity: 50 registered-repo PR(s), 30 merged, 2 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	e11734937-beep; Gittensor profile; 50 PR(s), 2 issue(s).
Improvement	✅ Minor	risk: clean · value: minor · LLM: moderate

Linked issue satisfaction

Addressed
The PR adds POLICY_VERDICT_CACHE_PURGE_SPEC in store-maintenance.js, wires it into purge-cli.js's REAL_PURGE_TARGETS, adds resolvePolicyVerdictCacheDbPath to status.js's storeIntegrityChecks and migrate-cli.js's STORES, and adds purgeByRepo plus tests covering purge/status/migrate paths, matching every listed requirement while leaving policy-doc-cache.js untouched.

Review context

• Author: e11734937-beep
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: JavaScript
• Official Gittensor activity: 50 PR(s), 2 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Start here: Add a concise scope and risk note.
• Then work through the remaining 2 steps in the Signals table above.

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.