This is the point of Betterloop. Everything below was written by the real engine and ranked so the most costly problem sits at the top. No one hand-wrote these.
Two kinds of input feed it, and both are generated for this demo: 7 days of browser traffic, which you can see in the other tabs, and observations from 5 connected sources (GitHub, PageSpeed Insights, Plausible Analytics, Site audit, Stripe). What is real is everything after that: the detectors, the thresholds, the ranking, and the findings that only exist because two sources were read together. The AI layers ran on top of the deterministic ones.
In a real project each card carries Acknowledge / Mark done / Dismiss buttons, and the same feed is pushed to Slack or pulled into Claude Code over MCP. The demo is read-only, so the controls are hidden here.
bugseverity: high/checkoutrules
JS error hitting 22 sessions: Cannot read properties of undefined (reading 'zip')
"Cannot read properties of undefined (reading 'zip')" fired 36 times across 22 sessions in the last 7 days (sample page: /checkout).
Top of stack:
TypeError: Cannot read properties of undefined (reading 'zip')
at validateAddress (checkout.4f2a1c9.js:118:22)
at handleSubmit (checkout.4f2a1c9.js:204:9)
evidence: message=Cannot read properties of undefined (reading 'zip') sessions=22 occurrences=36
reliabilityseverity: highfrom GitHubrules
CI fails 34% of the time
34 of the last 100 workflow runs failed, most of them in the checkout integration suite. It went from 12 to 34 % between 2026-09-10 and 2026-09-12, measured by GitHub. A step change like this usually has one cause you can find in what shipped during that window, which makes it far cheaper to chase now than after it becomes the baseline everyone forgets was ever different.
evidence: unit=% since=2026-09-10T12:01:32.429Z value=34 target=acme/storefront movedTo=34 sources=["github"] changePct=183 movedFrom=12 worstWorkflow=checkout-e2e
uxseverity: high/cartrules
Users rage-click "Apply promo code" on /cart
27 different sessions rapidly clicked the same element (form.promo-form>button#apply-promo) 47 times total in the last 7 days. That usually means it looks broken, is too slow to respond, or does not give feedback. Check its loading/disabled states and make the response instant or visibly in progress.
evidence: clicks=47 selector=form.promo-form>button#apply-promo sessions=27 windowDays=7
performanceseverity: highrules
Real users see a much slower page than the lab test does
Chrome's field data puts LCP at 5400ms while the synthetic Lighthouse run measured 3100ms on the same page. Your actual audience is on slower devices, worse networks, or hitting a cold cache far more often than the test does. Optimise against the field number - the lab one is already telling you a story that is true for nobody.
evidence: url=https://shop.acme-demo.example labLcpMs=3100 fieldLcpMs=5400
securityseverity: highfrom GitHub + Site audit + StripeAI
Payment-form vulnerability plus no CSP puts checkout revenue directly at risk
One of the 3 open high-severity Dependabot alerts is a prototype-pollution issue in the payment form's validation library, and the site serves no Content-Security-Policy header, so an exploit of that library could run arbitrary script against a logged-in checkout session with nothing to contain it. Checkout is not a side page: it drives the 412 active subscriptions and roughly $18,420 in monthly recurring revenue currently flowing through Stripe. Patch the vulnerable validation library first since it is the one alert with a known exploit path into checkout, then add a CSP header as a second layer of containment. This is the one dependency alert where the blast radius is quantified in real revenue, not just a scanner score.
evidence: target=acme/storefront sources=["github","site_audit","stripe"] csp_header=0 approx_mrr_usd=18420 dependabot_high=3 active_subscriptions=412 vulnerable_component=payment form validation library
securityseverity: highfrom GitHub + Site audit + own_telemetryAI
The exact checkout code path that crashes for users also ships a public prototype-pollution flaw
Github's dependabot alert names a prototype-pollution vulnerability in the payment form's validation library, and telemetry shows that same checkout page throwing 'Cannot read properties of undefined (reading zip)' in 23 sessions this week, a shape-of-object failure consistent with the same validation code. CI failures are concentrated in the checkout integration suite at a 34% fail rate, meaning the tests that would catch a payment-form regression are themselves unreliable right now. This is not three separate problems, it is one fragile, exploitable, poorly-tested surface sitting directly in front of revenue. Patch the validation library dependency first, then use the fix to also stabilize the zip-field crash before touching anything else in checkout.
evidence: target=acme/storefront:/checkout sources=["github","site_audit","own_telemetry"] dependabot_high=3 ci_fail_rate_pct=34 checkout_error_sessions=23
reliabilityseverity: highfrom GitHub + StripeAI
Checkout is breaking down across code, runtime and revenue signals at once
CI fails 34% of the time and the note specifies most failures are in the checkout integration suite, yet 31 commits shipped in the last 7 days and a release went out just 3 days ago. In production the same flow throws 'Cannot read properties of undefined (reading zip)' on 28 sessions at /checkout, and Stripe shows 27 failed payments in the last 30 days. These are three independent systems (CI, browser telemetry, billing) all pointing at the same broken path, which means the checkout suite is not catching what is actually shipping. Freeze non-critical checkout PRs until the integration suite is green and the zip-field null case is fixed before the next release.
evidence: target=acme/storefront:/checkout sources=["github","stripe"] commits_7d=31 ci_fail_rate_pct=34 days_since_release=3 zip_error_sessions=28 failed_payments_30d=27
ideaseverity: highfrom GitHub + Site audit + own_telemetryAI
Every domain fails on the same page: rebuild checkout as one hardened, tested flow instead of patching it piecemeal
Checkout independently shows up as the CI failure hotspot, the site of an unhandled JS crash affecting 26 sessions, the page with 4 unlabeled form fields, the page with no CSP, and the page with a CSRF-reachable session cookie. That is five different sources and domains pointing at one page rather than five unrelated problems, which suggests the checkout code path itself is under-owned rather than each issue being isolated. Rather than filing five separate fixes, scope a single checkout rebuild ticket that bundles the accessibility labels, the CSP header, the cookie flag, and a real CI-gated test suite for that one flow, so the next 47-day-old PR isn't the thing that finally touches it.
evidence: target=https://shop.acme-demo.example/checkout sources=["github","site_audit","own_telemetry"] csp_present=0 ci_fail_rate_pct=34 unlabeled_fields=4 oldest_open_pr_days=47 checkout_zip_error_sessions=26
reliabilityseverity: high/checkoutfrom GitHub + Site auditAI
Checkout is broken end to end: failing CI, a live JS crash, and unlabeled fields
CI fails 34% of the time and github flags most of those failures as coming from the checkout integration suite, yet /checkout still shipped with a JS error reading 'zip' that hit 26 sessions against only 42 checkout pageviews - meaning most people who reach checkout hit a fatal error, on top of 4 form fields with no label at all. This is not three separate bugs, it is one under-tested surface that the test suite already knew was fragile before it reached production. Freeze new checkout feature work, fix the zip error and labels first, and make the checkout suite a required (not advisory) CI gate before the next merge touches that path.
evidence: target=/checkout sources=["github","site_audit"] ci_fail_rate_pct=34 unlabeled_fields=4 checkout_pageviews=42 zip_error_sessions=26
functionalseverity: highfrom GitHub + own_telemetry + StripeAI
The checkout suite that CI keeps failing is the same one throwing the zip-code crash and failing payments
GitHub shows checkout integration tests failing in 34 of the last 100 CI runs, and in production the exact same page throws "Cannot read properties of undefined (reading 'zip')" in 19 sessions this week. Stripe shows 27 failed payments in the last 30 days, and checkout only gets 36 sessions this week against 70 on /cart, so a meaningful share of the funn that reaches checkout is hitting a code path nobody's tests are passing. Fix the address/zip handling that the integration suite is failing on before merging anything else into that file, then confirm failed-payment count drops on the next Stripe pull. This is the one place all three systems agree something is broken.
evidence: target=acme/storefront:checkout sources=["github","own_telemetry","stripe"] ci_failure_rate_pct=34 failed_payments_30d=27 checkout_weekly_sessions=36 checkout_zip_error_sessions=19
functionalseverity: high/checkoutfrom GitHub + Plausible Analytics + StripeAI
Checkout crash and revenue loss trace back to the same failing CI suite
GitHub shows the checkout integration suite failing in 34 of the last 100 CI runs, and production is seeing the predicted result: a JS error reading 'zip' hits 21 checkout sessions, session count drops from 70 on /cart to just 39 on /checkout, and Stripe logged 27 failed payments against $18,420 in approximate MRR. This is not three separate problems, it is one broken flow that keeps merging past a test suite that already knows it is broken. Next action: treat the checkout integration suite as a merge gate instead of an advisory check, and root-cause the zip-read crash before shipping anything else to that path.
evidence: target=/checkout mrr_usd=18420 sources=["github","plausible","stripe"] cart_sessions=70 ci_fail_rate_pct=34 checkout_sessions=39 zip_error_sessions=21 failed_payments_30d=27
productseverity: high/checkoutfrom GitHub + StripeAI
Checkout crashes for most sessions that make it past cart, and CI can't catch it
Cart draws 70 sessions but checkout only sees 40, and of those 40 sessions 25 hit the 'reading zip' crash - meaning the majority of people who reach checkout run into a page that throws before they can pay. GitHub's CI is failing 34% of the time with most failures in the checkout integration suite, which is exactly the code path where this crash lives, so the tests that should have caught it are themselves unreliable. Stripe shows 27 failed payments in the last 30 days on top of this, compounding revenue loss from a page that is both crashing and mis-billing. Fix the checkout suite's flakiness first so a real regression test for the zip-read crash can actually gate merges, then ship the fix. This is the highest-traffic revenue page in the funnel and it is currently the least trustworthy one.
evidence: target=/checkout sources=["github","stripe"] cart_sessions=70 ci_fail_rate_pct=34 checkout_sessions=40 zip_error_sessions=25 failed_payments_30d=27
a11yseverity: highfrom Site auditrules
4 form fields have no label
Four inputs on the checkout have no <label for>, no aria-label and no aria-labelledby. Unlabelled fields are unusable with a screen reader and unhelpful with autofill, which costs completions from everyone rather than only assistive-tech users.
evidence: unit=count value=4 target=https://shop.acme-demo.example/checkout sources=["site_audit"]
securityseverity: highfrom GitHubrules
3 open high-severity dependency alerts
Three published vulnerabilities in packages this repo ships, including a prototype-pollution issue in the payment form's validation library. The exploits are public by definition - that is what publication means.
evidence: unit=count value=3 target=acme/storefront sources=["github"]
productseverity: high/blog/how-we-sourcerules
91% of visitors leave /blog/how-we-source without going anywhere
84 of 92 sessions that started on /blog/how-we-source viewed nothing else in the last 7 days. Either the page does not deliver what visitors expected, or the next step is not obvious. Check the primary call to action above the fold and whether the page matches its traffic sources.
evidence: bounced=84 sessions=92 bounceRate=0.91
reliabilityseverity: highfrom GitHub + Plausible AnalyticsAI
The checkout integration suite is failing 34% of the time yet a checkout TypeError still reached 22 sessions
GitHub shows CI fails 34% of runs, concentrated in the checkout integration suite, while telemetry shows a live 'Cannot read properties of undefined (reading zip)' error hit 22 sessions on /checkout - almost exactly the code path that suite exists to protect. With 31 commits landed in the last 7 days and a release only 3 days ago, the team is merging through a red checkout suite rather than gating on it. Fix or quarantine the flaky checkout tests this week and make checkout CI a hard merge gate before the next release, or this exact class of bug will keep shipping.
evidence: target=acme/storefront sources=["github","plausible"] commits_7d=31 ci_fail_rate_pct=34 days_since_release=3 zip_error_sessions=22
securityseverity: high/checkoutfrom GitHub + Site auditAI
Checkout combines a public payment-library exploit with no CSP and no CSRF cookie defense
GitHub flags a high-severity prototype-pollution vulnerability in the payment form's validation library, and the site audit separately shows no Content-Security-Policy header and a session cookie missing SameSite - all three sit on the same page. That means an exploit for a published vulnerability has no CSP to contain it if triggered, and the session token is attachable to cross-site requests during checkout, exactly where card data flows. Treat this as one incident, not three tickets: patch or replace the validation library first, then ship a CSP and SameSite=Lax/Strict on the session cookie together so the same page isn't reopened by the next dependency alert.
evidence: target=/checkout sources=["github","site_audit"] csp_header=0 cookie_samesite=missing high_severity_alerts=3
bugseverity: high/checkoutfrom own_telemetry + StripeAI
Checkout's undefined 'zip' crash likely explains a chunk of failed Stripe payments
21 sessions hit "Cannot read properties of undefined (reading 'zip')" on /checkout in own telemetry, while Stripe logged 27 failed payments in the same window. Billing zip is typically required for card verification, so a JS crash on that field right before submission would surface as a declined or failed charge in Stripe rather than a visible UI error, meaning customers are being charged for a bug they never see. Pull timestamps for both sets of events and check for overlap; if they correlate, this single fix recovers real revenue, not just a console error count.
evidence: target=/checkout sources=["own_telemetry","stripe"] zip_error_sessions=21 failed_payments_30d=27
pricingseverity: mediumfrom Striperules
30 day subscription churn: 8.7%
36 of 412 subscriptions cancelled in the last 30 days. At that rate the customer base turns over roughly every 11 months, so growth has to outrun the leak before it can compound. It went from 5.1 to 8.7 % between 2026-09-10 and 2026-09-12, measured by Stripe. A step change like this usually has one cause you can find in what shipped during that window, which makes it far cheaper to chase now than after it becomes the baseline everyone forgets was ever different.
evidence: unit=% since=2026-09-10T12:01:32.429Z value=8.7 movedTo=8.7 sources=["stripe"] changePct=71 movedFrom=5.1
performanceseverity: mediumfrom PageSpeed Insightsrules
LCP from real Chrome users (CrUX) moved 69% in the wrong direction
It went from 3,200 to 5,400 ms between 2026-09-10 and 2026-09-12, measured by PageSpeed Insights. A step change like this usually has one cause you can find in what shipped during that window, which makes it far cheaper to chase now than after it becomes the baseline everyone forgets was ever different.
evidence: to=5400 from=3200 unit=ms since=2026-09-10T12:01:32.429Z sources=["pagespeed"] changePct=69
performanceseverity: highrules
Lighthouse performance score is 41/100 on mobile
Google's own audit of https://shop.acme-demo.example/product/aurora-lamp scores 41 for performance on mobile. Mobile is the profile Google ranks on, so this number affects acquisition and not only experience. The individual failing audits appear as their own insights where they carry a measurable saving. It went from 68 to 41 score between 2026-09-10 and 2026-09-12, measured by PageSpeed Insights. A step change like this usually has one cause you can find in what shipped during that window, which makes it far cheaper to chase now than after it becomes the baseline everyone forgets was ever different.
evidence: url=https://shop.acme-demo.example/product/aurora-lamp score=41 since=2026-09-10T12:01:32.429Z movedTo=41 category=performance strategy=mobile changePct=40 movedFrom=68
bugseverity: high/accountrules
JS error hitting 10 sessions: Failed to fetch orders: 503 Service Unavailable
"Failed to fetch orders: 503 Service Unavailable" fired 16 times across 10 sessions in the last 7 days (sample page: /account).
Top of stack:
TypeError: Failed to fetch
at loadOrders (account.9b1ef04.js:64:11)
at async OrdersPanel (account.9b1ef04.js:96:3)
evidence: message=Failed to fetch orders: 503 Service Unavailable sessions=10 occurrences=16
ideaseverity: mediumfrom GitHub + Site audit + own_telemetry + StripeAI
Bundle the checkout-specific fixes into one stabilization sprint instead of fixing in isolation
Checkout is where a 23-session JS error lives, where CI fails most (the checkout integration suite drives the 34% failure rate), where 4 form fields have no labels, and where the payment validation library carries the open high-severity vulnerability - four different sources all pointing at the same 36-view-a-day page that gates 412 paying subscriptions. Fixing these one ticket at a time under separate labels risks losing the sequencing: the label fix and the JS fix touch the same form markup, and a green CI suite is the only way to trust that either shipped correctly. Stand up a short, dedicated effort that fixes the zip-code crash, adds the missing labels, and gets the checkout CI suite green in the same PR chain, then land the dependency bump behind that green build.
evidence: target=acme/storefront sources=["github","site_audit","own_telemetry","stripe"] zip_error_sessions=23 ci_failure_rate_pct=34 active_subscriptions=412 checkout_sessions_7d=36 missing_label_fields=4
pricingseverity: mediumrules
27 failed payments against 412 active subscriptions
Involuntary churn - expired cards, insufficient funds, issuer declines - is revenue you already earned and then lost to plumbing, from customers who never decided to leave. It is the cheapest retention work available: card-expiry reminders before the charge, a dunning sequence with real retries, and Stripe's automatic card updater. Expired cards, insufficient funds and issuer declines - revenue already earned and then lost to plumbing, from customers who never decided to leave.
evidence: failedPayments30d=27 activeSubscriptions=412
growthseverity: mediumrules
Roughly 84% of your visitors never reach client-side analytics
Plausible counted 2,140 visitors over the last 7 days; our in-browser SDK saw 338 sessions. One measures at the edge and the other inside the page, so a gap this size usually means ad blockers, Do Not Track and privacy browsers - though it can also mean the snippet is missing from some pages, which is worth ruling out first. Note: this is measured against unique visitors rather than visits, because your Plausible connection has not reported a visit count - so if people return during the week, the real gap is larger than this. Two consequences: every client-side number you look at - conversion, funnels, session counts - is an undercount by about this much, and the missing group skews technical, which is exactly who you least want to be blind to.
evidence: comparedTo=visitors coveragePct=16 sdkSessions7d=338 plausibleVisitors7d=2140
seoseverity: mediumfrom Site auditrules
No structured data on product pages
No application/ld+json was found. Product schema is what produces the price, availability and rating shown under a search result, and it is the difference between a plain link and a rich one on a page whose whole job is selling.
evidence: unit=count value=0 target=https://shop.acme-demo.example/product/aurora-lamp sources=["site_audit"]
seoseverity: mediumfrom Site auditrules
No meta description
The product listing has no meta description, so Google writes the snippet from whatever text it finds. That snippet is the ad copy for every search result the page appears in.
evidence: unit=count value=0 target=https://shop.acme-demo.example/products sources=["site_audit"]
performanceseverity: mediumfrom Site auditrules
5 render-blocking tags in <head>
Three synchronous scripts and two stylesheets block the first paint. Nothing renders until all five have downloaded and executed.
evidence: unit=count value=5 target=https://shop.acme-demo.example sources=["site_audit"]
securityseverity: mediumfrom Site auditrules
No Content-Security-Policy
No Content-Security-Policy header or meta tag was returned, so any injected script - from a compromised dependency, an ad tag or a stored-XSS payload - runs with full access to the page and to logged-in sessions.
evidence: unit=bool value=0 target=https://shop.acme-demo.example sources=["site_audit"]
securityseverity: mediumfrom Site auditrules
Session cookie is missing SameSite
acme_session is set with Secure and HttpOnly but no SameSite attribute, so it is attached to cross-site requests and the checkout is reachable by CSRF.
evidence: unit=count value=1 target=acme_session sources=["site_audit"]
a11yseverity: mediumfrom Site auditrules
23 images have no alt text
Counted in the server-rendered HTML, so this is a lower bound. Product imagery announced as "image" gives a screen reader nothing, and gives search engines nothing either.
evidence: unit=count value=23 target=https://shop.acme-demo.example sources=["site_audit"]
performanceseverity: mediumfrom PageSpeed Insightsrules
Reduce unused JavaScript: 2,400ms
402KB of JavaScript is parsed before anything is interactive and never used on this page.
evidence: unit=ms value=2400 target=https://shop.acme-demo.example/product/aurora-lamp sources=["pagespeed"] savingsMs=2400 savingsBytes=412000
performanceseverity: mediumfrom PageSpeed Insightsrules
Serve images in a modern format at the right size: 1,800ms
The hero image is a 1.9MB PNG served at 3x the size it renders at.
evidence: unit=ms value=1800 target=https://shop.acme-demo.example/product/aurora-lamp sources=["pagespeed"] savingsMs=1800 savingsBytes=1940000
securityseverity: mediumfrom GitHubrules
11 open medium-severity dependency alerts
GitHub flagged this on acme/storefront (11).
evidence: unit=count value=11 target=acme/storefront sources=["github"]
functionalseverity: high/product/aurora-lamprules
Clicking "Size chart" on /product/aurora-lamp does nothing
11 sessions clicked this interactive-looking element (div.pdp-specs>span.size-chart) with no visible reaction - no navigation, no DOM change. Either the handler is broken, or the element should not look clickable. 21 dead clicks in 7 days.
evidence: clicks=21 selector=div.pdp-specs>span.size-chart sessions=11 windowDays=7
functionalseverity: medium/product/nomad-backpackrules
Clicking "Only 3 left" on /product/nomad-backpack does nothing
9 sessions clicked this interactive-looking element (div.pdp-buy>span.stock-badge) with no visible reaction - no navigation, no DOM change. Either the handler is broken, or the element should not look clickable. 22 dead clicks in 7 days.
evidence: clicks=22 selector=div.pdp-buy>span.stock-badge sessions=9 windowDays=7
bugseverity: high/productsrules
JS error hitting 7 sessions: undefined is not an object (evaluating 'p.variants.length')
"undefined is not an object (evaluating 'p.variants.length')" fired 12 times across 7 sessions in the last 7 days (sample page: /products).
Top of stack:
TypeError: undefined is not an object (evaluating 'p.variants.length')
at renderCard (catalog.71c0d2.js:88:15)
at ProductGrid (catalog.71c0d2.js:141:7)
evidence: message=undefined is not an object (evaluating 'p.variants.length') sessions=7 occurrences=12
a11yseverity: mediumrules
Lighthouse fails 3 accessibility checks
Text has insufficient colour contrast; Form elements have no associated labels; Links have no discernible name. These are automated checks, so they are the floor rather than the ceiling of what is wrong - but every one is a concrete, reproducible defect with a known fix, which makes them the cheapest accessibility work you will ever do.
evidence: url=https://shop.acme-demo.example/product/aurora-lamp failed=["Text has insufficient colour contrast","Form elements have no associated labels","Links have no discernible name"]
performanceseverity: high/product/aurora-lamprules
/product/aurora-lamp is slow: LCP p75 is 5927ms
The 75th percentile LCP on /product/aurora-lamp is 5927ms over 88 samples (7 days). Google rates LCP above 4000ms as "poor". Check hero image size, render-blocking scripts, and server response time.
evidence: p75=5927 metric=LCP samples=88
a11yseverity: mediumrules
Lighthouse accessibility score is 72/100 on mobile
Google's own audit of https://shop.acme-demo.example/product/aurora-lamp scores 72 for accessibility on mobile. Mobile is the profile Google ranks on, so this number affects acquisition and not only experience. The individual failing audits appear as their own insights where they carry a measurable saving.
evidence: url=https://shop.acme-demo.example/product/aurora-lamp score=72 category=accessibility strategy=mobile
performanceseverity: high/product/nomad-backpackrules
/product/nomad-backpack is slow: LCP p75 is 5803ms
The 75th percentile LCP on /product/nomad-backpack is 5803ms over 36 samples (7 days). Google rates LCP above 4000ms as "poor". Check hero image size, render-blocking scripts, and server response time.
evidence: p75=5803 metric=LCP samples=36
performanceseverity: high/cartrules
/cart is slow: INP p75 is 551ms
The 75th percentile INP on /cart is 551ms over 28 samples (7 days). Google rates INP above 500ms as "poor". Look for long tasks blocking the main thread on interaction - heavy handlers, large re-renders.
evidence: p75=551 metric=INP samples=28
pricingseverity: lowrules
1 of your 3 plans have no subscribers
Everyone is clustered on Starter - $19/mo, while Scale - $149/mo has no takers at all. Unused tiers are not free: every extra column on the pricing page costs comprehension before it costs anything else, and a tier nobody picks is either priced wrong or describes a customer you do not have.
evidence: plans=[{"plan":"Growth - $49/mo","subscribers":168},{"plan":"Scale - $149/mo","subscribers":0},{"plan":"Starter - $19/mo","subscribers":244}]
seoseverity: lowrules
Lighthouse seo score is 78/100 on mobile
Google's own audit of https://shop.acme-demo.example/product/aurora-lamp scores 78 for seo on mobile. Mobile is the profile Google ranks on, so this number affects acquisition and not only experience. The individual failing audits appear as their own insights where they carry a measurable saving.
evidence: url=https://shop.acme-demo.example/product/aurora-lamp score=78 category=seo strategy=mobile
codeseverity: lowfrom GitHubrules
Oldest open pull request is 47 days old
A branch open for 47 days has drifted far enough from main that merging it is its own project, and the review it finally gets will be too large to be a real review.
evidence: unit=count value=47 target=acme/storefront sources=["github"]
codeseverity: lowrules
60% of open issues are over 90 days old
41 of 68 open issues on acme/storefront have sat untouched for more than three months. A backlog that old stops being a plan and becomes a place things go to be forgotten - which means real reports get buried alongside the stale ones. Closing what you will not do is what makes the rest trustworthy.
evidence: open=68 repo=acme/storefront stale=41
performanceseverity: medium/checkoutrules
/checkout is slow: LCP p75 is 3076ms
The 75th percentile LCP on /checkout is 3076ms over 25 samples (7 days). Google rates LCP above 2500ms as "needs improvement". Check hero image size, render-blocking scripts, and server response time.
evidence: p75=3076 metric=LCP samples=25
performanceseverity: medium/checkoutrules
/checkout is slow: INP p75 is 201ms
The 75th percentile INP on /checkout is 201ms over 15 samples (7 days). Google rates INP above 200ms as "needs improvement". Look for long tasks blocking the main thread on interaction - heavy handlers, large re-renders.
evidence: p75=201 metric=INP samples=15
uxseverity: low/checkoutrules
Users rage-click "Place order" on /checkout
2 different sessions rapidly clicked the same element (button#place-order) 5 times total in the last 7 days. That usually means it looks broken, is too slow to respond, or does not give feedback. Check its loading/disabled states and make the response instant or visibly in progress.
evidence: clicks=5 selector=button#place-order sessions=2 windowDays=7
productseverity: medium/accountrules
75% of visitors leave /account without going anywhere
9 of 12 sessions that started on /account viewed nothing else in the last 7 days. Either the page does not deliver what visitors expected, or the next step is not obvious. Check the primary call to action above the fold and whether the page matches its traffic sources.
evidence: bounced=9 sessions=12 bounceRate=0.75