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 23 sessions: Cannot read properties of undefined (reading 'zip')
"Cannot read properties of undefined (reading 'zip')" fired 32 times across 23 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=23 occurrences=32
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-25 and 2026-09-27, 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-25T06:01:33.163Z 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
26 different sessions rapidly clicked the same element (form.promo-form>button#apply-promo) 50 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=50 selector=form.promo-form>button#apply-promo sessions=26 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
Checkout is simultaneously the least reliable, least secure and least accessible page
The checkout integration suite drives most of the 34% CI failure rate, the session cookie there lacks SameSite, there is no CSP, and Dependabot's high-severity prototype-pollution alert is in the payment form's own validation library - four independent weaknesses stacked on the one page that captures the $18,420 MRR flowing through Stripe. Each was flagged separately, but together they mean the page most exposed to CSRF and injected-script attacks is also the one engineering trusts least and users can navigate least reliably. Prioritize a security and stability pass on /checkout specifically, starting with patching the vulnerable validation library and adding SameSite plus a CSP, before shipping further checkout feature work. Track CI checkout-suite pass rate as the exit criterion.
evidence: target=https://shop.acme-demo.example/checkout mrr_usd=18420 sources=["github","site_audit","stripe"] csp_present=false dependabot_high=3 ci_failure_rate_pct=34 cookie_samesite_missing=true
reliabilityseverity: highfrom GitHub + Site audit + Plausible AnalyticsAI
CI fails mostly in checkout tests, and production checkout is where errors cluster
34 of the last 100 CI runs failed, concentrated in the checkout integration suite, and in the same period 22 real sessions hit a checkout crash reading an undefined zip property. With 31 commits landed in the last 7 days and a release only 3 days old, the pattern suggests checkout changes are shipping despite a red test suite rather than because of a green one. That is a direct line from a broken CI gate to a live bug hitting the highest-intent page on the funnel. Next step: block merges to main on the checkout suite passing, and treat its current failures as release-blocking until the zip-field crash is traced to a specific commit.
evidence: target=acme/storefront sources=["github","site_audit","plausible"] commits_7d=31 failing_suite=checkout integration days_since_release=3 ci_failure_rate_pct=34 checkout_zip_error_sessions=22
securityseverity: highfrom GitHub + own_telemetry + StripeAI
The vulnerable payment-form validation library may be the source of the checkout crash and failed payments
GitHub's high-severity Dependabot alert names a prototype-pollution issue specifically in the payment form's validation library, and that same checkout page is throwing a client-side crash on 22 sessions ('reading zip') while Stripe logged 27 failed payments in 30 days. A prototype-pollution bug in form validation is a plausible root cause for objects like the shipping/zip payload arriving undefined, which would explain both the crash and some of the payment failures. This is worth treating as one incident, not two: patch the vulnerable dependency first, then re-test the zip-field crash against the same checkout session recordings to see if it clears. Until patched, the same flaw is a known exploit path on the page that handles card data.
evidence: target=acme/storefront sources=["github","own_telemetry","stripe"] failed_payments_30d=27 dependabot_high_count=3 checkout_js_error_sessions=22
ideaseverity: highfrom GitHub + own_telemetry + Site auditAI
Bundle every checkout signal into one stabilization sprint instead of five isolated tickets
Checkout is the single page where a failing CI suite (34%), a production crash hitting 21 sessions, a missing CSP, a missing cookie SameSite attribute, and unlabeled form fields all overlap at once. Treating these as separate backlog items misses that they compound: a broken test gate let the zip-property bug ship, and the same security gaps sit on a form screen readers already cannot label. At 31 commits in the last 7 days and only 3 days since the last release, the fastest way to cut risk is a single cross-functional sprint scoped to checkout only: null-safe the zip parsing, land CSP plus SameSite, add labels, and make the CI suite blocking before any other checkout commit merges.
evidence: target=https://shop.acme-demo.example/checkout sources=["github","own_telemetry","site_audit"] commits_7d=31 csp_present=false ci_fail_rate_pct=34 samesite_missing=true days_since_release=3 zip_error_sessions=21
reliabilityseverity: highfrom GitHub + own_telemetry + StripeAI
Checkout is failing in CI, in production, and at the bank all at once
The checkout integration suite is the main source of the 34% CI failure rate, the live site is throwing a zip-read error to 27 sessions on /checkout, and Stripe logged 27 failed payments in the last 30 days. None of these numbers prove one root cause, but together they describe a checkout path that is unstable at every layer: code, browser, and payment processor. This is the page that converts revenue, so instability here has a direct commercial cost beyond any single bug ticket. Prioritize stabilizing and re-testing the checkout integration suite before merging further changes to that path, and add monitoring that ties JS errors on /checkout to payment outcomes.
evidence: target=acme/storefront:/checkout sources=["github","own_telemetry","stripe"] ci_fail_rate_pct=34 failed_payments_30d=27 active_subscriptions=412 checkout_zip_error_sessions=27
pricingseverity: highfrom GitHub + own_telemetry + StripeAI
A broken, unstable checkout is a plausible driver of the 8.7% subscription churn
CI fails 34% of the time and most failures are in the checkout integration suite, own telemetry shows a checkout-specific crash hitting 30 sessions plus 27 failed payments in 30 days, and Stripe shows 36 of 412 subscriptions (8.7%) cancelling in the same window. These are not independent facts: a checkout that a test suite cannot reliably pass, and that visibly errors for real users, is exactly the kind of friction that turns a failed renewal or a frustrating experience into a cancellation instead of a retry. At $44.70 ARPU, even a modest share of that churn tied to checkout failures is recoverable revenue. Prioritize stabilizing the checkout CI suite and shipping a fix for the zip-read crash before running any retention or win-back campaign, since the leak may be upstream of pricing.
evidence: target=acme/storefront sources=["github","own_telemetry","stripe"] cancelled=36 ci_fail_rate=34 churn_30d_pct=8.7 zip_error_sessions=30 failed_payments_30d=27 active_subscriptions=412
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: 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
pricingseverity: highfrom Stripe + own_telemetryAI
Failed-payment count matches checkout crash sessions almost exactly - likely the same event
Stripe logged 27 failed payments in the last 30 days, and the /checkout JS crash reading 'zip' hit exactly 27 sessions in the last 7 days. Address/zip validation throwing before submission is a plausible direct cause of a declined or malformed payment attempt reaching Stripe, which would mean this is not passive card-decline noise but revenue actively lost to a fixable bug. Cross-reference Stripe's failed-payment timestamps against the checkout error timestamps to confirm the overlap, and if confirmed, treat the zip-field fix as a payments fix, not just a UX fix.
evidence: target=https://shop.acme-demo.example/checkout sources=["stripe","own_telemetry"] failed_payments_30d=27 checkout_crash_sessions=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-25 and 2026-09-27, 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-25T06:01:33.163Z 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-25 and 2026-09-27, 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-25T06:01:33.163Z 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-25 and 2026-09-27, 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-25T06:01:33.163Z movedTo=41 category=performance strategy=mobile changePct=40 movedFrom=68
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
functionalseverity: high/product/nomad-backpackrules
Clicking "Only 3 left" on /product/nomad-backpack does nothing
13 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=13 windowDays=7
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"]
bugseverity: high/productsrules
JS error hitting 8 sessions: undefined is not an object (evaluating 'p.variants.length')
"undefined is not an object (evaluating 'p.variants.length')" fired 12 times across 8 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=8 occurrences=12
bugseverity: high/accountrules
JS error hitting 8 sessions: Failed to fetch orders: 503 Service Unavailable
"Failed to fetch orders: 503 Service Unavailable" fired 11 times across 8 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=8 occurrences=11
functionalseverity: high/product/aurora-lamprules
Clicking "Size chart" on /product/aurora-lamp does nothing
10 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. 20 dead clicks in 7 days.
evidence: clicks=20 selector=div.pdp-specs>span.size-chart sessions=10 windowDays=7
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 6018ms
The 75th percentile LCP on /product/aurora-lamp is 6018ms over 78 samples (7 days). Google rates LCP above 4000ms as "poor". Check hero image size, render-blocking scripts, and server response time.
evidence: p75=6018 metric=LCP samples=78
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 5650ms
The 75th percentile LCP on /product/nomad-backpack is 5650ms over 33 samples (7 days). Google rates LCP above 4000ms as "poor". Check hero image size, render-blocking scripts, and server response time.
evidence: p75=5650 metric=LCP samples=33
performanceseverity: high/cartrules
/cart is slow: INP p75 is 591ms
The 75th percentile INP on /cart is 591ms over 30 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=591 metric=INP samples=30
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"]
uxseverity: medium/checkoutrules
Users rage-click "Place order" on /checkout
5 different sessions rapidly clicked the same element (button#place-order) 10 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=10 selector=button#place-order sessions=5 windowDays=7
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 3048ms
The 75th percentile LCP on /checkout is 3048ms over 30 samples (7 days). Google rates LCP above 2500ms as "needs improvement". Check hero image size, render-blocking scripts, and server response time.
evidence: p75=3048 metric=LCP samples=30
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
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