Skip to content

Application Overview

Purpose

This document provides a code-based overview of the current gmpro-49 repository. It is based on the implementation in the app, Supabase Edge Functions, Cloudflare Workers, and PBX/Twilio integration files rather than earlier aspirational docs.

System Summary

The product is a CRM and operations platform for auto glass workflows. The current build centers on: - high-volume lead and contact management - a three-panel Message Center for SMS, calls, follow-ups, and AI workflows - broadcast/campaign creation and campaign-lead operations - sales-sheet, reporting, jobs, and admin tools - hybrid telephony using both Twilio and PBX/FreePBX assets - Cloudflare AI orchestration for extraction, response generation, and intent evaluation

Runtime Topology

  • Frontend: Vite + React + TypeScript
  • Data and application backend: Supabase Postgres + Edge Functions
  • Client state/query layer: TanStack Query
  • UI stack: Tailwind, shadcn/Radix, Ant Design for shared table infrastructure
  • AI orchestration: Cloudflare Workers (ai-runner, ai-agent)
  • Telephony: Twilio-heavy messaging path with PBX click-to-call and webhook-side integrations

UX Surface Map

Routes in src/App.tsx define the real primary surfaces: - / and /message-center: unified communication workspace - /leads: contact management with classic and gated “new” UI modes - /contact-search, /campaign-intelligence, /business-rules: newer gated surfaces - /broadcasts, /broadcasts/:campaignId/leads, /broadcast-analytics - /sales-sheet - /jobs, /work-orders/*, /field-sales - /admin, /settings, /employees - reporting routes for acquired interaction and auditor workflows

Maturity Assessment

Production-leaning areas

  • Message Center
  • Leads/contact management
  • campaign CRUD and campaign-lead operational flows
  • admin AI settings and prompt management
  • follow-up categorization and realtime UI updates

Mixed or partially complete areas

  • Broadcast Analytics: KPIs are real, but charts and funnel logic are still partly mocked/heuristic
  • Cloudflare AI: implemented and wired, but operationally split across Workers, Supabase callbacks, and prompt KV
  • Telephony: hybrid and operational, but not yet a single-provider end state

Clearly placeholder/demo-heavy areas

  • Jobs: current page still depends on mockJobs and in-memory drag/drop state
  • Field Sales: current page is UI-forward and not yet backed by the same level of server-side workflow depth as Message Center or Leads

Core Architectural Patterns

  • Frontend pages are thin route shells over hooks plus module-specific components
  • Supabase Edge Functions are the primary application service layer
  • shared Deno helpers under supabase/functions/_shared centralize DB access and utility behavior
  • Cloudflare ai-runner orchestrates context fetch + agent fanout, while ai-agent owns direct model execution
  • AI writes back into Supabase through agent callback/update functions instead of mutating frontend state directly

Major Domain Areas

Contact and lead management

  • Lead search, filtering, counts, vehicles, addresses, opportunities, phones, and billing-opportunity data
  • heavy dependency on RPC-backed search and summary flows

Message Center

  • thread list, thread detail, context panel, mobile view, follow-up actions, voicemail, send-later, file send, OCR-assisted image extraction

Broadcasts

  • wizard-based campaign creation/editing
  • campaign-lead search, send, delivery status, metrics

AI

  • no-intent and yes-intent decisions
  • lead, vehicle, and summary extraction
  • admin-managed prompts backed by Cloudflare KV plus Supabase draft storage

Telephony

  • inbound/outbound SMS via Twilio-backed handlers
  • PBX click-to-call path through gm-call.php and FreePBX dialplan overrides
  • thread-level call locking and activity tracking in Supabase

Operational Risks

  • Telephony architecture is split between Twilio and PBX conventions, which raises integration and ownership complexity
  • Some PBX and deployment assets contain environment-specific values and should be treated as operational configuration, not portable defaults
  • Edge Function inventory is very large and organically grown; ownership boundaries are mostly encoded by naming rather than a formal service map
  • Several routes and features depend on nontrivial enum state and provider bootstrapping, which can make failures look like UI bugs when they are initialization/data-contract issues

Spec Set