feat(engine): add a stable, versioned getTrackRecordSummary read API

[lourincedaging0-commits]

Summary

Groundwork for #6208 (reputation-bridge spec), part of the #6206 AMS+ORB synergy epic. Today AMS's calibration/track-record data is read ad-hoc with no single documented contract a future consumer could rely on. This adds one.

• getTrackRecordSummary(input): TrackRecordSummaryReadResult in @loopover/engine — a thin, versioned wrapper over the existing computeTrackRecordSummary, returning { version, summary } under a fixed envelope (TRACK_RECORD_SUMMARY_READ_VERSION) so a consumer can depend on one shape regardless of how TrackRecordSummary evolves.
• Read-only; adds no score/ranking fields — preserves the same public-safe boundary the summary itself keeps.
• Exported from the package barrel alongside the existing track-record APIs.

Tests

packages/loopover-engine/test/track-record-summary.test.ts adds a populated case (asserts the envelope carries exactly computeTrackRecordSummary's output, with the right version and merge/close counts) and an empty/no-history case (default-disabled summary, zeroed counts). Verified passing locally via node --test (30/30).

Closes #6246.

[superagent-security]

🚨 Contributor flagged. Click here for more info: Superagent Dashboard

[superagent-security]

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

[loopover-orb]

Warning

⏸️ LoopOver review result - manual review recommended

_{Review updated: 2026-07-16 04:27:16 UTC}

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

⏸️ Suggested Action - Manual Review

Review summary
This adds a thin, versioned passthrough wrapper (`getTrackRecordSummary`) around the existing `computeTrackRecordSummary`, plus a version constant and type, exported from the package barrel. The implementation is trivial and correct — it just returns `{ version, summary }` with no logic of its own — and the two new tests actually exercise the real function (populated and empty/no-history cases), asserting the envelope matches `computeTrackRecordSummary`'s real output rather than a fabricated shape.

Nits — 4 non-blocking

• The function is a pure 1-line passthrough with no validation or transformation of its own, so the JSDoc block is disproportionately long relative to the code — consider trimming it once the reputation-bridge consumer (Spec: bridge ORB's submitter-reputation signal with AMS's calibration/track-record data #6208) actually materializes and its real constraints are known.
• TRACK_RECORD_SUMMARY_READ_VERSION is hardcoded to `1` with no runtime path yet that could bump it — verify there's a plan (e.g. in Spec: bridge ORB's submitter-reputation signal with AMS's calibration/track-record data #6208) for how a future version 2 envelope would actually be produced/consumed, since right now it's an unused affordance.
• If Spec: bridge ORB's submitter-reputation signal with AMS's calibration/track-record data #6208 is still speculative, consider landing this wrapper directly alongside the first real consumer instead of as standalone groundwork, to avoid dead exported surface area sitting unused in the meantime.
• Add a brief note in the JSDoc or PR description about what a non-additive envelope change would look like in practice, so the version-bump comment has a concrete example to point to later.

Flagged checks (non-blocking)

• Contributor trust — Contributor flagged for review

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	#6246
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	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 99 registered-repo PR(s), 44 merged, 5 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	lourincedaging0-commits; Gittensor profile; 99 PR(s), 5 issue(s).
Improvement	✅ Minor	risk: clean · value: minor

Review context

• Author: lourincedaging0-commits
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: not available
• Official Gittensor activity: 99 PR(s), 5 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Start here: Add a concise scope and risk note.
• 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://gittensory.aethereal.dev/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.