feat(ui): add confidence-calibration card to the analytics dashboard

[claytonlin1110]

Summary

• Adds CalibrationCard to the analytics dashboard (/app/analytics): predicted slop-severity band vs. realized merge rate per bucket (a genuine confidence-calibration curve), plus the recommendation-outcome split and a headline "is this actually predictive?" verdict.
• A note on the data source, since it required a real correction to the issue's own references. feat(ui): confidence-calibration curve card on the analytics dashboard #2192 cites src/review/ops.ts's Calibration/computeCalibration (lines 61/250) as "the existing computed payload." I traced that all the way through before implementing and found it's ported-but-unwired "reviewbot" code from a prior convergence (3c4a30b0 Convergence: reviewbot → gittensory): nothing anywhere in this repo constructs its OpsAgentConfig, its handleInternalCalibration/handleInternalDecision handlers are registered on no route, and its own review_targets/review_audit tables are never populated in gittensory — src/review/ops-wire.ts's own header comment says so explicitly ("ADAPTED TO GITTENSORY'S OWN OUTCOME DATA — NOT reviewbot's review_targets/review_audit (those tables are not populated here)"). Building a card against it would mean either fabricating a fake slug/config or shipping a card that can never show real data.
• Gittensory's actual, live equivalent is src/services/outcome-calibration.ts's buildSlopOutcomeCalibration/buildRecommendationOutcomeCalibration — already used by the real, maintainer-authenticated GET /v1/repos/:owner/:repo/outcome-calibration route and the ops-wire.ts observability cron. This PR mirrors that instead: same "bins" concept (per-slop-band merge rate, the deterministic predicted-risk signal gittensory actually computes), same "is it predictive" verdict (discriminates), just fleet-wide instead of per-repo.
• Backend addition (small, reuses only existing pure/tested builders, no new SQL): buildFleetOutcomeCalibration in src/services/outcome-calibration.ts — a thin new async loader that feeds listAllPullRequests/listAgentRecommendationOutcomes (both pre-existing bulk-read helpers) into the same pure buildSlopOutcomeCalibration/buildRecommendationOutcomeCalibration/buildOutcomeCalibrationSignals functions the per-repo route already uses and already tests. Wired into operator-dashboard.ts's OperatorDashboardPayload exactly like PR feat(ui): add gate-precision analytics card (#2191) #4314 wired gateEval for the sibling gate-precision card (feat(ui): gate-precision analytics card (precision + confusion matrix) #2191).
• Surfaces the "recommended confidence floor" deliverable as a labeled Stat ("Calibration signal": Predictive / Not discriminating / Insufficient data) + BoundaryBadge boundary="private-api", since a literal numeric floor doesn't exist in the real signal — the verdict + boundary marker is the equivalent "is this trustworthy, and is it private-scoped" signal the issue asks for.
• Renders nothing when there's no resolved-PR or recommendation signal at all, matching GatePrecisionCard's established convention on this same page.
• Placed between the gateEval and cycleTime cards (not after cycleTime) deliberately: PR feat(ui): reversal-rate + auto-action health card #4702 (still open, sibling issue feat(ui): reversal-rate + auto-action health card #2193) is sitting on the "after cycleTime" insertion point in this same file, so this avoids a guaranteed line-level collision with it.

Scope

• The PR title follows type(scope): short summary Conventional Commit format.
• This PR is focused (one card + its one backend data source) and does not mix unrelated changes.
• This follows CONTRIBUTING.md and does not reintroduce GitHub Pages, VitePress, site/, or CNAME.
• I linked a currently open issue this PR resolves — Closes feat(ui): confidence-calibration curve card on the analytics dashboard #2192.

Validation

• git diff --check
• npm run actionlint
• npm run typecheck
• npm run test:coverage locally (full unsharded run; new backend code — src/services/outcome-calibration.ts's buildFleetOutcomeCalibration and its operator-dashboard.ts wiring — is src/**, so it IS Codecov-patch-gated, unlike my prior UI-only PRs this session. Added 2 new buildFleetOutcomeCalibration tests (populated fleet data across multiple repos, and a fully-empty fail-safe case) plus an operator-dashboard.test.ts assertion for the new calibration field's fail-safe empty shape. Scoped --coverage run on just these two files showed 100%/100% lines on outcome-calibration.ts and confirmed zero of my added lines were uncovered on either file — the only flagged gaps were pre-existing lines I never touched.)
• npm run test:workers
• npm run build:mcp
• npm run db:migrations:check
• npm run db:schema-drift:check
• npm run ui:openapi:check
• npm run ui:openapi:settings-parity
• npm run ui:version-audit
• npm run docs:drift-check
• npm run manifest:drift-check
• npm run command-reference:check
• npm run ui:lint
• npm run ui:typecheck
• npm run ui:test (149/149 passed across both UI workspaces)
• npm run ui:build
• npm audit --audit-level=moderate (0 vulnerabilities)

If any required check was skipped, explain why:

• npm run test:mcp-pack and npm run cf-typegen:check fail locally only due to a pre-existing Windows dev-machine spawnSync bare-command resolution gap (ENOENT for npm/wrangler without shell: true) — unrelated to this diff.
• npm run engine-parity:drift-check fails locally only because it falls back to my local (stale) fork origin/main ref absent GITHUB_BASE_SHA, which real CI sets. No src/signals/**/packages/gittensory-engine/** files are touched by this PR.

Safety

• No secrets, wallet details, hotkeys, coldkeys, user PATs, private keys, raw trust scores, private rankings, or private maintainer evidence are exposed — only aggregate counts (per-band sample size/merge rate, recommendation positive/negative/pending) ever render; asserted by a redaction check in the new backend test.
• Public GitHub text stays sanitized, low-noise, and does not imply compensation guarantees or optimization tactics. (N/A surface — authenticated operator analytics UI, not a public GitHub comment.)
• Auth, cookie, CORS, GitHub App, Cloudflare, or session changes include negative-path tests. (N/A — no such changes.)
• API/OpenAPI/MCP behavior is updated and tested where needed. (No new route; the payload field is on the existing operator-dashboard response, which is registered with a loose passthrough OpenAPI schema like its gateEval/cycleTime siblings — no schema regen needed.)
• UI changes use live API data or real empty/error/loading states, not production mock/demo fallbacks — the card renders the real fleet-wide calibration field; the "no signal yet" state is a genuine totalResolved === 0 early return, not a demo placeholder.
• Visible UI changes include a UI Evidence section below with JPG/JPEG or PNG screenshots.
• Public docs/changelogs are updated where needed; changelogs are only edited for release-prep PRs. (No changelog edit in this PR.)

UI Evidence

State / title	Screenshot
Full curve (4 bands + recommendation split)	predictive verdict, merge rate descending clean→high
Single populated band	insufficient-data verdict, 3 bands shown as "no data"

Notes

• The fully-empty case (zero resolved PRs and zero recommendation outcomes) renders nothing at all — there is no third screenshot for it because there is nothing to show, matching GatePrecisionCard's identical convention on this same page.
• Flagging for visibility: this PR touches src/services/operator-dashboard.ts, a file PR feat(ui): reversal-rate + auto-action health card #4702 (open, sibling issue feat(ui): reversal-rate + auto-action health card #2193) is also mid-flight on modifying, though at a different insertion point chosen specifically to avoid overlap. If feat(ui): reversal-rate + auto-action health card #4702 merges first, this branch may still need a follow-up rebase.

[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.15%. Comparing base (e3c0ba6) to head (11e98d4).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #4720   +/-   ##
=======================================
  Coverage   94.14%   94.15%           
=======================================
  Files         437      437           
  Lines       38561    38565    +4     
  Branches    14058    14058           
=======================================
+ Hits        36304    36309    +5     
  Misses       1599     1599           
+ Partials      658      657    -1     

Files with missing lines	Coverage Δ
src/services/operator-dashboard.ts	100.00% <ø> (ø)
src/services/outcome-calibration.ts	98.46% <100.00%> (+0.10%)	⬆️

... and 1 file with indirect coverage changes

🚀 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

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

⏸️ Gittensory review result - manual review recommended

_{Review updated: 2026-07-10 20:29:42 UTC}

8 files · 1 AI reviewer · no blockers · readiness 100/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/**), src/services/outcome-calibration.ts (matched src/services/**).

Review summary
This adds a fleet-wide confidence-calibration card to the analytics dashboard, backed by a new `buildFleetOutcomeCalibration` in `src/services/outcome-calibration.ts:174-186` that reuses the already-tested pure `buildSlopOutcomeCalibration`/`buildRecommendationOutcomeCalibration` folds over every repo instead of one. The PR does real diligence tracing why it does NOT wire against #2192's own cited `ops.ts` `Calibration` code (correctly identifying it as unwired dead code with unpopulated tables) and instead mirrors the live `buildRepoOutcomeCalibration` pattern already used by a real route — this is exactly the kind of root-cause verification this repo wants. Tests cover the real distinguishing subtlety (zero-sample band shown as 'no data' vs a genuine 0% merge rate) and the fleet-scope path (two different repos folded together), not a fabricated scenario.

Nits — 6 non-blocking

• src/services/outcome-calibration.ts:182 hard-caps `listAgentRecommendationOutcomes(env, { limit: 5000 })` with no documented sort order — once the fleet ledger exceeds 5000 rows the 'positiveRate' verdict silently reflects a partial (and order-dependent) slice; worth a comment on what ordering the cap relies on or switching to a windowDays bound like the repo-scoped version uses.
• apps/gittensory-ui/src/components/site/calibration-card.tsx — `CalibrationCard` is a single ~77-line function; consider splitting the band-row rendering into a small subcomponent for readability.
• No test exercises the case where `calibration.signals` is empty but the card still renders (only the all-zero early-return and the populated-signals cases are covered) — add one for full branch coverage of the `signals.length > 0` ternary.
• Verify `listAllPullRequests` (newly imported in src/services/outcome-calibration.ts:11) has bounded/appropriate cost for a fleet-wide read on every dashboard load, same as the other `Promise.all` fleet-wide calls in operator-dashboard.ts.
• Consider exposing a `truncated` flag from `buildFleetOutcomeCalibration` (mirroring the `mcpCompatibilityAdoption.truncated` pattern already on this same dashboard) so the UI can signal when the 5000-row recommendation cap was hit, instead of silently showing a partial calibration as if it were complete.
• 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	#2192
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: 461 registered-repo PR(s), 318 merged, 102 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	claytonlin1110; Gittensor profile; 461 PR(s), 102 issue(s).
Gate result	⚠️ Not blocking	Advisory; not blocking this PR.

Review context

• Author: claytonlin1110
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: Python, JavaScript, TypeScript, Rust
• Official Gittensor activity: 461 PR(s), 102 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.

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

[loopover-orb]

Gittensory detected this pull request has been converted to draft 2 times — repeatedly cycling between ready and draft to solicit review feedback without a real one-shot attempt is not allowed. Please open a new pull request with the issues addressed.