# Estrategia de Propagación del Core CD-System

## 🎯 Respuesta Directa

**¿Debería propagarse automáticamente?** 

**NO, pero SÍ de forma controlada y automatizada.**

### ✅ Mejores Prácticas Recomendadas

1. **Propagación Manual Controlada** (Recomendado)
   - El desarrollador decide **cuándo** actualizar cada proyecto
   - Permite testing antes de propagar
   - Evita romper proyectos en producción
   - Permite rollback si algo sale mal

2. **Proceso Automatizado con Herramientas**
   - Scripts que facilitan la propagación
   - Protección automática de archivos del proyecto
   - Verificación de conflictos antes de aplicar

3. **Estrategia de Protección**
   - `.gitattributes` con `merge=ours` protege automáticamente:
     - `config/cd-system.php` (configuración del proyecto)
     - `config/site.php` (identidad del proyecto)
     - Assets del proyecto
   - Los archivos protegidos **nunca** se sobrescriben

---

## 📊 Arquitectura Actual

```
cd-system (core)
├── rama: cd-system (fuente de verdad)
└── cambios se propagan a ↓

Proyectos (cada uno con su propia rama cd-system)
├── cokecolombres/cd-system
├── mirage/cd-system
├── terashe/cd-system
└── ... otros proyectos
```

### Flujo de Actualización

```
1. Desarrollo en cd-system/cd-system
   ↓
2. Commit y push al core
   ↓
3. Propagación controlada a proyectos
   ↓
4. Testing en cada proyecto
   ↓
5. Deploy (si todo está bien)
```

---

## 🔄 Proceso de Propagación Recomendado

### Opción 1: Propagación Individual (Actual)

**Cuándo usar:**
- Actualizaciones críticas que requieren testing específico
- Proyectos en producción que necesitan cuidado especial
- Cambios que pueden tener impacto diferente en cada proyecto

**Cómo hacerlo:**
```bash
# Desde cd-system
cd /Applications/XAMPP/xamppfiles/htdocs/cd-system
./scripts/propagate-core-improvements.sh https://github.com/LACOMPANIADIGITAL/cokecolombres.git

# Con opciones
./scripts/propagate-core-improvements.sh \
  https://github.com/LACOMPANIADIGITAL/cokecolombres.git \
  --push yes \
  --dry-run  # Primero hacer dry-run
```

### Opción 2: Propagación en Batch (Mejora Propuesta)

**Cuándo usar:**
- Actualizaciones menores (bugfixes, mejoras de performance)
- Múltiples proyectos que necesitan la misma actualización
- Cambios que ya fueron testeados en un proyecto piloto

**Cómo hacerlo (propuesto):**
```bash
# Script mejorado que detecta proyectos locales
./scripts/propagate-to-all-projects.sh --dry-run
./scripts/propagate-to-all-projects.sh --projects cokecolombres,mirage,terashe
```

---

## 🛡️ Protección Automática

### Archivos que NUNCA se Sobrescriben

Gracias a `.gitattributes` con `merge=ours`, estos archivos se mantienen automáticamente:

**En cada proyecto:**
- ✅ `config/cd-system.php` - Configuración del proyecto (demo, módulos activos)
- ✅ `config/site.php` - Identidad del proyecto (nombre, URL, email)
- ✅ `public/cd-project/assets/*` - Assets del proyecto (logos, favicons)

**Resultado:** Cada proyecto mantiene su identidad, pero recibe mejoras del core.

### Archivos que SÍ se Actualizan

- ✅ Nuevos módulos y funcionalidades
- ✅ Mejoras en código reutilizable
- ✅ Actualizaciones de dependencias
- ✅ Nuevas migraciones y seeders
- ✅ Mejoras en helpers y utilidades
- ✅ Correcciones de bugs
- ✅ Actualizaciones de documentación

---

## 📋 Checklist de Propagación

### Antes de Propagar

- [ ] **Verificar cambios en el core**: ¿Qué se actualizó?
- [ ] **Revisar impacto**: ¿Qué proyectos se verán afectados?
- [ ] **Testing en desarrollo**: Probar en un proyecto de prueba primero
- [ ] **Backup**: Asegurar backups de proyectos en producción
- [ ] **Comunicación**: Notificar a los equipos si es necesario

### Durante la Propagación

- [ ] **Dry-run primero**: Simular sin hacer cambios
- [ ] **Revisar conflictos**: Verificar que no haya conflictos inesperados
- [ ] **Verificar protección**: Confirmar que archivos protegidos se mantienen
- [ ] **Testing básico**: Verificar que el proyecto sigue funcionando

### Después de Propagar

- [ ] **Testing completo**: Probar funcionalidades principales
- [ ] **Revisar logs**: Ver qué cambios se aplicaron
- [ ] **Documentar**: Si hay cambios importantes, documentarlos
- [ ] **Deploy**: Solo después de verificar que todo funciona

---

## 🚨 Casos Especiales

### Breaking Changes

Si el core tiene cambios que rompen compatibilidad:

1. **Comunicar primero**: Notificar a todos los equipos
2. **Documentar cambios**: Crear guía de migración
3. **Propagar gradualmente**: No propagar a todos a la vez
4. **Soporte**: Estar disponible para ayudar con la migración

### Conflictos en Archivos No Protegidos

Si hay conflictos en archivos que no están protegidos:

1. **Revisar cambios**: Ver qué cambió en el core vs. el proyecto
2. **Decidir estrategia**: ¿Mantener cambios del core o del proyecto?
3. **Resolver manualmente**: Editar archivos conflictivos
4. **Commitear resolución**: Hacer commit de la resolución

---

## 🔧 Mejoras Propuestas al Script Actual

### 1. Detección Automática de Proyectos Locales

```bash
# Detectar proyectos en el mismo directorio padre
./scripts/propagate-core-improvements.sh --auto-detect-local
```

### 2. Propagación en Batch

```bash
# Propagación a múltiples proyectos
./scripts/propagate-core-improvements.sh \
  --batch cokecolombres,mirage,terashe \
  --dry-run
```

### 3. Integración con Workflow

```bash
# Crear PR automáticamente en cada proyecto
./scripts/propagate-core-improvements.sh \
  --create-pr \
  --review-required
```

---

## 📚 Referencias

- [Protección de Archivos del Sistema](./proteccion-archivos-sistema.md)
- [Propagación de Mejoras del Core](./propagacion-mejoras-core.md)
- [Git Attributes Documentation](https://git-scm.com/docs/gitattributes)
- [Git Merge Strategies](https://git-scm.com/docs/merge-strategies)

---

## ✅ Resumen Ejecutivo

**¿Debería propagarse automáticamente?**

**NO automático, pero SÍ controlado y facilitado:**

1. ✅ **Proceso manual controlado** - El desarrollador decide cuándo
2. ✅ **Herramientas automatizadas** - Scripts que facilitan el proceso
3. ✅ **Protección automática** - `.gitattributes` protege archivos del proyecto
4. ✅ **Testing antes de deploy** - Verificar que todo funciona
5. ✅ **Rollback posible** - Poder revertir si algo sale mal

**Resultado:** Proyectos actualizados con mejoras del core, pero manteniendo su identidad y estabilidad.