# Procedimiento para cambios y mejoras — XPERT_DEV_COMFAR / XPERT_PRO_COMFAR

Dos líneas de código independientes, cada una con su propio repo de GitHub:

- **DEV** → `Ruizdiazo/XPERT_DEV_COMFAR` → local (`c:\Proyectos\XPERT_DEV_COMFAR`) + GCP (puerto 8084) + `200.10.10.145` (real del cliente)
- **PRO** → `Ruizdiazo/XPERT_PRO_COMFAR` → local (`c:\Proyectos\XPERT_PRO_COMFAR`) + GCP (puerto 80) + `200.10.10.150` (real del cliente)

Nunca se mezclan entre sí — un cambio en una línea no llega solo a la otra.

## Orden de los pasos, siempre igual

1. **Desarrollar en local**, en el repo que corresponda (DEV para probar cosas nuevas; PRO solo si el cambio ya está validado o es igual de bajo riesgo).
2. **Commit + push a GitHub.**
3. **Desplegar en el GCP de esa línea** (`git pull` en el servidor — siempre funciona sin fricción, es el ambiente de prueba).
4. **Probar ahí** (navegador contra la IP:puerto del GCP) antes de tocar cualquier ambiente real.
5. **Recién con el OK del usuario**, desplegar al ambiente real del cliente correspondiente (`.145` para DEV, `.150` para PRO) — nunca de forma proactiva, siempre pedido explícito.
6. **Si el cambio ya se probó bien en DEV y se quiere en PRO**, se repite el mismo camino (push al repo de PRO, GCP de PRO, y recién después PRO real) — con confirmación explícita en cada salto a un ambiente real.

## Cómo desplegar en cada lugar

**GCP (DEV o PRO, ya con git armado):**
```bash
sudo git -C /var/www/XPERT_DEV_COMFAR pull origin main   # o XPERT_PRO_COMFAR
sudo chown -R ruizdiazo:ruizdiazo /var/www/XPERT_DEV_COMFAR   # (o www-data:www-data para PRO)
```

**`.145` (DEV real, ya con git armado desde 2026-08-02):**
```bash
cd /var/www/WMS && git pull origin main
```
(vía SSH con PuTTY `plink.exe`, usuario `comfar`, ver más abajo)

**`.150` (PRO real, git armado desde 2026-08-02):**
```bash
git -C /var/www/WMS fetch origin              # como comfar, SIN sudo (usa su propia clave SSH)
sudo git -C /var/www/WMS checkout -f main     # CON sudo (escribe archivos del sitio, dueños de www-data)
sudo git -C /var/www/WMS status               # confirmar "up to date" y "working tree clean"
```
Nota: a diferencia de `.145`, acá `comfar` no tiene permiso de escritura directa sobre `/var/www/WMS`, por eso el fetch va sin sudo (para usar la clave SSH de `comfar`) pero el checkout va con sudo (para poder escribir). Los archivos históricos sueltos (`.bak*`, `docs/`, `database/seeds/`) están cubiertos por `.gitignore` y nunca se tocan.

## Acceso a los servidores reales del cliente (.145 / .150)

- Requiere VPN de la empresa conectada (FortiClient, ya instalado).
- SSH: usuario `comfar`, misma contraseña para los dos (pedirla cuando haga falta, no queda guardada en ningún lado por seguridad).
- Usar PuTTY (`plink.exe` / `pscp.exe`) con `-pw` para no tipear contraseña interactivamente. La primera vez que se conecta a un host nuevo, aceptar su huella SSH explícita con `-hostkey "SHA256:..."` en vez de confiar en pipes de "y" (no siempre funciona).

## Reglas de oro

- **Nunca tocar un ambiente real sin haberlo probado antes en el GCP correspondiente.**
- **Nunca tocar PRO (ni GCP ni real) sin confirmación explícita** — la autorización de trabajar en DEV no se extiende a PRO automáticamente.
- **Backup antes de sobreescribir** cualquier archivo en un ambiente real.
- **Cambios aditivos**: preferir agregar código nuevo sobre modificar función existente; si hay que tocar una función compartida, que degrade con seguridad al comportamiento anterior si algo falla (ver ejemplo: el fix de impresoras de Empaque, que no rompía Recepción aunque fallara).
- Si algo no sale como se espera en un ambiente real, **priorizar revertir** (`git revert`, o restaurar el backup) antes que seguir parchando en caliente.