fix(engine): preserve explicit zero pairwise calibration weights

[RealDiligent]

Summary

• Fix normalizePairwiseWeights so explicit all-zero weights pass through as zeros instead of silently restoring the default 50/50 blend.
• Add the missing usable-weights / objective-only fallback stage in computePairwiseCalibrationScore, matching the fix(engine): backport reviewer-consensus-calibration.ts's zero-weight and malformed-repo handling to its two older siblings #6170 sibling pattern.
• Keep NaN/negative weight recovery on the 50/50 default; add engine + vitest regression coverage.

Closes #7443

Test plan

• Engine pairwise-calibration node:test suite (11 pass)
• npx vitest run test/unit/engine-calibration-convergence.test.ts
• git diff --check
• CI green (especially codecov/patch ≥99%)

[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 91.40%. Comparing base (4314944) to head (0fa6ac5).
⚠️ Report is 3 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #7477      +/-   ##
==========================================
+ Coverage   91.36%   91.40%   +0.04%     
==========================================
  Files         717      717              
  Lines       73020    73029       +9     
  Branches    21632    21636       +4     
==========================================
+ Hits        66717    66755      +38     
+ Misses       5265     5227      -38     
- Partials     1038     1047       +9     

Flag	Coverage Δ
shard-1	34.16% <0.00%> (-0.01%)	⬇️
shard-2	39.34% <100.00%> (+0.03%)	⬆️
shard-3	32.61% <0.00%> (+0.01%)	⬆️
shard-4	39.52% <0.00%> (-0.01%)	⬇️
shard-5	36.58% <0.00%> (-0.01%)	⬇️
shard-6	34.32% <0.00%> (-0.01%)	⬇️

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

Files with missing lines	Coverage Δ
...ckages/loopover-engine/src/pairwise-calibration.ts	89.58% <100.00%> (+87.01%)	⬆️

... and 1 file with indirect coverage changes

[loopover-orb]

Tip

✅ LoopOver review result - approve/merge recommended

_{Review updated: 2026-07-20 11:58:16 UTC}

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

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
This fixes normalizePairwiseWeights so an explicit {objectiveAnchor:0, pairwiseJudge:0} no longer silently reverts to the 50/50 default, and adds a second usable-weights stage in computePairwiseCalibrationScore so the objective-only fallback is reached correctly even when a real pairwiseJudgeScore exists (previously the composite would have incorrectly zeroed out under the old total<=0 check). I traced all five new test scenarios (explicit zero w/ pairwise present, NaN/negative recovery, non-zero normalization, missing-pairwise-with-zero-weights, missing-pairwise-with-nonzero-weights) against the implementation and each computed compositeScore/weights value matches what the code actually produces. The isInvalidWeight/NaN-negative branch correctly preserves the pre-existing 50/50 recovery behavior so it doesn't regress the older invalid-weight test.

Nits — 4 non-blocking

• packages/loopover-engine/src/pairwise-calibration.ts:59 — isInvalidWeight duplicates the !Number.isFinite(value) || value < 0 check already in finiteNonNegative; consider deriving one from the other to avoid drift.
• The explanatory comments in pairwise-calibration.ts (lines ~72-80, ~152-155) are quite long multi-line blocks; could be trimmed since the linked issue/PR already documents the rationale.
• Consider extracting the isInvalidWeight check into finiteNonNegative itself (e.g., have it return both the clamped value and an isInvalid flag) so the two functions can't diverge if the clamping rule changes later.
• The pattern here duplicates reviewer-consensus-calibration.ts's usable-weights logic (fix(engine): backport reviewer-consensus-calibration.ts's zero-weight and malformed-repo handling to its two older siblings #6170) — worth a shared helper if a third calibration module needs the same fallback shape.

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	#7443
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: 370 registered-repo PR(s), 171 merged, 34 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	RealDiligent; Gittensor profile; 370 PR(s), 34 issue(s).
Improvement	✅ Minor	risk: clean · value: minor · LLM: moderate

Linked issue satisfaction

Addressed
The diff makes normalizePairwiseWeights return explicit zeros (not the default blend) unless the input was actually invalid (NaN/negative), and computePairwiseCalibrationScore now adds the missing usable-weights second stage that falls back to objective-anchor-only when the usable total is zero, matching the reference pattern; regression tests cover the explicit-all-zero case, the NaN/negative rec

Review context

• Author: RealDiligent
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: Python, JavaScript, Ruby, Svelte, TypeScript, Markdown, MDX
• Official Gittensor activity: 370 PR(s), 34 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Keep the PR focused and include validation evidence before maintainer review.

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.