IA Academy evoluciona en público, en rondas. Esta página lista los 66 frentes de las dos rondas hasta ahora — de "academia de cursos" a Career Center, a "aprender → practicar → demostrar → prepararse para trabajar" — 56 ya construidos e integrados con lo que ya existía, y el resto clasificado entre lo que sigue y lo que queda para más adelante, con el motivo de cada decisión.
Construido, integrado con lo que ya existía y verificado.
Wizard de objetivo + nivel + intereses + tiempo disponible que recomienda una ruta o carrera real.
Por qué: Es la puerta de entrada a todo lo demás: sin esto, el resto de la personalización no tiene de dónde partir. Reutiliza rutas y carreras existentes, no crea contenido nuevo.
Ver en la plataformaEvaluación de 12 preguntas en 6 categorías, con fortalezas/debilidades y nivel calculado.
Por qué: Mismo wizard que el punto 1; separarlo hubiera duplicado la UI. Scoring 100% determinístico y auditable, sin costo variable.
Ver en la plataformaReencuadrado con honestidad, con autorización explícita del usuario para adelantar esto sabiendo que estaba reservado a un tier pago futuro: CourseSearchBox en cada lección busca la duda dentro del curso (contenido + quizzes) y en el Diccionario de IA — nunca se presenta como chat ni como "el tutor responde", porque no lo hace.
Por qué: Un asistente conversacional real necesita comprensión de lenguaje natural genuina para ser honesto sobre qué es — una búsqueda por palabras clave disfrazada de chat generaría una expectativa falsa. Lo honestamente construible sin llamar a un modelo es encontrar DÓNDE ya está explicado lo que la persona pregunta, y decir exactamente eso. El AI Tutor conversacional real sigue reservado al tier pago que pueda absorber el costo variable por pregunta — esto no es una versión barata de esa feature, es la versión honesta de "ayudarte a encontrar la respuesta" en vez de "respondértela".
Sustancialmente entregado por Practice Lab (pt. 3 del roadmap original) desde una ronda anterior: ejercicios prácticos calificados automáticamente por el AI Evaluator rule-based. Lo único que sigue gateado es la palabra "IA" siendo un modelo real en vez de un rubric — ver AI Tutor (pt. 3) para el mismo razonamiento.
Por qué: Este ítem y Practice Lab pedían la misma experiencia de usuario ("ejercicio práctico, calificado automáticamente, sin esperar a un humano") — Practice Lab ya la resuelve con evaluateSubmission() en vez de un modelo. No hay una segunda feature que construir acá, solo reconocer que ya existe con un motor distinto al que el ítem original imaginaba.
Página que reúne proyectos completados, herramientas usadas e insignias ganadas por proyecto.
Por qué: Alto impacto para el objetivo "demostrar habilidades" del brief, y de bajo costo: es una vista nueva sobre datos que ya existían (proyectos, insignias, progreso).
Ver en la plataformaPortfolio con configuración de visibilidad + URL /portfolio/[username] preparada, más Build my AI CV (4 estilos, datos reales) — un perfil combinando portfolio, carreras, certificados e insignias.
Por qué: Se resolvió en la segunda ronda de evolución (v2) con Portfolio Builder + AI CV Builder. La URL pública sigue siendo una vista previa de un solo navegador — todavía no hay backend de usuarios para que sea realmente pública entre dispositivos.
Ver en la plataforma10 carreras reales (AI Developer, Prompt Engineer, AI Automation Specialist, etc.) con requisitos evaluados por el mismo motor de insignias.
Por qué: Consolida los pts. 9, 10 y 18 (Carreras + Job Readiness + Misiones) en un solo sistema para no duplicar una lógica de requisitos que ya existía para insignias.
Ver en la plataformaPanel de % de preparación en vivo para la carrera más cercana del usuario.
Por qué: Mismo sistema que el punto 9 — es la misma pregunta ("¿qué tan cerca estoy de X?") vista desde el ángulo del usuario en vez del catálogo.
Ver en la plataformaUn prompt, término del Glosario o mini-desafío de Practice Lab distinto cada día (DailyAI, en /dashboard y la home), elegido determinísticamente por fecha sobre contenido que ya existe.
Por qué: El bloqueo original ("necesita una fuente de contenido curado día a día") se resolvió rotando sobre lo que ya existe en vez de esperar un pipeline de curación nuevo: mismo día, mismo pick para todos, sin aleatoriedad ni job que correr. Ruteado por useToday() (extraído de AnalyticsView a un hook compartido) para evitar el mismatch de hidratación de "hoy" — ver docs/ARCHITECTURE.md.
Cada ficha de herramienta suma "Novedades sobre [herramienta]": los artículos de Noticias de IA que la mencionan (NewsArticle.relatedTools), ordenados por fecha.
Por qué: Reencuadrado con honestidad: los 5 artículos de news.ts son deliberadamente atemporales/guía (ver su propio comentario), no anuncios de versión con changelog real — armar un changelog estructurado inventaría datos que no existen. Lo honesto y ya soportado por el modelo de datos es "qué se escribió sobre esta herramienta", etiquetado explícitamente como eso, no como changelog oficial.
Ver en la plataformaSección 🔥 Trending / 🆕 Nuevas / ⭐ Populares sobre el catálogo de herramientas real.
Por qué: Pura curaduría editorial sobre datos existentes (3 flags opcionales en Tool). Cero costo, alto valor: comunica que el catálogo se mantiene activo.
Ver en la plataformaEl soporte a 3 herramientas ya existía (SLOTS=3, sin que el roadmap lo reflejara); lo que realmente faltaba — resaltar diferencias automáticamente — ya está: cada fila marca si las herramientas difieren, más un toggle "mostrar solo lo que difiere".
Por qué: Refactor a filas data-driven (ComparisonRow[]) en vez de ~10 bloques <tr> casi idénticos, para que el chequeo de diferencia (comparación de igualdad serializada) se aplique de forma uniforme a las ~13 filas en vez de reimplementarse en cada una.
Ver en la plataformaLas recomendaciones del dashboard ahora explican el motivo (continuar un curso, cerrar un gap de carrera, reforzar una debilidad del diagnóstico) en vez de ser una lista genérica.
Por qué: Reutiliza el heurístico de recommendations.ts ya existente y lo conecta con Carreras (pt. 9) y el Skill Assessment (pt. 2) — cero costo variable, mejora directa de percepción de personalización.
Ver en la plataformaConstruido junto con el pt. 46 ("Smart Review") — eran la misma feature descripta dos veces en distintas rondas del roadmap. Ver el pt. 46 para el detalle real de lo construido.
Por qué: Al implementar el pt. 46 se detectó que este ítem describía exactamente lo mismo (repetición espaciada de términos del Glosario y preguntas falladas del Assessment) con una redacción más corta — se resolvió como una sola feature en vez de dos builds parciales, mismo criterio que la limpieza de duplicados anterior en este roadmap (ver pt. 29).
Reencuadrado con honestidad: en vez de un banco de preguntas por nivel de dificultad (la mayoría de las lecciones tienen exactamente 1 pregunta de quiz — no hay pool del que adaptar), cada pregunta que se falla se suma automáticamente a la cola de Smart Review (pt. 46).
Por qué: "Ajustar la dificultad según aciertos previos" asume un banco de preguntas por lección que este catálogo no tiene (140 quizzes, casi todos de 1 sola pregunta) — construirlo habría significado reescribir contenido de 48 cursos, no una mejora de motor. Lo que sí es genuinamente adaptativo sin inventar esa jerarquía: lo que fallaste vuelve a aparecer (en /repaso), lo que no fallaste no. Ver docs/ARCHITECTURE.md.
Consolidado dentro de Carreras (pt. 9): cada carrera es, en los hechos, una misión de varios pasos con recompensa de XP.
Por qué: Construir "Misiones" como sistema aparte hubiera duplicado exactamente el motor de requisitos de insignias/carreras. Se decidió activamente no crear ese duplicado.
Ver en la plataformaLos 29 proyectos del catálogo (18 + 11 capstones) ahora tienen un rubric evaluado por el mismo AI Evaluator que ya usaban Practice Lab, Missions e Interview — score + fortalezas + mejoras + solución mejorada, en la propia página del proyecto.
Por qué: Reusa el evaluador existente (4ta vez), no crea nada nuevo. Deliberadamente sin XP propio: 'Marcar como completado' ya recompensa terminar el proyecto — el review es una segunda señal opcional ('qué tan bueno es lo que hiciste'), no una segunda forma de ganar la misma recompensa.
Ver en la plataformaCertificado profesional evidence-based por Carrera: requiere cursos + challenges/projects + XP + capstone (100% de readiness), sin tocar el sistema de certificados de Cursos/Rutas.
Por qué: Se resolvió en la v2: cada Carrera ahora tiene un capstone project que es, a la vez, uno de sus propios requirements — así que "100% listo" y "capstone hecho" son el mismo hecho, evaluado por el motor de requisitos existente sin lógica paralela. Certificate (rutas) y CareerCertificate (carreras) se mantienen como tipos separados a propósito — ver la nota en types/index.ts.
Ver en la plataformaUn quiz de 5 preguntas por carrera (55 en total), con 80% para aprobar. Aprobarlo se registra en passedCareerExams y es un requirement más de esa carrera ("careerExamPassed") — el certificado profesional ahora exige cursos + capstone + XP + examen aprobado.
Por qué: Se sumó un nuevo tipo de BadgeRequirement ("careerExamPassed") en vez de forzar el examen en el sistema de rubrics del AI Evaluator: un examen final prueba conocimiento con respuesta correcta determinística, para lo que un quiz de opción múltiple (mismo patrón que LessonQuiz) es la herramienta correcta — no todo tiene que pasar por el evaluador de texto libre.
Ver en la plataformaMapeo visual de estrellas (1 a 5) sobre el Level existente de cursos y proyectos.
Por qué: Deliberadamente no es un dato nuevo: es una capa de presentación sobre Level para no crear una segunda taxonomía de dificultad en paralelo.
Ver en la plataformaConstruida la mitad "medir" en /admin/auditoria-practica: minutos de lectura (durationMin autorado) vs. minutos de práctica estimados (ejercicio + quiz + proyecto final) por curso, rankeado. Catálogo hoy: ~60% práctica promedio, los 48 cursos por debajo del objetivo de 80%.
Por qué: La mitad "aumentar" sigue siendo, a propósito, trabajo editorial humano: decidir qué ejercicio agregarle a una lección específica no es algo que este pase deba auto-generar. Se auditó primero con una lectura por conteo de palabras — dio 96-98% en casi todos los cursos porque las 140 lecciones ya tienen ejercicio Y quiz, así que no distinguía nada real — y se corrigió usando durationMin (ya autorado por lección, literalmente etiquetado "minutos de lectura" en la página de la lección), que sí produjo un ranking creíble.
XP, 10 niveles, insignias, logros, rachas, árbol de habilidades y ranking — con lenguaje y estética profesional, no infantil.
Por qué: Construido en la fase de gamificación previa a esta iteración; esta ronda lo extiende (Carreras, Portfolio) en vez de reconstruirlo.
Ver en la plataformaPrincipio permanente del proyecto: sin planes pagos, sin suscripciones, sin funciones reservadas a quien pague — nunca.
Por qué: Decisión explícita y permanente, no una fase pendiente: IA Academy no tendrá jamás planes Free/Pro/Premium/Enterprise ni ningún otro esquema de pago (se auditó el código: nada lee user.plan para restringir acceso, y ese campo quedó eliminado del modelo de datos). Las funciones con costo variable por uso (Tutor con IA, Practice Mode con IA real, Sandbox, Battle, Reviews con IA real) siguen deliberadamente sin implementar — no porque se estén guardando para un tier pago futuro que no va a existir, sino porque un costo variable por usuario es estructuralmente incompatible con una plataforma gratuita para siempre. La misión del proyecto es democratizar el acceso a la educación en IA para estudiantes, docentes e instituciones, sin barreras económicas.
Resuelto por Learning Analytics (pt. 44, /analitica): racha, horas estudiadas estimadas y progreso por categoría, con gráficos de XP semanal/mensual.
Por qué: Quedó mal marcado como pendiente en la primera ronda — la v2 lo construyó de punta a punta bajo el nombre "Learning Analytics" antes de que alguien revisara si este ítem original ya estaba cubierto. Corregido acá para que el roadmap no muestre la misma feature como pendiente y hecha a la vez.
Ver en la plataforma/admin/analitica: usuarios registrados, certificados emitidos (de ruta y profesionales), insignias otorgadas, top 10 cursos más completados, top 10 herramientas más favoritas, y % promedio de preparación por carrera entre usuarios con progreso real.
Por qué: Es la primera sección de /admin con datos reales de Postgres en vez de src/data/*.ts o localStorage — solo fue posible una vez que el progreso empezó a sincronizarse (pt. 62). Falla en silencio si la base no responde (mismo criterio que el resto de la API), en vez de romper la página de admin.
Ver en la plataformaPasada dedicada de responsividad sobre las páginas nuevas de esta iteración (Carreras, Practice Lab, Misiones, Entrevista, Job Match, CV, Portfolio, Diagnóstico, Admin Analytics).
Por qué: Verificación en viewport 375px (sin overflow horizontal en ninguna) más una revisión visual de cada página — encontró un bug real (no de layout): un hydration mismatch en CvBuilder y PortfolioSettingsPanel por pasar la lectura en vivo de localStorage como getServerSnapshot de useSyncExternalStore en vez de una referencia congelada. Corregido en ambos componentes — ver docs/ARCHITECTURE.md.
Verificar que el crecimiento del catálogo (48 cursos, 11 carreras, 29 proyectos, 55 preguntas de examen) no degrade tiempos de carga.
Por qué: npm run build compila y genera las 347 páginas estáticas en ~2s sin warnings — el patrón "contenido como data" sigue manteniendo el bundle liviano a este volumen. Nada que optimizar todavía.
Metadata, sitemap, robots y datos estructurados para las páginas nuevas (Carreras, Practice Lab, Misiones, Portfolio, Diagnóstico).
Por qué: Auditoría confirmó metadata/generateMetadata presente en todas las páginas nuevas, robots: noindex correcto en las herramientas personales (Portfolio, CV, Diagnóstico, Analytics, Entrevista, Job Match) vs. indexables en el catálogo público (Carreras, Practice Lab, Misiones), y sitemap.ts ya incluía las rutas nuevas. Único gap real: faltaba JSON-LD en /carreras/[slug] (el patrón ya existía en /cursos/[slug]) — agregado con schema.org EducationalOccupationalProgram.
Esta misma página: la clasificación autopriorizada de los 35 puntos, con el motivo de cada decisión.
Por qué: Es, a la vez, el último ítem del brief y el documento que explica cómo se priorizaron todos los demás.
Ver en la plataformaMotor de evaluación rule-based (score + fortalezas + mejoras + solución mejorada) que reutilizan Practice Lab, Real World Missions y el Interview Simulator.
Por qué: Es la pieza de arquitectura que hace posible "practicar y recibir feedback" sin costo variable por uso — un rubric por ejercicio (keywords ponderadas, largo mínimo, patrones vagos) en vez de una llamada a un modelo. Construirla una sola vez y reusarla en 3 lugares evitó 3 evaluadores distintos.
7 laboratorios (Prompt/Research/Automation/Coding/Agent/Image/Content) con ejercicios reales evaluados por el AI Evaluator, sin necesidad de entrar a un curso.
Por qué: Alto valor para la propuesta "aprender haciendo": convierte la plataforma en algo para volver todos los días a practicar, no solo a mirar contenido nuevo. Arquitectura preparada para sumar laboratorios nuevos como pura data.
Ver en la plataforma5 problemas con forma de trabajo real (Support/Marketing/Automation/Developer/Business), con contexto, restricciones, herramientas permitidas y evaluación automática.
Por qué: Es el puente entre "sé usar la herramienta" y "puedo resolver un problema real" — la pieza que más se acerca a un caso de entrevista técnica o un desafío de portfolio.
Ver en la plataformaEl portfolio ahora suma skills, carreras completadas, certificados profesionales y capstones, con un panel para elegir qué mostrar públicamente y una URL /portfolio/[username] preparada.
Por qué: Consolida el pt. 8 original. Desde el pt. 63, la URL pública ya resuelve por publicSlug contra la base — cualquiera con el link la ve desde cualquier dispositivo, no solo el navegador que la configuró.
Ver en la plataformaGenerador de CV con 4 estilos (Professional/Technical/Minimal/Creative) usando skills, cursos, certificaciones, insignias y carreras reales — la experiencia laboral la escribe el usuario.
Por qué: Nunca inventa experiencia (regla explícita del brief); todo lo demás es 100% datos reales de la plataforma. Exportable a PDF vía impresión del navegador — sin backend de generación de documentos.
Ver en la plataformaPegás una descripción de puesto y la plataforma extrae skills mencionadas (contra el vocabulario real de categorías de curso + nombres de herramientas), calcula un % de match y recomienda cursos/proyectos para cerrar la brecha.
Por qué: Mismo heurístico de "score por superposición" que ya usaba el onboarding para recomendar carreras — reusado, no reinventado. Sin llamada a un modelo: matching por keywords sobre un vocabulario cerrado y real.
Ver en la plataforma7 categorías de entrevista con preguntas reales, evaluadas por el AI Evaluator — Interview Score + recomendaciones al finalizar.
Por qué: Cierra el círculo "practicar → demostrar": es el ensayo más parecido a una entrevista real que la plataforma puede ofrecer sin costo variable.
Ver en la plataformaUn capstone project por carrera (11 en total), listado como requirement de esa carrera — completarlo es parte de llegar al 100% de preparación, que es lo que habilita el certificado profesional.
Por qué: Resuelve de una vez los puntos 11/12 del brief original de esta ronda sin arquitectura nueva: el capstone es un Project más (misma UI, mismo botón de completar), y el certificado reusa el motor de requirements ya construido para badges y carreras.
Ver en la plataformaXP semanal/mensual (gráficos SVG livianos, sin librería), tasa de finalización, skills, mejores scores de entrevista y racha — todo derivado de progreso real.
Por qué: El único dato genuinamente nuevo es xpHistory (una foto diaria de XP acumulado, tope 90 días) — todo lo demás se deriva de datos que ya existían. Sin librería de gráficos para no engordar el bundle.
Ver en la plataforma2 ejercicios de texto libre (prompt de viaje, diseño de una automatización) al final de las 12 preguntas de opción múltiple, evaluados por el mismo AI Evaluator que Practice Lab.
Por qué: El AI Evaluator ya existía (pt. 36) y el runner de texto libre también (SubmissionRunner) — extender /diagnostico para reusar ambos fue un cambio acotado: un nuevo paso "practical" en DiagnosticoWizard, sin tocar el wizard existente. Los dos ejercicios pueden sumar una categoría a fortalezas (o sacarla de debilidades) aunque la opción múltiple haya ido mal en esa categoría, y viceversa — miden cosas distintas (reconocer un concepto vs. poder hacerlo). Un promedio muy alto en los prácticos también puede subir el nivel final un escalón.
/repaso: repetición espaciada de preguntas falladas en quizzes de curso y en el diagnóstico, más términos del Glosario marcados a mano — un scheduler de intervalos fijos (1/3/7/14/30/60 días), no un banco de contenido nuevo.
Por qué: Unifica este ítem con el pt. 16 (misma feature, redactada dos veces) y reencuadra el pt. 17 con honestidad (ver su rationale). Nada del contenido se duplica: solo se guardan direcciones (curso+lección+índice de pregunta, índice de pregunta del diagnóstico, slug del glosario) — la pregunta o definición real siempre se resuelve en vivo desde src/data/*.ts, igual que completedProjects/favoriteTools guardan slugs y no contenido. Ver docs/ARCHITECTURE.md.
/noticias reordena los artículos cuyas relatedTools coinciden con las herramientas que el usuario ya conoce (getKnownToolSlugs, de Job Match) primero, marcados "Relevante para vos" — más un filtro por categoría con FilterBar.
Por qué: "Filtrado por skills y herramientas" se acotó a herramientas: relatedTools es el único campo de NewsArticle con un join real posible, no hay categoría de curso que cruzar honestamente contra las 5 categorías de noticia. Nunca oculta contenido — reordena, así que alguien sin progreso ve exactamente el mismo feed cronológico de siempre.
"Mi Watchlist" en /herramientas: cada herramienta favorita con su novedad más reciente (de la sección construida en el pt. 12), marcada "Nuevo" si se publicó en los últimos 30 días.
Por qué: Quedaba bloqueado por no tener una fuente real de "qué cambió" por herramienta — resuelto por el pt. 12 en esta misma ronda. "Aviso de novedades" se implementó como ventana de recencia (¿se publicó hace menos de 30 días?), no como tracking de leído/no-leído por usuario — no hace falta estado nuevo persistido, y es el mismo patrón que un badge "Nuevo" de cualquier feed de contenido real.
El contenido de cada lección detecta términos del Glosario y linkea la PRIMERA aparición de cada uno — clickearlo abre su definición y ejemplo sin salir de la lección (reusa el Modal existente, no un popover nuevo).
Por qué: Solo la primera aparición se linkea a propósito: términos como "IA" o "prompt" aparecen decenas de veces por lección, y linkear cada una sería ruido visual, no ayuda. Reutiliza el mismo Modal de BadgeDetailModal en vez de construir un sistema de posicionamiento de popover nuevo.
getRecommendedCourses penaliza un curso de nivel más bajo que el más alto ya completado en su misma categoría, y prioriza el que sigue justo arriba — "el siguiente paso", no un curso que ya deberías tener superado.
Por qué: "100% en getSkillLevels" reencuadrado: ese estado implica que ya no queda ningún curso de esa categoría por recomendar (completedSlugs ya los excluye a todos), así que la condición literal nunca se dispara sobre un candidato real — igual se agregó como filtro explícito por honestidad con el dato. El caso real y frecuente en este catálogo es una categoría con varios niveles (ej. Prompt Engineering: principiante + intermedio) donde conviene dejar de empujar el básico una vez superado.
PersonalGoalCard en /dashboard y la home: objetivo declarado en /diagnostico + la ruta o carrera que le corresponde (matchRecommendation) + % de avance real (nueva getPathProgress, o getCareerReadiness si es una carrera).
Por qué: Deliberadamente distinto de CareerReadinessCTA ("¿estoy preparado?"): ese widget mide la carrera a la que estás objetivamente más cerca HOY según tu progreso real; este mide el objetivo que DECLARASTE en el diagnóstico, fijo desde ese momento — son dos señales distintas, no la misma tarjeta repetida. De paso se encontró y corrigió un bug real: PathTimeline daba por incompleto todo paso de tipo "proyecto" aunque el usuario ya lo hubiera marcado como completado (completedProjects existe hace rondas; el comentario que decía "no trackeado todavía" había quedado desactualizado).
"La misión de hoy" (XP chico) se muestra junto a Daily AI: es el mismo touchStreak() de siempre otorgando un bonus la primera vez que pasa algo real en el día — sin estado nuevo, sin generador de variedad separado.
Por qué: El bloqueo ("necesita un generador de variedad diaria") ya lo había resuelto Daily AI (pt. 11) para el CONTENIDO mostrado — para la MISIÓN en sí no hacía falta variedad de condición: "completaste tu misión de hoy" y "le diste continuidad a tu racha" son el mismo evento real en esta app, así que se modeló como uno solo en vez de inventar una distinción que no existe. Antifraude gratis: touchStreak ya solo se dispara una vez por día.
"Desafío de la semana" en /dashboard y la home: una Real World Mission rotada por semana (determinístico por fecha, src/lib/weekly-challenge.ts) con +50 XP extra al completarla, sobre su XP normal.
Por qué: El roadmap ya decía que el motor de badges/XP soportaba esto sin cambios — lo único que faltaba ("el proceso editorial de rotar el desafío") se resolvió con el mismo truco de rotación determinística por fecha que Daily AI (pt. 11), en vez de un job/proceso humano semanal. El bonus se otorga vía awardedRewardKeys, ligado al número de semana — completar la misma misión en una rotación futura es un desafío nuevo, no un re-cobro.
/admin/calidad-contenido: detecta cursos sin actualizar hace 6+ meses (comparando contra updatedAt) y cursos que referencian una herramienta marcada inactive en el catálogo. Hoy: 0 de 48 cursos con alertas — todo el catálogo se actualizó en el último trimestre y ninguna herramienta referenciada está inactiva.
Por qué: Reencuadrado a solo la mitad detectable sin juicio editorial: "duplicado" quedó deliberadamente afuera (un heurístico de similitud de texto arriesga falsos positivos con confianza en una página de admin que se usa para actuar, peor que no marcar nada) y decidir qué reescribir en un curso marcado sigue siendo trabajo humano — mismo criterio que la auditoría de práctica (pt. 26). Cero alertas hoy no es un bug: significa que el catálogo está genuinamente al día: esto existe para detectar el desgaste a medida que pase el tiempo, no para inventar un problema que todavía no existe.
Sumado a /admin/analitica: DAU/WAU/MAU (sobre lastActiveDate, ya autorado por touchStreak), menor tasa de finalización por curso, y en qué lección promedio abandonan quienes no terminan un curso (mínimo 3 usuarios por curso para mostrarse, evita ruido de muestra chica).
Por qué: El mismo razonamiento que bloqueaba esto ("depende de datos reales, sin eso no tiene valor") ya se había resuelto para el pt. 30 (Analytics de administrador) sin esperar usuarios reales — el código es correcto con 0 usuarios (muestra 0%/vacío, mismo guard que activeStates.length === 0 de esa página), solo no es SIGNIFICATIVO todavía. Escribir las queries no dependía de tener usuarios, solo de que alguien las escribiera.
El wizard de /diagnostico ya cubre objetivo, nivel, intereses y tiempo disponible, y devuelve una ruta o carrera recomendada.
Por qué: Construido en la primera ronda de evolución. La única diferencia con el pedido de esta ronda es de framing ("Tu AI Roadmap está listo" vs. la pantalla de resultados actual) — cosmético, no funcional.
Ver en la plataformaCon XP > 0, la home reemplaza categorías + cursos/rutas/herramientas/proyectos destacados por ReturningUserHome: racha y XP, ¿Estoy preparado?, Mi objetivo, curso en progreso, próxima misión, última insignia y repaso pendiente. Hero, la sección "¿Para quién es IA Academy?", FAQ y el CTA final quedan igual para todos.
Por qué: HomeFeed (client) decide entre el bloque de descubrimiento (recibido como children ya renderizado por el Server Component de la home, sin duplicar esa lista) y el feed de continuidad — mismo patrón de gate ya usado en NewsFeed/SmartReviewCTA. "Progreso real" se definió como xp > 0, igual que el resto de la app trata "¿hay algo que continuar?".
progress-store.ts sigue siendo local-first y síncrono (localStorage no se fue a ningún lado), pero ahora también sincroniza a /api/progress en segundo plano cuando hay sesión — local vs. servidor, gana quien tenga más XP.
Por qué: Era el desbloqueador de todo lo demás marcado "depende de una base de datos" en este roadmap (verificación pública de certificados, portfolio realmente compartible, ranking global — pts. 63-65). Deliberadamente NO es un merge por campo: es last-write-wins a nivel de documento completo, simple y documentado como tal — no hay usuarios reales multi-dispositivo todavía que justifiquen algo más sofisticado. No pude probar el round-trip contra una base real en este sandbox (el .env local nunca tuvo credenciales de Postgres reales); sí se verificó que el sitio entero sigue funcionando sin cambios cuando la base no está disponible, que es la condición real de este entorno.
/certificados/[id] ahora consulta /api/certificates/[id] (público, sin sesión) cuando el certificado no está en el navegador actual — funciona desde cualquier dispositivo, no solo el que lo emitió.
Por qué: Chequea local primero (instantáneo, funciona incluso antes de que sincronice) y recién si no lo encuentra ahí pregunta al servidor — así no se pierde ni un caso que ya funcionaba. Si la base no responde, el endpoint devuelve un error controlado en vez de romper la página; el usuario ve "no pudimos verificar", nunca una pantalla rota.
Ver en la plataformaReservar un nombre de usuario (PortfolioSettingsPanel, requiere sesión) lo persiste en Postgres con una restricción de unicidad real; /api/portfolio/[username] lo resuelve públicamente, sin sesión, desde cualquier dispositivo.
Por qué: publicSlug necesitaba ser una columna real (no JSON) para que la propia base rechace dos personas reclamando el mismo nombre — Postgres hace el trabajo de detectar el conflicto, la API solo lo traduce a un error legible ("ese nombre ya está en uso"). El resto de la configuración de visibilidad viaja junto porque son solo un puñado de booleanos, no vale la pena una tabla aparte.
Ver en la plataforma/ranking ahora trae el top 20 real por XP desde Postgres (público, sin sesión para verlo) y, si el usuario logueado no entra en esa lista, le muestra su posición real con una query de conteo aparte.
Por qué: Respeta la preferencia de privacidad que ya existía (nickname vs. nombre real, user-profile.ts) — ahora sincronizada al servidor (pt. 64 mismo mecanismo) para que el ranking la pueda leer de otros usuarios. Un visitante sin sesión sigue viendo el ranking real completo (es información pública) más su propia fila local marcada explícitamente como "vista previa, sin sincronizar", para no fingir una posición que no es real.
Ver en la plataformaSe revisó todo el proyecto buscando cualquier rastro de un futuro plan pago (código, datos, textos legales, roadmap, docs) y se agregó contenido institucional real: página "Quiénes somos", contacto que envía un email de verdad, y una sección honesta sobre a quién está dirigida la plataforma.
Por qué: Decisión explícita del usuario (2026-09): IA Academy es y será siempre gratuita para aprender, sin planes pagos, suscripciones ni funciones bloqueadas por pago, para poder presentarse ante escuelas, universidades y organismos públicos sin ambigüedad. Se eliminó el campo `plan`/`PlanTier` (nunca usado para restringir nada) del modelo de datos, se reescribieron el FAQ, los Términos y este mismo roadmap (pt. 28) para dejar de hablar de "planes futuros", y se sacó de la home un bloque de testimonios con nombres y citas inventadas (incompatible con una presentación institucional seria) — reemplazado por "¿Para quién es IA Academy?" (`WhoItsFor.tsx`), que describe audiencias reales sin atribuirle palabras a nadie. No se inventó ningún convenio, aval institucional, cifra de usuarios ni testimonio: todo lo agregado usa datos reales del catálogo (cantidad de cursos, rutas, carreras, proyectos) o queda explícitamente planteado como invitación a contactarse, no como un hecho consumado.
Ver en la plataformaAlcance claro, esperando una decisión puntual (diseño, contenido o negocio).
El valor real depende de algo fuera de esta etapa: monetización, comunidad activa o escala de catálogo.
Entorno para probar prompts o código con feedback de un modelo en vivo.
Por qué: Revisado de nuevo con autorización explícita para reencuadrar #3-6 sin IA real — a diferencia de esos, acá el argumento original se sostiene: sin una llamada real a un modelo, un sandbox no aporta valor diferencial sobre simplemente linkear a ChatGPT/Claude (Practice Lab y los Real World Missions ya son la versión rule-based de "practicar con feedback" — un sandbox sin modelo sería una caja de texto que no hace nada). Depende de que la monetización soporte el costo por uso.
Desafíos 1 a 1 evaluados por IA.
Por qué: Revisado de nuevo con autorización explícita para reencuadrar #3-6 sin IA real — acá el bloqueo real es doble, y solo uno de los dos (el juez de IA) es reencuadrable: el AI Evaluator rule-based SÍ podría puntuar ambos lados de un "batalla" hoy. Pero "batallar" necesita a otra persona real del otro lado, y sin masa crítica de usuarios activos el modo quedaría vacío contra nadie — ese segundo bloqueo no lo resuelve ninguna reinterpretación de código.
Eventos con insignias/recompensas de tiempo limitado.
Por qué: Requiere un mecanismo de fechas de inicio/fin y contenido dedicado por temporada — más operativo (necesita mantenimiento continuo) que técnico. Se prioriza después de tener una base de usuarios activa que lo justifique.
Unificado con el pt. 56 ("Community-ready") — misma feature descripta dos veces en distintas rondas del roadmap. Ver el pt. 56 para el detalle.
Por qué: Detectado al revisar el balde "later": ambos ítems pedían dejar preparado el modelo de datos para foros/comentarios/likes/seguidores sin construir la red social todavía, con el mismo argumento ("sin usuarios reales, sobre-diseñar el esquema es un riesgo") — mismo criterio de limpieza que la unificación anterior de los pts. 16/46.
Unificado con el pt. 47 ("Knowledge Map interactivo") — misma feature descripta dos veces en distintas rondas del roadmap. Ver el pt. 47 para el detalle.
Por qué: Detectado al revisar el balde "later": ambos ítems pedían lo mismo (mapa navegable de relaciones entre cursos, herramientas, proyectos y conceptos) con el mismo argumento para posponerlo — mismo criterio de limpieza que la unificación anterior de los pts. 16/46.
Revisión sistemática de los 48 cursos por precisión, actualidad y calidad pedagógica.
Por qué: Trabajo editorial recurrente, no una feature de una sola vez — mejor tratarlo como proceso continuo que como ítem de este roadmap de producto.
Visualización navegable de relaciones entre conceptos, skills, cursos, herramientas, proyectos y carreras. Unifica este ítem con el pt. 24 ("Knowledge Graph"), la misma feature descripta dos veces.
Por qué: Alto costo de UI (un grafo interactivo real) para un valor que hoy cubren parcialmente el Glosario, las Rutas y el Career Center. Se prioriza si el catálogo crece lo suficiente para que la navegación lineal deje de alcanzar.
Eventos temáticos con badges exclusivos, XP especial, challenges y rankings propios.
Por qué: Mismo razonamiento que Seasons (pt. 19) del roadmap original: se beneficia de una base de usuarios activa que todavía no existe.
Dejar preparado el modelo de datos para comentarios, likes y seguidores sin construir la red social todavía. Unifica este ítem con el pt. 20 ("Preparación de arquitectura de comunidad"), la misma feature descripta dos veces.
Por qué: Mismo razonamiento que la preparación de arquitectura de comunidad (pt. 20 del roadmap original): diseñar el esquema sin usuarios reales todavía arriesga sobre-diseñar para supuestos incorrectos.
Herramienta interna para ayudar a crear/actualizar cursos, quizzes, challenges y badges, con un workflow de revisión antes de publicar.
Por qué: El admin panel hoy es un CRUD demo sobre localStorage, no conectado a las páginas públicas (ver docs/ARCHITECTURE.md). Un asistente de contenido tiene sentido recién cuando el admin escriba a una base de datos real que alimente el sitio.