Homepage hero metrics are wrong: decision accuracy pegged at 100%, AI-work-reused renders no value

[JSONbored]

Context

The homepage hero's live-stats strip is showing two broken values:

1. Decision accuracy: 100% — implausible. The published number comes from src/review/public-stats.ts (accuracyPct = 1 − reversed / (merged + closed), reversal-grounded). Ground truth in the calibration ledger shows real reversals exist (the same_pr_merged / user-reopened-and-merged class was backfilled into both cloud D1 and the ORB pg ledger), so a pegged 100% means the reversed count feeding the public stat is 0 when it shouldn't be — either the fleet-analytics path (computeFleetAnalytics, src/orb/analytics.ts) has no eligible registered instances and the own-ledger fallback's reversal feed is empty/stale, or reversal detection never writes into whichever ledger this stat reads.
2. AI work reused: — (no value renders at all) — the metric is either never populated or the renderer receives null and shows an em-dash with a sparkline, which reads as broken on the hero (apps/loopover-ui/src/components/site/proof-of-power-stats.tsx).

With 13k+ total ORB reviews now in the ledgers there is more than enough data for both of these to show real, defensible values — no small-N excuse applies.

Requirements

• Trace the full pipeline for both metrics: ledger writes → src/review/public-stats.ts aggregation → API (src/api/routes.ts) → proof-of-power-stats.tsx render.
• Determine why reversed is 0 in the published snapshot despite backfilled ground-truth reversals; fix the feed (or the fallback selection between fleet accuracy and own-ledger accuracy) so the published accuracy reflects real reversal data.
• Determine why the AI-work-reused value is absent; either populate it from real data or (if genuinely no signal source exists yet) render an honest empty state instead of a dash next to a live sparkline.
• Audit the remaining hero metrics (PRs reviewed, filtered-without-merge, maintainer time saved) for the same class of skew while in there — the strip should be trustworthy end to end.
• Regression tests for each fixed feed (the 99%+ patch-coverage bar applies to src/** changes).

Expected Outcome

The hero strip shows real, reversal-grounded accuracy (not a degenerate 100%), a populated (or honestly-absent) AI-work-reused value, and every number on the strip is traceable to ledger data.

[linear-code]

JSO-6074

[JSONbored]

Root cause confirmed against production D1 (2026-07-26). Both broken tiles share one structural cause: every hero metric still reads the cloud worker's own review ledger, which froze at the self-host cutover (last event 2026-06-29), while all the live data flows into orb_signals from the self-hosted instance — which is unregistered.

Decision accuracy = 100%:

• The UI prefers fleetAccuracy (live, reversal-grounded, from computeFleetAnalytics) but requires instanceCount > 0.
• Production: orb_instances has exactly one instance (0c110b7c2e090471, 6,127 signals in the 90-day window — far past the MIN_DECIDED = 5 bar) but registered = 0. The fleet trust gate (registered = 1) therefore yields zero eligible instances.
• The UI falls back to own-ledger totals.accuracyPct = 1 − reversed/(merged+closed). Production audit_events contains zero reversal_reopened/reversal_reverted/reversal_superseded rows, so reversed = 0 → exactly 100%, structurally forever (the frozen ledger can never accrue a reversal again).
• The hero hint "reversal-grounded" is the exact totals.reversed === 0 fallback arm — visible confirmation of this path.

AI work reused = "—" (with a live-looking sparkline):

• reuseRateTrend reads github_app.%cache_hit/%cache_miss audit events scoped to LOOPOVER_PUBLIC_STATS_REPOS. Production has 20,209 such events — all before 2026-06-29, none since.
• The last ~4 weekly buckets are empty → below MIN_REUSE_RATE_TREND_SAMPLE = 5 → reuseRatePct = null → the tile renders "—" while the sparkline still draws the older, decaying weeks. Worst-of-both rendering.

Fix plan (in order):

1. Operational: register the self-host instance (POST /v1/internal/orb/instances/register, upsert already supported). Immediately makes fleetAccuracy eligible — the accuracy tile switches to the live, reversal-grounded fleet number computed from orb_signals.reversal_flag (real reversals, not the frozen zero).
2. Code: the reuse tile must not pair a null latest week with a populated sparkline. Either fold live self-host reuse telemetry into the trend (extend the anonymized collector export with daily hit/miss counters — the honest long-term fix, consistent with the single-live-platform direction) or make the tile render the latest sampled week with explicit staleness (and hide when the whole window is empty).
3. Audit the rest of the strip: the accuracy sparkline (accuracyTrend) and weekly deltas are own-ledger too, hence equally frozen; same treatment. "PRs reviewed"/"time saved" already fold in the live Orb fleet aggregate, so they keep growing — verified unaffected.

[JSONbored]

Deploy complete — both original halves are live, plus a deeper finding

orb-v3.5.0-beta.3 (main tip, carrying #8821) is deployed and healthy on the ORB server; 3 migrations applied, orb_reuse_counters created, no error-level boot logs. The instance is registered for fleet calibration, and the export cursor was rewound in three passes so reversal history re-exported.

Live results:

• AI work reused — fixed. 30 days of counters flowing (84,211 hits / 66,842 misses); the trend now publishes real weekly values (51.3% / 63.5% / 46.2%) instead of a dash.
• Reversal export — fixed. All 26 exportable superseded reversals now carry their flag in cloud orb_signals (was 0). The remaining legacy reversal_reopened/reverted events are pre-cutover reviewbot-sourced rows in the old target-id format, correctly excluded by the exporter's source = 'gittensory-native' filter — not a bug.
• Decision accuracy — moved off the structural 100%, but landed at 99.6%, which is still wrong. Root-caused below.

The accuracy number was measuring the wrong thing

1 − reversalRate overstates accuracy two independent ways:

1. Holds are in the denominator. 2,234 of 6,277 fleet signals (~36%) are hold verdicts — deferrals to a human, not decisions that can be right or wrong. They drag the rate toward zero and the published number toward 100 regardless of real performance.
2. Only explicit reversal markers count. Outright mispredictions were invisible: 213 PRs where the gate said merge and the PR ended up closed, and 21 where it said close and the PR merged.

Real confusion matrix across all three repos:

verdict	outcome	reversal	n
merge	merged	none	2,580
hold	merged	none	1,770
close	closed	none	1,203
hold	closed	none	464
merge	closed	none	213
close	closed	superseded	26
close	merged	none	21

4,043 real decisions, 3,783 confirmed → 93.6% true decision accuracy vs the 99.6% published. Fix in #8822.

Remaining gap

#8823: pr_outcome is missing for 40 of the 66 PRs carrying a superseded marker — verified bot-closed on GitHub but never given an outcome row, so the export's inner join drops them entirely. Since the dropped rows are disproportionately errors, closing that gap will lower the published number further toward truth.

This issue stays open until #8822 and #8823 land and the hero shows the corrected figure.