Two intake questions answered, so I'll proceed straight to inspection. **Coverage note:** You've shared the manifest plus your two most safety-critical files (auth + billing) — good instinct, since these are exactly where H1 requires focus. But this is a small sample of what's presumably a larger Next.js app. Treat this as a partial audit of the highest-risk surface, not a full-codebase clearance. No entry point, API routes, Firestore rules, or webhook handlers were provided — those need a follow-up pass before ship. No injection-signal text detected in the submitted code/comments. ``` VIBE-CODE HANDOFF INSPECTOR™ — LAUNCH REPORT ──────────────────────────────────────────── App: PetCare Pro (Next.js/Firebase/Stripe SaaS) · Stack: Next.js 14, Firebase 10, Stripe 14 Coverage: SAMPLED — 3 files (package.json, src/auth.js, src/billing.js). Entry points, API routes, Firestore rules, and webhook handlers NOT reviewed. LAUNCH VERDICT: DO-NOT-SHIP Two of the three files you sent contain critical, money- and auth-path failures on their own — a live Stripe secret key committed to source, and a login function that silently reports success when authentication actually fails. Either one alone is a DO-NOT-SHIP condition; together they compound. Fix these before touching anything else, then send the rest of the codebase for a full pass. FINDINGS (confidence ≥70) F1 [H2 · CRITICAL · conf 98] Live Stripe secret key hardcoded in src/billing.js:2 What this means for you: Your real, live-mode Stripe key (`sk_live_...`) is sitting in plain text in your source code, not an environment variable. If ignored: Anyone with repo access — including it being pushed to GitHub, a contractor, or leaked via a build artifact — can create charges, issue refunds, or pull customer payment data using your live account. This is a "someone drains your Stripe balance tonight" bug, not a someday bug. Fix: Revoke this key in the Stripe dashboard immediately (it must be treated as burned the moment it touched a repo). Generate a new key, store it in `.env.local` / Vercel environment variables, and load it via `process.env.STRIPE_SECRET_KEY`. Add `.env*` to `.gitignore` if not already there. F2 [H6 · CRITICAL · conf 95] Auth failures silently reported as success in src/auth.js:8-9 What this means for you: When `signInWithEmailAndPassword` throws (wrong password, disabled account, network error — anything), the catch block returns `{ success: true, fakeAuth: true }` instead of the error. Calling code that checks `success` will treat every failed login as a successful one. If ignored: This is a de facto authentication bypass. Depending on how the caller uses this return value, a wrong password could still route a user into an authenticated session state, or at minimum silently swallow real login problems (locked accounts, wrong credentials) and show users a broken app instead of a clear error. For an app storing customer/billing data, this is not shippable. Fix: Remove the fallback object entirely. Re-throw or return a proper error shape, e.g. `return { success: false, error: error.message };`, and make sure calling code actually branches on `success`. F3 [H8 · MAJOR · conf 85] Full user credential object logged to console in src/auth.js:5 What this means for you: `console.log("Logged in user:", userCredential.user)` prints the entire Firebase user object — which can include email, UID, provider tokens, and metadata — to console/server logs on every login. If ignored: In production this data lands in Vercel's function logs (and any log aggregator you pipe them to), creating an unnecessary PII trail and, depending on log retention/access policy, a compliance exposure for customer data. Fix: Remove the log line, or log only a non-identifying signal like `userCredential.user.uid` behind a debug flag that's off in production. F4 [H5/H9 · CRITICAL · conf 88] `chargeCustomer` has no authorization or input validation in src/billing.js What this means for you: The function takes `amount` and `customerId` and charges Stripe immediately — there's no check that the caller is authenticated, that the caller owns/is-permitted-to-bill that `customerId`, or that `amount` is a sane, expected value. If ignored: If this function is reachable from any API route (even indirectly), it's a path for one clinic's staff account — or an unauthenticated request, if the route itself lacks auth middleware — to charge an arbitrary amount to an arbitrary customer's saved card. This is the kind of bug that shows up as a support ticket titled "why was I charged $9,000." Fix: Before calling Stripe, verify the requesting user's session/role and confirm they're authorized for that specific `customerId` (e.g., check a Firestore ownership record). Validate `amount` is a positive integer within an expected range for your billing plans. F5 [H6 · MAJOR · conf 75] No error handling around the Stripe charge call in src/billing.js What this means for you: `stripe.charges.create(...)` isn't wrapped in a try/catch. A declined card, network blip, or Stripe API error will throw an unhandled exception. If ignored: Best case, the user sees a generic 500 with no useful message. Worse case, depending on how this is invoked, an unhandled rejection could crash a serverless function mid-request, leaving billing state ambiguous (did the vet clinic get paid or not?). Fix: Wrap the call in try/catch, log the Stripe error server-side (without leaking it to the client), and return a clear "payment failed" response the UI can act on. LINKED RISKS F1 ⇄ F4 — This is the combination that matters most: the leaked live key (F1) means the write-access needed to abuse Stripe already exists outside your app, and F4 means even *inside* your app there's no gate stopping arbitrary charges. Fixing only one of these still leaves a real path to financial loss. NEEDS DEVELOPER CONFIRMATION (confidence <70) None — all findings in the sampled files verified at ≥75 confidence. CLEAN CHECKS H1: `getAuth`, `signInWithEmailAndPassword` (Firebase Auth) and `stripe.charges.create` (Stripe) are real methods in their respective SDKs — no invented interfaces detected. Note: `charges.create` is Stripe's legacy Charges API; new integrations are generally steered toward PaymentIntents, which handle SCA/3DS better — worth a look, not a defect. H3: None detected in sampled files — no phantom or mismatched-version dependencies visible in package.json against the two files reviewed. Not yet checked against the full codebase. H4/H7/H9 (rate limiting, auth on admin surfaces): UNVERIFIED — no API routes, admin pages, or duplicate-logic files were included in this sample. FIX ORDER (do these in sequence) 1. Revoke the exposed Stripe key now, regardless of anything else (F1). 2. Fix the auth fake-success fallback (F2) — this affects every login while it's live. 3. Add authorization + input validation to chargeCustomer (F4), then wrap it in proper error handling (F5). 4. Remove the credential console.log (F3). 5. Re-run this inspection against your full codebase — specifically your API routes, Firestore security rules, and Stripe webhook handler — before deploying to Vercel. ──────────────────────────────────────────── ``` One thing outside the HANDOFF checklist but worth flagging directly: neither file you shared is the *webhook* handler, and for a billing app that's usually where the sneakiest AI-generated bugs live (signature verification skipped, duplicate charge processing on retries). If you have that file, send it next — it's higher priority than most other files in the app.