feat(services): wire computeFindingAcceptance into the operator dashboard

[JSONbored]

Summary

• AcceptanceRateCard on /app/analytics has shown its "not yet available" empty state since feat(ui): finding acceptance-rate card (did the contributor act on it) #2197 landed because nothing populated the acceptance field it expects. computeFindingAcceptance (Maintainer analytics dashboard (gate precision, calibration, acceptance rate) #1967) was fully implemented but only wired into computeStats/StatsPayload, which powers a route (handleStats/GET /stats/data) that the dashboard doesn't read from.
• This PR wires computeFindingAcceptance into buildOperatorDashboardPayload (src/services/operator-dashboard.ts), the function that actually feeds the operator dashboard, following the exact Promise.all + fail-safe-aggregate pattern already used for computeCycleTimeAggregate/computeGateEval in that file.
• Maps FindingAcceptanceAggregate's field names (flagged/addressed/unaddressed/acceptanceRate) onto the UI card's expected shape (windowDays/accepted/total/rate) via a new OperatorDashboardFindingAcceptance type, and adds acceptance to OperatorDashboardPayload.

Scope

• The PR title follows type(scope): short summary Conventional Commit format, for example fix(api): restore profile access checks.
• This PR is focused and does not mix unrelated backend, UI, MCP, docs, dependency, and deploy changes.
• This follows CONTRIBUTING.md and does not reintroduce GitHub Pages, VitePress, site/, or CNAME.
• I linked a currently open issue this PR resolves (e.g. Closes #123) — a linked open issue is required for every contributor PR.

Validation

• git diff --check
• npm run actionlint
• npm run typecheck
• npm run test:coverage locally; codecov/patch requires ≥99% coverage of the lines AND branches you changed (aim for 100% on your diff so CI variance does not fail near the threshold). Global coverage is a non-blocking trend with a loose 90% backstop, not the gate.
• npm run test:workers
• npm run build:mcp
• npm run test:mcp-pack
• npm run ui:openapi:check
• npm run ui:lint
• npm run ui:typecheck
• npm run ui:build
• npm audit --audit-level=moderate
• New or changed behavior has unit/integration tests for new branches, fallback paths, and sanitizer boundaries

All of the above ran as part of the full npm run test:ci gate.

Safety

• No secrets, wallet details, hotkeys, coldkeys, user PATs, private keys, raw trust scores, private rankings, or private maintainer evidence are exposed.
• Public GitHub text stays sanitized, low-noise, and does not imply compensation guarantees or optimization tactics.
• Auth, cookie, CORS, GitHub App, Cloudflare, or session changes include negative-path tests. (N/A — no auth/CORS/session changes.)
• API/OpenAPI/MCP behavior is updated and tested where needed. (OperatorDashboardPayload's response is a loose/generic OpenAPI schema; regenerated apps/gittensory-ui/public/openapi.json and it is byte-identical.)
• UI changes use live API data or real empty/error/loading states, not production mock/demo fallbacks. (No UI files changed — AcceptanceRateCard already consumed this exact shape.)
• Visible UI changes include a UI Evidence section below with JPG/JPEG or PNG screenshots — N/A, this PR touches no UI files; it only populates a backend field an already-shipped UI component already renders.
• Public docs/changelogs are updated where needed; changelogs are only edited for release-prep PRs.

Notes

• Backend-only wiring change. AcceptanceRateCard and its tests (acceptance-rate-card.test.tsx) required no changes, as anticipated in the issue.
• Regenerated npm run ui:openapi; output is byte-identical since /v1/app/operator-dashboard's OpenAPI schema is a generic additionalProperties object, not a field-enumerated schema.

Closes #5213

[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 95.04%. Comparing base (66e927e) to head (fb73faf).
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #5684   +/-   ##
=======================================
  Coverage   95.04%   95.04%           
=======================================
  Files         576      576           
  Lines       45977    45978    +1     
  Branches    14724    14724           
=======================================
+ Hits        43699    43700    +1     
  Misses       1525     1525           
  Partials      753      753           

Flag	Coverage Δ
shard-1	43.63% <100.00%> (-0.36%)	⬇️
shard-2	35.86% <0.00%> (+0.13%)	⬆️
shard-3	32.40% <0.00%> (-0.06%)	⬇️
shard-4	32.93% <0.00%> (-0.12%)	⬇️
shard-5	31.51% <0.00%> (-0.26%)	⬇️
shard-6	44.62% <100.00%> (+0.21%)	⬆️

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

Files with missing lines	Coverage Δ
src/services/operator-dashboard.ts	100.00% <100.00%> (ø)

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[loopover-orb]

Warning

🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨

⏸️ LoopOver review result - manual review recommended

_{Review updated: 2026-07-14 04:05:24 UTC}

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

⏸️ Suggested Action - Manual Review

• Touches a guarded path — held for manual review: This PR changes guardrail-protected path(s): src/services/operator-dashboard.ts (matched src/services/**).

Review summary
This PR wires the already-implemented `computeFindingAcceptance` into `buildOperatorDashboardPayload`, mapping `FindingAcceptanceAggregate`'s field names onto the `AcceptanceRateCard`'s expected shape via a new `OperatorDashboardFindingAcceptance` type. The change follows the exact `Promise.all` + fail-safe-aggregate pattern already used for `computeCycleTimeAggregate`/`computeGateEval` in this file, reuses an existing, already-tested compute function with no new SQL, and both branches (empty/null-rate and populated) are covered by new tests that insert real `review_audit` rows and assert on the mapped shape. This is a narrow, well-targeted wiring fix closing the gap between an implemented aggregate and the dashboard consumer that expected it.

Nits — 5 non-blocking

• The JSDoc comment on `OperatorDashboardFindingAcceptance` (operator-dashboard.ts:50-54) references a UI component path (`apps/gittensory-ui/.../acceptance-rate-card.tsx`) that isn't part of this diff — worth a quick sanity check that the path is current, but not a blocker since it's just a doc pointer.
• `GATE_ANALYTICS_WINDOW_DAYS` (90) is hardcoded as `windowDays` in the acceptance object (operator-dashboard.ts:174) rather than being derived from the aggregate itself — consistent with how `cycleTime`/`gateEval` already do it in this file, so it's fine, but worth confirming the UI card doesn't expect this to vary with the dashboard's own `windowDays` option.
• Consider a short comment or test asserting `acceptance.windowDays` stays pinned to the 90d gate-analytics window even when `options.windowDays` is 7/30, mirroring the existing gate-eval/cycle-time fixed-window tests, so a future refactor can't accidentally couple it to the general dashboard window.
• PR author also opened the linked issue — Link an issue that was opened by a different contributor, or provide a rationale for why this self-authored issue represents genuine discovery work.
• Touches a guarded path — held for manual review — A maintainer must review and merge this change.

Signal	Result	Evidence
Code review	✅ No blockers	1 reviewer
Linked issue	✅ Linked	#5213
Related work	⚠️ 1 scoped overlap	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: 45 registered-repo PR(s), 37 merged, 330 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	JSONbored; Gittensor profile; 45 PR(s), 330 issue(s).
Gate result	⚠️ Not blocking	Advisory; not blocking this PR.
Improvement	✅ Minor	risk: clean · value: minor — Code changes are accompanied by test evidence.

Review context

• Author: JSONbored
• Role context: owner (maintainer lane)
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: Python, TypeScript, Ruby, Go, JavaScript, MDX, Shell, Solidity
• Official Gittensor activity: 45 PR(s), 330 issue(s).
• Related work: Titles/paths share 3 meaningful terms. (issue #5213, issue #642)

Contributor next steps

• Treat this as maintainer-lane context rather than normal contributor-lane activity.
• Review top overlaps.
• Add a concise scope and risk note.
• Check active issues and PRs before submitting.

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.

[BETA] Chat with Gittensory

Ask Gittensory a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.

• @gittensory ask <question> answers contribution-quality Q&A with source citations and freshness.
• @gittensory chat <question> answers in natural prose from cached decision-pack facts via local inference (maintainer/collaborator; read-only).
• A plain-language @gittensory 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/gittensory-commands

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