# Site Flow (Listing & Management)
 
 ## Purpose
 Provide the tenant-facing list and management surface for all sites, including creation, navigation to settings/integrations, viewing, editing, and deletion. This is the primary entry point before drilling into site dashboard or settings.
 
 ## Code Locations (exact paths)
 - Page: `frontend/src/pages/Sites/Manage.tsx` (titled “Site Management”)
 - API: `frontend/src/services/api` (`fetchAPI` for sites collection and integration checks)
 - UI: `frontend/src/components/ui/{card,button,badge}`, `frontend/src/components/sites/SiteTypeBadge`, `frontend/src/components/ui/badge/Badge`
 
 ## High-Level Responsibilities
 - List all account sites with status, type, hosting, and integration hints.
 - Offer actions per site: view, edit, settings, delete, manage WordPress integration.
 - Provide entry point for creating new sites (routes to builder).
 
 ## Detailed Behavior
 - On mount: `loadSites()` → GET `/v1/auth/sites/`; if hosting_type is `wordpress`, performs an additional call to `/v1/integration/integrations/?site={id}&platform=wordpress` to flag `has_wordpress_integration`.
 - Renders grid of cards:
   - Shows name, slug, active badge, hosting badge, site type, optional WP integration button (“Connect WordPress” / “Manage Integration”).
   - Footer actions: View (`/sites/{id}`), Edit (`/sites/{id}/edit`), Settings (`/sites/{id}/settings`), Delete (DELETE `/v1/auth/sites/{id}/` after confirm).
 - Empty state: if no sites, shows CTA to create first site (`/sites/builder`).
 - Create button in header also routes to `/sites/builder`.
 
 ## Data Structures / Models Involved (no code)
 - Site list DTO: id, name, slug, site_type, hosting_type, status, is_active, page_count, integration_count.
 - Integration probe response: `results` length indicates WP connection presence.
 
 ## Execution Flow
 - `useEffect` → `loadSites` → set `sites`.
 - Per-site integration check executed inside `Promise.all` when hosting_type is `wordpress`.
 - Action buttons call navigation or delete; delete triggers reload.
 
 ## Cross-Module Interactions
 - Integrations tab reachable via settings link; integration existence probed via integration module API.
 - Builder route (`/sites/builder`) ties into site creation flow (outside this component).
 
 ## State Transitions
 - `loading` gates initial render; after deletion, reload resets state.
 - WP integration flag stored per site for button labeling.
 
 ## Error Handling
 - Load errors show toast (`Failed to load sites`); delete errors show toast.
 - Integration probe failures fall back to `has_wordpress_integration: false` without blocking list.
 
 ## Tenancy Rules
 - Backend scopes `/v1/auth/sites/` to current account; page does not switch tenants.
 
 ## Billing Rules (if applicable)
 - None on this page; plan limits enforced server-side when creating/managing sites.
 
 ## Background Tasks / Schedulers (if applicable)
 - None; no polling.
 
 ## Key Design Considerations
 - Integration probe is conditional to reduce extra calls for non-WordPress hosting.
 - Delete confirmation prevents accidental site removal.
 
 ## How Developers Should Work With This Module
 - When adding new hosting types or platforms, adjust integration probe logic and `SiteTypeBadge`.
 - Keep routes aligned with `App.tsx`; ensure permissions enforced server-side for edit/delete.
 - If adding pagination/filtering, wire through `fetchAPI` params and preserve integration detection per page.