fix(orb): correct stale "#6480 blocked on #6477" comments — federated import shipped

[kai392]

Summary

federated-bundle.ts:165-169 and federated-collector.ts:8-12,167 described the federated-import
trust mechanism (#6480) as still blocked on #6477. But src/orb/federated-import.ts fully
implements it: an operator-supplied federatedIntelligence.peerKeys allowlist (fail-closed when
unset, no PKI/reputation system), exactly per #6477's ratified key-trust design — and
federated-benchmark.ts:2-4 already lists export/transport/import as "already-shipped".

Updates both comments to describe #6480's shipped state. The collector's scope boundary — verification
lives on the import side, not the transport client that only fetches — is preserved (it was correct;
only the "blocked/not-yet-built" framing was stale).

Source of truth for the corrected text: src/orb/federated-import.ts (the allowlist trust-gate).

Test plan

• Comment-only change (issue states no test coverage requirement)
• No stale "blocked on Design: trust-gating/anti-poisoning scoring rules for federated signal-bundle import #6477" phrasing remains in src/orb/
• tsc --noEmit clean; federated-bundle/federated-collector unit tests still pass (39/39)

Closes #8878

[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 90.59%. Comparing base (6aaea39) to head (13e2315).
⚠️ Report is 5 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #8957      +/-   ##
==========================================
+ Coverage   90.56%   90.59%   +0.03%     
==========================================
  Files          96       98       +2     
  Lines       22490    22585      +95     
  Branches     3884     3923      +39     
==========================================
+ Hits        20367    20462      +95     
  Misses       1945     1945              
  Partials      178      178              

Flag	Coverage Δ
backend	100.00% <ø> (?)

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

Files with missing lines	Coverage Δ
src/orb/federated-bundle.ts	100.00% <ø> (ø)
src/orb/federated-collector.ts	100.00% <ø> (ø)

[loopover-orb]

Tip

✅ LoopOver review result - approve/merge recommended

_{Review updated: 2026-07-26 14:39:20 UTC}

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

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
This is a comment-only doc-fix updating two stale "#6480 blocked on #6477" comments to reflect that federated import shipped in src/orb/federated-import.ts, which I can confirm exists and does exactly what the updated comments describe: a fail-closed peerKeys allowlist gate (federated-import.ts's isFederatedImportEnabled, verifyFederatedBundle, importPeerBundles). The new comment text accurately reflects the real code — the allowlist design, fail-closed-when-unset behavior, and the scope boundary (verification lives on the import side, not the transport client) all check out against the referenced file. No functional code is touched, so there's no behavioral risk here.

Nits — 4 non-blocking

• The PR closes fix(orb): stale "blocked on #6477" comments in federated-bundle.ts/federated-collector.ts -- #6480 already shipped #8878 while the description title/body centers on Implement signature-bundle import + trust-gating validation for federated fleet intelligence #6480/Design: trust-gating/anti-poisoning scoring rules for federated signal-bundle import #6477 — worth double-checking that fix(orb): stale "blocked on #6477" comments in federated-bundle.ts/federated-collector.ts -- #6480 already shipped #8878 is actually the tracking issue for this stale-comment cleanup and not a mismatch.
• src/orb/federated-bundle.ts:165 and federated-collector.ts reference issue numbers (Design: trust-gating/anti-poisoning scoring rules for federated signal-bundle import #6477, Implement signature-bundle import + trust-gating validation for federated fleet intelligence #6480) directly in prose rather than as named constants, which is consistent with the existing comment style in these files so not worth changing here.
• None needed beyond what's already nitted — this is a low-risk, well-targeted documentation correction.
• Code changes lack test evidence — Add focused regression tests or explain why existing coverage is sufficient.

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	#8878
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	⚠️ 20/25	Preflight is ready, but the PR body does not name the validation run.
Contributor workload	✅ 10/10	Author activity: 130 registered-repo PR(s), 67 merged, 6 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	kai392; Gittensor profile; 130 PR(s), 6 issue(s).
Improvement	ℹ️ None detected	risk: low · value: none · LLM: minor

Linked issue satisfaction

Addressed
Both stale comments are updated to describe #6480 as shipped via federated-import.ts's peerKeys allowlist per #6477's ratified design, replacing the 'blocked on #6477' framing, and the PR cites federated-import.ts as the source of truth as required.

Review context

• Author: kai392
• 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: 130 PR(s), 6 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Start here: Add validation command/output.
• 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

[loopover-orb]

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