feat(proof): the public per-repo proof page, the last piece of #9569 - #9989
Conversation
The API half already shipped: `/v1/public/repos/:owner/:repo/proof`, the badge SVG, the feature flag and the per-repo opt-out are all on main, all built on `buildProofSummary`. What was missing was the page the issue is named for. ONE IMPLEMENTATION, TWO RENDERINGS. This component renders and computes nothing. Every figure comes from the endpoint, which is the same composition the in-app trust panel (#9193) reads, so the two cannot disagree about a number. The only arithmetic is multiplying an already-computed rate by 100 for display -- a percentage derived here would be a second implementation free to drift from the first, undermining the exact property the page exists to demonstrate. The states are the substance, because each is somewhere a plausible implementation says something untrue: • BELOW THE SAMPLE FLOOR the page shows the decision COUNT and no rate -- "7 decisions, too few to claim a rate". Hiding the count along with the figure, or printing 0%, both misrepresent it. • NOT-YET-ANCHORED and EMPTY LEDGER are neutral. A new repository is not a failing one, and rendering it as an error lies in the more damaging direction. • A BROKEN ledger is the one state stated as a problem, naming the row and the kind of break, because the kind is the actionable half. • UNAVAILABLE says so explicitly: it is not a claim that anything is wrong. • AN OPTED-OUT REPO (404) is an EMPTY state, not an error -- a different ARIA role and a different meaning. Telling an opted-out repo something broke invites someone to hunt a fault that does not exist. • ACCURACY never appears without its denominator and Wilson interval. The boundary statement is rendered FROM THE PAYLOAD rather than written here, so a screenshot or an embed cannot shed the caveat while keeping the numbers. Digests are shown head-and-tail with the full value in `title`: a truncated digest with no way back to the whole cannot be checked against anything. Mutation-tested: publishing a rate below the floor, hardcoding the boundary statement, and turning the 404 into an error each fail. Closes #9569
Deploying with
|
| Status | Name | Latest Commit | Updated (UTC) |
|---|---|---|---|
| ❌ Deployment failed View logs |
loopover-ui | fa8be68 | Jul 31 2026, 05:03 AM |
|
Caution 🛑 LoopOver review result - fixes requiredReview updated: 2026-07-31 05:13:19 UTC
Review summary Nits — 6 non-blocking
CI checks failing
Decision drivers
Context & advisory signals — never blocks the verdict
Linked issue satisfactionPartially addressed Review context
Contributor next steps
Signal definitions
🧪 Chat with LoopOverAsk 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.
Full command reference: https://loopover.ai/docs/loopover-commands 🧪 Experimental — new and may change. Decision record
Visual preview
Click any thumbnail to open the full-size screenshot. Before = production · After = this PR's preview deploy. Scroll preview
A short scroll-through clip (desktop) — click either thumbnail to open the full animation. Evidence for scroll-linked behavior a single screenshot can't show. 🟩 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.
|
|
Superagent didn't find any vulnerabilities or security issues in this PR. |
Bundle ReportChanges will increase total bundle size by 8.09kB (0.1%) ⬆️. This is within the configured threshold ✅ Detailed changes
Affected Assets, Files, and Routes:view changes for bundle: loopover-uiAssets Changed:
|
|
On the red It is Cloudflare-side, not GitHub Actions. The GitHub-side Three things point away from our code:
So it is non-blocking and not caused by this change. Worth a look when you have dashboard access, though. This is a dashboard-configured GitHub integration, independent of the repo's workflows — and it targets production ( |


The API half already shipped.
/v1/public/repos/:owner/:repo/proof, the badge SVG, the feature flag and the per-repo opt-out are all onmain, all built onbuildProofSummary. What was missing was the page the issue is named for — there was noapps/loopover-ui/src/routes/proof.*.One implementation, two renderings
This component renders and computes nothing. Every figure comes from the endpoint, which is the same composition the in-app trust panel (#9193) reads, so the two cannot disagree about a number. The only arithmetic is multiplying an already-computed rate by 100 for display — a percentage derived here would be a second implementation free to drift from the first, undermining the exact property the page exists to demonstrate.
The states are the substance
Each is somewhere a plausible implementation says something untrue, so each is tested:
0%, are not.Two further details:
title— a truncated digest with no way back to the whole cannot be checked against anything.Mutation testing
Baseline restored green.
Issue requirements
/proof/:owner/:repopage — this PRbuildProofSummaryproof-summary.tsisProofPageEnabledForRepoVerification
ui:typecheck,typecheck,docs:drift-check,dead-source-files:check,dead-exports:check,import-specifiers:check,coverage-boltons:check,ui-derived-types:checkgreenui:testsuite green; 10 new testsrouteTree.gen.tsregenerated viaui:buildand committedtext-token-*design tokens, whichui:lint'sno-restricted-syntaxrule enforcesNote:
ui:lintcurrently fails onmainfor an unrelated reason —chart.test.tsxformatting, fixed in #9988. Not caused by this PR.Closes #9569