feat(mcp): add a maintain audit-feed CLI mirror for loopover_get_agent_audit_feed

[luciferlive112116]

Summary

The agent audit feed was reachable over MCP (loopover_get_agent_audit_feed) and REST (GET /v1/repos/:owner/:repo/agent/audit-feed), but not from the CLI — it wasn't among maintain's subcommands. This adds:

loopover-mcp maintain audit-feed --repo owner/repo [--since <iso>] [--limit <n>] [--pull <n>]

a thin proxy over that same route, following the maintain precision / onboarding-pack subcommand shape (the precedent the issue names).

Design

• The CLI never decides locally. The API already enforces maintainer authorization and validates every param — since must be ISO-8601, limit 1–200, pull a positive integer — so the flags are forwarded verbatim and a bad value surfaces as the route's own 400 detail. Re-validating here would be a second, drifting copy of rules the route already owns.
• Absent flags are omitted from the query entirely (not sent as empty), so the route applies its own defaults.
• Output parity is structural: --json re-serializes the API payload untouched via the shared emit, so the CLI and REST/MCP surfaces return the same bytes for the same input. Only the plain-text rendering is CLI-local.
• The plain-text line reflects the route's two shapes: pullNumber is echoed only on the ?pull= branch, so the header reads owner/repo for the repo-wide feed and owner/repo#7 when scoped.
• A null detail is dropped from the line rather than printed as "null".

Per the #6261 convention noted on precision: every field is the API's own, and the composed line reaches the terminal only on the plain-text path, where the route has already sanitized detail before it left the server.

Two things the CLI surface required beyond the subcommand

Neither is in the issue's deliverables, but both are load-bearing — the change is incomplete and CI-red without them:

• COMPLETION_SPEC's maintain list (loopover-mcp.js:95) enumerates subcommands for shell completion. Without audit-feed there, the command exists but never tab-completes.
• mcp-cli-basics.test.ts:224 pins the generated PowerShell completer's exact 'maintain' = @(…) string, so it fails the moment that list changes. Updated to match. I checked the other shells (bash/zsh/fish) — only PowerShell's list is pinned; the rest are generated dynamically and needed nothing.

Tests

Three cases in mcp-cli-maintain.test.ts, mirroring precision's existing pattern, driven through the real CLI against the fixture server:

• Plain + JSON output, with parity — the same events reach both surfaces; the null-detail line is asserted to render without a trailing "null".
• Flag pass-through — --since/--limit/--pull are asserted to arrive at the route (the fixture echoes the received query), plus the #7-scoped header. This is the issue's "output parity between the mirrored surfaces for identical input" requirement.
• Omission — with no flags, the route receives no query params at all.

The fixture server gained an audit-feed handler that mirrors the route's two real shapes (repo-wide vs ?pull=-scoped) and echoes the query it received, which is what makes the pass-through assertions meaningful rather than self-referential.

Validation

• 48/48 pass across every affected suite: mcp-cli-maintain, mcp-cli-basics, mcp-cli-completion-spec — the last two because the shared harness and the completion spec both changed.
• node --check on the CLI entrypoint passes · npm run typecheck — 0 errors · eslint — 0 errors/0 warnings · git diff --check clean · rebased on latest main, no base conflict.

Codecov scope, checked rather than assumed: the root vitest.config.ts coverage.include is src/**, packages/loopover-engine/src/**, and packages/loopover-miner/lib/** — packages/loopover-mcp/** is not listed, so the 99% patch gate does not reach this file. Flagging that explicitly so a reviewer isn't puzzled by the absent signal; the subcommand is fully covered by the three tests above regardless.

One pre-existing failure, not mine — verified, not assumed: command-reference:check reports command-reference.ts stale, and does so identically on clean main with my work stashed (a local line-ending artifact). Regenerating produces a zero-content diff, and the generator reports the same "9 maintainer-only" command count before and after — it enumerates top-level commands, not maintain subcommands — so no regenerated file belongs in this diff.

Scope

• Four files: the subcommand + help + completion list, its tests, the fixture route, and the one pinned completer assertion. Wanted paths (packages/, test/).
• No new route, no new tool, no auth change — this mirrors an existing surface and adds no capability that MCP/REST didn't already expose.
• No UI, so no screenshot table applies.
• No secrets; no changelog, site/, CNAME, or lovable changes.

Safety

• Read-only: a GET proxy with no write path.
• Purely additive — every existing subcommand is untouched, and the unknown-subcommand error message is extended to list audit-feed so it stays accurate.
• Authorization is unchanged and remains server-side: an unauthenticated or non-maintainer caller is rejected by the same route that already rejects them today.

Closes #6733

[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.71%. Comparing base (363a8b5) to head (edeed5b).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #6933   +/-   ##
=======================================
  Coverage   93.71%   93.71%           
=======================================
  Files         685      685           
  Lines       68358    68358           
  Branches    18726    18726           
=======================================
  Hits        64059    64059           
  Misses       3302     3302           
  Partials      997      997           

Flag	Coverage Δ
shard-1	43.69% <ø> (ø)
shard-2	36.84% <ø> (ø)
shard-3	32.76% <ø> (ø)
shard-4	34.84% <ø> (-0.01%)	⬇️
shard-5	31.32% <ø> (ø)
shard-6	45.75% <ø> (ø)

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

[loopover-orb]

Tip

✅ LoopOver review result - approve/merge recommended

_{Review updated: 2026-07-17 14:32:35 UTC}

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

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
This PR adds a `maintain audit-feed` CLI subcommand that thin-proxies GET .../agent/audit-feed, following the exact pattern of the existing `precision`/`onboarding-pack` subcommands: flags are omitted from the query when absent (letting the API apply its own defaults), `--json` re-serializes the payload untouched for structural parity, and the plain-text renderer correctly drops a null `detail` via `filter(Boolean)` and only echoes `pullNumber` on the scoped branch. Tests exercise plain+json parity, flag forwarding, and the omitted-flags-default case via a matching fixture-server addition, and the completion-spec list, help text, and error message are all updated consistently. The implementation is well-scoped to the stated issue (#6733) and I don't see a defect in the visible diff.

Nits — 5 non-blocking

• The subcommand block in loopover-mcp.js is heavily comment-laden relative to the rest of the file's style; consider trimming to the non-obvious parts (query omission behavior, null-detail dropping) rather than restating what the code already shows.
• `payload.pullNumber ? ... : repoFullName` in the audit-feed handler would silently fall back to the repo-wide header if the API ever returned `pullNumber: 0`; harmless today since pull numbers are always positive, but worth a comment noting that assumption if it isn't already documented at the route.
• No test asserts behavior when the API returns a 400 for an invalid `since`/`limit`/`pull` value — worth one case confirming the CLI surfaces the route's own error detail verbatim, consistent with the PR's stated design.
• Add a negative-path test (bad `--limit` or `--since`) mirroring the existing `precision`/`onboarding-pack` error-surfacing tests, since that's the core design claim of this PR (no local re-validation).
• Consider extracting the repeated `filter(Boolean).join(" ")` event-line composition if a fourth maintain subcommand ever needs it, though at two occurrences it's not yet worth abstracting.

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	#6733
Related work	⚠️ 3 scoped overlaps	Top overlaps are listed below; lower-confidence bulk is hidden.
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: 171 registered-repo PR(s), 103 merged, 28 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	luciferlive112116; Gittensor profile; 171 PR(s), 28 issue(s).
Improvement	✅ Minor	risk: clean · value: minor · LLM: minor

Linked issue satisfaction

Addressed
The PR adds a `maintain audit-feed` subcommand proxying the REST route with --since/--limit/--pull forwarded verbatim, updates printMaintainHelp and the completion spec, and adds unit tests mirroring the precision pattern plus an explicit output-parity assertion between plain-text and --json.

Review context

• Author: luciferlive112116
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: Python, JavaScript, MDX, Rust, TypeScript
• Official Gittensor activity: 171 PR(s), 28 issue(s).
• Related work: Titles/paths share 8 meaningful terms. (issue #6735, issue #6733)
• Related work: Titles/paths share 8 meaningful terms. (issue #6737, issue #6733)
• Related work: Titles/paths share 8 meaningful terms. (issue #6736, issue #6733)
• Additional title-only matches omitted; title-only overlap does not block.

Contributor next steps

• Start here: Review top overlaps.
• Then work through the remaining 2 steps 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.