shippingszn 0.9.6 → 0.9.7

package/LICENSE

@@ -1,6 +1,6 @@
 MIT License
 
-Copyright (c) 2026 Vibe Coder Launch Checklist contributors
+Copyright (c) 2026 shippingszn llc
 
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal

package/README.md

@@ -1,9 +1,9 @@
 # shippingszn
 
-Primary local scanner for shippingszn launch readiness. Run it inside the app
-you are about to ship to catch the launch debt AI builders commonly miss:
-leaked API keys, missing crawl assets, weak browser defenses, dangerous code
-patterns, and last-mile polish gaps.
+Primary local launch inspector for AI-built apps. Run it inside the app you are
+about to ship to catch the launch debt AI builders commonly miss: leaked API
+keys, missing crawl assets, weak browser defenses, dangerous code patterns, and
+last-mile polish gaps.
 
 ```bash
 npx shippingszn@latest
@@ -18,18 +18,18 @@ version, and safe stack tags. It never uploads source code, repo URLs, project
 names, secrets, handles, or emails. Finding-level detail stays out of public
 CLI/Wall output and opens inside the paid Launch Fix Kit.
 
-Human output starts with a Launch Debt Score, severity counts, a short
-plain-English launch-risk explanation, completed checks, and the locked Fix Kit
-handoff. Run with `--json` to get the same score-and-counts summary in a
-machine-readable shape:
+Human output starts with a verdict, a higher-is-better Readiness Score,
+severity counts, a short plain-English launch-risk explanation, completed
+checks, and the locked Fix Kit handoff. Run with `--json` to get the same
+score-and-counts summary in a machine-readable shape:
 
 ```json
 {
-  "score": 43,
-  "band": "no_go",
-  "counts": { "critical": 1, "high": 3, "medium": 4, "lower": 2 },
+  "score": 60,
+  "band": "fix_first",
+  "counts": { "critical": 0, "high": 11, "medium": 1, "lower": 1 },
   "filesScanned": 128,
-  "coverage": { "checksCompleted": 19, "checklistAreas": 46 },
+  "coverage": { "checksCompleted": 19, "checklistAreas": 51 },
   "detailsLocked": true,
   "unlockUrl": "https://shippingszn.com/fix-kit?scanResultId=00000000-0000-4000-8000-000000000123",
   "scanHandoff": {
@@ -40,9 +40,9 @@ machine-readable shape:
 }
 ```
 
-Finding titles, files, evidence, fix prompts, and verification steps are paid.
-The free CLI explains why the score matters, but the actual fixes unlock inside
-the Launch Fix Kit.
+Finding titles, files, evidence, AI-builder punch list, and verification steps
+are paid. The free CLI explains why the score matters, but the actual fixes
+unlock inside the Launch Fix Kit.
 
 ## Aggregate summary
 
@@ -81,7 +81,8 @@ maps back to one of the items on the checklist.
 
 Internally each finding is tagged Critical, High, Medium, or Lower and maps to
 the relevant checklist item. The free CLI output keeps that finding-level detail
-locked.
+locked; the Fix Kit turns it into the human launch decision and AI-builder punch
+list.
 
 ## Suppressing false positives
 
@@ -122,8 +123,8 @@ These are deliberately out of scope for v1:
   quotas, etc.).
 
 A clean report is **not** a launch certificate — it just means none of the
-obvious things tripped a tripwire. Walk through the full checklist before you
-ship.
+obvious things tripped a tripwire. Use the Fix Kit, owner-verification items, and
+rerun loop before you ship.
 
 ## Usage
 

package/dist/index.js

@@ -396,12 +396,14 @@ var ITEMS_CRITICAL_A = [
       "Click Run and let it finish. It usually takes a few minutes; longer for big projects.",
       "Sort by severity and look at everything marked Critical or High first. Ignore Low for now.",
       `For each finding, click into it. The scanner explains what's wrong in plain language and often suggests a fix. If you don't understand a finding, paste it into your AI builder and ask "what does this mean and how do I fix it?"`,
+      "Run your builder's own scanner too \u2014 Cursor, Claude Code, Lovable, Replit, Bolt, Snyk, Semgrep, or whatever your stack exposes. Treat it as the final gate after the manual checks, not a substitute for them.",
       "Re-run the scanner after each batch of fixes. You want zero Critical and as few High as possible before launch."
     ],
     redFlags: [
       "Any Critical finding you can't explain in your own words",
       `High-severity issues you're planning to "deal with later"`,
       'A long list of "hidden" or "ignored" issues with no notes on why',
+      "Your AI builder has a security/audit panel and you have never opened it",
       "Findings that show your app sending user data to companies you didn't intend",
       "Files flagged as malicious or unsafe that you don't recognize"
     ],
@@ -415,12 +417,13 @@ var ITEMS_CRITICAL_A = [
     category: "Security",
     priority: "critical",
     timeEstimate: "1 hr",
-    prompt: "Act as a security engineer. Scan my entire codebase (including config, scripts, tests, frontend, build output, and any committed .env files) for hardcoded secrets \u2014 API keys, tokens, database passwords, OAuth client secrets, webhook signing keys, JWT signing keys, anything that should be private. For each finding, tell me: file, line, what kind of secret it appears to be, and which service it's for. Then refactor every finding to read from environment variables with clear names (OPENAI_API_KEY, STRIPE_SECRET_KEY, DATABASE_URL, etc.), and update any .env.example or docs to list the required variables. Also audit runtime leakage paths: any console.log / logger call that prints req.body, req.headers, full user objects, OAuth callback params, or error objects containing tokens; any Sentry (or equivalent) breadcrumbs that capture request bodies or auth headers without scrubbing; any TODO/debug comments that quote a real key. List every secret that needs to be ROTATED at the source service because it was previously committed, shared, or logged. Never print actual secret values back to me \u2014 only references and filenames.",
+    prompt: "Act as a security engineer. Scan my entire codebase (including config, scripts, tests, frontend, build output, and any committed .env files) for hardcoded secrets \u2014 API keys, tokens, database passwords, OAuth client secrets, webhook signing keys, JWT signing keys, anything that should be private. Classify every key as public-safe or secret-only: publishable Stripe keys, Supabase anon keys, and other documented browser keys may live in the frontend; service-role keys, Stripe secret keys, OpenAI/Anthropic keys, database URLs, webhook secrets, OAuth client secrets, and signing keys must stay server-side only. For each finding, tell me: file, line, what kind of secret it appears to be, and which service it's for. Then refactor every secret-only finding to read from environment variables with clear names (OPENAI_API_KEY, STRIPE_SECRET_KEY, DATABASE_URL, etc.), and update any .env.example or docs to list the required variables without values. Also audit runtime leakage paths: any console.log / logger call that prints req.body, req.headers, full user objects, OAuth callback params, or error objects containing tokens; any Sentry (or equivalent) breadcrumbs that capture request bodies or auth headers without scrubbing; any TODO/debug comments that quote a real key. List every secret that needs to be ROTATED at the source service because it was previously committed, shared, logged, screenshotted, or pasted into chat. Never print actual secret values back to me \u2014 only references and filenames.",
     what: "Every app you build talks to other services \u2014 Stripe for payments, OpenAI for AI, your database for data. Each of those gives you a long secret string (an API key) that proves it's you. If those strings are sitting inside your code, anyone who looks at your code can use them. That includes anyone you accidentally share a screenshot with, anyone you push to GitHub, and anyone who gets into your builder account.",
-    why: `This is the #1 way vibe-coded apps get destroyed. One leaked OpenAI key can rack up thousands of dollars over a weekend. One leaked Stripe key can let someone refund every charge you've ever made. Every modern builder gives you a place to store these safely \u2014 usually called "Secrets," "Environment Variables," or ".env" \u2014 you just have to use it.`,
+    why: `This is the #1 way AI-built apps get destroyed. One leaked OpenAI key can rack up thousands of dollars over a weekend. One leaked Stripe key can let someone refund every charge you've ever made. Every modern builder gives you a place to store these safely \u2014 usually called "Secrets," "Environment Variables," or ".env" \u2014 you just have to use it.`,
     steps: [
       "Find the Secrets / Environment Variables panel in your builder (usually a lock or key icon in the sidebar). Replit calls it Secrets, Vercel calls them Environment Variables, Bolt calls it .env, etc.",
       'Search your code for anything that looks like a long random string \u2014 things starting with "sk-", "AIza", or any variable named "API_KEY", "SECRET", "TOKEN", or "PASSWORD".',
+      "Separate public keys from secret keys. Publishable Stripe keys and Supabase anon keys can be browser-visible when provider docs say so; service-role keys, secret keys, AI keys, database URLs, and signing secrets cannot.",
       "Run a git-history scan, not just a search through current files. Tools like gitleaks (free, one command: `gitleaks detect`) check every commit you've ever made \u2014 including ones where you 'removed' the key by editing the file. A removed key still lives in history forever, and bots scrape public GitHub for these patterns within minutes of a push.",
       'For each one, add it to Secrets / env vars with a clear name (like OPENAI_API_KEY), then ask your AI builder: "replace the hardcoded OPENAI_API_KEY in my code with the environment variable."',
       "Test that the app still works after the swap.",
@@ -429,6 +432,8 @@ var ITEMS_CRITICAL_A = [
     redFlags: [
       "You can search your project files and find an actual API key sitting in plain text",
       "A database connection URL with the password right in it, in code",
+      "A VITE_ / NEXT_PUBLIC_ / EXPO_PUBLIC_ variable whose name includes SECRET, TOKEN, PASSWORD, PRIVATE, SERVICE_ROLE, or ADMIN",
+      "A Supabase service-role key, Stripe secret key, OpenAI key, Anthropic key, webhook secret, OAuth client secret, or database URL visible in frontend code",
       "You've pasted real keys into chats, screenshots, or AI prompts and never rotated them",
       "Your .env or secrets file is sitting in your GitHub history",
       "You've never run gitleaks (or any history scanner) \u2014 only searched current files"
@@ -437,8 +442,8 @@ var ITEMS_CRITICAL_A = [
     cliPrompt: {
       whatFailed: "Your codebase contains what looks like a hardcoded API key or password. The scanner found a string that matches a common provider's secret format (OpenAI, Anthropic, Stripe, AWS, GitHub, etc.) sitting directly in source code or a committed config file.",
       whyItBlocksLaunch: "A leaked production key is the single fastest way to lose money or expose user data. Public-repo secrets get scraped within minutes of being committed, and the bots that find them spin up paid API calls or exfiltrate database content before you notice. Even private repos leak \u2014 screenshots, accidental publishes, and shared chat threads all count.",
-      fixInstructions: "Move every detected secret out of source into environment variables (OPENAI_API_KEY, STRIPE_SECRET_KEY, DATABASE_URL, etc.) and read them at runtime via process.env. Add the variable names to .env.example so future runs know what to set. Then ROTATE the original secret at the provider \u2014 the leaked value must be considered compromised. Update .gitignore to exclude .env, and run gitleaks across history to catch earlier commits.",
-      aiBuilderPrompt: "Find every hardcoded secret in this project (API keys, tokens, OAuth client secrets, JWT signing keys, webhook secrets, database passwords). For each: tell me the file, the line, and what kind of secret it is. Then refactor each to read from process.env with a clear name (OPENAI_API_KEY, STRIPE_SECRET_KEY, etc.). Add every required variable to .env.example. Make sure .env is in .gitignore. List every secret value that needs to be ROTATED at the source service. Never print actual secret values back to me \u2014 only references.",
+      fixInstructions: "Move every detected secret-only value out of source into environment variables (OPENAI_API_KEY, STRIPE_SECRET_KEY, DATABASE_URL, etc.) and read them at runtime via process.env. Browser-visible public keys are allowed only when provider docs explicitly mark them publishable or anonymous; everything else moves behind a backend endpoint or serverless function. Add variable names to .env.example without values. Then ROTATE the original secret at the provider \u2014 the leaked value must be considered compromised. Update .gitignore to exclude .env, and run gitleaks across history to catch earlier commits.",
+      aiBuilderPrompt: "Find every hardcoded credential in this project (API keys, tokens, OAuth client secrets, JWT signing keys, webhook secrets, database passwords). For each: tell me the file, the line, what kind of credential it is, and whether provider docs say it is public-safe or secret-only. Refactor every secret-only credential to read from process.env with a clear name (OPENAI_API_KEY, STRIPE_SECRET_KEY, etc.) or move the action behind a backend endpoint. Add every required variable name to .env.example without values. Make sure .env is in .gitignore. List every secret value that needs to be ROTATED at the source service. Never print actual secret values back to me \u2014 only references.",
       verificationStep: "Run `npx shippingszn` again and confirm zero findings under `secrets`. Run `gitleaks detect --source . --verbose` to scan git history. Rotate any value that ever appeared in a commit, screenshot, or chat \u2014 even removing it from current code doesn't unrotate it."
     }
   },
@@ -449,11 +454,12 @@ var ITEMS_CRITICAL_A = [
     category: "Operations",
     priority: "critical",
     timeEstimate: "2 hr+",
-    prompt: "Act as a senior backend engineer. Audit my app for every paid third-party API I call (OpenAI, Anthropic, Replicate, ElevenLabs, Twilio, image generation, transcription, anything per-request). For each one: (1) tell me where in the provider's dashboard to set a HARD spending cap (not just an alert) and what number to start with \u2014 recommend a sane default for an early-stage app; (2) add an in-app per-user daily and per-IP daily quota for that endpoint, returning a polite 429 when exceeded; (3) add a global kill-switch I can toggle via env var to instantly stop calls if costs spike; (4) log every paid call with user ID, route, token count or unit cost so I can see who is consuming what; (5) add a simple cost dashboard or weekly email summary. After you're done, tell me the absolute worst-case daily spend if my app got pounded by a bot.",
+    prompt: "Act as a senior backend engineer. Audit my app for every paid third-party API I call (OpenAI, Anthropic, Replicate, ElevenLabs, Twilio, Resend, SendGrid, scraping, search, image generation, transcription, anything per-request). For each one: (1) tell me where in the provider's dashboard to set a HARD spending cap (not just an alert) and what number to start with \u2014 recommend a sane default for an early-stage app; (2) set dashboard alerts at 50% and 80% of that cap where the provider supports alerts; (3) add an in-app per-user daily and per-IP daily quota for that endpoint, returning a polite 429 when exceeded; (4) add a global kill-switch I can toggle via env var to instantly stop calls if costs spike; (5) log every paid call with user ID, route, token count or unit cost so I can see who is consuming what; (6) add a simple cost dashboard or weekly email summary. After you're done, tell me the absolute worst-case daily spend if my app got pounded by a bot.",
     what: "Every AI API and paid third-party service charges per request. If your app calls OpenAI, Anthropic, Replicate, ElevenLabs, Twilio, or anything similar, an attacker (or a bug) can run those calls in a loop and turn your free trial into a four-figure bill overnight. Spend caps and per-user quotas are the seatbelts.",
-    why: "This is the most underrated risk for vibe-coded apps in 2026. AI builders happily wire up an OpenAI key for you with no quotas. One infinite loop, one abusive script, or one curious user can rack up $1K\u2013$10K in a weekend. The provider will not refund it. Caps cost nothing and take 10 minutes to set.",
+    why: "This is the most underrated risk for AI-built apps in 2026. AI builders happily wire up an OpenAI key for you with no quotas. One infinite loop, one abusive script, or one curious user can rack up $1K\u2013$10K in a weekend. The provider will not refund it. Caps cost nothing and take 10 minutes to set.",
     steps: [
       "Log into every paid API dashboard (OpenAI, Anthropic, Replicate, etc.) and set a HARD monthly spending cap, not just a warning email. Start low \u2014 you can raise it.",
+      "Set dashboard alerts before the cap, at minimum 50% and 80%, so you hear about abuse before the provider shuts off the service or the bill lands.",
       "In your app, add per-user quotas: 'this user can make at most N AI requests per day.' Even logged-in users need this.",
       "Add per-IP rate limits on AI endpoints, separate from your normal API rate limits \u2014 much stricter.",
       "Add a global kill-switch (an env variable like AI_ENABLED=false) you can flip in 10 seconds if costs spike.",
@@ -461,6 +467,8 @@ var ITEMS_CRITICAL_A = [
     ],
     redFlags: [
       "No spending cap set in your AI provider's dashboard",
+      "Only a warning email exists \u2014 no hard cap, quota, or kill switch",
+      "No alert before the cap is hit",
       "No per-user limit on your AI features \u2014 anyone signed up can call them unlimited times",
       "AI endpoints exposed to logged-out users without strict per-IP limits",
       "You can't quickly answer 'what's the worst case my AI bill could be tomorrow?'",
@@ -475,7 +483,7 @@ var ITEMS_CRITICAL_A = [
     category: "Security",
     priority: "critical",
     timeEstimate: "2 hr+",
-    prompt: "Act as a senior application security engineer. I want to replace any custom or partial authentication in this app with a battle-tested provider. First, recommend the best fit for my stack from: Clerk, Auth0, Supabase Auth, Stytch, or my platform's built-in auth \u2014 and explain why in one paragraph. Then implement it end-to-end: signup, login, logout, password reset, email verification, session management, and protected routes (both pages and API). Use the provider's recommended secure defaults. Add server-side checks on every protected route \u2014 never trust the frontend. Add login and OTP rate limiting (max 5 attempts per 15 minutes per IP+identifier). If email or SMS one-time codes are used, normalize phone numbers to E.164, make resend/cooldown behavior explicit, use anti-enumeration responses, write clear mobile copy, verify real code delivery, and add a recovery path if paid access depends on OTP. Set session expiry to 24h of inactivity. Migrate any existing user data safely. After you're done, give me a checklist of what I need to verify in the provider dashboard before launch.",
+    prompt: "Act as a senior application security engineer. I want to replace any custom or partial authentication in this app with a battle-tested provider. First, recommend the best fit for my stack from: Clerk, Auth0, Supabase Auth, Stytch, or my platform's built-in auth \u2014 and explain why in one paragraph. Then implement it end-to-end: signup, login, logout, password reset, email verification, session management, and protected routes (both pages and API). Use the provider's recommended secure defaults. Add server-side checks on every protected route \u2014 never trust the frontend. Add login and OTP rate limiting (max 5 attempts per 15 minutes per IP+identifier). If email or SMS one-time codes are used, normalize phone numbers to E.164, make resend/cooldown behavior explicit, use anti-enumeration responses, write clear mobile copy, verify real code delivery, handle double-clicked/expired verification links gracefully, and add a recovery path if paid access depends on OTP. Set session expiry to 24h of inactivity. Migrate any existing user data safely. After you're done, give me a checklist of what I need to verify in the provider dashboard before launch.",
     what: "How users sign in, receive verification codes, recover paid access, and stay signed in. Done well, only the real user can get into their account. Done badly, an attacker can guess codes, enumerate customers, abuse SMS/email delivery, steal sessions, or read passwords straight out of your database.",
     why: "If your login or OTP flow is weak, every other security thing you did doesn't matter \u2014 the attacker just walks in the front door or your paid users get locked out. The good news: you almost never need to build login from scratch. Use a proven provider and let shippingszn scan for the launch risks AI builders usually miss.",
     steps: [
@@ -483,6 +491,7 @@ var ITEMS_CRITICAL_A = [
       "Never store passwords directly. Real auth providers store a one-way scrambled version (a hash) so even they can't read it.",
       "Turn on rate limiting on login (max 5 wrong attempts in 15 minutes) so attackers can't sit there guessing forever.",
       "If you use email or SMS OTP, normalize phone numbers, add resend cooldown copy, use generic success-shaped start responses, and smoke a real delivered code before launch.",
+      "Make expired, reused, and double-clicked verification links land in a safe state instead of throwing a scary error or leaking account state.",
       "If paid report or purchase access depends on OTP, add a recovery path: alternate contact, receipt/support handoff, or purchase history.",
       "Set sessions to expire (12\u201324 hours is normal) so a stolen laptop doesn't mean a permanent account takeover.",
       "Offer two-factor authentication (2FA) if your auth provider supports it \u2014 most do, with one toggle."
@@ -496,6 +505,7 @@ var ITEMS_CRITICAL_A = [
       "SMS OTP compares raw phone strings instead of normalized E.164 numbers",
       "The OTP start screen reveals whether an email, phone, purchase, or report exists",
       "Paid users have no fallback when the email or SMS code does not arrive",
+      "Verification links break when clicked twice, opened on mobile, or opened after expiry",
       "Session cookies missing HttpOnly, Secure, or SameSite (check Application \u2192 Cookies in dev tools)"
     ],
     cliCoverage: "automated",
@@ -514,7 +524,7 @@ var ITEMS_CRITICAL_A = [
     category: "Security",
     priority: "critical",
     timeEstimate: "2 hr+",
-    prompt: "Act as a security auditor. Audit my full app against the OWASP Top 10, focusing on: (1) SQL injection \u2014 find any place I'm building queries with string concatenation or user input that bypasses my ORM's parameterization; (2) NoSQL injection (Mongo, Firestore) \u2014 any place user input becomes a filter object without validation; (3) command injection \u2014 any place user input reaches a shell-invocation API in my language (Node shelling out, Python shell wrappers, Ruby backticks, etc.); (4) LDAP injection if I talk to a directory service; (5) XSS \u2014 find any place user input is rendered as HTML without escaping (innerHTML, raw HTML props, v-html, raw template interpolation, legacy doc-write APIs); (6) CSRF \u2014 find any state-changing endpoint without CSRF protection or SameSite cookies; (7) SSRF \u2014 find any place user input becomes a URL my server fetches; (8) insecure deserialization; (9) open redirects; (10) file upload handling \u2014 verify every upload path enforces a MIME allowlist, max size, path-traversal-safe filenames, and stores outside the web root (or on object storage with no public list); (11) verbose error responses \u2014 verify NODE_ENV (or equivalent) is 'production' in production and no stack trace, ORM dump, or absolute file path ever leaks to an end-user response body. For each finding: file, line, severity, plain-English explanation, exact fix. Apply the fixes after listing them. Then add a Content Security Policy header tuned to my actual asset sources \u2014 no wildcards, minimal unsafe-inline, justify any exception.",
+    prompt: "Act as a security auditor. Audit my full app against the OWASP Top 10, focusing on: (1) SQL injection \u2014 find any place I'm building queries with string concatenation or user input that bypasses my ORM's parameterization; (2) NoSQL injection (Mongo, Firestore) \u2014 any place user input becomes a filter object without validation; (3) command injection \u2014 any place user input reaches a shell-invocation API in my language (Node shelling out, Python shell wrappers, Ruby backticks, etc.); (4) LDAP injection if I talk to a directory service; (5) XSS \u2014 find any place user input is rendered as HTML without escaping (innerHTML, raw HTML props, v-html, raw template interpolation, legacy doc-write APIs); (6) CSRF \u2014 find any state-changing endpoint without CSRF protection or SameSite cookies; (7) SSRF \u2014 find any place user input becomes a URL my server fetches; (8) insecure deserialization; (9) open redirects; (10) file upload handling \u2014 verify every upload path enforces a MIME allowlist, max size, path-traversal-safe filenames, and stores outside the web root (or on object storage with no public list); (11) verbose error responses \u2014 verify NODE_ENV (or equivalent) is 'production' in production and no stack trace, ORM dump, SQL query, table name, column name, internal service URL, or absolute file path ever leaks to an end-user response body. For each finding: file, line, severity, plain-English explanation, exact fix. Apply the fixes after listing them. Then add a Content Security Policy header tuned to my actual asset sources \u2014 no wildcards, minimal unsafe-inline, justify any exception.",
     what: "There are a handful of attacks that bots constantly run against every site on the internet. They have ugly names \u2014 XSS, SQL injection, CSRF \u2014 but the idea is simple: they trick your app into running code or queries it shouldn't. Modern frameworks have built-in defenses; you just have to use them correctly.",
     why: "These bots don't care who you are. They scan the entire internet looking for sites that forgot to defend. If yours is one of those, your data ends up dumped on a forum, your users get hijacked, and you find out by reading about yourself online.",
     steps: [
@@ -522,19 +532,21 @@ var ITEMS_CRITICAL_A = [
       "Never paste user input directly into HTML you display to other users. Frameworks like React handle this safely by default \u2014 don't disable that behavior.",
       "Add a Content Security Policy header (your AI builder can set this up in one prompt) that tells browsers what code they're allowed to run.",
       "Use anti-CSRF tokens on forms that change data, if your auth provider doesn't already handle them.",
+      "Show generic errors to users and log detailed errors server-side. Users should never see SQL, table names, stack traces, service URLs, or raw exception text.",
       'Ask your AI builder: "audit my app for XSS, SQL injection, and CSRF vulnerabilities and fix any you find."'
     ],
     redFlags: [
       "Anywhere you're building SQL queries by gluing strings together",
       "Anywhere user input gets shown back to other users without going through the framework's safe rendering",
       "Your framework is showing security warnings in the console you've been ignoring",
-      "Forms that change data (delete, update, transfer money) work fine when called from random other websites"
+      "Forms that change data (delete, update, transfer money) work fine when called from random other websites",
+      "Production errors show stack traces, table names, SQL snippets, ORM errors, absolute file paths, or internal service URLs"
     ],
     cliCoverage: "automated",
     cliPrompt: {
       whatFailed: "The scanner caught a code pattern that maps to a well-known automated attack: unsafe HTML rendering (XSS), wildcard CORS (any origin can call your API), runtime code-execution calls, or a SQL/NoSQL query built from string concatenation instead of parameterization.",
       whyItBlocksLaunch: "These are not theoretical. Bots scan the entire internet looking for sites that forgot to use the framework's safe defaults. Your app is one bot away from a stolen session, a hijacked admin route, or a customer-data dump on a forum. The fix is almost always a one-line change to use the framework's safe primitive instead of the raw one.",
-      fixInstructions: "Replace unsafe HTML rendering APIs (innerHTML, raw HTML props, v-html, legacy doc-write APIs) with the framework's safe interpolation (React's default {}, Vue's {{ }}, etc.). Replace wildcard CORS (`*`) with an explicit allowlist of trusted origins. Eliminate runtime code-execution calls \u2014 there is almost always a parser or DSL that does the job safely. Use parameterized queries everywhere \u2014 never glue strings into SQL/NoSQL filters. Add a Content Security Policy header tuned to your actual asset origins.",
+      fixInstructions: "Replace unsafe HTML rendering APIs (innerHTML, raw HTML props, v-html, legacy doc-write APIs) with the framework's safe interpolation (React's default {}, Vue's {{ }}, etc.). Replace wildcard CORS (`*`) with an explicit allowlist of trusted origins. Eliminate runtime code-execution calls \u2014 there is almost always a parser or DSL that does the job safely. Use parameterized queries everywhere \u2014 never glue strings into SQL/NoSQL filters. Return generic user-facing errors and log detailed exceptions only server-side. Add a Content Security Policy header tuned to your actual asset origins.",
       aiBuilderPrompt: "Audit every finding in this scan tagged `common-attacks`. For each: explain in plain English what the attack is, show me the exact line, and apply the smallest safe fix \u2014 escape HTML rather than disabling sanitization, parameterize queries rather than string-glue, narrow CORS to the actual production origin(s), replace runtime code-execution calls with a typed parser. Also add a Content Security Policy header that allowlists ONLY my actual asset origins (no wildcards, minimal unsafe-inline, justify every exception). Show me the diff before applying.",
       verificationStep: "Re-run the scanner and confirm zero findings tagged `common-attacks`. In the deployed app, open dev-tools Network and confirm responses include a tight CSP header. Try posting a `<script>alert(1)</script>` payload anywhere user content is rendered \u2014 confirm it shows as text, not as an executed alert."
     }
@@ -554,7 +566,7 @@ var ITEMS_CRITICAL_B = [
     what: "HTTPS is the little padlock in the browser bar. It encrypts everything between your user and your server, so people sharing the same WiFi can't read passwords as they're being typed. Security headers are extra instructions you send to the browser saying \u201Cnever trust content claiming to be from me unless it really is.\u201D",
     why: "Without HTTPS, anyone on the same coffee-shop WiFi can read your users' passwords as plaintext. Without security headers, attackers can wrap your site inside theirs (clickjacking) or trick browsers into running malicious scripts. The fixes are basically free.",
     steps: [
-      "Most modern hosting (Replit, Vercel, Netlify, Cloudflare Pages, Railway) gives you HTTPS automatically when you publish \u2014 confirm the lock icon shows up in the browser bar.",
+      "Most modern hosting gives you HTTPS automatically when you publish \u2014 confirm the lock icon shows up in the browser bar.",
       "Set up an automatic redirect from http:// to https:// so no one accidentally lands on the unencrypted version.",
       "Add a Content-Security-Policy header that locks down where your scripts, images, and fonts are allowed to come from.",
       "Add X-Content-Type-Options: nosniff and X-Frame-Options: DENY (or SAMEORIGIN if you embed your own pages).",
@@ -608,7 +620,7 @@ var ITEMS_CRITICAL_B = [
     priority: "critical",
     timeEstimate: "1 hr",
     prompt: "Act as a senior infrastructure engineer. Tell me, for my specific database setup, exactly: (1) is automatic point-in-time backup turned on, and how far back can I restore? (2) where the backups physically live and who can access them; (3) the EXACT click-by-click procedure to restore my database to a point 24 hours ago in a non-destructive way (clone first, swap if good, never restore in place blind). Then walk me through ACTUALLY DOING a test restore right now to a clone \u2014 not in theory, in practice \u2014 so I know it works before I need it. Also recommend an additional manual backup strategy (weekly export to object storage I control) so I'm not 100% dependent on my host. Output a one-page DISASTER_RECOVERY.md I can keep with my project.",
-    what: "An automatic, recent copy of your entire database stored somewhere safe \u2014 and the ability to restore from it without panicking. Most managed databases (Neon, Supabase, Replit DB, RDS, PlanetScale) include some form of backup, but defaults vary, and 'a backup exists' is not the same thing as 'a backup that works.'",
+    what: "An automatic, recent copy of your entire database stored somewhere safe \u2014 and the ability to restore from it without guessing under pressure. Most managed databases (Neon, Supabase, Replit DB, RDS, PlanetScale) include some form of backup, but defaults vary, and 'a backup exists' is not the same thing as 'a backup that works.'",
     why: "Sooner or later you, your AI builder, or a script will run the wrong query against the production database. Without a tested backup, your only options are 'rebuild from memory' and 'apologize to users in public.' With one, it's a 10-minute fix. The whole point of doing this BEFORE launch is that nobody is depending on the data yet \u2014 so testing the restore is free.",
     steps: [
       "Open your database's dashboard (Neon, Supabase, Replit, etc.) and find the Backups or Point-in-time Recovery section. Confirm automatic backups are on, and note how many days you can restore back.",
@@ -636,13 +648,14 @@ var ITEMS_CRITICAL_B = [
     category: "Security",
     priority: "critical",
     timeEstimate: "2 hr+",
-    prompt: "Act as a backend security engineer. Go through every API endpoint in my app and check two things for each: (1) authentication \u2014 is the user logged in? (2) authorization \u2014 is THIS user allowed to access THIS specific resource? (the IDOR check). Pay especially close attention to endpoints that use IDs from the URL like /users/:id or /orders/:id \u2014 these are the most commonly broken. Output a table per endpoint: route, method, requires login? (Y/N), checks resource ownership? (Y/N), risk level. Then fix every endpoint that's missing checks. Add input validation (Zod, Yup, or my framework's equivalent) to every endpoint \u2014 validate types, ranges, lengths, formats. Lock down CORS to my own domain \u2014 no wildcards in production. After fixes, give me 3 curl commands I can run to verify a logged-out user, a regular logged-in user, and another user's account all get blocked appropriately.",
+    prompt: "Act as a backend security engineer. Go through every API endpoint in my app and check four things for each: (1) authentication \u2014 is the user logged in? (2) authorization \u2014 is THIS user allowed to access THIS specific resource? (the IDOR check); (3) server-side validation \u2014 does the backend validate types, ranges, lengths, formats, and required fields before writing or calling paid APIs? (4) safe errors \u2014 does the route return generic user-facing errors while logging detailed errors server-side only? Pay especially close attention to endpoints that use IDs from the URL like /users/:id or /orders/:id \u2014 these are the most commonly broken. Output a table per endpoint: route, method, requires login? (Y/N), checks resource ownership? (Y/N), validates input server-side? (Y/N), leaks internal error detail? (Y/N), risk level. Then fix every endpoint that's missing checks. Add input validation (Zod, Yup, Valibot, Joi, or my framework's equivalent) to every endpoint \u2014 validate types, ranges, lengths, formats, and payload shape on the server, not only in React. Lock down CORS to my own production domain plus localhost/preview as needed \u2014 no wildcards in production. After fixes, give me 3 curl commands I can run to verify a logged-out user, a regular logged-in user, and another user's account all get blocked appropriately.",
     what: "Your app has a frontend (what users see) and a backend (the URLs the frontend calls to load and save data \u2014 these are called API endpoints). If those backend URLs aren't checking who's asking and what they're allowed to do, anyone with browser developer tools can call them directly and do whatever they want.",
-    why: 'This is one of the most common silent disasters in vibe-coded apps: the frontend hides the "delete account" button from non-admins, but the backend lets anyone call /api/delete-account if they know the URL. The button is decoration; the backend check is the actual lock.',
+    why: 'This is one of the most common silent disasters in AI-built apps: the frontend hides the "delete account" button from non-admins, but the backend lets anyone call /api/delete-account if they know the URL. The button is decoration; the backend check is the actual lock.',
     steps: [
       'Every endpoint that touches user data should check: "is this person logged in?"',
       `Every endpoint that touches a specific user's data should also check: "is this person allowed to access THIS user's data?" This is the most commonly missed step.`,
-      "Validate every input on the backend \u2014 don't trust the frontend to send you clean data.",
+      "Validate every input on the backend \u2014 don't trust the frontend to send clean data. Client-side Zod is UX; server-side validation is security.",
+      "Return generic errors to users and log detailed errors server-side. Never hand an attacker table names, SQL, stack traces, or schema details.",
       `Ask your AI builder: "go through every API endpoint in my project and tell me which ones don't check authentication or authorization, and fix them."`,
       "Set up CORS so only your own frontend can call your backend."
     ],
@@ -650,6 +663,8 @@ var ITEMS_CRITICAL_B = [
       "Admin functions you can call from a logged-out browser",
       "You can change the user ID in a URL (/api/users/123 \u2192 /api/users/124) and read someone else's data",
       "Your backend trusts whatever the frontend sends without re-checking it",
+      "Forms only validate in the browser, with no matching server-side schema",
+      "API responses expose SQL, table names, stack traces, ORM errors, or internal service URLs",
       "CORS is wide open (Access-Control-Allow-Origin: *) on a non-public API"
     ],
     cliCoverage: "automated"
@@ -687,12 +702,12 @@ var ITEMS_CRITICAL_B = [
     category: "Product & Launch",
     priority: "critical",
     timeEstimate: "1 hr",
-    prompt: 'Act as a product engineer. Add /terms and /privacy pages to my app. IMPORTANT: do not invent legal language. Instead, generate a structured outline of every section that needs to exist in each page, customized to what my app actually does. Detect what to include by inspecting my dependencies and code \u2014 list every third-party service I integrate (Stripe, OpenAI, Google Analytics, Resend, Sentry, etc.) and note which ones need to be disclosed in the privacy policy. Output the outline as headings with a 1-sentence description of what each section should cover. Add a clear banner at the top of each page: "This is a starting outline. Get the actual legal language from a lawyer or a service like Termly, iubenda, or Termageddon." Then add the page routes, link them from the footer / signup / cookie banner, and include an "Effective date" field and a real contact email.',
+    prompt: 'Act as a product engineer. Add /terms and /privacy pages to my app. IMPORTANT: do not invent legal language. Instead, generate a structured outline of every section that needs to exist in each page, customized to what my app actually does. Detect what to include by inspecting my dependencies and code \u2014 list every third-party service I integrate (Stripe, OpenAI, Google Analytics, Resend, Sentry, Supabase, Firebase, Neon, Vercel, Cloudflare, etc.) and note which ones need to be disclosed in the privacy policy. Include a data-location section that points to the separate data-location inventory: where user data lives, what processors touch it, and which deletion/export path covers each one. Output the outline as headings with a 1-sentence description of what each section should cover. Add a clear banner at the top of each page: "This is a starting outline. Get the actual legal language from a lawyer or a service like Termly, iubenda, or Termageddon." Then add the page routes, link them from the footer / signup / cookie banner, and include an "Effective date" field and a real contact email.',
     what: "Two pages most apps need: Terms of Service (the rules of using your app) and a Privacy Policy (what data you collect and what you do with it). They are legal documents \u2014 the words matter, and they have to actually describe what your app does.",
     why: "These protect you from getting sued and protect your users from being misled. Most platforms (App Store, Google, Stripe, even Google sign-in) require them. Generated or copy-pasted policies that don't match your actual product are worse than nothing \u2014 they're evidence in a lawsuit.",
     steps: [
       "Do not have an AI write your final legal pages. Use a reputable template service (Termly, iubenda, Termageddon) or pay an actual attorney for a few hours.",
-      "Tailor whatever template you use to match what your app actually does \u2014 every third-party service you use (analytics, AI, payments, email) probably needs to be mentioned.",
+      "Tailor whatever template you use to match what your app actually does \u2014 every third-party service you use (analytics, AI, payments, database, auth, hosting, email) probably needs to be mentioned.",
       "Create /terms and /privacy pages and link them from the footer, signup, and any place you collect data.",
       "Include an effective date and a real way to contact you.",
       "If you collect cookies or run analytics, add a cookie banner where required (especially in the EU and UK)."
@@ -702,7 +717,8 @@ var ITEMS_CRITICAL_B = [
       "AI-generated policies that talk about features your app doesn't have",
       "Pages copied from another company (with their company name still in there)",
       "No effective date, no contact info",
-      "Your privacy policy doesn't mention services you actually use (Stripe, OpenAI, Google Analytics, etc.)"
+      "Your privacy policy doesn't mention services you actually use (Stripe, OpenAI, Google Analytics, etc.)",
+      "No one can say which provider or region stores user data"
     ],
     cliCoverage: "automated"
   },
@@ -714,8 +730,8 @@ var ITEMS_CRITICAL_B = [
     priority: "critical",
     timeEstimate: "2 hr+",
     prompt: "Act as a privacy-aware product engineer. Add two flows to my app: (1) Account deletion \u2014 a button in account settings that, when confirmed (with a second-step modal), permanently deletes the user, all their personal data, and all their content, with a 7-day grace period during which the account can be recovered. After 7 days, the deletion is hard. Email confirmation when initiated and when finalized. (2) Data export \u2014 a button that emails the user a downloadable JSON or CSV of all their personal data and content within 24 hours. Audit my schema and tell me which tables/columns count as 'personal data' and need to be included. Make sure the deletion respects foreign-key constraints and removes data from any third party I forward to (Stripe customer, email provider, analytics). Don't break referential integrity for OTHER users (e.g., comments by deleted user become 'deleted user' instead of cascading). Output a short DATA_RIGHTS.md describing what's deleted and what's retained for legal reasons.",
-    what: "Two buttons in account settings: 'Download my data' and 'Delete my account.' One emails the user a copy of everything you have on them; the other actually removes them. Both are required almost everywhere personal data is regulated, and both are missing from almost every vibe-coded app.",
-    why: "GDPR (EU), CCPA (California), and an expanding list of US state laws make these legally required if you have any users in those places \u2014 which you will, because the internet is global. Beyond legal: it's the right thing, it builds trust, and it costs basically nothing to add now versus a panicked weekend later when someone files a complaint.",
+    what: "Two buttons in account settings: 'Download my data' and 'Delete my account.' One emails the user a copy of everything you have on them; the other actually removes them. Both are required almost everywhere personal data is regulated, and both are missing from almost every AI-built app.",
+    why: "GDPR (EU), CCPA (California), and an expanding list of US state laws make these legally required if you have any users in those places \u2014 which you will, because the internet is global. Beyond legal: it's the right thing, it builds trust, and it costs basically nothing to add now versus a rushed weekend later when someone files a complaint.",
     steps: [
       "Add a 'Delete my account' button in account settings. Require a second confirmation step ('type DELETE to confirm') so it's not accidental.",
       "Implement a 7-day grace period: the account is disabled immediately, deleted permanently after 7 days. Email the user when each happens.",
@@ -769,7 +785,7 @@ var ITEMS_CRITICAL_B = [
     timeEstimate: "2 hr+",
     prompt: "Act as a payments engineer. Audit my app's entire paid flow before launch. First, identify whether I use Stripe, Lemon Squeezy, Paddle, RevenueCat, app-store payments, or something else. Then verify and fix: (1) checkout can be created only by the server, never with a client-supplied price or product; (2) the success page does NOT unlock paid access just because the URL says success; it checks the backend for a paid order; (3) webhooks verify the provider signature and persist paid status, receipt ID, amount, currency, and customer email; (4) every paid product, subscription, upgrade, cancellation, refund, and failed-payment state has a real user-facing path; (5) test-mode checkout, webhook delivery, receipt email, refund, and cancellation all work end-to-end. Output exact test-card steps, webhook setup steps, env vars, and the one thing I should click in the provider dashboard to prove money would actually move.",
     what: "If your app charges money, the payment flow is not 'done' when the checkout button opens. It is done when payment succeeds, your backend hears the signed webhook, paid access unlocks, the receipt lands, and cancellation/refund paths do not strand the user.",
-    why: "This is where vibe-coded apps embarrass themselves fast. A founder launches, someone pays, the success page lies, the webhook never arrives, and now the first customer is both confused and charged. Or worse: a user edits a client-side price and buys the expensive thing for $0. Payments need a real dry run before launch day.",
+    why: "This is where AI-built apps embarrass themselves fast. A team launches, someone pays, the success page lies, the webhook never arrives, and now the first customer is both confused and charged. Or worse: a user edits a client-side price and buys the expensive thing for $0. Payments need a real dry run before launch day.",
     steps: [
       "Run a full test-mode checkout from a logged-out or brand-new account. Pay with the provider's test card and confirm the success page shows the right purchased thing.",
       "Verify paid access comes from your backend's recorded payment state, not from a success URL, localStorage flag, or client-side boolean.",
@@ -838,6 +854,114 @@ var ITEMS_CRITICAL_B = [
     ],
     cliCoverage: "manual_only",
     whyManual: "AI guardrails need scenario testing against real prompts, tool permissions, data boundaries, and destructive-action confirmations. Static code cannot prove the model behaves safely under adversarial input."
+  },
+  {
+    id: "database-access-rules",
+    number: 19,
+    title: "Prove every user can only read their own rows",
+    category: "Security",
+    priority: "critical",
+    timeEstimate: "2 hr+",
+    prompt: "Act as a database security engineer. Audit every table, collection, bucket, and document store that contains user data. First identify the backend: Supabase/Postgres, Firebase/Firestore, MongoDB, Prisma/Drizzle/SQL, object storage, or something else. Then verify the real access boundary: (1) Supabase/Postgres: Row Level Security is enabled on every user-scoped table and policies exist for select/insert/update/delete; service-role keys never reach the browser; policies are tested with two different users. (2) Firebase/Firestore: security rules deny by default and explicitly check auth.uid/resource ownership; rules are tested in the emulator. (3) SQL/ORM: every query that reads user data filters by the authenticated user or permission model server-side. (4) Storage: private files live in private buckets with signed URLs and ownership checks. Output a table: data surface, user-scoped? rule/policy present? cross-user test passed? risk. Then write the exact SQL/rules/tests needed to close gaps.",
+    what: "Database access rules are the lock underneath your UI. Your frontend can hide another user's records, but the database or API still has to refuse the request when someone changes an ID, opens DevTools, or calls the endpoint directly.",
+    why: "This is the classic AI-built app data breach: the app looks private, but Supabase RLS is off, Firebase rules allow broad reads, or the server query forgets `where user_id = currentUser.id`. That is not a hack; it is an unlocked door.",
+    steps: [
+      "List every user-scoped table, collection, storage bucket, and API route that returns saved user data.",
+      "For Supabase, enable RLS on every user-scoped table and write policies for select, insert, update, and delete. Do not ship with zero policies.",
+      "For Firebase/Firestore, make rules deny by default and allow reads/writes only when auth.uid owns the document or has an explicit role.",
+      "Test with two real test users: create data as User A, log in as User B, and try to read, edit, or delete User A's records through the app, the API, and any SDK/browser console path.",
+      "Keep privileged service-role/admin keys server-side only. If a browser bundle can use the key to bypass rules, the rules do not matter."
+    ],
+    redFlags: [
+      "Supabase table shows RLS disabled or zero policies",
+      "Firestore rules include broad allow read/write statements",
+      "The frontend hides records but backend/API queries do not check ownership",
+      "Service-role/admin/database credentials are present in browser code",
+      "No cross-user test has ever been run with two separate accounts"
+    ],
+    cliCoverage: "manual_only",
+    whyManual: "Database access rules must be proven against the real provider and two real users. Static code can spot hints, but it cannot prove Supabase RLS, Firebase rules, storage policies, and cross-user ownership tests all work in the deployed environment."
+  },
+  {
+    id: "auth-failure-cases",
+    number: 20,
+    title: "Test the auth failures attackers try first",
+    category: "Security",
+    priority: "critical",
+    timeEstimate: "30 min",
+    prompt: "Act as a QA/security engineer. Run the auth failure-case drill before launch, using production-similar auth settings and throwaway test accounts. Test: (1) wrong password or wrong OTP 5-6 times in a row \u2014 confirm rate limiting/lockout and generic copy; (2) password reset or magic-link start for an email that does not exist \u2014 confirm it looks the same as a real email path and does not reveal account existence; (3) verification or magic link clicked twice, opened after expiry, and opened on a different device \u2014 confirm it lands in a safe state with a recovery path; (4) signup with an already registered email or phone \u2014 confirm it does not leak account state beyond the provider's safe default; (5) login from mobile and desktop \u2014 confirm session/cookie behavior is correct. Output pass/fail evidence, screenshots or curl commands where useful, and the exact copy users see.",
+    what: "Happy-path auth testing proves almost nothing. The dangerous bugs are in the weird edges: wrong codes, fake emails, repeated attempts, duplicate signup, expired links, and users opening links on a different device.",
+    why: "Attackers probe the failure paths first because they reveal whether an account exists, whether a code can be brute-forced, and whether a user can get locked out. Paid users hit the same paths accidentally on launch day.",
+    steps: [
+      "Try the wrong password, magic code, or OTP 5-6 times. Confirm a real limit kicks in and the message stays generic.",
+      "Start password reset or magic-link login for an email that does not exist. The response should look like success, not 'account not found.'",
+      "Click the same verification/magic link twice and after expiry. It should recover gracefully, not show a stack trace or reveal internals.",
+      "Sign up with an email or phone that already exists. Confirm the provider's safe default copy and rate limits are used.",
+      "Record the exact pass/fail evidence in the launch report so nobody hand-waves auth as 'probably fine.'"
+    ],
+    redFlags: [
+      "Wrong password or OTP can be tried indefinitely",
+      "Password reset says whether an email exists",
+      "Verification links crash or leak internals when reused",
+      "Signup copy reveals registered users in a way attackers can enumerate",
+      "No one has tested auth failure states outside the happy path"
+    ],
+    cliCoverage: "manual_only",
+    whyManual: "Auth failure behavior requires a live auth provider, delivered emails/SMS, real browser sessions, and throwaway accounts. The scanner can flag code signals, but it cannot honestly click links, trigger provider lockouts, or verify copy in every failure state."
+  },
+  {
+    id: "data-location-inventory",
+    number: 21,
+    title: "Know where every piece of user data lives",
+    category: "Product & Launch",
+    priority: "critical",
+    timeEstimate: "1 hr",
+    prompt: "Act as a privacy and infrastructure operator. Build a data-location inventory for this app before launch. Inspect the code, dependencies, env var names, docs, provider dashboards, and signup/payment/email/auth flows. Output a table with: data type collected, source form/route, primary store, provider, region/location if available, third parties that receive it, retention period, deletion/export path, and policy disclosure needed. Include email providers, auth providers, analytics, error monitoring, payment processors, AI providers, file storage, databases, logs, and support tools. If a provider dashboard is needed to confirm region, say exactly which dashboard page must be checked. Do not invent regions \u2014 mark unknown until verified.",
+    what: "The moment you collect an email, payment, file, prompt, or user profile, you need to know where it goes. 'It is somewhere in Supabase' or 'Vercel handles it' is not enough when a user asks for deletion or a platform asks for your privacy details.",
+    why: "Legal pages only protect you if they match reality. If your app sends user data to Stripe, OpenAI, Resend, Sentry, PostHog, Supabase, Firebase, Neon, or a support inbox, those processors and regions have to be known before launch.",
+    steps: [
+      "List every data collection point: signup, checkout, waitlist, contact form, uploaded file, AI prompt, analytics event, error log, support request.",
+      "For each one, write where it is stored first, which third parties receive it, and how long it is kept.",
+      "Open provider dashboards and record region/location where available: database, hosting, auth, email, analytics, AI, payments, storage, logs.",
+      "Tie every data store to a deletion/export path so account deletion is not just deleting one database row.",
+      "Update the privacy policy outline so it names the real categories of data, processors, retention, and deletion/export contact."
+    ],
+    redFlags: [
+      'You cannot answer "where does a new user email go?"',
+      "Privacy policy names fewer processors than the code actually uses",
+      "No one knows the database/auth/storage region",
+      "Error monitoring or analytics receives personal data without disclosure",
+      "Account deletion only touches the app database and ignores Stripe, email, analytics, logs, or support tools"
+    ],
+    cliCoverage: "manual_only",
+    whyManual: "Data location depends on live provider dashboard settings, regions, processors, and retention choices. Static repo scanning can infer likely services, but it cannot prove where provider-held data physically lives or whether privacy disclosures match reality."
+  },
+  {
+    id: "public-form-abuse",
+    number: 22,
+    title: "Block bots from public forms before launch",
+    category: "Security",
+    priority: "critical",
+    timeEstimate: "1 hr",
+    prompt: "Act as an abuse-prevention engineer. Find every public form or unauthenticated write surface: signup, login/OTP send, password reset, waitlist, contact, feedback, newsletter, invite request, file upload, AI demo, support, and checkout-start. For each one, decide whether it needs CAPTCHA/Turnstile, rate limiting, email/phone verification, honeypot fields, server-side validation, or all of the above. Prefer Cloudflare Turnstile for public marketing/contact/waitlist forms because it is free and privacy-friendly. Add the provider secret server-side only, verify tokens on the backend before accepting the submission, keep localhost/dev bypasses development-only, and add abuse logging. Then test with a missing token, invalid token, repeated submissions, and a real browser pass.",
+    what: "Public forms are doors bots can walk through without an account. If they can submit freely, they will fill your waitlist with spam, burn SMS/email credits, scrape paid APIs, or bury real leads under junk.",
+    why: "A polished launch can still get wrecked by a public form with no bot guard. The app looks fine until the first traffic spike turns into 500 spam contacts, SMS pumping, or an AI endpoint bill.",
+    steps: [
+      "Inventory every unauthenticated form or POST route, not just the contact form.",
+      "Put CAPTCHA or Cloudflare Turnstile on public marketing/contact/waitlist/feedback forms that accept arbitrary submissions.",
+      "Keep rate limits on every public write endpoint even when CAPTCHA is present. CAPTCHA slows bots; rate limits cap damage.",
+      "Verify bot tokens server-side before writing to the database, sending email/SMS, or calling a paid API.",
+      "Test missing-token, invalid-token, repeated-submit, and real-browser success paths before launch."
+    ],
+    redFlags: [
+      "Contact, waitlist, feedback, signup, or OTP forms accept unlimited public submissions",
+      "CAPTCHA token is checked only in the frontend",
+      "CAPTCHA is present but the endpoint still writes data when the token is missing",
+      "No rate limit backs up the CAPTCHA",
+      "Development/test bypass can run in production"
+    ],
+    cliCoverage: "manual_only",
+    whyManual: "Bot protection has to be verified against live public forms and provider token validation. The scanner can look for rate-limit or CAPTCHA libraries, but it cannot prove every unauthenticated form rejects missing tokens and survives repeated submissions."
   }
 ];
 
@@ -851,7 +975,7 @@ var ITEMS_CRITICAL = [
 var ITEMS_HIGH = [
   {
     id: "error-monitoring",
-    number: 19,
+    number: 23,
     title: "Get notified the moment something breaks",
     category: "Operations",
     priority: "high",
@@ -876,7 +1000,7 @@ var ITEMS_HIGH = [
   },
   {
     id: "uptime-monitoring",
-    number: 20,
+    number: 24,
     title: "Get pinged the moment your app goes completely down",
     category: "Operations",
     priority: "high",
@@ -903,17 +1027,18 @@ var ITEMS_HIGH = [
   },
   {
     id: "rate-limiting",
-    number: 21,
+    number: 25,
     title: "Cap how often someone can hit your app",
     category: "Security",
     priority: "high",
     timeEstimate: "1 hr",
-    prompt: "Act as a backend security engineer. Add rate limiting to every public-facing endpoint. Use a sensible default (60 req/min/IP) for read endpoints, and tighter limits for sensitive ones: login (5 per 15 min per IP+email), signup (3 per hour per IP), password reset (3 per hour per email), AI/expensive endpoints (whatever fits a daily budget \u2014 ask me what I'm willing to spend per day). Return a clean 429 response with a Retry-After header and a friendly JSON message. Log every rate-limit hit with IP and route so I can see attacks. Use my framework's recommended middleware (express-rate-limit, hono-rate-limit, etc.). Recommend in-memory vs Redis backing based on whether I'm running multiple instances. After you're done, give me a curl one-liner I can run to verify it actually blocks me after N attempts.",
+    prompt: "Act as a backend security engineer. Add rate limiting to every public-facing endpoint. Use a sensible default (60 req/min/IP) for normal public reads, around 100 req/min/IP for low-risk public utility endpoints, and tighter limits for sensitive ones: login (5 per 15 min per IP+email), signup (3 per hour per IP), password reset (3 per hour per email), OTP send (3-5 per hour per identifier), public forms (strict enough to stop spam), and AI/expensive endpoints (whatever fits a daily budget \u2014 ask me what I'm willing to spend per day). Return a clean 429 response with a Retry-After header and a friendly JSON message. Log every rate-limit hit with IP and route so I can see attacks. Use my framework's recommended middleware (express-rate-limit, hono-rate-limit, @upstash/ratelimit, Arcjet, etc.). Recommend in-memory vs Redis/Upstash backing based on whether I'm running multiple instances. After you're done, give me a curl one-liner I can run to verify it actually blocks me after N attempts.",
     what: "Rate limiting puts a maximum on how many requests one person (or one IP address) can make in a given window \u2014 say, 60 requests a minute. Without it, a single bot can hammer your backend until it falls over, run up your AI bill, or brute-force passwords until something works.",
     why: "Without rate limits you are one bad actor away from a $10,000 OpenAI bill, a crashed server, or a leaked password. Rate limits are cheap to add and save you from a long list of nightmares.",
     steps: [
       "Add rate limiting to every public-facing endpoint.",
       "Use stricter limits on the sensitive ones: login (5 per 15 minutes), signup (3 per hour), password reset (3 per hour), AI calls (whatever fits your budget).",
+      "Use a shared backing store such as Redis/Upstash when the app runs more than one instance. In-memory limits reset per instance.",
       `Return a clear "you're going too fast, try again in X seconds" message \u2014 don't just silently fail.`,
       "Watch for repeated rate-limit hits \u2014 they're usually attacks. Have alerts set up for spikes.",
       'Ask your AI builder: "add per-IP rate limiting to all my endpoints with stricter limits on login, signup, and password reset."'
@@ -922,6 +1047,7 @@ var ITEMS_HIGH = [
       "No rate limits at all",
       "Same limits everywhere (login should be way stricter than browsing)",
       "Auth endpoints (login, signup, password reset) not strictly capped \u2014 brute-force and credential-stuffing bots will find you",
+      "Rate limits are in-memory even though production runs multiple instances",
       "No alerting when someone repeatedly hits the limit",
       "You can't see how often this is happening"
     ],
@@ -929,12 +1055,12 @@ var ITEMS_HIGH = [
   },
   {
     id: "dependency-audit",
-    number: 22,
+    number: 26,
     title: "Patch your dependencies for known vulnerabilities",
     category: "Security",
     priority: "high",
     timeEstimate: "30 min",
-    prompt: "Act as a senior security engineer. Audit my project's installed dependencies for known vulnerabilities AND for supply-chain hygiene, and apply fixes. Tasks: (1) run the right auditor for my package manager \u2014 `npm audit` or `pnpm audit` for Node, `pip-audit` for Python, `bundle audit` for Ruby, `cargo audit` for Rust \u2014 and report the severity counts (critical / high / moderate / low). (2) for every Critical or High finding, try the auto-fix first (`npm audit fix`); if that doesn't clear it, upgrade the offending package manually and test the app after each change. Don't blindly `--force`. (3) if clearing a CVE needs a major-version bump that would break my app, document the CVE + the blocked upgrade + my exposure, then add a temporary mitigation if one's possible. (4) supply-chain hygiene \u2014 for every direct dependency, look up weekly download count and most-recent release date on the registry. Flag any dep with <1k weekly downloads (could be a typosquat \u2014 check the name against the obvious legitimate package) and any dep with no release in 12+ months (unmaintained \u2014 plan a replacement). (5) turn on automated dependency updates so this doesn't rot: Dependabot (free on GitHub) or Renovate \u2014 PR weekly for minor/patch, prompt on major. (6) add an audit step to my CI pipeline that fails the build on any new Critical CVE. When you're done, tell me plainly: any CVEs that made it to prod, any I deferred (with reasoning), any suspicious or abandoned deps I should swap, and the auto-update cadence you configured.",
+    prompt: "Act as a senior security engineer. Audit my project's installed dependencies for known vulnerabilities AND for supply-chain hygiene, and apply fixes. Tasks: (1) run the right auditor for my package manager \u2014 `npm audit` or `pnpm audit` for Node, `pip-audit` for Python, `bundle audit` for Ruby, `cargo audit` for Rust \u2014 and report the severity counts (critical / high / moderate / low). (2) for every Critical or High finding, try the auto-fix first (`npm audit fix`); if that doesn't clear it, upgrade the offending package manually and test the app after each change. Don't blindly `--force`. (3) if clearing a CVE needs a major-version bump that would break my app, document the CVE + the blocked upgrade + my exposure, then add a temporary mitigation if one's possible. (4) run or configure the builder/platform's built-in dependency/security scanner too, then compare its findings against the package-manager audit so nothing is silently ignored. (5) supply-chain hygiene \u2014 for every direct dependency, look up weekly download count and most-recent release date on the registry. Flag any dep with <1k weekly downloads (could be a typosquat \u2014 check the name against the obvious legitimate package) and any dep with no release in 12+ months (unmaintained \u2014 plan a replacement). (6) turn on automated dependency updates so this doesn't rot: Dependabot (free on GitHub) or Renovate \u2014 PR weekly for minor/patch, prompt on major. (7) add an audit step to my CI pipeline that fails the build on any new Critical CVE. When you're done, tell me plainly: any CVEs that made it to prod, any I deferred (with reasoning), any suspicious or abandoned deps I should swap, and the auto-update cadence you configured.",
     what: "Your app pulls in hundreds of third-party packages via `npm install` (or pip, bundle, cargo). Some of those packages have known security bugs with public write-ups and working exploits. Auditing means running one command to list every known bug in your dependencies, then upgrading to the fixed versions.",
     why: "Most successful attacks on small apps aren't clever \u2014 they're automated scanners finding sites that ship an old version of a popular library with a published CVE. The fix is usually a one-command upgrade. Skipping this is handing attackers the easiest version of your app.",
     steps: [
@@ -942,12 +1068,14 @@ var ITEMS_HIGH = [
       "For every Critical or High finding, try the auto-fix first (e.g. `npm audit fix`). Test that the app still works after each fix.",
       "For fixes that require a major-version bump, read the package's upgrade notes before updating \u2014 breaking changes are real.",
       "If a CVE has no fix yet, at least know you have it. Document it and subscribe to the package's security advisories.",
+      "Check your builder or hosting scanner output too. If Cursor, Claude Code, Lovable, Replit, GitHub, Snyk, or Semgrep flags dependency risk, reconcile it with the package audit.",
       "Turn on Dependabot or Renovate in your GitHub repo so it opens PRs as new versions ship \u2014 you're not manually checking anymore.",
       "Add the audit command to your CI pipeline so shipping a new Critical CVE breaks the build."
     ],
     redFlags: [
       "You have never run `npm audit` (or your language's equivalent) on this project",
       "The audit shows Critical severity \u2014 and you shipped anyway",
+      "Your builder or GitHub security tab shows warnings you have not read",
       "Dependabot / Renovate is not turned on",
       "Your lockfile hasn't been touched in more than 6 months",
       "CI never fails on a new CVE \u2014 you'll only find out from a bug report or a breach"
@@ -957,7 +1085,7 @@ var ITEMS_HIGH = [
   },
   {
     id: "logging",
-    number: 23,
+    number: 27,
     title: "Keep a paper trail of what your app is doing",
     category: "Operations",
     priority: "high",
@@ -983,7 +1111,7 @@ var ITEMS_HIGH = [
   },
   {
     id: "session-management",
-    number: 24,
+    number: 28,
     title: "Make sessions feel safe AND convenient",
     category: "Security",
     priority: "high",
@@ -1008,7 +1136,7 @@ var ITEMS_HIGH = [
   },
   {
     id: "github",
-    number: 25,
+    number: 29,
     title: "Connect to GitHub for backups and history",
     category: "Infrastructure",
     priority: "high",
@@ -1033,19 +1161,19 @@ var ITEMS_HIGH = [
   },
   {
     id: "rollback",
-    number: 26,
+    number: 30,
     title: "Know how to roll back a bad deploy in under a minute",
     category: "Operations",
     priority: "high",
     timeEstimate: "15 min",
     prompt: "Act as a deployment engineer. For my specific hosting platform, walk me through the EXACT click-by-click procedure to roll back to the previous deploy. Then have me actually do it once \u2014 to a previous commit, then forward again \u2014 so I know the muscle memory before I need it. Also: (1) tell me what's preserved during a rollback (env variables, secrets, data) and what isn't (any DB migration that ran on the bad deploy is NOT undone \u2014 call this out); (2) recommend whether I should enable preview deployments on every PR/branch so I can test changes before they hit production; (3) give me a 5-line emergency runbook (ROLLBACK.md) I can paste into my repo: 'If production is broken, do these 3 things in this order.'",
-    what: "The ability to undo a deployment in 30 seconds and get back to the last known good version. Almost every modern host (Replit, Vercel, Netlify, Railway, Render, Fly) supports one-click rollback to any prior version \u2014 but you need to know where the button is BEFORE the bad deploy.",
-    why: "You will ship something broken to production. Your AI builder will help you 'fix' something at midnight and the fix will be worse. The difference between a 30-second outage and a 3-hour panic is whether you've practiced rolling back once when nothing was wrong.",
+    what: "The ability to undo a deployment in 30 seconds and get back to the last known good version. Almost every modern host supports one-click rollback to any prior version \u2014 but you need to know where the button is BEFORE the bad deploy.",
+    why: "You will ship something broken to production. Your AI builder will help you 'fix' something at midnight and the fix will be worse. The difference between a 30-second outage and a 3-hour incident is whether you've practiced rolling back once when nothing was wrong.",
     steps: [
       "Find the Deployments or Releases panel in your hosting platform (most have 'Promote to production' or 'Rollback' next to each version).",
       "Do a practice rollback NOW, while everything is fine. Roll back one version, confirm the site still works, then roll forward again. You want this in muscle memory.",
       "Understand what rollback does NOT undo: any database migration that ran on the bad version is still applied \u2014 your code is rolled back but your schema isn't. Plan accordingly (migrations should be backwards compatible).",
-      "Turn on preview deployments (Vercel, Netlify, Railway all do this) so every change gets a temporary URL you can test before it touches production.",
+      "Turn on preview deployments so every change gets a temporary URL you can test before it touches production.",
       "Write a 5-line ROLLBACK.md in your repo: '1. Open hosting dashboard. 2. Find latest known-good version. 3. Click Rollback. 4. Verify site works. 5. Tell users in status page / Twitter what happened.'"
     ],
     redFlags: [
@@ -1053,14 +1181,14 @@ var ITEMS_HIGH = [
       "You've never actually performed a rollback even once",
       "All your changes go straight to production without a preview deployment",
       "Database migrations run automatically and are not reversible",
-      "No written runbook \u2014 at 2am you'll be improvising in panic"
+      "No written runbook \u2014 at 2am you'll be improvising under pressure"
     ],
     cliCoverage: "manual_only",
     whyManual: "Rollback readiness is muscle memory in the hosting dashboard plus a real recovery path for data migrations. The scanner cannot prove you practiced rollback and forward again."
   },
   {
     id: "soft-launch",
-    number: 27,
+    number: 31,
     title: "Soft-launch to 5 friends before you launch publicly",
     category: "Product & Launch",
     priority: "high",
@@ -1087,7 +1215,7 @@ var ITEMS_HIGH = [
   },
   {
     id: "interviews",
-    number: 28,
+    number: 32,
     title: "Talk to your first 10 users on a real call",
     category: "Growth",
     priority: "high",
@@ -1114,7 +1242,7 @@ var ITEMS_HIGH = [
   },
   {
     id: "onboarding",
-    number: 29,
+    number: 33,
     title: "Make the first 5 minutes obvious",
     category: "Product & Launch",
     priority: "high",
@@ -1145,7 +1273,7 @@ var ITEMS_HIGH = [
 var ITEMS_MEDIUM = [
   {
     id: "analytics",
-    number: 30,
+    number: 34,
     title: "Set up basic usage tracking",
     category: "Operations",
     priority: "medium",
@@ -1171,7 +1299,7 @@ var ITEMS_MEDIUM = [
   },
   {
     id: "db-performance",
-    number: 31,
+    number: 35,
     title: "Make your database queries fast",
     category: "Infrastructure",
     priority: "medium",
@@ -1197,7 +1325,7 @@ var ITEMS_MEDIUM = [
   },
   {
     id: "custom-domain",
-    number: 32,
+    number: 36,
     title: "Get your own domain (yourname.com)",
     category: "Infrastructure",
     priority: "medium",
@@ -1229,7 +1357,7 @@ var ITEMS_MEDIUM = [
   },
   {
     id: "email",
-    number: 33,
+    number: 37,
     title: "Make app emails actually arrive",
     category: "Infrastructure",
     priority: "medium",
@@ -1257,7 +1385,7 @@ var ITEMS_MEDIUM = [
   },
   {
     id: "mobile",
-    number: 34,
+    number: 38,
     title: "Make it not suck on phones",
     category: "Product & Launch",
     priority: "medium",
@@ -1284,7 +1412,7 @@ var ITEMS_MEDIUM = [
   },
   {
     id: "performance",
-    number: 35,
+    number: 39,
     title: "Make it fast",
     category: "Product & Launch",
     priority: "medium",
@@ -1310,7 +1438,7 @@ var ITEMS_MEDIUM = [
   },
   {
     id: "accessibility",
-    number: 36,
+    number: 40,
     title: "Make it usable for everyone, including people with disabilities",
     category: "Product & Launch",
     priority: "medium",
@@ -1337,12 +1465,12 @@ var ITEMS_MEDIUM = [
   },
   {
     id: "seo",
-    number: 37,
+    number: 41,
     title: "Set up the basics so search and social shares work",
     category: "Growth",
     priority: "medium",
     timeEstimate: "1 hr",
-    prompt: "Act as a technical SEO engineer. Add complete meta tags to every page. For each route, generate a unique <title> (\u226460 chars, includes brand) and meta description (\u2264160 chars, action-oriented and not stuffed with keywords). Add full Open Graph tags (og:title, og:description, og:image with absolute URL, og:url, og:type, og:site_name) and Twitter Card tags (summary_large_image variant with the same image). Add a canonical link per page. If my framework supports it (Next, Remix, Nuxt, SvelteKit, etc.), use the framework's metadata API; otherwise inject into <head>. Generate /sitemap.xml and /robots.txt using the real production domain (ask me what it is). When done, give me 3 URLs from my site I can paste into opengraph.xyz to verify previews look right.",
+    prompt: "Act as a technical SEO engineer. Add complete meta tags to every page. For each route, generate a unique <title> (\u226460 chars, includes brand) and meta description (\u2264160 chars, action-oriented and not stuffed with keywords). Add full Open Graph tags (og:title, og:description, og:image with absolute URL, og:url, og:type, og:site_name) and Twitter Card tags (summary_large_image variant with the same image). Add a canonical link per page. If my framework supports it (Next, Remix, Nuxt, SvelteKit, etc.), use the framework's metadata API; otherwise inject into <head>. Generate /sitemap.xml and /robots.txt using the real production domain (ask me what it is). Do not claim Google has indexed the site from this work alone; Search Console submission and URL Inspection are a separate launch closeout step. When done, give me 3 URLs from my site I can paste into opengraph.xyz to verify previews look right.",
     what: "Tiny bits of metadata in your HTML that tell Google what each page is about, and tell Twitter, LinkedIn, Slack, and iMessage how to display a preview when someone shares your link.",
     why: "These are your free billboards. A page with no title gets no clicks in Google. A link in iMessage with no preview image looks broken or sketchy. You only have to do this once per page.",
     steps: [
@@ -1350,6 +1478,7 @@ var ITEMS_MEDIUM = [
       "Add a unique meta description (under 160 characters) \u2014 this is what shows under your link in Google.",
       "Add Open Graph tags (og:title, og:description, og:image, og:url) \u2014 these power link previews in iMessage, Slack, LinkedIn.",
       "Add Twitter Card tags (twitter:card = summary_large_image plus title/description/image) for Twitter/X previews.",
+      "Make sure robots.txt points at the real production sitemap and important pages are not accidentally noindexed.",
       "Test how your link looks BEFORE you announce it: opengraph.xyz, metatags.io, or just paste it into a Slack channel and see."
     ],
     redFlags: [
@@ -1357,13 +1486,43 @@ var ITEMS_MEDIUM = [
       "No meta descriptions (Google generates random snippets for you)",
       "Sharing your link shows no preview image",
       "Preview image is broken or shows a default builder-supplied placeholder",
-      "No canonical URL set (causes duplicate-content issues in search)"
+      "No canonical URL set (causes duplicate-content issues in search)",
+      "Saying the site is indexed when you have only generated sitemap and robots files"
     ],
     cliCoverage: "automated"
   },
+  {
+    id: "search-discovery",
+    number: 42,
+    title: "Submit and inspect your site before launch",
+    category: "Growth",
+    priority: "medium",
+    timeEstimate: "30 min",
+    prompt: "Act as a search discoverability engineer doing a production launch closeout. First confirm the real production domain and verify the deployed version is the one I intend to launch. Then verify /robots.txt returns 200, does not block public pages, and points to the production sitemap. Verify /sitemap.xml returns 200, uses absolute production URLs, and includes the homepage plus every important public page. Check important public pages for self-referential canonical URLs, unique titles and meta descriptions, internal links, and no accidental noindex tags or X-Robots-Tag headers. In Google Search Console, use the domain property if available, submit the production sitemap, use URL Inspection for the homepage and high-value changed URLs, and report indexed status, crawl allowed status, Google-selected canonical, user-declared canonical, and last crawl time. Request indexing for high-value new or changed pages when the UI allows it. Start validation for fixed Discovered - currently not indexed or Crawled - currently not indexed buckets when appropriate. For Bing/Microsoft, configure or use IndexNow in production only and submit the sitemap URLs. If Search Console or Bing access is missing, do not pretend this is complete: tell me exactly which property, sitemap URL, and page URLs to verify or submit.",
+    what: "This is the handoff from 'my site has SEO files' to 'search engines have actually been told about the launch.' A sitemap sitting in your repo is not the same thing as Google knowing about the pages, crawling them, and deciding whether to index them.",
+    why: "Prelaunch founders often announce a product and then discover that Google has not crawled the homepage, the new guide pages are only 'discovered,' or the sitemap was never submitted. That turns launch momentum into dead air. This check makes discovery status visible before you start sending people to the site.",
+    steps: [
+      "Use the real production domain, not localhost, preview, or a platform fallback URL.",
+      "Verify robots.txt, sitemap.xml, canonical URLs, internal links, and noindex/X-Robots-Tag on the live production pages.",
+      "Submit the production sitemap in Google Search Console for the domain property, preferably sc-domain:yourdomain.com.",
+      "Inspect the homepage and high-value launch pages in Search Console. Record whether each page is live, crawlable, submitted, discovered, crawled, and indexed.",
+      "Request indexing for high-value new or changed pages when Search Console allows it, and start validation for fixed indexing buckets when appropriate.",
+      "Submit the production sitemap URLs to Bing/Microsoft with IndexNow. Do not submit preview or development URLs."
+    ],
+    redFlags: [
+      "Assuming a page is indexed because it exists on production",
+      "A sitemap exists, but Search Console has never downloaded it",
+      "No verified Search Console property for the real production domain",
+      "Important pages are live but orphaned from nav, footer, homepage, or related pages",
+      "Preview or development domains are submitted to search engines",
+      'Final report says "indexed" when the page was only submitted or requested'
+    ],
+    cliCoverage: "manual_only",
+    whyManual: "Search discovery requires authenticated Search Console/Bing access, production-domain checks, and third-party crawl/index state. The local scanner can verify files and page HTML, but it cannot honestly prove sitemap submission, URL Inspection status, manual indexing requests, or whether Google has indexed a page."
+  },
   {
     id: "feedback",
-    number: 38,
+    number: 43,
     title: "Give users an easy way to tell you what's broken",
     category: "Product & Launch",
     priority: "medium",
@@ -1390,7 +1549,7 @@ var ITEMS_MEDIUM = [
   },
   {
     id: "responsive-actions",
-    number: 39,
+    number: 44,
     title: "Make every action tell the user what's happening",
     category: "Product & Launch",
     priority: "medium",
@@ -1417,7 +1576,7 @@ var ITEMS_MEDIUM = [
   },
   {
     id: "launch-polish",
-    number: 40,
+    number: 45,
     title: "Walk through the whole app one last time",
     category: "Product & Launch",
     priority: "medium",
@@ -1445,7 +1604,7 @@ var ITEMS_MEDIUM = [
   },
   {
     id: "launch-list",
-    number: 41,
+    number: 46,
     title: "Map exactly where your first 100 users will come from",
     category: "Growth",
     priority: "medium",
@@ -1472,14 +1631,14 @@ var ITEMS_MEDIUM = [
   },
   {
     id: "support",
-    number: 42,
+    number: 47,
     title: "Give users a real way to get help",
     category: "Product & Launch",
     priority: "medium",
     timeEstimate: "1 hr",
     prompt: "Act as a customer support systems designer for a tiny early-stage app. Add a simple, real support path that a paying or stuck user can find in under 10 seconds. Requirements: (1) a support email or help link visible from footer, account/settings, checkout/success, receipts, and error states; (2) route support messages somewhere I actually monitor daily; (3) include enough context automatically when possible: user ID, email, current URL, order/report ID, browser, and last error; (4) create canned first replies for payment issue, login/code not arriving, data deletion/export, bug report, and refund request; (5) add a simple SUPPORT.md with where messages land, expected response time during launch week, and refund/escalation rules. Do not add a giant help center. Make the smallest support loop that prevents paying users from feeling abandoned.",
-    what: "Feedback is how users tell you what is broken. Support is how a real person gets help when they are stuck, locked out, charged, confused, or angry. For a vibe-coded launch, this can be one monitored email address \u2014 but it has to be visible and it has to work.",
-    why: "The worst early customer experience is not a bug. It is paying, getting stuck, and finding no human way out. A simple support path turns panic into a conversation and keeps small launch issues from becoming public complaints.",
+    what: "Feedback is how users tell you what is broken. Support is how a real person gets help when they are stuck, locked out, charged, confused, or angry. For an AI-built launch, this can be one monitored email address \u2014 but it has to be visible and it has to work.",
+    why: "The worst early customer experience is not a bug. It is paying, getting stuck, and finding no human way out. A simple support path turns a bad moment into a conversation and keeps small launch issues from becoming public complaints.",
     steps: [
       "Create one support destination you will actually watch during launch week: support@yourdomain.com, a shared inbox, Plain, Crisp, Intercom, HelpScout, or even a monitored Gmail alias.",
       "Put the support link where pain happens: footer, account/settings, checkout success, receipt email, error pages, login/OTP screens, and paid-report pages.",
@@ -1503,7 +1662,7 @@ var ITEMS_MEDIUM = [
 var ITEMS_LOWER = [
   {
     id: "aeo",
-    number: 43,
+    number: 48,
     title: "Make AI assistants able to recommend you",
     category: "Growth",
     priority: "lower",
@@ -1533,7 +1692,7 @@ var ITEMS_LOWER = [
   },
   {
     id: "community",
-    number: 44,
+    number: 49,
     title: "Start a small community space",
     category: "Growth",
     priority: "lower",
@@ -1560,7 +1719,7 @@ var ITEMS_LOWER = [
   },
   {
     id: "iteration",
-    number: 45,
+    number: 50,
     title: "Plan what you'll improve in week 1",
     category: "Growth",
     priority: "lower",
@@ -1587,14 +1746,14 @@ var ITEMS_LOWER = [
   },
   {
     id: "installable-app",
-    number: 46,
+    number: 51,
     title: "Make your app installable on phones",
     category: "Product & Launch",
     priority: "lower",
     timeEstimate: "30 min",
     prompt: "Act as a frontend engineer. Make my web app a proper Progressive Web App (PWA) so phone users can install it to their home screen. Tasks: (1) create a /manifest.json with name, short_name (\u226412 chars), start_url: '/', display: 'standalone', background_color, theme_color matching my brand, and an icons array with at least 192\xD7192 and 512\xD7512 PNGs (generate them from my logo if I don't have them yet \u2014 lossless, transparent background). (2) add <link rel='manifest' href='/manifest.json'> and <meta name='theme-color' content='#yourbrand'> to <head>. (3) generate a proper favicon bundle: favicon.ico (multi-size), favicon.svg, apple-touch-icon.png (180\xD7180), and wire them into <head> with <link rel='icon'> and <link rel='apple-touch-icon'>. (4) verify in Chrome DevTools \u2192 Application \u2192 Manifest that every field validates and the install prompt appears. (5) test on a real phone: open in Safari or Chrome, use Share \u2192 'Add to Home Screen', confirm the app launches full-screen without the browser chrome. Report any warnings from Lighthouse's PWA audit.",
     what: "A tiny /manifest.json plus proper-sized icons lets people add your site to their phone's home screen with one tap. When they launch it, it opens full-screen \u2014 no browser URL bar in the way \u2014 like a real app. Zero app-store submission needed.",
-    why: "Most vibe-coded sites stop at the default favicon and never get installed. Users who add your app to their home screen return two to three times more often than bookmark-only users \u2014 and it's a 30-minute setup to enable it forever. Also closes the subtle credibility gap of a generic browser favicon on your production URL.",
+    why: "Most AI-built sites stop at the default favicon and never get installed. Users who add your app to their home screen return two to three times more often than bookmark-only users \u2014 and it's a 30-minute setup to enable it forever. Also closes the subtle credibility gap of a generic browser favicon on your production URL.",
     steps: [
       "Generate your icon set: at minimum a 512\xD7512 PNG, a 192\xD7192 PNG, a 180\xD7180 apple-touch-icon.png, and a favicon.ico or favicon.svg. Transparent backgrounds.",
       "Create a /manifest.json with your app name, short name (\u226412 chars), start URL, standalone display mode, theme color, and the icons.",
@@ -3883,6 +4042,24 @@ var SCORE_BANDS = [
     goNoGoLabel: "Go"
   }
 ];
+function scoreWithinBand(rawScore, band) {
+  return Math.max(band.minScore, Math.min(band.maxScore, rawScore));
+}
+function severityBandedScore(rawScore, counts) {
+  if (counts.critical > 0) {
+    return Math.min(rawScore, SCORE_BANDS[0].maxScore);
+  }
+  if (counts.high > 0) {
+    return scoreWithinBand(rawScore, SCORE_BANDS[1]);
+  }
+  if (counts.medium > 0) {
+    return scoreWithinBand(rawScore, SCORE_BANDS[2]);
+  }
+  if (counts.lower > 0) {
+    return scoreWithinBand(rawScore, SCORE_BANDS[3]);
+  }
+  return SCORE_BANDS[3].maxScore;
+}
 var SOURCE_SCORE_CAP = {
   url: 88,
   cli: 100,
@@ -4219,13 +4396,14 @@ function prioritizeLaunchFindings(findings, source = "manual", promptBuilder) {
 function scoreFromCounts(counts, source) {
   const weightedPenalty = counts.critical * SEVERITY_WEIGHTS.critical + counts.high * SEVERITY_WEIGHTS.high + counts.medium * SEVERITY_WEIGHTS.medium + counts.lower * SEVERITY_WEIGHTS.lower;
   const rawScore = clampScore(100 - weightedPenalty);
+  const severityScore = severityBandedScore(rawScore, counts);
   const scoreCap = SOURCE_SCORE_CAP[source];
-  const score = Math.min(rawScore, scoreCap);
+  const score = Math.min(severityScore, scoreCap);
   return {
     score,
     rawScore,
     weightedPenalty,
-    coveragePenalty: Math.max(0, rawScore - score)
+    coveragePenalty: Math.max(0, severityScore - score)
   };
 }
 function scoreBandFor(score) {
@@ -4419,8 +4597,8 @@ function printHelp() {
   process.stdout.write(
     `shippingszn v${PKG_VERSION}
 
-Read-only scanner that checks the current project against a small set of
-high-signal launch-readiness items from shippingszn.
+Read-only launch inspector that checks the current project against high-signal
+launch-readiness items from shippingszn.
 
 Usage:
   npx shippingszn@latest [path] [options]
@@ -4436,14 +4614,14 @@ Options:
   -h, --help            Show this help.
   -v, --version         Print version.
 
-This is the FREE preflight. It tells you launch debt exists. It does NOT tell
+This is the FREE inspection. It tells you launch risk exists. It does NOT tell
 you what's broken or how to fix it \u2014 that's gated behind the $49 Launch Fix Kit
-(unlocks full findings + 46-item workbook + paste-ready AI-builder prompts +
-verification steps + red-flag checks). Read-only on disk. Normal runs create a
-locked scan handoff for checkout and send anonymous Wall stats (score, severity
-counts, file count, scanner version \u2014 no project name, no paths, no
-finding-level detail); there is no Wall publish opt-in or opt-out flag. Exit
-code non-zero if any critical findings.
+(unlocks full findings + 51-item workbook + human ship decision + AI-builder
+punch list + verification steps + red-flag checks). Read-only on
+disk. Normal runs create a locked scan handoff for checkout and send anonymous
+Wall stats (score, severity counts, file count, scanner version \u2014 no project
+name, no paths, no finding-level detail); there is no Wall publish opt-in or
+opt-out flag. Exit code non-zero if any critical findings.
 `
   );
 }
@@ -4699,11 +4877,13 @@ ${c.bold("shippingszn")} ${c.dim(`v${PKG_VERSION}`)}
   process.stdout.write(c.dim(`Scanned ${files.length} files.
 
 `));
+  process.stdout.write(`${c.bold("Verdict:")} ${bandColor(c.bold(bandLabel))}
+`);
   process.stdout.write(
-    `${c.bold("Launch Debt Score:")} ${launchReadiness.score}/100  \u2014  ${bandColor(c.bold(bandLabel))}
-
+    `${c.bold("Readiness Score:")} ${launchReadiness.score}/100
 `
   );
+  process.stdout.write(c.dim("Higher is better.\n\n"));
   process.stdout.write(`${c.bold("Findings detected:")}
 `);
   process.stdout.write(`  ${c.red(`${totals.critical} critical`)}
@@ -4746,19 +4926,19 @@ ${c.bold("shippingszn")} ${c.dim(`v${PKG_VERSION}`)}
       if (totals.high > 0) {
         process.stdout.write(
           c.dim(
-            "High and medium launch debt can expose trust gaps, break conversion moments, or make the project feel unfinished.\n\n"
+            "High and medium launch gaps can expose trust gaps, break conversion moments, or make the project feel unfinished.\n\n"
           )
         );
       } else if (totals.medium > 0) {
         process.stdout.write(
           c.dim(
-            "Medium launch debt usually will not crash the app, but it can make users hesitate, miss conversion moments, or make the project feel unfinished.\n\n"
+            "Medium launch gaps usually will not crash the app, but they can make users hesitate, miss conversion moments, or make the project feel unfinished.\n\n"
           )
         );
       } else {
         process.stdout.write(
           c.dim(
-            "Lower launch debt usually will not break the app, but it can still make the project feel rough or unfinished.\n\n"
+            "Lower launch gaps usually will not break the app, but they can still make the project feel rough or unfinished.\n\n"
           )
         );
       }
@@ -4778,7 +4958,7 @@ ${c.bold("shippingszn")} ${c.dim(`v${PKG_VERSION}`)}
 `);
       process.stdout.write(
         c.dim(
-          `  Includes the ${totalFindings} specific ${pluralize(totalFindings, "finding")}, file evidence, and AI-builder fix prompts.
+          `  Includes the ${totalFindings} specific ${pluralize(totalFindings, "finding")}, file evidence, human launch decision, and AI-builder punch list.
 
 `
         )

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "shippingszn",
-  "version": "0.9.6",
-  "description": "Read-only CLI scanner that checks a project for common pre-launch issues from the shippingszn.com launch checklist.",
+  "version": "0.9.7",
+  "description": "Read-only launch inspector for AI-built apps.",
   "license": "MIT",
   "type": "module",
   "bin": {
@@ -15,6 +15,7 @@
   "keywords": [
     "cli",
     "launch",
+    "launch-inspector",
     "checklist",
     "preflight",
     "security",