SlopStopper automatically verifies security, functionality, reliability, observability, and accessibility of your app on every push.
Static checks read your code, your live URL is crawled, an AI agent tests your site, and PRs are automatically opened with fixes.
a real PR SlopStopper opened
SlopStopper: apply 3 auto-fixes and 6 AI fixes
#8
Opened automatically by SlopStopper after a scan.
Addresses:
- reliability.missing-error-boundary
- reliability.missing-ci-pipeline
- observability.no-error-monitoring
- security.dependency-cves (next@14.2.5)
- security.dependency-cves (postcss@8.4.31)
- security.missing-rate-limit
- reliability.external-call-no-timeout
- security.missing-csrf-protection
- security.dependency-cves (@supabase/auth-js@2.65.0)
Files changed: app/error.tsx, sentry.client.config.ts, sentry.server.config.ts, sentry.edge.config.ts, instrumentation.ts, package.json, next.config.mjs, .github/workflows/ci.yml, app/api/tasks/route.ts, app/page.tsx, package-lock.json
AI-generated fixes (6) — review carefully, these were written by an LLM, not a template:
package.json— Upgrade next to a patched version.package.json— Upgrade postcss to a patched version.app/api/tasks/route.ts— Add rate limiting to this route.app/page.tsx— Add a timeout to this call.app/api/tasks/route.ts— Add CSRF protection to this route, or confirm SameSite cookie settings already cover it.package.json— Upgrade @supabase/auth-js to a patched version.
Full scan results — 53% readiness, 14 findings
✅ fixed in this PR · ⬜ still outstanding
Security
- next@14.2.5 has known vulnerabilities
- lodash@4.17.15 has known vulnerabilities — needs a decision
- postcss@8.4.31 has known vulnerabilities
- API route with no visible rate limiting
- Session-cookie-authenticated route with no visible CSRF protection
- @supabase/auth-js@2.65.0 has known vulnerabilities
- Supabase client used, no local RLS policy files found — needs a decision
Reliability
- No CI pipeline detected
- No app/error.tsx found
- External call with no visible timeout
- Possible N+1 database query — guided fix
Observability
- No error-monitoring integration detected
- No uptime monitoring configured — guided fix
Functional
- No automated tests found — guided fix
AI-fix question (1 of 2) — reliability.n-plus-one-query in lib/dashboard.ts
The real fix requires a batch/IN query (e.g. db.findMany({ where: { id: { in: projectIds } } })), but lib/db.ts's placeholder client only exposes findUnique, create, and listProjectIds — there is no findMany or equivalent batch method to call. I can't safely change lib/dashboard.ts alone to use a batched call without that method existing (it would break the build), and this task only gives me lib/dashboard.ts to edit. Could you confirm whether I should add a findMany-style batch method to lib/db.ts (and what its expected signature/behavior should be), so dashboard.ts can call it instead of looping over findUnique?
Reply starting with 1: and I'll retry the fix — e.g. 1: it's declared in apps/api/package.json. This PR has more than one open question; you can answer several in one comment by starting each answer on its own N: line.
1: Yes, please add it. Add a findMany(ids: string[]): Promise<Project[]> method to lib/db.ts that returns every Project whose id is in the given array (same shape as findUnique's return value, just as an array) — then dashboard.ts can call db.findMany(projectIds) once instead of looping over findUnique.
Thanks — pushed a fix based on that. 👍
Free
$0
- ·Unlimited scans
- ·Deterministic auto-fixes
- ·Automatic scans on every push / pull request
Pro
$29/mo
- ·Everything in Free
- ·AI-generated fixes / PRs on every scan
- ·60 AI fixes / month
- ·15 agent-test runs / month
Team
$79/mo
- ·Everything in Pro
- ·200 AI fixes / month
- ·50 agent-test runs / month
Test a project
A one-time check — upload code, point at a live URL, or both. Nothing gets connected.