walphi/auro-app

1. This repo is a multi-surface AI real-estate platform, not a single app. The production runtime is centered on Netlify serverless functions, a Supabase-backed data layer, and external AI/communications services. The root also contains extensive operational scripts and diagnostics, but those are support tooling rather than user-facing runtime.

2. There are two main client surfaces:

- src/ is the root React app, which includes a dashboard plus marketing pages.

- sites/ is a separate Vite React app for generated “agent sites” and their section-based rendering system.

Both are static frontends that consume APIs and content from the backend layer.

3. The backend is mostly in netlify/functions/ with one edge function in netlify/edge-functions/. These handlers expose the product’s API surface: WhatsApp, VAPI, RAG, listings sync, OCR, site generation, CRM sync, image proxying, booking notifications, and tenant/agent site lookup. This is the primary boundary where all external requests enter the system.

4. Core AI orchestration lives under lib/. Important subsystems include:

- lib/gemini.ts for model access.

- lib/aiBuilder/ for generating agent sites/content.

- lib/rag/ for embeddings, prompts, and retrieval helpers.

- lib/agentLogic.ts, lib/crmRouter.ts, lib/notificationOrchestrator.ts, and tenant config helpers for routing requests across tenants, channels, and downstream actions.

These modules are shared by the Netlify handlers rather than serving directly.

5. The main conversational flow is channel-driven. Incoming WhatsApp or VAPI events hit their respective Netlify functions, which then:

- identify tenant/agent context,

- fetch relevant knowledge or listing data,

- call Gemini or other tools,

- persist lead/session state,

- and respond back through Twilio/VAPI.

This is the most important request/response loop in the system.

6. Retrieval-Augmented Generation is a distinct subsystem. It has ingestion, learning, query, delete, and embedding-processing handlers (rag-ingest, rag-learn, rag-query, rag-delete, process-embeddings) plus supporting SQL/schema files. The knowledge base is tenant-aware and appears to index project/listing documents, campaign history, and other real-estate content used by the assistants.

7. CRM and lead management form another boundary. Functions such as update-lead, crm sync handlers, HubSpot OAuth/webhook handlers, and Bitrix webhooks connect external sales systems to the platform. The data model tracks leads, intents, bookings, and agent activity so conversational events can be mirrored into CRM workflows.

8. Real-estate listings and media are handled as a separate ingestion/sync pipeline. There are functions for scraping listings and site style, syncing listings, formatting images, proxying images, and updating listing records. This pipeline feeds both the AI assistants and the generated sites, rather than being just a content feed.

9. Agent-site generation is its own product subdomain. The backend can build or rebuild a site from structured data and templates, while the sites/ app renders the final public-facing experience with reusable sections like hero, services, listings, testimonials, and contact. The generated site content is stored and later served through lookup functions such as get-agent-site.

10. Persistence is primarily Supabase/Postgres. The repo includes both supabase/migrations/ and standalone sql/ scripts, indicating a mix of formal migrations and one-off schema/data fixes. The schema covers tenants, profiles, projects, RAG chunks, leads, bookings, agent configs, and site-related tables, which makes tenancy a first-class architectural boundary.

11. Operationally, the repository includes many scripts for validation, backfills, simulation, image cleanup, DB checks, and webhook testing. These are important for maintenance and verification, but they sit outside the runtime request path.

12. Deployment is Netlify-centric. The repo ships static frontend builds plus serverless functions, with environment variables for Gemini, Twilio, and optional VAPI verification. External dependencies are therefore not embedded services but runtime integrations orchestrated at the function layer.