fix(miner): resolve metrics-cli correct/incorrect via the calibration outcome-join

[rsnetworkinginc]

Summary

packages/loopover-miner/lib/metrics-cli.ts's collectPredictionMetricRows mapped
prediction-ledger rows onto MinerPredictionMetricRow but only ever set conclusion,
leaving the optional correct field unset on every row. As a result
loopover-miner metrics's loopover_miner_prediction_correct_total /
loopover_miner_prediction_incorrect_total counters were permanently stuck at zero for
every self-hosted miner, even though the renderer and the outcome-join both already exist.

This wires the realized-outcome pairing using the join calibration-cli.ts already
implements — no second join, and buildCalibrationReport's public contract is untouched.

Changes

• packages/loopover-miner/lib/metrics-cli.ts

  • collectPredictionMetricRows now resolves each prediction's correct by looking up the
    latest pr_outcome for the same (repoFullName, targetId) — reusing toPredictionRecords
    and toOutcomeRecords from calibration-cli.ts and normalizing both sides through
    calibration.ts's normalizeDecision, exactly as buildCalibrationReport does. A row is
    scored true/false only when both the prediction and its realized outcome normalize to
    merge/close.
  • A still-pending prediction (no realized outcome), a hold conclusion (no merged/closed
    counterpart), and an unclassifiable/malformed outcome all stay unresolved (correct left
    unset) — an undecided row is never fabricated as false, matching buildCalibrationReport's
    own treatment of hold.
  • runMetrics opens the event ledger the same way the bare calibration command does
    (initEventLedger(resolveEventLedgerDbPath(env)), read once, close in a finally), so
    metrics stays strictly read-only and offline with no change to its zero-argument usage
    contract.
  • The stale "the miner has no outcome-join yet" header comment is corrected.

• packages/loopover-miner/lib/calibration.ts: export the existing normalizeDecision
  so the metrics join reuses it verbatim (additive; no behavior change).

• test/unit/miner-metrics-cli.test.ts: cover every branch of the new join directly — a
  merge prediction confirmed by merged (correct: true) and disconfirmed by closed
  (false), a close prediction confirmed and disconfirmed the same way, a hold prediction
  (never resolved), a prediction with no outcome yet (pending, unresolved), a well-formed
  outcome whose decision is neither merged nor closed (unclassifiable, unresolved), and a
  malformed pr_outcome event (non-integer prNumber, skipped by toOutcomeRecords); plus the
  real event-ledger open path resolving the counters end-to-end.

Expected outcome

loopover_miner_prediction_correct_total / loopover_miner_prediction_incorrect_total now move
as real predictions resolve against realized PR outcomes, instead of being permanently zero.

Closes #8315

[superagent-security]

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

[codecov]

Codecov Report

❌ Patch coverage is 0% with 26 lines in your changes missing coverage. Please review.
✅ Project coverage is 89.30%. Comparing base (14ad838) to head (dfced6b).
⚠️ Report is 16 commits behind head on main.

Files with missing lines	Patch %	Lines
packages/loopover-miner/lib/metrics-cli.ts	0.00%	26 Missing ⚠️

❌ Your patch check has failed because the patch coverage (0.00%) is below the target coverage (99.00%). You can increase the patch coverage or adjust the target coverage.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #8487      +/-   ##
==========================================
+ Coverage   79.69%   89.30%   +9.61%     
==========================================
  Files         791       99     -692     
  Lines       79334    22778   -56556     
  Branches    23960     3898   -20062     
==========================================
- Hits        63222    20341   -42881     
+ Misses      13047     2259   -10788     
+ Partials     3065      178    -2887     

Flag	Coverage Δ
shard-1	0.00% <0.00%> (-55.42%)	⬇️
shard-2	?

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

Files with missing lines	Coverage Δ
packages/loopover-miner/lib/calibration.ts	0.00% <ø> (-100.00%)	⬇️
packages/loopover-miner/lib/metrics-cli.ts	0.00% <0.00%> (-100.00%)	⬇️

... and 692 files with indirect coverage changes

[loopover-orb]

Caution

🛑 LoopOver review result - fixes required

_{Review updated: 2026-07-24 15:39:36 UTC}

3 files · 1 AI reviewer · no blockers · CI failing · unstable

🛑 Suggested Action - Fix Blockers

Review summary
This wires `collectPredictionMetricRows` to resolve `correct` via the existing calibration outcome-join (`toOutcomeRecords`/`toPredictionRecords`/`normalizeDecision`), fixing the previously-permanent zero on the correct/incorrect counters, and threads an `EventLedger` open/close through `runMetrics` mirroring the existing `withPredictionLedger` pattern. The join logic in `resolveCorrect` correctly mirrors `buildCalibrationReport`'s classification (pending, hold, and unclassifiable outcomes stay unresolved rather than fabricating `false`), and `normalizeDecision` is exported from calibration.ts cleanly without altering its behavior. The new unit tests exercise the real join with a realistic event set (matched, mismatched, hold, pending, unclassifiable, and malformed prNumber cases), which is a meaningful improvement over the prior conclusion-only test.

Nits — 5 non-blocking

• The `fix(miner): metrics-cli's collectPredictionMetricRows never resolves correct/incorrect despite calibration-cli.ts already having the outcome join #8315` issue reference in metrics-cli.ts:42's comment is just a tracking id, not a magic number needing a named constant — the external brief's flag here is a false positive.
• console.log at metrics-cli.ts:119 is the pre-existing, intentional stdout output path for this CLI command, not a debug leftover.
• calibration.ts and metrics-cli.ts now each define their own private `recordKey` helper with identical logic — consider exporting one from calibration.ts to avoid drift if the key format ever changes.
• Consider exporting `recordKey` from calibration.ts and importing it in metrics-cli.ts instead of duplicating the function, since both must stay in lockstep with `buildCalibrationReport`'s join semantics.
• The codecov/patch failure (0% patch coverage reported) is inconsistent with the added join-focused test in miner-metrics-cli.test.ts — this is likely a stale coverage artifact given the branch is 4 commits behind default, worth re-running after a rebase.

CI checks failing

• codecov/patch — 0.00% of diff hit (target 99.00%)

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	#8315
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: 35 registered-repo PR(s), 14 merged, 3 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	rsnetworkinginc; Gittensor profile; 35 PR(s), 3 issue(s).
Improvement	✅ Minor	risk: clean · value: minor · LLM: moderate

Linked issue satisfaction

Addressed
The diff wires collectPredictionMetricRows to resolve `correct` via the existing calibration-cli.ts join primitives (toPredictionRecords/toOutcomeRecords, normalizeDecision), correctly leaves pending/hold/unclassifiable predictions unresolved, updates runMetrics to open the event ledger read-only, corrects the stale header comment, and adds unit tests covering matched/mismatched, hold, pending, an

Review context

• Author: rsnetworkinginc
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: TypeScript
• Official Gittensor activity: 35 PR(s), 3 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 is closing this pull request on the maintainer's behalf (CI is failing (codecov/patch)). This is an automated maintenance action — to pursue this change, please open a new pull request with the issues resolved. Closed PRs may be analyzed later to improve review accuracy, but they are not automatically reopened or re-reviewed.