feat(review): bridge a submitter's AMS track record into ORB reputation, upgrade-only

[davion-knight]

What & why

Implements #6208's decided design. A repo running both ORB and AMS had no way to let a submitter's genuine AMS track record count toward their standing here — a contributor with a strong record on a local AMS instance still started from scratch on the ORB side.

This adds a pull-based, upgrade-only bridge behind a new amsReputationBridge converged feature.

Design (all four boundaries from #6208, enforced)

• Pull, never push. ORB pulls from AMS on demand. A push model would let any AMS instance — including a self-hosted one running against an arbitrary repo, per AMS's own "works standalone" design — write arbitrary trust signals into ORB's internal reputation store, a direct gaming vector. Pull keeps ORB in control.
• Upgrade-only. A strong AMS record can move a submitter toward trusted, never toward low. upgradeReputationSignal takes a boolean rather than a signal precisely so there is no representable way for AMS data to push a submitter down — an AMS record can never be used punitively against a contributor on an unrelated repo. Tested explicitly with a deliberately terrible record.
• Identity = plain authorLogin — the axis submitter-reputation.ts and TrackRecordPullRequestOutcome already share. No new identity system; deliberately not hotkey/wallet.
• Privacy by construction. TrackRecordPullRequestOutcome carries no score/ranking/wallet/hotkey fields, so the consumed shape is already safe. Inherits submitter-reputation.ts's STRICTLY INTERNAL contract — never surfaced in a label, comment, or check-run.

Fail-safe + config

Matching this path's existing contract, every degraded case yields "no bonus signal applied" and never throws into the gate: no endpoint configured, no AMS data, non-OK status, malformed body, unreachable instance, or timeout. The probe is timeout-bounded (AMS_TRACK_RECORD_TIMEOUT_MS = 400) so a slow AMS never stalls gate evaluation, and an already-trusted submitter skips the network entirely.

Default OFF, config-as-code: gated by the features.amsReputationBridge .loopover.yml toggle (documented in .loopover.yml.example + config/examples/loopover.full.yml) plus the LOOPOVER_REVIEW_AMS_REPUTATION_BRIDGE env kill-switch, following improvement-signal-wire.ts's precedent. With either unset the reputation path is byte-identical to today.

Tests

test/unit/ams-reputation-bridge.test.ts covers every case the issue names — no AMS data → unchanged; positive record → upgrades; unreachable/timeout/malformed/non-OK → unchanged, no throw; off-by-default; and the never-downgrade guarantee. 100% line and branch coverage on both new modules (44/44 stmts, 41/41 branches; wire 3/3, 6/6), with zero uncovered lines across every changed file.

Docs

LOOPOVER_REVIEW_AMS_REPUTATION_BRIDGE is documented in both surfaces the docs-drift check requires — tuning.mdx (the flag's behavior, its features.amsReputationBridge co-requisite, and the LOOPOVER_AMS_TRACK_RECORD_URL endpoint) and privacy-security.mdx (the operator flag block, marked never-shown like its reputation sibling).

Closes #6485

[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 93.60%. Comparing base (93f3467) to head (0f8d3ce).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #6566   +/-   ##
=======================================
  Coverage   93.60%   93.60%           
=======================================
  Files         675      677    +2     
  Lines       67764    67799   +35     
  Branches    18627    18646   +19     
=======================================
+ Hits        63431    63466   +35     
  Misses       3360     3360           
  Partials      973      973           

Flag	Coverage Δ
shard-1	43.98% <100.00%> (-0.07%)	⬇️
shard-2	36.85% <2.77%> (+0.05%)	⬆️
shard-3	32.52% <2.77%> (+0.10%)	⬆️
shard-4	34.87% <2.77%> (-0.03%)	⬇️
shard-5	31.09% <2.77%> (-0.03%)	⬇️
shard-6	45.58% <2.77%> (-0.04%)	⬇️

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

Files with missing lines	Coverage Δ
packages/loopover-engine/src/focus-manifest.ts	99.00% <100.00%> (ø)
src/review/ams-reputation-bridge-wire.ts	100.00% <100.00%> (ø)
src/review/ams-reputation-bridge.ts	100.00% <100.00%> (ø)
src/review/feature-activation.ts	100.00% <ø> (ø)

[loopover-orb]

Tip

✅ LoopOver review result - approve/merge recommended

_{Review updated: 2026-07-16 14:22:54 UTC}

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

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
Adds a pull-based, upgrade-only bridge letting an AMS track record upgrade a submitter's ORB reputation signal, gated behind a new `amsReputationBridge` converged feature and a paired env kill-switch/endpoint config. The logic is sound and well-tested: `upgradeReputationSignal` only ever moves toward `trusted`, `fetchAmsTrackRecord` fails safe on every error class (non-OK, malformed body, timeout, network error) and never throws, and an already-`trusted` submitter skips the network call entirely. Wiring into `focus-manifest.ts`, `feature-activation.ts`, env typing, and the example configs is consistent with the existing `improvementSignal`/`rag` pattern, and the empty-features fixtures in the modified tests were updated to match the new key. The CI `validate`/`validate-code` failures are worth checking (likely lint/format, e.g. import-order in `feature-activation.ts` where `isAmsReputationBridgeEnabled` is inserted out of alphabetical order relative to the other imports) but nothing in the visible diff indicates a functional break.

Nits — 5 non-blocking

• src/review/feature-activation.ts:35 — the new `isAmsReputationBridgeEnabled` import is inserted between `isImprovementSignalEnabled` and `isRagEnabled`, breaking the otherwise-alphabetical import order used by the surrounding lines; likely the cause of the `validate-code` (lint) failure.
• src/review/ams-reputation-bridge-wire.ts:1 and src/env.d.ts:349 use "master kill-switch" — consider "main kill-switch" to match neutral terminology used elsewhere in the codebase.
• src/review/ams-reputation-bridge.ts — `isUsableOutcome` only validates `authorLogin`/`state` are strings but never validates `state` is one of the expected enum values (`merged`/`closed`/`open`); a payload with `state: "bogus"` silently passes through and is simply excluded from both merged/terminal counts, which is fine behaviorally but undocumented.
• README/docs (apps/loopover-ui/content/docs/tuning.mdx:95) also uses "master kill-switch" phrasing — same neutral-terminology nit as the code comment.
• Fix the import order in src/review/feature-activation.ts to resolve the validate-code CI failure before merge.

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	#6485
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: 162 registered-repo PR(s), 104 merged, 0 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	davion-knight; Gittensor profile; 162 PR(s), 0 issue(s).
Improvement	✅ Minor	risk: clean · value: minor · LLM: moderate

Review context

• Author: davion-knight
• 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: 162 PR(s), 0 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.

Visual preview

Route	Viewport	Before (production)	After (this PR's preview)	Diff
/	desktop	before /	after /	diff /
/	mobile	before / (mobile)	after / (mobile)	—

Click any thumbnail to open the full-size screenshot. Before = production · After = this PR's preview deploy · Diff highlights exactly what changed.

_{🟩 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.