LeadScout — safety audit done + exact "make it sellable" fix plan (2026-07-11)

ACTIVE MODES (re-invoke first in the fresh session)

• fable-mode skill (five-gate discipline — this is a security + live-data migration)
• base44-workflow skill (safe read/test/edit/deploy + the RLS shorthand trap + functions-deploy-LAST)
• ponytail full (smallest change that fixes each thing)
• Safety playbooks: reference/vibe-coding-safety-net.md + reference/fable-mode-money-path-audit.md

The app (confirmed by name + id)

• LeadScout 6a46ad7a89bffa371e7637da — live https://alluring-scout-your-leads.base44.app — sandbox app, git_remote_source: s3.
• Backend functions: scan-campaign, verify-leads, push-to-ghl. Entities: Campaign, Lead, ScrapeJob, UsageEvent, WorkspaceSettings, Invite (+ User).
• IGNORE LeadScout Copy 6a46b10699d9700eef138ce8 (Sondra's pre-existing copy — untouched, confirmed alive).
• Sandbox restore point from today: checkpoint 6a52ddc053d0beaf82471882 ("before city-scan + campaign-detail fixes").
• Working folders (local scaffolds, throwaway): PROJECTS/LeadScout DFY/sandbox-work/ (scaffold; base44/functions/ pulled incl. edited scan-campaign/entry.ts), PROJECTS/LeadScout DFY/clone/ (ejected frontend + entities, node_modules), scratch/leadscout-app-definition.json, scratch/leadscout-fns/.js (all 3 fn sources).

---

PART A — already SHIPPED + LIVE + verified this session (the 3 UX fixes). DO NOT redo.

Goal was "fix 3 broken things." All done, deployed to the master, verified by a real run.

1. Campaign-detail page — new src/pages/CampaignDetail.jsx + route /campaigns/:id in App.jsx. Opens a campaign → its leads (filtered), scan status, counts (Scanned/No-website/Social-only/Leads-saved), Launch-scan + Verify + Push-to-GHL + Export scoped to it.
2. Dashboard clickable — Home.jsx stat tiles navigate (Campaigns/Leads/No-Website→/leads?site=no_website/Social-Only); recent-campaign rows open detail. StatCard.jsx gained optional onClick. Leads.jsx reads ?site=/?campaign= initial filters. Campaigns.jsx rows are clickable. AppLayout.jsx nav stays active on /campaigns/*.
3. City / County / Zip choice — Campaigns.jsx New-Campaign form has a 3-way toggle. Entity Campaign changed: zip_codes now OPTIONAL (required is [name, niche]), added search_areas (array) + location_mode (enum zips/city/county) — back-compatible (old zip campaigns still open). scan-campaign builds the Outscraper query from search_areas → else zip_codes → else location_label; stamps zip only when the area is a real 5-digit zip.

• Proven: created a real CITY campaign "TEST - Stuart FL florists" (6a52df17f052b16b0860363f, no zips, limit 3) → scan returned 3 real Stuart florists, correct city + real zips, scored. Live bundle = index-BjIA-6jH.js, master id baked in, all change-strings present. Entities intact (6), all 3 functions re-registered. Eject copy 6a52e0b6… deleted.
• Data state: 3 campaigns / 157 leads = your original 154 (Jupiter Plumbing 21 + Palm Beach Electrical 133) + the 3 test florists. created_by: campaigns = sondra (filter-proven), leads = none. The "TEST - Stuart FL florists" campaign + its 3 leads are safe to delete (mine, not real prospects) — left in place as working proof; delete on Sondra's word.

---

PART B — THE JOB FOR THE FRESH SESSION: make LeadScout a SELLABLE, clone-ready template.

Sondra: "I have to be able to sell this... make sure everything is working." She chose HANDOFF → fresh session for this because it's a security + live-data migration on her 154 real leads and this session crossed her 250K freshness line.

Verdict from the /app-safety-check (why it's NOT sellable yet) — 🔴 DO NOT SELL YET

Two CRITICAL holes, both confirmed by actually running them:

1. 🔴 World-readable data, no login. public_settings = "public_without_login" + RLS is null on ALL 6 entities. Anonymous GET to .../entities/Campaign and .../entities/Lead returned 200 + full records (pulled a real business name/phone/address with zero auth). Every buyer's leads would be public.
2. 🔴 Paid functions open to anonymous callers. Anon POST to push-to-ghl + verify-leads got inside the function (400 "No leads selected" = past the door). Real IDs → burns Outscraper/Firecrawl/GHL credits + mutates others' leads. All 3 functions run base44.asServiceRole with no auth.me() gate and no ownership check.
3. 🟠 SHOULD-fix: caps are decorative. WorkspaceSettings (fields daily_outscraper_cap, daily_firecrawl_cap, max_results_per_scan) is only read/written by SettingsPage.jsx. UsageEvent (kind, units) is never written. No function checks a cap → unlimited spend.
4. 🟠 No Privacy/Terms page (collects business contact data + pushes to a CRM). Pages have no /privacy.
5. is_remixable = False — must be turned ON to clone/sell (do LAST).

• Already safe: admin is role-based (user.role === 'admin', first-signup-is-admin → cloner becomes their own admin; no hardcoded email); no Sondra branding in code; functions fail gracefully when a key is missing; secrets are app-level and DON'T travel to clones (buyers add their own keys → buyers never spend Sondra's money).

Load-bearing facts discovered (these shape the fix — don't re-derive):

• created_by is a SYSTEM field: honored on create, IMMUTABLE on update (proven: updating a real lead's created_by → filter count 0→0). So you cannot backfill the 157 leads' owner via created_by.
• Custom fields ARE updatable. → Use a custom owner_email field on Lead for ownership; backfill it via update.
• Campaigns already carry created_by = sondraverva@gmail.com (filter-proven) → they can use created_by directly.
• hide_entity_created_by = False. base44 secrets list = OUTSCRAPER_API_KEY, FIRECRAWL_API_KEY, GHL_API_KEY, GHL_LOCATION_ID (all app secrets).

THE FIX — ordered, safe sequence (checkpoint first!)

1. npx base44 sandbox checkpoint --name "before sellable-security fixes".
2. Require login — flip public_settings off public_without_login (try npx base44 auth …; if not CLI-exposed, Sondra toggles "require login" in the builder). Verify: anon GET /entities/Lead → 401.
3. Add owner_email (string) to Lead (sandbox edit base44/entities/Lead.jsonc, syncs live). Add it to ScrapeJob + UsageEvent too if you scope those.
4. Fix the 3 functions (base44/functions/*/entry.ts, they're pulled in sandbox-work):

• Top of each: const me = await base44.auth.me().catch(()=>null); if (!me) return Response.json({error:"Sign in required"},{status:401});
• scan-campaign: require campaign.created_by === me.email || me.role === "admin"; on each Lead.create add owner_email: campaign.created_by.
• verify-leads / push-to-ghl: for each lead require lead.owner_email === me.email || me.role === "admin" before acting.
• Wire caps: read the owner's WorkspaceSettings, count today's UsageEvent, block when over daily_outscraper_cap/daily_firecrawl_cap, and write a UsageEvent per run (kind = outscraper/firecrawl/ghl, units = count). Respect max_results_per_scan.
• Keep using base44.asServiceRole for the writes (it bypasses RLS by design) — identity/authz is the me check above.

1. Backfill the 157 existing leads' owner: exec loop — for each lead, Lead.update(id, { owner_email: <its campaign's created_by> }) (campaign owner = sondra for all current data). Custom field → update works.
2. Granular RLS (the ENFORCED form — rls, not row_level_security) on every data entity, sandbox-editing each .jsonc:

• Campaign: read/update/delete {created_by:"{{user.email}}"}, create {created_by:"{{user.email}}"}. Add an admin-sees-all clause if the platform supports OR-ing role==admin.
• Lead: read/update/delete {data.owner_email:"{{user.email}}"}; block anon create (users never create leads directly — only the service-role function does, which bypasses RLS).
• ScrapeJob, UsageEvent, WorkspaceSettings, Invite: owner/admin-scoped (settings + invites are created by the user via UI → created_by works).

1. Publish (base44-workflow §6): sandbox edits already synced entities → eject master → VITE_BASE44_APP_ID=6a46ad7a89bffa371e7637da npm run build → verify bundle has master id + no copy id → site deploy with base44/entities set aside → functions deploy LAST (site deploy wipes the fn registry). Delete the eject "Copy".
2. PROVE it (the DFY gate) with 2 real accounts (use Google login — email OTP was undeliverable + Turnstile blocks automated signup on this platform): (a) anon GET /entities/Lead → 401; (b) anon POST to each function → 401; (c) account B's dashboard empty + B cannot read A's campaign/lead by URL or API; (d) B cannot verify/push A's leads. Sondra (admin) still sees her 157.
3. Only then: turn is_remixable ON + write NEW-OWNER-SHEET.md (buyer adds their own OUTSCRAPER/FIRECRAWL/GHL secrets; first signup = admin; publish once; functions re-register on their first builder publish).
4. Add a /privacy page (pull from reference_canonical_legal_docs / context/legal/ — entity is a lead tool, not health data).

Definition of done (Gate 1 — verify, don't assert)

A stranger who clones LeadScout: logs in (becomes admin), sees ONLY their own campaigns/leads, the internet can't read the data API, anon can't fire the paid functions, caps are enforced, and the 3 UX fixes + full scan→website-check→score→push path all work — proven by running it with two accounts.

---

Housekeeping / uncommitted

• The 3 UX fixes are LIVE on Base44 (platform, not git). Local working folders under PROJECTS/LeadScout DFY/ are scaffolds (heavy node_modules) — not worth committing beyond this handoff + fn source.
• Workspace had many pre-existing modified files at session start (NOT mine) — left untouched; do not git add -A.
• After the fix ships: run /app-safety-check again to confirm 🟢, then update the CEO Dashboard LeadScout card + wiki/projects/base44-apps.md.