careonroad/careonroad-application

Purpose and Entry Point

CareOnRoad is a Next.js prototype for roadside vehicle care, with separate customer and mechanic experiences. The browser entry route is app/page.tsx; global document shell and styling originate in app/layout.tsx and app/globals.css.

Role Selection and App Shells

components/role-picker.tsx selects the user-facing mode, routing control into one of two client-side application shells:

• Customer shell: components/care/care-app.tsx

• Mechanic shell: components/mechanic/mechanic-app.tsx

These shells own screen selection and assemble persistent navigation, headers, and role-specific interaction surfaces.

Customer Care Application

The customer flow centers on vehicle ownership, appointments, maintenance, roadside rescue, and history. Its primary navigation/screens are:

• components/care/screens/home-screen.tsx

• components/care/screens/schedule-screen.tsx

• components/care/screens/rescue-screen.tsx

• components/care/screens/vehicles-screen.tsx

• components/care/screens/history-screen.tsx

Reusable domain cards render bookings, maintenance status, mechanics, and vehicles through components/care/booking-card.tsx, components/care/maintenance-card.tsx, and components/care/vehicle-card.tsx.

Customer State and AI Boundary

components/care/app-context.tsx is the customer-side state boundary for sharing application data/actions across screens and components. Booking cancellation is encapsulated by components/care/cancel-appointment-modal.tsx; emergency escalation is surfaced through components/care/sos-button.tsx.

The chat interaction is isolated in components/care/ai-chatbox.tsx and backed by local simulated AI behavior in lib/mock-ai.ts; no real AI provider or backend integration is evident.

Mechanic Operations Application

The mechanic shell provides a separate operational workflow for dashboard, job queue, job details, scheduling, and profile:

• components/mechanic/screens/mechanic-dashboard.tsx

• components/mechanic/screens/mechanic-jobs-screen.tsx

• components/mechanic/screens/mechanic-job-detail.tsx

• components/mechanic/screens/mechanic-schedule.tsx

Job progression/update interactions are bounded in components/mechanic/forms/job-update-form.tsx, while dispatch/job/customer/earnings summaries are represented by components under components/mechanic/cards/.

Mechanic State and Data Contracts

components/mechanic/mechanic-app-context.tsx is the mechanic-side shared-state boundary. Mechanic-domain interfaces are defined in lib/mechanic-types.ts; fixture records are supplied by lib/mechanic-mock-data.ts. This separates mechanic UI workflows from eventual live dispatch, customer, and earnings services.

Data, Runtime, and Infrastructure

The project runs on Next.js with TypeScript, using the App Router conventions in app/. Current domain data is local/mock rather than persisted or fetched remotely: lib/mock-data.ts, lib/mechanic-mock-data.ts, and lib/mock-ai.ts. Shared customer types reside in lib/types.ts.

Deployment is expected through the v0-linked workflow described in README.md, where merges to main automatically deploy. No API routes, database client, authentication layer, payment provider, maps/geolocation SDK, or external service client appears in the repository tree.