Desarrollo de aplicaciones con IA: crea y publica el CRM de un negocio

Qué se trabaja

• Qué es un CRM, qué problema resuelve en un pequeño negocio y qué entra y qué no entra en NexoCRM (MVP, usuario principal, evidencia, iteración y deuda técnica).
• El ciclo de trabajo con IA: definir objetivo, dar contexto, pedir un cambio pequeño, leer el plan, ejecutar, probar, guardar evidencia, hacer commit y revisar.
• Instalación de Node LTS, Git, VS Code y terminal, y creación segura de las cuentas de Claude Code o Codex, GitHub (con 2FA), Vercel y Supabase sin compartir contraseñas ni API keys.
• Mapa de responsabilidades (ordenador local, GitHub, Vercel, Supabase), flujo de publicación y memoria persistente del asistente: CLAUDE.md o AGENTS.md, docs/architecture.md, docs/plans/, .env.local y .env.example.

Lecciones del módulo

1. 1.1

   Qué vamos a construir y cómo trabajaremos

   45 min

   Fijas el alcance real de NexoCRM y redactas la ficha de negocio (docs/product/brief.md) que guiará todas las decisiones del curso.

   Práctica segura

   Clasificas doce funcionalidades habituales de un CRM en 'Núcleo del MVP', 'MVP, segunda ola' o 'No corresponde'. Es un ejercicio sobre el alcance de NexoCRM, sin tocar código ni cuentas: equivocarte aquí solo te enseña dónde está la frontera. Después, un cuestionario corto comprueba que distingues un MVP bien planteado.

   Evidencia

   Demuestra que el alcance de tu NexoCRM está definido por escrito y cabe en una página.

2. 1.2

   El ciclo correcto con Claude Code o Codex

   1 h

   Redactas el prompt de bootstrap que abrirá el repositorio de NexoCRM (docs/prompts/01-bootstrap.md) y fijas cómo pedirás cada cambio durante el curso.

   Práctica segura

   Construyes un prompt bloque a bloque en el prompt-builder: la plataforma valida que cada bloque tenga longitud y concreción suficientes y te muestra un ejemplo débil y otro profesional para comparar. No se ejecuta nada: practicas la redacción sin riesgo. Después, un cuestionario te pide diagnosticar qué le falta a un prompt débil.

   Evidencia

   Demuestra que tu primer prompt limita el alcance y pide una forma de probar el resultado.

3. 1.3

   Instalación y creación segura de cuentas

   1 h 15 min

   Preparas el equipo (Node LTS, Git, VS Code, terminal) y las cuatro cuentas con las que construirás y publicarás NexoCRM: Claude Code o Codex, GitHub, Vercel y Supabase.

   Práctica segura

   Tres ejercicios sin riesgo. El setup-checklist te presenta una lista de acciones de configuración mezcladas con trampas ('compartir la contraseña con el formador', 'pegar la service_role key en el chat'): debes marcar solo lo correcto. El terminal-simulator relaciona ocho comandos con su efecto antes de teclearlos en tu equipo. El accounts-completion-check es la lista de finalización de las cuatro cuentas más Node y Git.

   Evidencia

   Demuestra que tu equipo funciona y que las cuatro cuentas existen, sin exponer ninguna credencial.

4. 1.4

   Conectar todo y preparar el control continuo

   1 h

   Enlazas el repositorio de NexoCRM con GitHub y Vercel, creas la memoria persistente del asistente (CLAUDE.md, docs/architecture.md, docs/plans/) y haces el primer deployment de prueba.

   Práctica segura

   Dos ejercicios sin tocar tu repositorio. En el release-flow-simulator ordenas los ocho pasos de un cambio, del plan al smoke test; equivocarte aquí es gratis, equivocarte con un push real no lo es tanto. En el responsibility-map relacionas cada lugar (ordenador local, GitHub, Vercel, Supabase) con su fuente de verdad y con su regla de uso.

   Evidencia

   Demuestra que el circuito local → GitHub → Vercel funciona y que la memoria del asistente existe, sin exponer ningún valor sensible.

Qué se trabaja

• Definir los dos perfiles del CRM, propietario/a y miembro del equipo, con sus decisiones y sus tareas frecuentes.
• Limitar el MVP a cuentas y workspace, contactos, empresas, oportunidades, tareas, actividades y dashboard; todo lo demás va a 'Fuera del MVP'.
• Escribir historias con criterios Dado que / cuando / entonces verificables antes de pedir cualquier cambio a la IA.
• Justificar cada pantalla y cada campo con una historia: ninguna pantalla existe solo porque queda bonita.

Lecciones del módulo

1. 2.1

   Usuarios, flujos y propuesta de valor

   1 h

   Defines quién usa NexoCRM (propietario/a y miembro del equipo), qué decide cada perfil y cómo viaja un lead hasta el cierre; el resultado vive en docs/product/users-and-flows.md y será el contexto de todos los prompts siguientes.

   Práctica segura

   En el journey map ordenas los ocho pasos del flujo 'nuevo lead -> seguimiento -> oportunidad -> cierre' de la agencia. Es seguro porque trabajas sobre un caso ficticio sin tocar tu repositorio, y el feedback te dice qué dato se crea en cada paso, justo lo que necesitarás para revisar el borrador de la IA. El quiz de job to be done te entrena a distinguir necesidad, solución y demografía.

   Evidencia

   Demuestra que el documento existe, está versionado y que la propuesta de valor cabe en una frase que alguien ajeno al negocio entiende.

2. 2.2

   Historias de usuario y criterios de aceptación

   1 h

   Escribes las doce historias del núcleo comercial de NexoCRM, las que guiarán cada petición a Claude Code o Codex durante el resto del curso, y los criterios con los que comprobarás su trabajo; viven en docs/product/user-stories.md.

   Práctica segura

   En el editor de criterios marcas, entre siete criterios del CRM, cuáles son ambiguos; el feedback reescribe cada uno de forma verificable. Es seguro porque los criterios son de ejemplo y no tocas tu documento, y te entrena en la revisión que harás después sobre los borradores de la IA. La actividad de Dado que / cuando / entonces te hace montar dos criterios completos pieza a pieza.

   Evidencia

   Demuestra que las doce historias existen, están numeradas y versionadas, y que al menos una tiene criterios que otra persona podría ejecutar sin preguntarte nada.

3. 2.3

   Navegación, pantallas y diseño de datos inicial

   1 h

   Conviertes las historias en el menú de NexoCRM (Dashboard, Contactos, Empresas, Oportunidades, Tareas, Ajustes) y en los campos de contacts, companies, deals y tasks que usará la base de datos en el módulo 4; el resultado vive en docs/product/navigation-and-fields.md.

   Práctica segura

   En la actividad de arquitectura de información unes nueve necesidades del equipo con la pantalla que las resuelve. Es seguro porque las pantallas son las del CRM de ejemplo y no tocas tu documento; el feedback explica por qué cada necesidad vive en una lista, un detalle, un formulario o el dashboard. El quiz de campos te entrena a decidir en qué entidad vive cada dato antes de que la IA lo decida por ti.

   Evidencia

   Demuestra que el mapa de navegación y los campos existen, que cada pantalla tiene historia y que los nombres de campo coinciden con el modelo oficial.

Qué se trabaja

• Usar TypeScript, rutas en inglés dentro del grupo app/(app) y componentes reutilizables en components/, con estados de carga, vacío y error definidos desde el principio.
• Revisar .gitignore antes de publicar la aplicación para que node_modules, .next y .env.local nunca lleguen a GitHub; .env.example sí se versiona.
• Entender commit, push, ramas y pull request como red de seguridad, con cuatro comandos básicos y sin convertir Git en una barrera de entrada.
• Revisar cada propuesta de Claude Code o Codex con el mapa del proyecto en la cabeza: plan antes de código, diff antes de commit, pruebas antes de evidencia.

Lecciones del módulo

1. 3.1

   Crear el proyecto y entender su estructura

   1 h 15 min

   La carpeta nexo-crm que creaste en el módulo 1 se convierte en la aplicación Next.js 15 con TypeScript y Tailwind sobre la que se construirá NexoCRM durante todo el curso.

   Práctica segura

   Antes de tocar tu proyecto, practica a ubicar cambios en la carpeta correcta con un árbol de archivos ficticio y comprueba con un quiz breve que entiendes rutas, layouts y variables de entorno. Puedes equivocarte tantas veces como quieras: no se toca ningún archivo real.

   Evidencia

   Demuestra que el proyecto existe, arranca y está documentado. Las evidencias se revisan tal cual: comprueba que no contienen secretos antes de subirlas.

2. 3.2

   Sistema visual y pantallas estáticas

   1 h 15 min

   NexoCRM gana su shell de aplicación (barra lateral y cabecera) y las cinco pantallas estáticas /dashboard, /contacts, /companies, /deals y /tasks que después se conectarán a Supabase.

   Práctica segura

   Antes de construir las pantallas, entrena el ojo con un ejercicio de emparejar: cada situación de una pantalla con datos (carga, vacío, sin resultados, error, con datos, éxito) con lo que la persona usuaria debería ver. No toca tu proyecto y te da el vocabulario para revisar lo que genere la IA.

   Evidencia

   Demuestra que el shell existe, que las cinco rutas navegan y que los estados vacío y de carga están resueltos. Todo con datos ficticios.

3. 3.3

   GitHub como historial y garantía de recuperación

   1 h 30 min

   El repositorio privado que creaste en el módulo 1 recibe la aplicación Next.js con un .gitignore correcto y un historial de commits legible; Vercel, conectado desde la lección 1.4, publica ya la aplicación en cada push.

   Práctica segura

   Practica sobre un repositorio simulado: publica cambios pendientes con la secuencia correcta de comandos, revisa un .gitignore con fallos que dejarían pasar secretos y distingue mensajes de commit útiles de los que no dicen nada. Nada de esto toca tu proyecto.

   Evidencia

   Demuestra que la aplicación está en GitHub, que el historial es legible y que no se ha subido nada que no debía. Revisa cada captura antes de adjuntarla.

Qué se trabaja

• Claves, relaciones 1:N, índices sobre workspace_id y migraciones versionadas en supabase/migrations.
• Sesión con Supabase Auth y @supabase/ssr: cliente de navegador, cliente de servidor y middleware que protege rutas.
• Distinguir NEXT_PUBLIC_SUPABASE_ANON_KEY (pública, limitada por RLS) de SUPABASE_SERVICE_ROLE_KEY (salta RLS, nunca al cliente ni al repositorio).
• Probar el aislamiento entre workspaces con dos usuarios ficticios: ocultar un botón no es seguridad, RLS sí.

Lecciones del módulo

1. 4.1

   Modelado relacional para un CRM

   1 h 30 min

   Defines el esquema completo de NexoCRM: nueve tablas con claves, relaciones e índices que usarás durante el resto del curso.

   Práctica segura

   En el schema builder conectas las siete entidades de negocio de NexoCRM eligiendo la cardinalidad de cada relación y colocando campos en su tabla. Es un tablero interactivo: puedes equivocarte y volver a intentarlo sin tocar tu proyecto ni Supabase.

   Evidencia

   Demuestra que el modelo existe, está versionado y que entiendes las decisiones tomadas.

2. 4.2

   Crear y consultar la base de datos

   1 h 15 min

   La base de datos de NexoCRM pasa de diagrama a tablas reales en Supabase, con datos ficticios que ya puedes consultar.

   Práctica segura

   En SQL ordering colocas en secuencia los bloques de una migración con seed: tablas padre, tablas hijas, claves y foreign keys, índices, datos ficticios y consulta de comprobación. Practicas el orden sin ejecutar nada contra tu proyecto. Después, el cuestionario te hace decidir qué hacer cuando un cambio se hizo a mano en el Table Editor.

   Evidencia

   Demuestra que la base de datos existe, tiene datos ficticios y responde a las consultas del negocio.

3. 4.3

   Autenticación y perfiles

   1 h 15 min

   NexoCRM gana registro, acceso, cierre de sesión, recuperación de contraseña, un perfil creado automáticamente y el workspace inicial con sus seis etapas de pipeline.

   Práctica segura

   En auth flow order colocas en secuencia el recorrido de una cuenta: registro, verificación, sesión, ruta protegida, cierre de sesión y comprobación del caso de error. El cuestionario de claves te obliga a decidir qué puede ir al navegador y qué no, sin riesgo para tu proyecto.

   Evidencia

   Demuestra que una persona puede registrarse, entrar, salir y que las rutas privadas están cerradas sin sesión.

4. 4.4

   Row Level Security sin miedo

   1 h

   NexoCRM queda protegido: cada workspace ve solo sus datos gracias a políticas RLS verificadas con dos usuarios ficticios.

   Práctica segura

   En RLS decision resuelves ocho casos con dos workspaces, un usuario sin sesión, dos personas propietarias, alguien que pertenece a los dos negocios y un intento de insert con workspace ajeno. Decides permitir o denegar y el feedback te explica qué cláusula (USING o WITH CHECK) actúa en cada caso. El cuestionario final fija la idea central: ocultar un botón no es seguridad.

   Evidencia

   Demuestra que RLS está activa en todas las tablas y que dos usuarios ficticios no pueden ver ni escribir datos del otro workspace.

Qué se trabaja

• Validar datos con Zod y mostrar errores que ayuden a corregir.
• Construir búsqueda, filtros y vistas de detalle con datos persistidos.
• Conectar empresa y contactos con integridad y feedback de interfaz.
• Situar cada credencial en su sitio: pública, secreto de servidor o personal.

Lecciones del módulo

1. 5.1

   Cliente de Supabase, tipos y datos reales

   1 h

   NexoCRM deja de ser una maqueta: endureces la conexión con Supabase que montaste en M4 y añades los tipos de dominio y la capa de acceso a datos que usarán todas las pantallas del módulo.

   Práctica segura

   Antes de tocar tu proyecto, clasificas diez valores reales de un proyecto Next.js + Supabase en público, secreto de servidor o credencial personal, y revisas un componente con una clave pegada para detectar por qué es grave. Te equivocas sin consecuencias y llegas a la tarea con el criterio claro.

   Evidencia

   Demuestra que las credenciales están bien situadas, que Git no las versiona y que la aplicación ya lee datos ficticios de Supabase.

2. 5.2

   Lista, búsqueda y filtros de contactos

   1 h 15 min

   La pantalla /contacts de NexoCRM pasa de estática a real: lista, busca y filtra los contactos del workspace leyendo de Supabase a través de la capa de datos de 5.1.

   Práctica segura

   Sobre un conjunto ficticio de seis contactos, predices qué debe devolver cada combinación de búsqueda y filtros antes de tocar código. Si te equivocas, aprendes cómo se combinan los criterios sin romper nada de tu proyecto.

   Evidencia

   Demuestra que la lista funciona con datos reales de tu Supabase, que los filtros se combinan y que el estado vacío informa y ofrece una salida.

3. 5.3

   Formulario de contacto robusto

   1 h 15 min

   NexoCRM gana las pantallas /contacts/new y /contacts/[id]/edit: alta y edición de contactos con validación compartida entre navegador y servidor, empresa asociada, fuente, estado y siguiente seguimiento.

   Práctica segura

   Revisas un esquema Zod de contacto propuesto por la IA y marcas sus fallos, y después eliges el mensaje de error que de verdad ayuda a corregir. Practicas el ojo crítico sin tocar tu proyecto.

   Evidencia

   Demuestra que el formulario crea y edita contactos reales en tu Supabase y que rechaza datos incorrectos con mensajes útiles.

4. 5.4

   Empresas y vista de detalle

   1 h 30 min

   NexoCRM completa su núcleo: CRUD de empresas, detalle de empresa con sus contactos y detalle de contacto con su empresa enlazada y la actividad reciente.

   Práctica segura

   Antes de tocar el proyecto, decides dónde vive cada dato entre company, contact, deal y activity y qué cardinalidad tiene cada relación. Practicas el criterio de modelado sin riesgo para tu base de datos.

   Evidencia

   Demuestra que la relación empresa-contactos funciona de extremo a extremo con datos ficticios y que la interfaz avisa antes de una acción destructiva.

Qué se trabaja

• Medir cada oportunidad con importe, probabilidad, fecha esperada y causa de pérdida; el valor ponderado (importe × probabilidad) resume el pipeline.
• Etapas configurables por workspace en deal_stages (position, color, is_closed, is_won), sembradas por el alta de workspace y nunca escritas como constantes en el código.
• Vista por columnas con alternativa accesible en lista (?view=list) y selector de etapa; arrastrar y soltar nunca es el único camino.
• Cada cambio de etapa registra una actividad stage_change para que la venta tenga trazabilidad de principio a fin.

Lecciones del módulo

1. 6.1

   Pipeline y etapas

   1 h

   NexoCRM da sentido a las seis etapas de deal_stages que el primer acceso creó en 4.3: revisas orden, color e indicadores, corriges lo que no cuadre y las muestras por primera vez en /pipeline.

   Práctica segura

   Antes de tocar la base de datos, clasificas ocho situaciones comerciales reales en las seis etapas. Es una práctica sin riesgo: no hay código ni datos, solo criterio. El feedback justifica cada respuesta para que tu equipo y tú clasifiquéis igual.

   Evidencia

   Demuestra que las etapas están correctas en la base de datos, siguen protegidas por RLS y se ven en la interfaz.

2. 6.2

   CRUD de oportunidades y valor esperado

   1 h 30 min

   NexoCRM da uso por fin a la tabla deals: lista en /deals y formulario de alta y edición con importe, probabilidad, fecha estimada, etapa y motivo de pérdida.

   Práctica segura

   Revisas el JSON de una oportunidad tal y como llegaría a la server action y marcas todos los problemas. Practicas la lectura crítica que después aplicarás al código del asistente, sin tocar tu base de datos.

   Evidencia

   Demuestra que puedes crear, editar y cerrar oportunidades, y que las validaciones existen también en la base de datos.

3. 6.3

   Vista de pipeline funcional

   1 h 30 min

   La página /pipeline pasa de listar etapas a ser un tablero de seis columnas con vista de lista accesible y una acción de mover oportunidades que registra cada cambio como actividad stage_change.

   Práctica segura

   Ordenas los seis pasos de una transición de etapa y clasificas seis movimientos según sean válidos, exijan motivo o no tengan efecto. Sin tocar el proyecto, fijas el criterio que después revisarás en el código del asistente.

   Evidencia

   Demuestra que el tablero muestra las seis etapas y que una transición ha quedado persistida y trazada en la base de datos.

Qué se trabaja

• Una tarea sin fecha ni responsable no es una tarea: título con verbo, due_date, prioridad, estado y contacto u oportunidad relacionada, con las vistas de /tasks (Pendientes, Hoy, Atrasadas, Próximas y Hechas) calculadas en el servidor sobre la tabla que ya existe desde el módulo 4.
• El historial mantiene el contexto de llamadas, notas y cambios de etapa en una sola tabla activities: las notas las escribe una persona, los eventos los registra la server action y nadie los edita.
• Los próximos seguimientos se ven sin buscarlos: la lista de hoy y atrasadas es la pantalla de inicio del trabajo diario y ninguna tarea se pierde dentro de una ficha.
• Textos de error, vacío y éxito que dicen qué ha pasado y qué hacer a continuación, anunciados con aria-live y con confirmación antes de borrar.

Lecciones del módulo

1. 7.1

   Tareas accionables y prioridades

   1 h 15 min

   NexoCRM pone en marcha la tabla tasks que ya existe desde 4.1 y estrena la página /tasks con las vistas Pendientes, Hoy, Atrasadas, Próximas y Hechas, para que ningún seguimiento se quede sin fecha ni responsable.

   Práctica segura

   Antes de programar, ordenas seis tareas de una misma mañana aplicando la regla que después implementará la lista: primero la fecha, después el impacto. No hay código ni datos reales; solo el criterio que hace útil la vista Hoy. El feedback justifica cada posición.

   Evidencia

   Demuestra que las vistas funcionan con datos ficticios y que coinciden con la base de datos.

2. 7.2

   Notas e historial de actividad

   1 h 15 min

   NexoCRM añade notas manuales a la tabla activities que ya registra los eventos automáticos, ajusta sus políticas para que solo el autor pueda tocar sus notas y estrena el timeline cronológico en la ficha de contacto y de oportunidad.

   Práctica segura

   Antes de programar, reconstruyes la historia de una venta ficticia ordenando seis eventos de tipos distintos y emparejas cada situación con su tipo de actividad y su origen (manual o automático). Sin código ni datos reales: solo el criterio que hace legible un historial.

   Evidencia

   Demuestra que el historial mezcla notas manuales y eventos automáticos, que está ordenado y que coincide con la base de datos.

3. 7.3

   Búsqueda global y calidad de interacción

   1 h 30 min

   NexoCRM estrena la búsqueda global sobre contactos, empresas y oportunidades (botón visible y atajo Ctrl/Cmd+K), avisos emergentes (toasts) accesibles con aria-live y confirmaciones antes de borrar en todo el CRM.

   Práctica segura

   Antes de escribir una línea, eliges el mensaje de error que de verdad ayuda entre cinco variantes que se ven a diario, y marcas qué debe tener un buen estado vacío. Sin código ni riesgo: es el criterio que después aplicarás a cada texto de NexoCRM.

   Evidencia

   Demuestra en vídeo que la búsqueda funciona desde cualquier página, que se navega a un resultado y que los mensajes de la interfaz orientan a la acción.

Qué se trabaja

• Cinco indicadores con fórmula y acción: oportunidades activas, valor ponderado (suma de amount × probability / 100 de las abiertas), ventas ganadas del mes por updated_at de las etapas ganadas, tareas vencidas y seguimientos a 7 días.
• El cálculo vive en lib/kpis.ts como función pura con test unitario frente a un seed conocido; el cargador solo consulta Supabase con filtro explícito por workspace.
• El dashboard se prueba con el seed y con un workspace vacío: ceros reales en las tarjetas y estado vacío con la acción que lo llena, nunca NaN ni datos de ejemplo.
• Cada tarjeta y cada sección enlazan a la pantalla filtrada donde se ejecuta la acción siguiente; lo urgente arriba y nada de gráficos decorativos.

Lecciones del módulo

1. 8.1

   Elegir indicadores útiles

   1 h

   NexoCRM fija en docs/product/kpis.md los cinco indicadores de su dashboard, cada uno con fórmula sobre las tablas reales, ventana temporal y acción asociada, antes de escribir una sola consulta.

   Práctica segura

   En kpi-selector clasificas ocho indicadores candidatos entre accionables y vanidosos aplicando la pregunta '¿y ahora qué hago?'. Después, un cuestionario te hace validar las fórmulas de los cinco KPIs frente a las columnas reales. No tocas tu proyecto: practicas el criterio que aplicarás al revisar la propuesta de la IA.

   Evidencia

   Demuestra que los indicadores están definidos con precisión suficiente para que otra persona (o la IA) los implemente sin preguntar.

2. 8.2

   Consultas y agregaciones

   1 h 15 min

   NexoCRM gana lib/kpis.ts, una función pura que calcula los cinco indicadores a partir de filas ya filtradas por workspace, un test unitario que fija los resultados frente a un seed conocido y un cargador lib/data/dashboard.ts que consulta Supabase.

   Práctica segura

   En query-to-kpi-match emparejas seis consultas SQL con el indicador o bloque del dashboard que alimentan, fijándote en el detalle que distingue cada una (join con etapas, 100.0, updated_at, ventana de fechas). Después, un cuestionario te hace calcular los cinco KPIs sobre el fixture del test. Todo sin tocar tu base de datos.

   Evidencia

   Demuestra que los números del dashboard son correctos por dos caminos independientes: el test unitario y la consulta SQL.

3. 8.3

   Dashboard usable

   1 h 45 min

   NexoCRM estrena su /dashboard real: tarjetas KPI que enlazan a la acción siguiente, tareas vencidas arriba, próximos seguimientos, pipeline resumido por etapa y un estado vacío que orienta, todo responsive y probado con datos y sin ellos.

   Práctica segura

   En dashboard-priority-lab ordenas seis bloques del panel de arriba a abajo según la urgencia de la acción que provocan. Después, un cuestionario te hace decidir qué debe ver un workspace recién creado y sin datos. Practicas el criterio de composición sin tocar tu código.

   Evidencia

   Demuestra que el dashboard orienta la acción con datos y también sin ellos, y que funciona en pantalla estrecha.

Qué se trabaja

• Niveles de prueba (manual, unitaria, integración, end-to-end) y qué probar primero en NexoCRM: validación Zod, cálculo de KPIs y el flujo login → crear contacto con Vitest y Playwright.
• Vincular GitHub y Vercel para desplegar automáticamente tras cada push, con Framework Preset Next.js, root directory correcto y preview deployments por rama.
• Variables de entorno por Development, Preview y Production: solo las NEXT_PUBLIC_ llegan al navegador, .env.local nunca se sube y la service_role key no existe en el proyecto.
• Diagnosticar la diferencia entre local y producción con commit, variables y logs (Vercel, Supabase, navegador), no con adivinanzas; QA de aceptación, triage de defectos y rollback seguro.

Lecciones del módulo

1. 9.1

   Pruebas que dan confianza

   1 h 15 min

   NexoCRM gana una red de seguridad: casos límite en los tests del esquema de contacto y de computeKpis, y un primer test end-to-end del flujo login → crear contacto con Playwright, instalado y configurado en esta lección.

   Práctica segura

   Dos ejercicios sin tocar tu repositorio. En test-level-match relacionas seis escenarios reales de NexoCRM con el nivel de prueba adecuado y el motivo. En el quiz decides qué hacer con unos tests generados por la IA que pasan pero no protegen nada. Practicas el criterio antes de aplicarlo a tu código.

   Evidencia

   Demuestra que los tests existen, pasan y protegen algo real, sin exponer credenciales del usuario de pruebas.

2. 9.2

   Deploy en Vercel y variables de entorno

   1 h 15 min

   NexoCRM pasa de funcionar en localhost a una URL pública en Vercel, con variables por entorno, preview deployments por rama y deploy automático en cada push a main.

   Práctica segura

   Dos ejercicios sin riesgo. En deploy-checklist marcas qué debe estar hecho antes de pulsar Deploy y dejas sin marcar las trampas que parecen atajos (subir .env.local, desactivar RLS, exponer una clave de servicio). En el quiz de diagnóstico eliges el primer paso correcto cuando algo funciona en local y no en Vercel.

   Evidencia

   Demuestra que NexoCRM está publicado, que las variables están en los tres entornos y que sabes dónde mirar cuando algo falla, sin exponer ningún valor.

3. 9.3

   QA, logs y cambios seguros

   1 h 30 min

   NexoCRM pasa su QA final: veinte comprobaciones sobre la versión publicada, hasta tres defectos reales corregidos con el ciclo completo y un procedimiento de vuelta atrás ensayado.

   Práctica segura

   Dos ejercicios sin tocar producción. En bug-triage clasificas ocho defectos reales de un CRM en bloqueante, importante o mejora, razonando por impacto en quien lo usa y no por dificultad. En el quiz de rollback eliges las dos acciones correctas cuando un cambio recién publicado rompe la lista de contactos.

   Evidencia

   Demuestra que el QA se hizo sobre la versión publicada, que los defectos se corrigieron con el ciclo completo y que sabes volver atrás.

Qué se trabaja

• Cerrar con documentación completa (README, docs/architecture.md, docs/user-guide.md para la persona del negocio y docs/known-limitations.md honesto), demo de producto, revisión de evidencias y backlog priorizado.
• Rúbrica final de 100 puntos en siete áreas (se aprueba con 70), autoevaluación con evidencias enlazables y roadmap por impacto y esfuerzo: Hacer ya, Planificar y Aparcar.
• Cómo pedir la próxima mejora a Claude Code o Codex con control y pruebas usando el prompt de mejora continua: plan de cinco pasos, confirmación, cambio mínimo, comprobaciones y sin commit ni push sin permiso.
• Certificado de aprovechamiento interno al completar las lecciones, superar las actividades con el 70 %, obtener 70/100 o más en la rúbrica y verificar las ocho evidencias finales; no es una titulación oficial.

Lecciones del módulo

1. 10.1

   Documentación que permite continuar

   1 h

   Cierras la documentación de NexoCRM: README completo (instalación, variables, scripts, modelo de datos y URL de demo), docs/architecture.md al día, docs/user-guide.md para la persona del negocio y docs/known-limitations.md honesto, para que otra persona pueda continuar el proyecto sin ti.

   Práctica segura

   En el readme-gap-checker lees un README incompleto de un CRM parecido a NexoCRM y marcas qué secciones faltan para que otra persona pueda arrancarlo y continuarlo. En el quiz de documentación eliges qué entrada de known-limitations está bien escrita. Ninguna de las dos toca tu repositorio: entrenas el ojo con documentación ajena antes de revisar la tuya.

   Evidencia

   Demuestra que la documentación permite continuar sin ti: el README es revisable por otra persona, docs/user-guide.md sirve a la persona del negocio y los límites están escritos con honestidad.

2. 10.2

   Demo de producto y narrativa

   1 h

   Preparas y ejecutas la demo de cinco minutos de NexoCRM con datos ficticios: problema, usuario, flujo completo, valor, arquitectura y próximos pasos, sin exponer secretos ni datos reales.

   Práctica segura

   En el demo-storyboard ordenas las seis escenas de una demo de cinco minutos y compruebas por qué el orden problema → usuario → flujo → valor → arquitectura → próximos pasos funciona. En el quiz de la demo marcas qué no debe aparecer nunca en pantalla. Practicas con un guion ajeno antes de exponer el tuyo.

   Evidencia

   Demuestra que la demo existe, que se preparó con datos ficticios y que no expone nada sensible.

3. 10.3

   Evaluación final y hoja de ruta

   1 h

   Evalúas NexoCRM con la rúbrica de 100 puntos, escribes docs/product/roadmap.md con seis mejoras priorizadas por impacto y esfuerzo, abres las primeras issues en un board de GitHub y pides la siguiente mejora a Claude Code o Codex con control.

   Práctica segura

   En el roadmap-prioritizer clasificas ocho mejoras de NexoCRM en Hacer ya, Planificar y Aparcar según impacto y esfuerzo, con feedback de por qué cada una va donde va. En el final-evidence-check repasas una a una las ocho evidencias finales del proyecto; solo se completa cuando las ocho están verificadas de verdad, no de memoria.

   Evidencia

   Demuestra que el proyecto se ha evaluado con la rúbrica, que su evolución está priorizada con criterio y que el repositorio final está listo para continuar.