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
1 · Modelo de datos (M7, 15 min)
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).2 · Especificar los endpoints (M6+M8, 10 min)
La lista de operaciones pedidas como contrato: GET /contactos?q=, POST, PUT /contactos/:id, DELETE con query de confirmación. Sin cuerpo de respuesta inventado: qué devuelve cada uno en éxito y en error.3 · Prompt por capas (M3+M14)
Primero base de datos + backend con sus pruebas; verde, después el frontend que lo consume. Nunca «hazme la app completa» en un prompt: cada capa se aprueba sola antes de subirse a la siguiente.4 · Revisión con las siete señales (cnf-oa02)
El backend nuevo pasa por el escaneo: SQL parametrizado, validación en servidor (no solo en el formulario), errores con mensaje útil y sin datos al log. Cada hallazgo, a HALLAZGOS.md —este proyecto va a llenarlo.5 · La prueba del borrado (cnf-oa03)
Antes de publicar: crea 20 contactos de prueba, respalda, y ejecuta el peor escenario que puedas imaginar contra TU base de desarrollo. PRUEBAS.md documenta el intento y qué pasó. Si algo se perdió sin recuperación, el protocolo estaba decorado: corrígelo aquí, no en producción.6 · Publicar con datos vivos (M16)
Base de datos en el servidor, variables de entorno para las credenciales (¡la clave de la base NUNCA en el código!), URL pública y repo con historial de commits que cuente la historia por capas.
Paso 1 de 6
El prompt del modelo de datos (el que va primero)
El prompt que fija las reglas de negocio ANTES de que la IA las "proponga"
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.
Una base de datos que sobrevive a todo es la que sobrevivió primero a tus ataques de prueba.
Tu texto se guarda sólo en este dispositivo.
Comentarios
Inicia sesión para comentar.
Todavía no hay comentarios. Sé la primera persona en opinar.