La misión: tu idea, hasta el final

Elige una aplicación que tú o alguien real necesite de verdad —el control de clientes de tu trabajo, la agenda de reserva del consultorio familiar, el tablero de entrenamiento del club—. Nada de inventar una idea bonita para la tarea: el proyecto final se sostiene con usuarios auténticos. Las siete fases son las del curso completo, pero caminadas sin guion: definir, especificar, diseñar arquitectura, dirigir el código por capas, probar, proteger, desplegar. Y una octava que casi ningún curso enseña: sostener —mantenimiento, costos y métricas durante al menos dos semanas públicas—.

La ruta, siete tiempos

Ruta del proyecto final

ESPECIFICACION.md completa: problema, usuario, casos de uso, pantallas, flujo, reglas de negocio y criterios de aceptación numerados. El recorte es parte del ejercicio: saca del alcance todo lo que no quepa en dos semanas —un «no por ahora» escrito vale más que un sí invisible.
Diagrama de componentes, modelo de datos, lista de APIs externas y funciones de IA con su hoja de costos. Divide en capas con fronteras probables (proyectos 1-5 te enseñaron el tamaño correcto de un bocado) y escribe el plan de construcción ordenado.
El documento maestro al día, prompts de capa con criterios de aceptación numerados, un paso por vez con diff revisado. Si la IA propone saltarse una capa o «arreglar» dos a la vez, tú mandas: ese es el hábito, no la velocidad.
Antes de probar funcionalidad: clave en el navegador, dependencia inventada, endpoint inexistente, sql directa con interpolación, permisos solo de menú, cero validación de entrada, borradura sin condición. Las siete pasadas con ctrl-f sobre el código real.
PRUEBAS.md: casos felices, límites, estados feos de cada integración, y la prueba de datos —un borrado que solo toque lo suyo, en una base con copia de seguridad de verdad—. Si algo rompió el usuario de prueba, es un hallazgo de HALLAZGOS.md, no un fracaso.
Dominio propio o subdominio, HTTPS, variables de entorno en el servidor, base migrada con respaldo probado (restaurar una vez, no solo respaldar), logs encendidos y una página de estado honesta si algo se cae.
Dos semanas pública con tu rutina mensual activada: revisar logs, backups, dependencias, costos. Luego la defensa de quince minutos ante alguien técnico: tres decisiones que defendiste, dos que la IA te hubiera colado sin auditoría, una que cambiarías. Grábala: se cuenta en tu portafolio.

El prompt de arranque (el que ya sabes escribir)

El punto 3: la IA detecta el alcance inflado, pero el recorte lo firmas tú

Proyecto final. Adjunto ESPECIFICACION.md completa (la mia, escrita por mi) y el\ndocumento maestro del stack elegido. No empieces a programar: primero construimos\nel plan.\n\n1. devuelve el DESGLOSE por capas con fronteras probables, en orden de construccion,\n   con que criterio de aceptacion numerado prueba cada capa\n2. marca cada capa que toque dinero, datos sensibles o una API externa: esas van con\n   auditoria antes de integrarse\n3. senala los puntos del alcance que ves recortables si el tiempo aprieta, SIN\n   recortarlos tu: la decision es mia y va escrita en ESPECIFICACION.md\n4. por cada capa esperame: te dare el si, y al terminar mostraras diff y la salida\n   de sus pruebas corriendo\n\nReglas del proyecto (del maestro): nunca clave en frontend, nunca DELETE sin WHERE\nverificable, nunca dependencia sin comprobar que existe, validacion en cada entrada.\nEmpieza por el desglose. Nada mas.

Qué entrega este proyecto

La mirada con la que quieres que te vean al terminar: «esta persona puede tener una idea y convertirla en software usando IA». Eso es exactamente lo que miden estos seis entregables juntos; cualquiera de ellos solo se puede fingir, los seis no.
Entregable	Barra alta del curso completo
ESPECIFICACION.md	problema real con usuario real, criterios numerados y los «no por ahora» escritos
ARQUITECTURA.md	el diagrama, el modelo de datos y la hoja de costos de cada función de IA
HALLAZGOS.md	lo que la IA intentó colarte en las siete señales: con fragmento de código y fecha
PRUEBAS.md	estados feos provocados, borrado auditado y la restauración del respaldo ejecutada una vez
App publicada	dos semanas en producción con rutina de mantenimiento cumplida (logs, backup, costo)
Defensa grabada	quince minutos explicando decisiones a un interlocutor técnico, sin leer

Prueba

En la defensa de quince minutos, el evaluador pregunta: «¿por qué tu app tarda en responder a veces y qué hiciste en el diseño por eso?». La respuesta que demuestra el curso entero es:

Si tu aplicación nunca muestra un error en las dos semanas de producción, el proyecto demuestra calidad.

Antes del prompt de arranque, escribe en una línea para qué usuario real existe tu app y cómo sabrás en la semana dos que le sirvió. Ese renglón es tu criterio de éxito: todo lo demás —las capas, las señales, la defensa— es la forma de llegar a poder decirlo con evidencia.

Pista

El curso termina donde empieza cualquier software de verdad: alguien lo usa, algo se rompe, tú lo sostienes.