fix(miner): cover ranked-candidates, replay-snapshot, and deny-hook-synthesis in right-to-be-forgotten purges (#8009)

[kai392]

Summary

• A repo-scoped right-to-be-forgotten purge (loopover-miner purge --repo <owner/repo>) left three repo-scoped stores untouched: ranked-candidates (miner_ranked_candidates), replay-snapshot (replay_snapshots, which embeds commit SHAs and README content), and deny-hook-synthesis (deny_rule_proposals).
• Add RANKED_CANDIDATES_PURGE_SPEC / REPLAY_SNAPSHOT_PURGE_SPEC / DENY_HOOK_SYNTHESIS_PURGE_SPEC in store-maintenance.ts, following the exact purge-cli.js omits contribution-profile-cache.js and governor-state.js's two repo-scoped tables from its right-to-be-forgotten sweep #7091/policy_verdict_cache missing from purge/status/migrate 'known local stores' lists #6987 shape; deny-hook-synthesis is purged on repo_full_name alone so the sweep clears every forge host (api_base_url), mirroring governor_reputation_history's documented precedent.
• Give each of the three stores a purgeByRepo method delegating to the shared, identifier-guarded purgeStoreByRepo (the same shape as run-state.ts / policy-verdict-cache.ts), and register all three in purge-cli.ts's REAL_PURGE_TARGETS — dry-run counting and real purges both included.
• No new purge mechanism, no behavior change for the existing nine targets; attempt-log's documented not-purgeable exemption is unaffected.

Closes #8009

Test plan

• test/unit/miner-purge-cli.test.ts: twelve-store dry-run counts, default-path env overrides, and a purge-cli's right-to-be-forgotten spec list is missing ranked-candidates, replay-snapshot, and deny-hook-synthesis stores #8009 regression proving real deletion across both forge hosts while other repos' rows survive
• Per-store purgeByRepo tests in miner-ranked-candidates.test.ts (incl. the malformed-repo guard), miner-replay-snapshot.test.ts, and miner-deny-hook-synthesis.test.ts (multi-forge sweep + 0-rows case)
• npm run typecheck; changed files at 100% line and branch coverage locally
• CI validate + codecov/patch

[loopover-orb]

Tip

✅ LoopOver review result - approve/merge recommended

_{Review updated: 2026-07-22 17:24:15 UTC}

10 files · 1 AI reviewer · no blockers · readiness 95/100 · CI green · clean

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
This PR extends `loopover-miner purge --repo` to cover three previously-untouched repo-scoped stores (ranked-candidates, replay-snapshot, deny-hook-synthesis), following the exact `LedgerPurgeSpec`/`purgeStoreByRepo` shape established by #7091/#6987. Each store gets a `purgeByRepo` method wired through `store-maintenance.ts`'s shared, identifier-guarded helper, and all three are registered in `purge-cli.ts`'s `REAL_PURGE_TARGETS` for both dry-run counting and real deletion. The deny-hook-synthesis purge correctly sweeps `repo_full_name` alone (ignoring `api_base_url`) to clear a repo across every forge host, mirroring `governor_reputation_history`'s documented precedent, and this is exercised by a real multi-forge regression test. Test coverage is thorough (dry-run counts, per-store purgeByRepo tests, a full #8009 regression proving real deletion while other repos survive) and the PR closes the linked issue #8009 with no scope creep beyond the three named stores.

Nits — 4 non-blocking

• packages/loopover-miner/lib/ranked-candidates.ts:108-113 defines its own local `normalizeRepoFullName(value, error)` (two-arg, custom error) while replay-snapshot.ts and deny-hook-synthesis.ts each use their own single-arg variants with hardcoded error strings — three near-duplicate guards across the three touched files; consider consolidating into `store-maintenance.ts` alongside the SQL-identifier guard already living there.
• The external-review brief's 'magic number 8009' flag on ranked-candidates.ts:108 is just the issue number in a comment, not a real literal — not an actual nit.
• Consider hoisting the repeated owner/repo validation regex logic into store-maintenance.ts as a shared `normalizeRepoFullName` so future repo-scoped stores don't need to redefine it a fourth time.
• The deny-hook-synthesis purge-spec doc comment (store-maintenance.ts:64-70) is dense; a shorter top-line summary would help scanability, though it's consistent with the file's existing verbose-comment style.

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	#8009
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: 87 registered-repo PR(s), 47 merged, 0 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	kai392; Gittensor profile; 87 PR(s), 0 issue(s).
Improvement	✅ Minor	risk: clean · value: minor

Linked issue satisfaction

Addressed
The PR adds RANKED_CANDIDATES_PURGE_SPEC, REPLAY_SNAPSHOT_PURGE_SPEC, and DENY_HOOK_SYNTHESIS_PURGE_SPEC in store-maintenance.ts following the exact shape of prior specs, registers them in purge-cli.ts's REAL_PURGE_TARGETS, adds purgeByRepo methods to each store keyed on repo_full_name (deny-hook-synthesis intentionally sweeps across all api_base_url values, mirroring governor_reputation_history's

Review context

• Author: kai392
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: JavaScript, Kotlin, Perl, Python, TypeScript, Vue
• Official Gittensor activity: 87 PR(s), 0 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.

[kai392]

@Loopover ask CI is green and the review verdict is approve/merge — is anything still blocking the automatic merge of this PR?