# G & S GOLD TRAVEL — REGLAS DEL PROYECTO

## 1. Arquitectura

Este proyecto es una aplicación web PHP procedural.

No utiliza framework PHP, ORM, MVC ni sistema de rutas.

La arquitectura existente debe conservarse.

NO introducir:
- Laravel.
- Symfony.
- CodeIgniter.
- MVC.
- ORM.
- Composer.
- React.
- Vue.
- otro framework.

No cambiar la arquitectura existente salvo autorización explícita.

## 2. Regla principal

Si algo ya funciona, NO modificarlo.

Antes de crear o modificar un módulo:

1. Buscar módulos existentes similares.
2. Identificar el patrón utilizado.
3. Utilizar ese patrón como referencia.
4. Modificar únicamente lo necesario.

Nunca crear una segunda implementación cuando ya exista una solución funcionando en el proyecto.

## 3. PHP

Mantener el estilo PHP procedural existente.

Conservar:
- includes existentes;
- funciones existentes;
- nombres de variables cuando no sea necesario cambiarlos;
- consultas preparadas;
- validaciones;
- redirecciones;
- protección administrativa;
- estructura de sesiones.

No reemplazar código funcional por una arquitectura diferente.

## 4. Seguridad

Nunca eliminar ni debilitar:

- proteger-admin.php;
- session.php;
- security.php;
- CSRF;
- consultas preparadas;
- validación de entradas;
- validación de IDs;
- comprobaciones de usuario activo;
- protección de sesiones.

Toda operación POST que modifique datos debe mantener protección CSRF.

## 5. Base de datos

NO modificar tablas existentes sin autorización explícita.

NO crear migraciones automáticamente.

NO cambiar nombres de tablas o columnas existentes.

Antes de proponer cambios de base de datos, revisar primero los scripts SQL existentes.

## 6. CSS

La identidad visual existente debe conservarse.

Antes de modificar un CSS compartido:

1. Buscar todas las páginas que lo utilizan.
2. Revisar sus dependencias.
3. Determinar qué reglas pueden verse afectadas.
4. Modificar únicamente lo necesario.

Nunca reemplazar un CSS compartido completo sin revisar primero sus dependencias.

No crear estilos duplicados si ya existe una regla equivalente.

## 7. Diseño administrativo

Los módulos administrativos deben conservar el patrón visual existente.

Utilizar como referencias:

- Pie de página para módulos completos.
- Menú para estructuras jerárquicas.
- Redes sociales y Logo para archivos e imágenes.
- Teléfonos, Correos y Dirección para CRUD simples.

Los módulos nuevos deben parecer parte del mismo sistema.

## 8. Archivos completos

Cuando se solicite modificar un archivo, entregar/modificar el archivo completo cuando sea apropiado.

No realizar parches innecesarios.

No eliminar código funcional que no esté relacionado con el cambio solicitado.

## 9. Antes de modificar

Antes de realizar cambios importantes:

1. Explicar qué archivos serán modificados.
2. Explicar brevemente por qué.
3. Revisar archivos relacionados.
4. Confirmar que no se está rompiendo una dependencia existente.

## 10. Después de modificar

Después de realizar cambios:

1. Revisar sintaxis PHP.
2. Revisar referencias CSS.
3. Revisar enlaces entre archivos.
4. Revisar dependencias.
5. Informar exactamente qué archivos fueron modificados.
6. Informar cualquier riesgo o punto que deba probarse.

## 11. No tocar módulos no relacionados

Si estamos trabajando en Paleta de colores, no modificar:

- Teléfonos.
- Correos.
- Dirección.
- Redes sociales.
- Menú.
- Pie.
- Login.
- Dashboard.

salvo que exista una dependencia real y sea estrictamente necesario.

## 12. Comunicación

Si existe más de una forma de implementar algo:

- explicar las opciones;
- recomendar la que mejor respete la arquitectura existente;
- esperar instrucciones cuando la decisión pueda afectar la arquitectura.

No asumir cambios estructurales importantes.

## 13. Estado actual

El proyecto actualmente contiene módulos funcionales de:

- autenticación administrativa;
- dashboard;
- cabecera;
- teléfonos;
- correos;
- dirección;
- redes sociales;
- logo;
- menú;
- pie de página;
- apariencia;
- paleta de colores.

Estos módulos existentes deben considerarse código de referencia y no deben romperse.

## 14. Paleta de colores

La tabla paleta_colores ya existe.

Actualmente contiene:

- nombre;
- RGB;
- RGBA;
- uso;
- orden;
- estado.

La paleta todavía debe integrarse posteriormente con la web pública y con el sistema visual.

No realizar esa integración hasta recibir instrucciones.

## 15. Regla crítica

ANTES DE ESCRIBIR CÓDIGO NUEVO, BUSCAR PRIMERO UN EJEMPLO EXISTENTE EN EL PROYECTO.

El proyecto debe evolucionar sobre su arquitectura actual, no mediante implementaciones paralelas.

FIN DE LAS REGLAS.