ogaradinest/wash_agent

1. Overall shape

- This repo is a two-tier application: a Python backend in backend/ and a React frontend in frontend/.

- The frontend is the primary user interface; the backend appears to provide the API and server-side logic behind it.

2. Frontend application shell

- The frontend is a single-page React app built with CRACO (frontend/craco.config.js) and styled with Tailwind CSS (tailwind.config.js, postcss.config.js).

- Entry points are frontend/src/index.js and frontend/src/App.js, with global styling in App.css and index.css.

3. UI and page structure

- The main app surface is organized into pages: LandingPage.jsx and Dashboard.jsx.

- Reusable feature components include AICallDemo.jsx and CallLogDetail.jsx, suggesting the app centers on an AI call/demo workflow plus call history or inspection.

- The large frontend/src/components/ui/ folder is a design-system layer of reusable controls (buttons, dialogs, tables, tabs, toast, etc.), likely built on a component library pattern.

4. Frontend data flow

- The UI likely follows a simple flow: landing page entry → dashboard interaction → detailed call views and notifications.

- Shared client-side helpers live in frontend/src/lib/utils.js, and transient UI state/feedback is handled via toast hooks in frontend/src/hooks/use-toast.js.

5. Frontend development-time extensions

- frontend/plugins/health-check/ adds custom health endpoints and a webpack health plugin, indicating the frontend dev server exposes operational checks beyond the normal app bundle.

- frontend/plugins/visual-edits/ contains Babel/dev-server plugins that support a visual editing workflow or metadata injection during development, so the frontend build is not just static bundling but also developer tooling-aware.

6. Backend service boundary

- backend/server.py is the runtime entry for the Python service.

- backend/requirements.txt defines the backend runtime dependencies, and backend_test.py indicates direct testing of backend behavior.

- The backend is the clear boundary for server-side APIs, health checks, and any AI/call-related logic that the frontend consumes.

7. Testing and validation

- There are separate repo-level test artifacts: backend_test.py, tests/, and test_reports/.

- The presence of iteration-based JSON reports suggests repeated evaluation runs or benchmark-style validation, not just ad hoc unit tests.

8. Deployment pipeline

- .github/workflows/deploy.yml is the primary CI/CD path and likely builds the frontend, validates the backend, and publishes the application.

- This implies a deployment boundary where the frontend build artifacts and backend service are promoted together or in coordinated steps.

9. Project guidance and product context

- memory/PRD.md and design_guidelines.json provide product/design constraints that influence implementation but are not runtime components.

- They likely define the intended behavior and UI consistency for the app’s main flows.

10. What to draw in an architecture diagram

- Show a browser client talking to a React SPA.

- Show the SPA depending on a Python API server for dynamic data/actions.

- Add a development-only tooling lane for health checks and visual-edit plugins on the frontend.

- Add a CI/CD lane from GitHub Actions into deployment, with tests and reports as quality gates.