# Guion de narración en español ## Estado real de GreenITESO Hoy vamos a revisar el estado real de Green ITESO. Primero veremos lo que ya funciona en la aplicación y después probaremos las operaciones que todavía están disponibles solo en la API. La grabación usa datos de prueba en un entorno local. Cada resultado queda ligado a la versión del código que estamos revisando, para que el equipo pueda repetir las pruebas y comprobar las correcciones. ## Qué estamos probando Para esta revisión congelamos las versiones de desarrollo del frontend y del backend, junto con la versión principal de infraestructura. No mezclamos cambios que siguen en pull requests. La aplicación corre contra Django y una base independiente de PostgreSQL dieciocho. Ana es nuestra estudiante de prueba; Laura, la administradora; y Diego sirve para comprobar permisos entre usuarios. Sus datos son sintéticos. Las sesiones se prepararon localmente, así que este recorrido no valida el inicio de sesión institucional con Microsoft. Una prueba aprobada significa que observamos la respuesta esperada y, cuando corresponde, sus efectos guardados. Una pantalla que se ve bien no basta. También comprobamos la compilación de producción: actualmente falla por cuatro errores de tipos relacionados con el feed. El servidor de desarrollo sí permite explorar estas pantallas, pero eso no demuestra que el frontend pueda publicarse todavía. ## Catálogo y registro de acciones Empezamos con el catálogo. Aquí aparecen tres acciones que acabamos de cargar en la base local: llegar en bicicleta, rellenar un termo y participar en una limpieza. La interfaz consulta el backend real y presenta los puntos, el límite configurado y el tipo de evidencia. Los factores ambientales son valores sintéticos de prueba; no representan una medición del impacto del campus. Después abrimos el formulario de registro y elegimos la bicicleta. Al pulsar Registrar aparece Formulario listo. Este detalle es importante: hoy el formulario únicamente valida una vista previa. Observamos cero solicitudes de creación de acciones y cero registros nuevos en la base. Por lo tanto, el catálogo sí está integrado, mientras que el registro desde la interfaz todavía necesita conectarse al servidor. Esta diferencia queda documentada con la captura y la comparación del estado antes y después. ## Puntos y reintentos Ahora enviamos la misma acción directamente a la API. El servidor responde con una acción aprobada y acredita diez puntos a Ana. También aumenta diez puntos en su clan institucional y en el clan privado que tiene activo. El registro guarda el valor de los puntos y el factor ambiental correspondientes a ese momento. No depende de que el navegador invente el saldo. Además, al compartir públicamente la acción, se genera una publicación en el feed. Luego repetimos exactamente la solicitud usando la misma clave de idempotencia. La base conserva un solo registro y no duplica los puntos, pero el servidor devuelve un error quinientos. Eso sigue siendo un fallo: un reintento normal debe tener una respuesta controlada que el cliente pueda interpretar. Las propuestas de límite diario e idempotencia siguen fuera de esta versión, y deben reconciliarse antes de integrarlas. ## Auditoría y reversión de puntos La limpieza requiere fotografía. Para comprobar el flujo del servidor enviamos una referencia sintética de archivo, claramente identificada como prueba. No estamos demostrando una carga real a almacenamiento. La acción queda pendiente de auditoría y todavía no acredita puntos. Ana intenta aprobarla y recibe un cuatrocientos tres: ese permiso está reservado al administrador. En cambio, la pantalla de auditoría de Laura no puede cargar los pendientes, porque solicita una lista que el backend responde con cuatrocientos cinco. La operación sí funciona usando la ruta correcta de auditoría por API. Laura aprueba y el saldo pasa de diez a treinta. Después la rechaza con un motivo: el saldo vuelve a diez, ambos clanes revierten los veinte puntos y la misión de limpieza vuelve de completada a pendiente. El servidor funciona en este recorrido secuencial; la bandeja administrativa necesita resolver su contrato con la API. ## Campañas y misiones En campañas tenemos dos ejemplos sintéticos. Ana ya participa en Semana sustentable, que está activa. Su registro aprobado de bicicleta incrementó la misión a una de dos acciones: el progreso consultado en la API es cincuenta por ciento. También tenemos Reto del termo en promoción, con inicio futuro. Abrimos su detalle desde la interfaz y usamos Unirme. La nueva participación queda guardada: pasamos de una a dos participaciones en la base. Al volver al inicio, la campaña aparece entre las campañas de Ana. Esto sí es una interacción integrada entre pantalla, servidor y persistencia. Las fases tienen significado: una campaña en promoción permite inscribirse antes del comienzo; una campaña activa registra el avance de sus misiones. Para seguir probando, podemos usar estos mismos casos como regresión después de integrar nuevos cambios, verificando tanto la inscripción como el progreso derivado de acciones aprobadas. ## Clasificación y privacidad La clasificación global consulta datos reales. Antes de cambiar la privacidad del perfil, Ana aparece primero con diez puntos; los otros usuarios conservan cero. La clasificación por equipos, sin embargo, llama a una ruta de ranking de clanes que todavía no está disponible. El resultado observado es cuatrocientos cuatro y la interfaz muestra su estado de error. No debemos presentar esa pestaña como funcional. Después comprobamos el perfil por API: Ana puede editar su biografía y cambiar su visibilidad a privada. La respuesta conserva sus puntos totales, el saldo disponible y el impacto de las acciones aprobadas. El factor de la limpieza rechazada ya no cuenta en ese impacto. Estas pruebas nos dan una base para completar la experiencia de perfil y extender la clasificación, sin confundir una operación disponible en el servidor con una pantalla que ya esté integrada. ## Feed y permisos entre usuarios El feed muestra publicaciones que llegan del backend, incluida la acción compartida y una publicación sintética de Diego. Probamos crear otra publicación como Ana y editarla mediante la API. Ambos cambios se guardan. Después Diego intenta modificar esa publicación ajena y el servidor responde con cuatrocientos tres. Esa protección está funcionando en el caso probado. Al regresar a la pantalla de Ana, su publicación se ve, pero no aparecen los controles que debería tener como autora. La versión del frontend usa un identificador fijo para decidir quién es propietario, y ese identificador no corresponde a nuestra sesión. Así, la autorización del servidor y la identificación del usuario en la pantalla tienen estados distintos. El próximo trabajo aquí es usar la identidad de la sesión y conservar los permisos del backend, seguido de una prueba de edición, eliminación y recarga con dos cuentas diferentes. ## Insignias y notificaciones La primera acción de Ana alcanza el umbral sintético de diez puntos para la insignia Primer paso. Verificamos que existe una insignia ganada en la base y que se crea su notificación. El rechazo de la limpieza también genera una notificación propia. La API de notificaciones devuelve estos eventos reales. La pantalla actual, en cambio, presenta mensajes de ejemplo y no hace solicitudes a esa API. Aunque permita marcar esos ejemplos como leídos, eso no verifica una actualización persistida en el servidor. Hay otro punto pendiente de integración: el perfil devuelve una lista vacía de insignias como placeholder, incluso cuando la relación de insignia ganada existe. Son piezas que ya tenemos en el backend y que conviene conectar de manera consistente. Después podremos probar lectura, contadores, recarga y, por separado, el comportamiento en tiempo real que todavía depende de cambios sin integrar. ## Clanes y administración del catálogo También revisamos las operaciones que hoy se pueden demostrar directamente por API. Ana ya lidera un clan privado; cuando intenta crear otro, recibe el rechazo esperado por la regla de un solo liderazgo. Diego sí es elegible y crea un clan temporal. Ana intenta eliminar ese clan ajeno y recibe un cuatrocientos tres. Diego, como propietario, puede disolverlo: el servidor devuelve doscientos cuatro y conserva la fila con su marca de borrado lógico. Esto evita confundir eliminar de la lista con borrar físicamente el historial. Por último, probamos una modificación administrativa del catálogo. La API responde doscientos, pero el nombre solicitado no cambia. Una respuesta exitosa sin persistencia no es un resultado aprobado. Ya existe trabajo local sobre ese problema; conviene terminar su integración y repetir este caso antes de considerar completo el mantenimiento del catálogo. ## Base de datos e infraestructura El trabajo de base de datos se coordinó con el otro agente para evitar duplicarlo. Su ensayo independiente aplicó veintiuna migraciones pendientes sobre un conjunto representativo de datos sintéticos, pasando de treinta y ocho a cincuenta y nueve. Comparó los datos existentes antes y después, incluidos saldos e historial congelado. También provocó el fallo de una misión duplicada y comprobó que la migración se podía reintentar después de retirar ese duplicado deliberado. El hub enlaza ese informe y distingue su versión de código de la versión usada en este video. Nuestro entorno local también arrancó con sus migraciones aplicadas. Ninguno de estos resultados prueba que los entornos compartidos ya estén actualizados. Aquí no aplicamos Terraform ni modificamos Neon, y no presentamos un despliegue de nube como validado. El siguiente paso operativo requiere revisar el grafo final y comprobar el entorno real autorizado. ## Resultados y próximo avance El paquete final deja treinta y una comprobaciones: veintiuna aprobadas, ocho fallidas, una integración todavía no implementada y una comprobación de nube sin ejecutar. Estas cifras describen la cobertura de este recorrido, no un porcentaje de calidad de todo el proyecto. El hub permite filtrar resultados y abrir cada captura, clip y respuesta guardada. Para avanzar, propongo primero recuperar la compilación del frontend; después conectar el registro y la auditoría con sus rutas reales. En paralelo, hay que reconciliar las propuestas de idempotencia y límite diario, terminar la identidad del feed y conectar las notificaciones persistidas. El ranking de clanes y las insignias del perfil quedan como integraciones pendientes claramente localizadas. Cada corrección puede repetir el mismo caso y comparar su resultado. Así llegamos a clase con una demostración honesta del avance y con evidencia que también sirve para trabajar, revisar cambios y comprobar que las mejoras realmente quedan guardadas.