# Prompt maestro: Generación de interfaz web + CRUD PHP + MySQL + JavaScript

## Objetivo

A partir de los **requerimientos funcionales y de datos proporcionados por el cliente**, construir la estructura completa de una aplicación web separando claramente:

1. Interfaz gráfica principal.
2. Formularios HTML independientes.
3. Hojas de estilos CSS independientes.
4. Menú principal en `index.html`.
5. Scripts PHP independientes para el CRUD y la conexión con MySQL.
6. Script JavaScript independiente para consumir los PHP mediante `fetch()`.
7. Comunicación dinámica entre formularios, JavaScript, PHP y MySQL.

La aplicación debe proyectar una estética **elegante, exclusiva, profesional y tranquila**, sin sacrificar usabilidad, accesibilidad ni facilidad de mantenimiento.

---

# 1. Entrada: requerimientos del cliente

Usar como entrada exclusivamente los requerimientos suministrados:

```text
[PEGAR AQUÍ LOS REQUERIMIENTOS DE LA APLICACIÓN]
```

Antes de generar código:

- Analizar las entidades, atributos y relaciones.
- Identificar las operaciones CRUD necesarias.
- Identificar los formularios y pantallas requeridos.
- Determinar qué información debe mostrarse en tablas, tarjetas, paneles o formularios.
- No inventar entidades, campos, reglas o funcionalidades que no estén justificadas por los requerimientos.
- Si existe una ambigüedad que afecte la estructura de la aplicación, señalarla claramente y adoptar la opción mínima necesaria.

---

# 2. Arquitectura general obligatoria

Mantener los componentes independientes.

Estructura recomendada:

```text
/aplicacion/
│
├── index.html
├── styles.css
├── script.js
│
├── /formularios/
│   ├── entidad1.html
│   ├── entidad2.html
│   ├── entidad3.html
│   └── ...
│
├── /php/
│   ├── db.php
│   ├── entidad1_crud.php
│   ├── entidad2_crud.php
│   ├── entidad3_crud.php
│   └── ...
│
└── /assets/
    ├── /img/
    └── /icons/
```

### Regla fundamental

No mezclar:

- HTML con PHP.
- CSS dentro de los HTML, salvo que sea estrictamente necesario.
- JavaScript dentro de los HTML.
- Consultas SQL directamente dentro de los formularios.
- Credenciales de MySQL dentro de archivos HTML o JavaScript.

Cada responsabilidad debe permanecer separada.

---

# 3. Diseño de la interfaz gráfica

Crear una interfaz visual:

- Elegante.
- Sobria.
- Moderna.
- Profesional.
- Exclusiva.
- Serena y agradable.
- Responsive.
- Fácil de navegar.

## Dirección visual

Utilizar una combinación de:

- Colores neutros.
- Tonos crema, marfil, blanco cálido, gris suave o tonos tierra según el contexto.
- Un color de acento refinado.
- Contrastes suficientes para facilitar la lectura.
- Espacios amplios.
- Bordes sutiles.
- Sombras suaves.
- Radios de borde moderados.
- Tipografía sans-serif moderna.
- Jerarquía visual clara.
- Animaciones discretas.

Evitar:

- Colores excesivamente saturados.
- Gradientes agresivos.
- Animaciones excesivas.
- Elementos visuales innecesarios.
- Interfaces sobrecargadas.
- Uso indiscriminado de sombras.

El resultado debe transmitir **exclusividad y calma**, no apariencia tecnológica exagerada.

---

# 4. Crear `index.html`

Generar un `index.html` independiente que funcione como pantalla principal.

Debe incluir:

## Encabezado

- Logotipo o nombre de la aplicación.
- Nombre del sistema.
- Descripción breve opcional.

## Menú principal

Crear botones o tarjetas de navegación hacia cada módulo.

Ejemplo conceptual:

```text
Inicio
│
├── Gestión de entidad 1
├── Gestión de entidad 2
├── Gestión de entidad 3
├── Consultas
└── Configuración
```

Solo crear opciones justificadas por los requerimientos.

## Área principal

Puede incluir:

- Resumen de información.
- Indicadores.
- Accesos rápidos.
- Descripción de la aplicación.
- Tarjetas con módulos disponibles.

## Pie de página

Incluir:

- Nombre de la aplicación.
- Información institucional cuando exista.
- Año.
- Texto discreto de derechos de autor.

El `index.html` debe permanecer libre de código PHP y de consultas SQL.

---

# 5. Crear formularios HTML independientes

Para cada entidad o módulo que requiera gestión, crear un archivo HTML independiente.

Ejemplo:

```text
/formularios/
├── pacientes.html
├── medicos.html
├── ingresos.html
└── ...
```

Cada formulario debe:

- Ser HTML5 válido.
- Tener estructura semántica.
- Ser responsive.
- Utilizar etiquetas `<label>` correctamente asociadas.
- Incluir validaciones HTML básicas.
- Mostrar mensajes claros.
- Tener botones diferenciados para:
  - Nuevo.
  - Guardar.
  - Actualizar.
  - Cancelar.
  - Eliminar, cuando corresponda.
- Incluir una zona para mostrar los registros existentes.
- Permitir seleccionar un registro para editarlo.
- Permitir eliminar registros con confirmación.
- No contener consultas SQL.
- No contener código PHP.
- No incluir JavaScript embebido.

El HTML debe encargarse exclusivamente de la estructura y presentación del formulario.

---

# 6. Tablas y visualización de registros

Cuando un módulo requiera mostrar registros:

Crear una tabla responsive con:

- Encabezados claros.
- Datos obtenidos dinámicamente.
- Botón `Editar`.
- Botón `Eliminar`.
- Estado vacío cuando no existan registros.
- Mensaje de carga.
- Mensaje de error si la consulta falla.

Ejemplo conceptual:

```text
---------------------------------------------------------
| Código | Nombre | Descripción | Estado | Acciones     |
---------------------------------------------------------
| 001    | ...    | ...         | Activo | Editar Borrar|
---------------------------------------------------------
```

No insertar registros directamente en el HTML.

Los datos deberán llegar mediante `fetch()` desde los scripts PHP.

---

# 7. Crear `styles.css`

Crear un único archivo CSS independiente para controlar el diseño general.

Debe contener:

- Variables CSS.
- Tipografía.
- Colores.
- Fondo.
- Encabezados.
- Menú.
- Botones.
- Formularios.
- Inputs.
- Selects.
- Textareas.
- Tablas.
- Tarjetas.
- Alertas.
- Mensajes de éxito.
- Mensajes de error.
- Estados hover.
- Estados focus.
- Diseño responsive.

Ejemplo de estructura:

```css
:root {
    --color-fondo: ...;
    --color-superficie: ...;
    --color-principal: ...;
    --color-acento: ...;
    --color-texto: ...;
    --color-texto-suave: ...;
    --color-borde: ...;
    --sombra-suave: ...;
    --radio: ...;
}
```

Usar `@media` para adaptar la aplicación a:

- Teléfonos.
- Tablets.
- Computadores portátiles.
- Monitores grandes.

---

# 8. Crear conexión PHP con MySQL

Crear:

```text
/php/db.php
```

Este archivo será responsable exclusivamente de la conexión a MySQL.

Debe:

- Utilizar PDO o MySQLi.
- Recomendar PDO como opción preferida.
- Configurar manejo de errores.
- Utilizar consultas preparadas.
- No contener lógica específica de ninguna entidad.
- No devolver HTML.
- No exponer credenciales al frontend.

Ejemplo conceptual:

```php
<?php

$host = 'localhost';
$db   = 'nombre_bd';
$user = 'usuario';
$pass = 'contraseña';

$pdo = new PDO(
    "mysql:host=$host;dbname=$db;charset=utf8mb4",
    $user,
    $pass,
    [
        PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
        PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC
    ]
);
```

Adaptar los datos a la configuración real proporcionada por el proyecto.

---

# 9. Crear scripts PHP CRUD independientes

Para cada entidad crear un archivo independiente.

Ejemplo:

```text
/php/
├── db.php
├── pacientes_crud.php
├── medicos_crud.php
├── ingresos_crud.php
└── ...
```

Cada script debe manejar las operaciones necesarias:

- `CREATE`
- `READ`
- `UPDATE`
- `DELETE`

Preferiblemente mediante un parámetro de operación:

```text
GET    ?action=list
POST   ?action=create
POST   ?action=update
POST   ?action=delete
```

También puede utilizarse una estructura REST-like si resulta más conveniente.

---

# 10. Respuesta de los PHP

Los scripts PHP deben devolver respuestas JSON.

Ejemplo:

```json
{
    "success": true,
    "message": "Registro guardado correctamente",
    "data": []
}
```

Para errores:

```json
{
    "success": false,
    "message": "No fue posible guardar el registro"
}
```

Configurar correctamente:

```php
header('Content-Type: application/json; charset=utf-8');
```

No devolver páginas HTML desde los endpoints CRUD.

---

# 11. Seguridad básica del CRUD

Implementar como mínimo:

- Consultas preparadas.
- Validación de datos recibidos.
- Sanitización cuando corresponda.
- Control de tipos.
- Validación de campos obligatorios.
- Manejo de excepciones.
- Respuestas JSON consistentes.
- No confiar en validaciones realizadas únicamente por HTML.
- No exponer credenciales de la base de datos.
- Evitar concatenar directamente valores enviados por el usuario en SQL.

No generar mecanismos de autenticación si no están incluidos en los requerimientos.

---

# 12. Crear `script.js`

Crear un único archivo JavaScript independiente:

```text
/script.js
```

Su función será conectar la interfaz HTML con los scripts PHP mediante `fetch()`.

No colocar código JavaScript dentro de los HTML.

---

# 13. Funciones JavaScript

Crear funciones reutilizables para:

## Listar

```javascript
async function listarRegistros() {
    // fetch() al PHP
}
```

## Crear

```javascript
async function crearRegistro(datos) {
    // fetch() con POST
}
```

## Actualizar

```javascript
async function actualizarRegistro(datos) {
    // fetch() con POST
}
```

## Eliminar

```javascript
async function eliminarRegistro(id) {
    // fetch() con POST
}
```

Las funciones deben:

- Utilizar `async/await`.
- Manejar errores con `try/catch`.
- Procesar respuestas JSON.
- Actualizar la interfaz después de una operación.
- Mostrar mensajes al usuario.
- Evitar duplicar código.

---

# 14. Comunicación mediante `fetch()`

Ejemplo conceptual:

```javascript
const respuesta = await fetch('../php/pacientes_crud.php?action=list');

const resultado = await respuesta.json();

if (resultado.success) {
    // Renderizar registros
} else {
    // Mostrar error
}
```

Para guardar:

```javascript
const respuesta = await fetch('../php/pacientes_crud.php?action=create', {
    method: 'POST',
    headers: {
        'Content-Type': 'application/json'
    },
    body: JSON.stringify(datos)
});

const resultado = await respuesta.json();
```

El método utilizado debe coincidir con la implementación PHP.

---

# 15. Actualización dinámica de formularios

Al cargar cada módulo:

1. Obtener los registros mediante `fetch()`.
2. Renderizarlos en la tabla.
3. Permitir seleccionar un registro.
4. Cargar sus datos en el formulario.
5. Cambiar el formulario a modo edición.
6. Permitir actualizar.
7. Permitir cancelar edición.
8. Volver a cargar los registros después de guardar.
9. Limpiar el formulario después de una operación exitosa.

No recargar innecesariamente toda la página.

---

# 16. Manejo de estados de la interfaz

Implementar estados visuales para:

### Cargando

```text
Cargando registros...
```

### Sin registros

```text
No existen registros para mostrar.
```

### Éxito

```text
Registro guardado correctamente.
```

### Error

```text
No fue posible completar la operación.
```

Los mensajes deben ser visualmente claros y coherentes con el diseño elegante y sereno.

---

# 17. Navegación entre archivos

El `index.html` debe enlazar los formularios independientes.

Ejemplo:

```html
<a href="formularios/pacientes.html">
    Gestión de pacientes
</a>
```

Los formularios no deben contener copias del menú principal innecesariamente complejas.

Si se necesita navegación de retorno:

```html
<a href="../index.html">Volver al inicio</a>
```

---

# 18. Reglas para relaciones entre entidades

Cuando un formulario dependa de otra entidad:

- Utilizar `<select>`, búsqueda o componente equivalente.
- Cargar las opciones dinámicamente desde PHP.
- Mostrar información comprensible al usuario.
- Enviar únicamente la clave correspondiente a la base de datos.
- Respetar las claves foráneas definidas por el modelo.

Ejemplo conceptual:

```text
Médico:
[ Seleccione un médico ▼ ]
```

El usuario ve el nombre, pero el sistema envía el código correspondiente.

---

# 19. Organización final de archivos

La salida final debe quedar organizada de forma similar a:

```text
/aplicacion/
│
├── index.html
├── styles.css
├── script.js
│
├── formularios/
│   ├── entidad1.html
│   ├── entidad2.html
│   └── entidad3.html
│
├── php/
│   ├── db.php
│   ├── entidad1_crud.php
│   ├── entidad2_crud.php
│   └── entidad3_crud.php
│
└── assets/
    ├── img/
    └── icons/
```

No generar archivos innecesarios.

---

# 20. Flujo completo de funcionamiento

La aplicación debe seguir este flujo:

```text
USUARIO
   │
   ▼
index.html
   │
   ▼
Formulario HTML
   │
   ▼
script.js
   │
   │ fetch()
   ▼
PHP CRUD
   │
   ▼
db.php
   │
   ▼
MySQL
   │
   ▼
PHP devuelve JSON
   │
   ▼
script.js procesa respuesta
   │
   ▼
HTML se actualiza dinámicamente
```

---

# 21. Reglas de calidad del código

Todo el código generado debe:

- Ser claro para un desarrollador principiante/intermedio.
- Tener nombres descriptivos.
- Mantener separación de responsabilidades.
- Evitar código duplicado.
- Utilizar comentarios únicamente donde aporten valor.
- Mantener indentación consistente.
- Ser compatible con navegadores modernos.
- Utilizar HTML5, CSS3, JavaScript moderno y PHP actual.
- Mantener rutas relativas correctas.
- Evitar dependencias externas innecesarias.
- No utilizar frameworks JavaScript si no fueron solicitados.
- Utilizar JavaScript puro (`vanilla JS`) para `fetch()` y manipulación del DOM.

---

# 22. Validaciones

Implementar validación en dos niveles:

### Frontend

HTML + JavaScript:

- `required`
- tipos correctos
- longitudes
- formatos
- rangos cuando correspondan

### Backend

PHP:

- Validar nuevamente todos los datos.
- Comprobar tipos.
- Comprobar campos obligatorios.
- Comprobar existencia de claves relacionadas.
- Evitar registros inválidos.

La validación del frontend nunca debe considerarse suficiente para proteger la base de datos.

---

# 23. Resultado esperado

A partir de los requerimientos proporcionados, entregar:

### Interfaz

- `index.html`
- Formularios HTML independientes.
- `styles.css`
- `script.js`

### Backend

- `db.php`
- Un PHP CRUD independiente por entidad.

### Funcionalidad

- Crear registros.
- Consultar registros.
- Editar registros.
- Eliminar registros.
- Mostrar registros dinámicamente.
- Comunicación mediante `fetch()`.
- Respuestas JSON.
- Validaciones frontend y backend.
- Manejo de errores.

### Diseño

La aplicación debe sentirse:

> Elegante + exclusiva + profesional + limpia + tranquila + moderna.

---

# 24. Formato obligatorio de entrega

Presentar la solución en este orden:

## 1. Análisis de requerimientos

Indicar:

- Entidades detectadas.
- Campos.
- Relaciones.
- Operaciones CRUD.
- Formularios necesarios.
- Dependencias entre formularios.

## 2. Arquitectura de carpetas

Mostrar el árbol completo.

## 3. `index.html`

Entregar el código completo.

## 4. Formularios HTML

Entregar cada archivo por separado.

## 5. `styles.css`

Entregar el código completo.

## 6. `script.js`

Entregar el código completo.

## 7. `db.php`

Entregar el código completo.

## 8. Scripts PHP CRUD

Entregar cada archivo PHP de forma independiente.

## 9. Instrucciones de instalación

Explicar:

1. Crear la base de datos.
2. Configurar `db.php`.
3. Copiar el proyecto al servidor local.
4. Utilizar Apache/PHP/MySQL o equivalente.
5. Abrir `index.html` mediante el servidor web, no mediante `file://`.
6. Verificar las rutas.
7. Probar listar, crear, editar y eliminar.

## 10. Pruebas funcionales

Crear una lista de pruebas para comprobar:

- Carga inicial.
- Listado.
- Creación.
- Edición.
- Eliminación.
- Validaciones.
- Relaciones.
- Errores de conexión.
- Registros inexistentes.
- Respuestas PHP.

---

# 25. Restricciones importantes

No:

- Mezclar HTML, CSS, JavaScript y PHP en un único archivo.
- Generar PHP dentro de los formularios.
- Generar SQL dentro de `script.js`.
- Colocar credenciales de MySQL en JavaScript.
- Escribir consultas SQL directamente con datos concatenados.
- Generar información ficticia que contradiga los requerimientos.
- Crear módulos que no estén justificados.
- Utilizar frameworks sin autorización.
- Eliminar la separación entre frontend y backend.

Sí:

- Mantener archivos independientes.
- Utilizar `fetch()`.
- Utilizar JSON.
- Utilizar consultas preparadas.
- Validar en frontend y backend.
- Mantener un diseño responsive.
- Mantener una estética elegante, exclusiva y serena.
- Generar código listo para organizarse en un servidor PHP/MySQL.

---

# 26. Instrucción final para el generador

**Analiza primero los requerimientos del cliente. Después diseña la arquitectura de la aplicación y finalmente genera todos los archivos solicitados. No comiences directamente escribiendo código sin identificar previamente entidades, campos, relaciones, formularios y operaciones CRUD.**

El resultado debe ser una aplicación modular en la que:

```text
HTML = estructura
CSS = presentación
JavaScript = interacción y comunicación
PHP = lógica del servidor y CRUD
db.php = conexión MySQL
MySQL = persistencia de datos
```

Mantén esta separación durante toda la implementación.