# Desarrollo local por area (sin clonar cd-system)

Objetivo: que cada developer trabaje y pruebe solo su area (`frontend` o `backend-modules`) usando una imagen runtime centralizada.

## 1) Publicar runtime base

En este repo (`cd-system`) ya queda workflow:

- `.github/workflows/build-runtime-image.yml`

Publica imagen en:

- `ghcr.io/<ORG>/cd-runtime:latest`

## 2) Setup para repo `cd-frontend`

1. Copiar `docs/split-repo-templates/frontend/docker-compose.yml` al root del repo `cd-frontend`.
2. Copiar `docs/split-repo-templates/frontend/dev.ps1` y `docs/split-repo-templates/frontend/stop.ps1` al root del repo.
3. Reemplazar `YOUR_ORG` por la org real de GitHub.
4. Levantar local con un comando:

```powershell
pwsh ./dev.ps1
```

Acceso local: `http://localhost:8080`

Detener:

```powershell
pwsh ./stop.ps1
```

## 3) Setup para repo `cd-backend-modules`

1. Copiar `docs/split-repo-templates/backend-modules/docker-compose.yml` al root del repo `cd-backend-modules`.
2. Copiar `docs/split-repo-templates/backend-modules/dev.ps1` y `docs/split-repo-templates/backend-modules/stop.ps1` al root del repo.
3. Reemplazar `YOUR_ORG`.
4. Levantar local con un comando:

```powershell
pwsh ./dev.ps1
```

Acceso local: `http://localhost:8081`

Detener:

```powershell
pwsh ./stop.ps1
```

## 4) Flujo de trabajo recomendado

1. Developer trabaja en su repo split.
2. Prueba local con Docker (sin repo principal).
3. Mergea en split repo.
4. Workflow del split repo abre PR automatico hacia `cd-system`.
5. Equipo core revisa y mergea al principal.

## 5) Notas

- El runtime incluye base Laravel y dependencias necesarias.
- Si requieren datos realistas, pueden apuntar a una DB de desarrollo por variables de entorno.
- Renovar `cd-runtime:latest` cuando haya cambios estructurales en backend/core.
- Para SQLite, migraciones, `AUTO_MIGRATE`, Doctrine DBAL y troubleshooting: ver `docs/split-repo-docker-runtime-reference.md`.