La misión
Una agenda de contactos profesional: crear (nombre, teléfono, correo, notas, favorita), listar ordenado y con búsqueda instantánea, editar sin recargar, borrar… con dos niveles (quitar de la vista / eliminar de verdad con confirmación tipada). Los datos viven en una base real, no en la memoria del navegador: recarga la página y todo sigue ahí. Backend y base de datos los arma la IA; el modelo de datos, las validaciones y el protocolo de borrado los escribes tú en la especificación.
La ruta, seis tiempos
Ruta del proyecto 2
- ESPECIFICACION.md empieza por la tabla: columnas, tipos, qué es obligatorio, qué puede ser nulo, cómo se ve afectada la búsqueda. Escribe la regla de negocio del borrado: ¿qué significa «borrar» aquí? (pista: si el registro tiene historial, la respuesta rara vez es DELETE).
El prompt del modelo de datos (el que va primero)
Vamos a construir la agenda de contactos del proyecto 2 de mi taller, por capas.\nCapa 1: base de datos y backend. Capa 2 la pidamos cuando esta este verde.\n\nModelo de datos (decidido por mi, no lo cambies sin discutirlo):\n- tabla contactos: id, nombre (obligatorio), telefono (10 digitos, opcional),\n correo (formato validado, opcional), notas (texto largo, opcional), favorita\n (booleano, default falso), creado_el, actualizado_el, eliminado_el (nulo = vivo)\n- reglas de negocio:\n * "borrar" de la vista = marcar eliminado_el (soft delete); la lista solo muestra\n donde eliminado_el es nulo\n * "eliminar de verdad" requiere confirmacion con la palabra SI en el frontend y\n solo esta disponible si el contacto esta borrado de la vista primero\n * un mismo correo no puede existir dos veces vivo; en borrados si puede (historial)\n\nEndpoints como contrato (definir exito Y error de cada uno):\nGET /contactos?q=&favoritas= | POST | PUT /:id | DELETE /:id (soft) | PURGE /:id (real)\n\nImplementa con [stack del documento maestro], con validacion EN EL SERVIDOR de todas\nlas reglas (el frontend es UX, no defensa). Pruebas automatizadas por endpoint: caso\nfeliz + al menos 2 casos de error por endpoint. Muestra el diff, corre las pruebas,\nespera mi revision antes de la capa 2.Qué entrega este proyecto
| Entregable | Barra alta de este proyecto |
|---|---|
| ESPECIFICACION.md | el modelo de datos con tipos y reglas de negocio, y los endpoints como contrato con casos de error |
| HALLAZGOS.md | la búsqueda que fallaba con acentos, la validación que solo existía en el formulario… |
| PRUEBAS.md | incluye la prueba del borrado: el escenario destructivo que corriste contra la base de desarrollo y su resultado |
| App publicada | datos que sobreviven recargar desde otro dispositivo, con búsqueda útil |
Prueba
Un usuario llama «borrar» al botón rojo de tu agenda. Según el modelo de este proyecto, ¿qué hace el sistema?
La validación del teléfono a 10 dígitos puesta en el formulario HTML (required + pattern) ya cumple la regla del modelo: no hace falta repetir en el servidor.
Orden de ataque: especificación de 25 minutos, luego el prompt de capa 1 y nada más hasta que esté verde. La prueba del borrado (paso 5) no es opcional: es la escena madre de este proyecto —documenta en HALLAZGOS.md lo que descubriste al intentar romper tu propia app.