feat(analytics): surface org-wide slop-band calibration + dashboard card (#2196)

[dhgoal]

What

Adds the slop-band calibration card to the operator analytics dashboard (Closes #2196): predicted slop band vs realized merge/close outcome across resolved PRs — is the deterministic slop score predictive (do higher-slop bands merge less)? Surfaces real data end-to-end — the existing, unit-tested buildSlopOutcomeCalibration wired over listAllPullRequests into the dashboard payload, then rendered. Bands only, never raw scores.

Both prior review points are now fully resolved:

• Diff-tight backend — operator-dashboard.ts is +20/−1 (no whole-file reformat churn).
• Fail-safe and covered — the read lives in a buildOrgSlopCalibration() helper that try/catches to an empty calibration (listAllPullRequests can throw, unlike the sibling reads), and both the success and the fail-safe branches are unit-tested, so codecov/patch covers every new line.

Changes

Backend (src/services/operator-dashboard.ts, +20/−1)

• New buildOrgSlopCalibration(env) helper: buildSlopOutcomeCalibration(await listAllPullRequests(env)), wrapped in try/catch → empty calibration on any read error, so one DB hiccup never fails the whole dashboard. Exposed via __operatorDashboardInternals for direct branch coverage.
• Wired into the existing Promise.all, exposing slopCalibration: SlopOutcomeCalibration on the payload.
• test/unit/operator-dashboard.test.ts: empty-signal assertion (success path) + a throwing-env test that exercises the fail-safe branch.

Frontend

• slop-band-calibration-card.tsx (new) — SlopBandCalibrationCard: per-band merge-rate bars + resolved · merged · closed counts + a predictive / inverted / insufficient-data verdict pill. Reuses AnalyticsCardShell.
• slop-band-calibration-card.test.tsx (new) — 5 tests: all-bands, empty-band, inverted, no-data, absent field.
• app.analytics.tsx — optional slopCalibration? + renders after the findings-breakdown card.

Verification

Backend test/unit/operator-dashboard.test.ts green (7 tests, incl. success + fail-safe branches); tsc clean on the changed files. Card + UI build verified in CI on the identical component previously (Build UI preview artifact passed).

Screenshots

/app/analytics, populated (predictive: clean 90% → high 0%) and empty, desktop + mobile, light + dark.

State	Desktop (light)	Desktop (dark)	Mobile
Populated	predictive · light	predictive · dark	mobile
Empty	empty · light	empty · dark	mobile

Closes #2196

[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.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 94.32%. Comparing base (a416632) to head (afa0a61).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #5126   +/-   ##
=======================================
  Coverage   94.32%   94.32%           
=======================================
  Files         471      471           
  Lines       39821    39824    +3     
  Branches    14533    14533           
=======================================
+ Hits        37560    37563    +3     
  Misses       1583     1583           
  Partials      678      678           

Flag	Coverage Δ
shard-1	46.35% <100.00%> (+<0.01%)	⬆️
shard-2	34.40% <25.00%> (-0.26%)	⬇️
shard-3	31.27% <25.00%> (+0.28%)	⬆️
shard-4	32.73% <25.00%> (-0.15%)	⬇️
shard-5	33.42% <25.00%> (-0.23%)	⬇️
shard-6	45.18% <75.00%> (+0.31%)	⬆️

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.

[gittensory-orb]

Warning

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

⏸️ Gittensory review result - manual review recommended

_{Review updated: 2026-07-11 18:07:05 UTC}

5 files · 2 AI reviewers · no blockers · readiness 100/100 · CI green · unstable

⏸️ 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 is a well-scoped, backend-first read: `buildOrgSlopCalibration` wraps the existing, already-unit-tested `buildSlopOutcomeCalibration(await listAllPullRequests(env))` in try/catch to fail safe to an empty calibration, wires it into the existing `Promise.all` in `buildOperatorDashboardPayload`, and adds a straightforward display card. Both the success path (empty-signal assertion) and the fail-safe throwing-DB path are unit-tested per `test/unit/operator-dashboard.test.ts`, and the frontend card has 5 tests covering all-bands, empty-band, inverted, no-data, and absent-field states. The `discriminates` semantics (predictive/inverted/insufficient-data) map correctly onto `computeDiscriminates` in `outcome-calibration.ts`, and the diff correctly surfaces bands only, never raw slop scores.

Nits — 6 non-blocking

• `SlopBand`/`SlopBandCalibration`/`SlopOutcomeCalibration` types are hand-duplicated in slop-band-calibration-card.tsx:8-22 instead of imported from src/services/outcome-calibration.ts — if the backend shape drifts, the frontend types silently go stale with no compiler signal across the package boundary.
• In BandRow (slop-band-calibration-card.tsx:44), `pct` is derived via `Math.round(row.mergeRate * 100)` but `mergeRate` itself is already rounded to 3 decimals upstream in outcome-calibration.ts — fine today but worth a comment noting the double-rounding is intentional/harmless if someone later changes the upstream rounding.
• The PR description claims 'existing, unit-tested `buildSlopOutcomeCalibration`' as justification for skipping new backend-logic tests, which is accurate, but there's no test asserting `buildOrgSlopCalibration`'s *success* path returns real (non-empty) data when `listAllPullRequests` resolves with slop-banded PRs — only the empty-env and throwing-env cases are covered.
• Import `SlopBand`, `SlopBandCalibration`, and `SlopOutcomeCalibration` types from `src/services/outcome-calibration.ts` (or a shared types module) instead of redeclaring them in the frontend card component.
• Consider adding one operator-dashboard test that seeds a resolved PR with a persisted slop band and asserts `buildOrgSlopCalibration` returns non-empty, real data — currently only the empty and throwing paths are exercised.
• Touches a guarded path — held for manual review — A maintainer must review and merge this change.

Flagged checks (non-blocking)

• Contributor trust — Contributor flagged for review

Signal	Result	Evidence
Code review	✅ No blockers	2 reviewers, synthesized
Linked issue	✅ Linked	#2196
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: 101 registered-repo PR(s), 62 merged, 14 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	dhgoal; Gittensor profile; 101 PR(s), 14 issue(s).
Gate result	⚠️ Not blocking	Advisory; not blocking this PR.
Improvement	✅ Minor	risk: clean · value: minor — Code changes are accompanied by test evidence. LLM value judgment: moderate — The diff wires an already-tested pure calibration function into the dashboard payload and adds a well-tested display card, closing #2196 with a diff-tight backend change (+20/-1) and full branch coverage on the new fail-safe path.

Linked issue satisfaction

Partially addressed
The PR delivers a working SlopBandCalibrationCard wired into app.analytics.tsx with bands-only display and solid vitest coverage (all-bands, empty-band, no-data variants), which covers the card's core intent. However it diverges from the issue's specified plumbing: the calibration data is sourced from a new operator-dashboard.ts/listAllPullRequests path rather than the slop-band fields of StatsPay

Review context

• Author: dhgoal
• 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: 101 PR(s), 14 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.

[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

Visual preview

Route	Viewport	Before (production)	After (this PR's preview)	Diff
/app/analytics	desktop			—
/app/analytics	mobile			—

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

_{🟩 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 Gittensory, a quiet PR intelligence layer for OSS maintainers.

• Re-run Gittensory review