# CI/CD Pipeline
 
 ## Purpose
 Document the build-and-deploy sequence using the artifacts present in the repo. No CI config is versioned here; this describes the expected pipeline based on Dockerfiles and compose.
 
 ## Code Locations (exact paths)
 - Compose stack definition: `docker-compose.app.yml`
 - Backend image definition: `backend/Dockerfile`
 - Frontend image definition: `frontend/Dockerfile` (production build via Caddy)
 - Backend config: `backend/igny8_core/settings.py`
 
 ## High-Level Responsibilities
 - Build backend and frontend images from repo sources.
 - Push images to registry (external step, not defined here).
 - Deploy via `docker-compose.app.yml` consuming those images on the target host/Portainer.
 
 ## Detailed Behavior
 - Build steps (as indicated in compose comments):
   - Backend: `docker build -t igny8-backend:latest -f backend/Dockerfile backend`
   - Frontend app: `docker build -t igny8-frontend-dev:latest -f frontend/Dockerfile.dev frontend`
   - Marketing: `docker build -t igny8-marketing-dev:latest -f frontend/Dockerfile.marketing.dev frontend`
   - Sites renderer: `docker build -t igny8-sites-dev:latest -f sites/Dockerfile.dev sites`
 - Deploy steps:
   - Ensure external infra stack (Postgres/Redis/network `igny8_net`) is running.
   - Pull/receive built images on target.
   - Run `docker compose -f docker-compose.app.yml -p igny8-app up -d`.
 - Healthcheck: backend service health gated by `/api/v1/system/status/`; frontend depends_on backend health.
 - No automated migrations are defined in compose; run `python manage.py migrate` inside backend container before switching traffic if schema changes are present.
 
 ## Data Structures / Models Involved (no code)
 - None; pipeline operates on container images.
 
 ## Execution Flow
 - CI: build images → (optional tests not defined here) → push to registry.
 - CD: pull images on host → `docker compose up -d` using new tags → healthcheck ensures backend ready.
 
 ## Cross-Module Interactions
 - Celery worker/beat use the same backend image; ensure it is rebuilt alongside backend changes.
 
 ## State Transitions (if applicable)
 - Service rollout occurs when new containers start; existing volumes (code mounts in compose) mean host filesystem is source of truth in current compose.
 
 ## Error Handling
 - Build failures visible during `docker build`.
 - Deploy failures captured via Docker/Portainer logs; unhealthy backend blocks dependent services.
 
 ## Tenancy Rules
 - Not altered by CI/CD; enforced at runtime by application.
 
 ## Billing Rules (if applicable)
 - None in pipeline.
 
 ## Background Tasks / Schedulers (if applicable)
 - Celery beat/worker containers start via compose; ensure images include latest task code.
 
 ## Key Design Considerations
 - Current compose uses local bind mounts (`/data/app/igny8/...`) which expect code present on host; in an immutable-image pipeline, remove bind mounts and bake code into images instead.
 - External infra stack separation requires coordination to ensure DB/Redis available during deploy.
 
 ## How Developers Should Work With This Module
 - If introducing automated CI, codify the build steps above and add migrations/test stages.
 - When changing service names or ports, update compose and healthcheck references consistently.