fix(routing): impose a total order on the reviewer-vote read so latest-vote-wins is deterministic

[RealDiligent]

Summary

computeProviderTrackRecords (packages/loopover-engine/src/calibration/provider-track-record.ts) dedupes reviewer signals per (provider, targetKey) with last-write-wins, keeping the last element of its input array (the #8876 re-vote-inflation guard). Its only production caller, loadLiveProviderTrackRecords (src/services/reviewer-routing.ts), read the reviewer_vote rows with no ORDER BY.

SQL row order without ORDER BY is unspecified in both backends this repo targets (D1/SQLite and the Postgres self-host), so when a provider re-reviews the same PR after a push, which vote survives — and therefore that provider's precision, agreementRate, consensusRate, and splitRate — was decided by whichever row the engine happened to return last. computeWouldHaveRouted sorts on those records to pick a preferredProvider, and the result is written to a durable routing-shadow audit event (recordRoutingShadow) that #8229 stage 2 reads as its evidence base — so the nondeterminism reached recorded evidence.

Fix

• loadLiveProviderTrackRecords's vote query now ends ORDER BY created_at ASC, id ASC, mirroring src/review/risk-control-wire.ts's created_at+id tie-break discipline. created_at alone is insufficient — votes for one PR are written in a single loop (src/queue/ai-review-orchestration.ts) and can share a timestamp — so the id tie-break is mandatory. The SELECT list and the ProviderReviewSignal shape are unchanged.
• computeProviderTrackRecords's doc comment now states its input-order contract: signals must be ascending-chronological, "latest-vote-wins" means "last element of the input array wins", and the caller guarantees it via the ORDER BY.

Tests

Added to test/unit/reviewer-routing.test.ts:

• A regression test capturing the emitted vote SQL to assert it carries ORDER BY created_at ASC, id ASC, plus that a re-reviewed PR's record reflects the chronologically later vote (fails against the unordered query).
• A same-created_at test proving the id tie-break makes the surviving vote deterministic — this one fails against the current unordered query even with the in-memory backend.

Full reviewer-routing suite passes (11/11).

Closes #9638

[loopover-orb]

Warning

⏸️ LoopOver review result - manual review recommended

_{Review updated: 2026-07-29 19:06:28 UTC}

3 files · 1 AI reviewer · no blockers · CI green · clean

⏸️ Suggested Action - Manual Review

Review summary
This PR adds a deterministic ORDER BY created_at ASC, id ASC to the reviewer_vote SQL read in loadLiveProviderTrackRecords, closing a real nondeterminism where computeProviderTrackRecords' last-write-wins dedup depended on unspecified SQL row order. The id tie-break is well-justified since votes in a single loop can share a timestamp, and the two regression tests correctly pin both the ordering (via captured SQL) and the tie-break behavior with deliberately adversarial insertion order. The change is narrow, correctly traces the fix to the actual source of nondeterminism (the query, not the dedup logic), and is well-documented with an input-order contract comment.

Nits — 3 non-blocking

• The `orb(routing): the reviewer-vote read has no ORDER BY #9638` issue reference in the doc comment (provider-track-record.ts:89) is a magic number in prose only — not a functional issue, just a nit on doc style.
• The description claims this closes orb(routing): the reviewer-vote read has no ORDER BY #9638 but the external brief notes coverage is only 'partial' for that issue — worth confirming the PR fully addresses the issue's scope before merge.
• Consider extracting `created_at ASC, id ASC` tie-break convention into a shared constant/comment reference since risk-control-wire.ts uses the same pattern, to make future drift between the two call sites easier to catch.

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	#9638
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	❌ 5/25	Preflight is holding this PR: the review lane is unavailable, so it is not ready for automated review.
Contributor workload	✅ 10/10	Author activity: 251 registered-repo PR(s), 99 merged, 38 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	RealDiligent; Gittensor profile; 251 PR(s), 38 issue(s).
Improvement	✅ Minor	risk: clean · value: minor · LLM: moderate

Linked issue satisfaction

Addressed
The diff adds the required ORDER BY created_at ASC, id ASC to the vote query, updates the computeProviderTrackRecords doc comment to state the ascending-chronological input-order contract, and includes both the reversed-order regression test and the same-created_at id tie-break test as required.

Review context

• Author: RealDiligent
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is registered but has no active allocation in the current snapshot.
• Public profile languages: Python, Ruby, TypeScript, Svelte, Cuda, JavaScript, Markdown, MDX
• Official Gittensor activity: 251 PR(s), 38 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Start here: Await review-lane availability.
• Then work through the remaining 1 step 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

[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.74%. Comparing base (8e2d51d) to head (89c3d6b).
⚠️ Report is 9 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #9885      +/-   ##
==========================================
- Coverage   91.75%   91.74%   -0.01%     
==========================================
  Files         919      919              
  Lines      112987   112993       +6     
  Branches    27193    27193              
==========================================
+ Hits       103667   103669       +2     
  Misses       8034     8034              
- Partials     1286     1290       +4     

Flag	Coverage Δ
backend	95.68% <ø> (-0.01%)	⬇️
engine	71.81% <100.00%> (+<0.01%)	⬆️

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

Files with missing lines	Coverage Δ
...er-engine/src/calibration/provider-track-record.ts	100.00% <100.00%> (ø)
src/services/reviewer-routing.ts	100.00% <ø> (ø)

... and 1 file with indirect coverage changes

[loopover-orb]

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