1
00:00:00,260 --> 00:00:03,620
Hoy vamos a revisar el estado real de
GreenITESO.

2
00:00:04,180 --> 00:00:08,020
Primero veremos lo que ya funciona en la
aplicación y después probaremos las

3
00:00:08,060 --> 00:00:11,880
operaciones que todavía están disponibles solo
en la API. La

4
00:00:11,920 --> 00:00:15,560
grabación usa datos de prueba en un entorno
local. Cada resultado

5
00:00:15,600 --> 00:00:19,560
queda ligado a la versión del código que estamos
revisando para que el equipo pueda

6
00:00:19,600 --> 00:00:21,640
repetir las pruebas y comprobar las correcciones

7
00:00:22,470 --> 00:00:26,370
Para esta revisión congelamos las versiones de
desarrollo del front-end y del

8
00:00:26,410 --> 00:00:30,310
back-end, junto con la versión principal de
infraestructura. No mezclamos

9
00:00:30,350 --> 00:00:33,870
cambios que siguen en pull requests. La
aplicación corre contra

10
00:00:33,910 --> 00:00:36,930
Django y una base independiente de Postgres 18.

11
00:00:37,750 --> 00:00:41,450
Ana es nuestra estudiante de prueba, Laura, la
administradora, y

12
00:00:41,490 --> 00:00:44,870
Diego sirve para comprobar permisos entre
usuarios. Sus datos son

13
00:00:44,910 --> 00:00:48,910
sintéticos. Las sesiones se prepararon
localmente, así que este

14
00:00:48,970 --> 00:00:52,350
recorrido no valida el inicio de sesión
institucional con Microsoft.

15
00:00:53,030 --> 00:00:56,810
Una prueba aprobada significa que observamos la
respuesta esperada y

16
00:00:56,850 --> 00:01:00,850
cuando corresponde, sus efectos guardados. Una
pantalla que se ve bien

17
00:01:00,910 --> 00:01:04,770
no basta. También comprobamos la compilación de
producción. Actualmente

18
00:01:04,830 --> 00:01:08,730
falla por cuatro errores de tipos relacionados
con el feed. El servidor de

19
00:01:08,750 --> 00:01:12,350
desarrollo sí permite explorar estas pantallas,
pero eso no demuestra que el

20
00:01:12,410 --> 00:01:14,110
front-end pueda publicarse todavía

21
00:01:14,947 --> 00:01:18,686
Empezamos con el catálogo. Aquí aparecen tres
acciones que acabamos de

22
00:01:18,726 --> 00:01:22,447
cargar en la base local: llegar en bicicleta,
rellenar un termo y

23
00:01:22,487 --> 00:01:26,367
participar en una limpieza. La interfaz consulta
el backend real

24
00:01:26,427 --> 00:01:29,987
y presenta los puntos, el límite configurado y
el tipo de evidencia.

25
00:01:30,567 --> 00:01:34,427
Los factores ambientales son valores sintéticos
de prueba, no representan una

26
00:01:34,467 --> 00:01:38,367
medición del impacto del campus. Después,
abrimos el formulario de

27
00:01:38,407 --> 00:01:42,287
registro y elegimos la bicicleta. Al pulsar
Registrar

28
00:01:42,387 --> 00:01:45,647
aparece Formulario listo. Este detalle es
importante.

29
00:01:46,187 --> 00:01:49,027
Hoy el formulario únicamente valida una vista
previa.

30
00:01:49,567 --> 00:01:53,567
Observamos cero solicitudes de creación de
acciones y cero registros nuevos en la

31
00:01:53,607 --> 00:01:57,547
base. Por lo tanto, el catálogo sí está
integrado, mientras que el

32
00:01:57,607 --> 00:02:00,787
registro desde la interfaz todavía necesita
conectarse al servidor.

33
00:02:01,587 --> 00:02:05,207
Esta diferencia queda documentada con la captura
y la comparación del estado

34
00:02:05,327 --> 00:02:06,287
antes y después

35
00:02:07,317 --> 00:02:11,077
Ahora enviamos la misma acción directamente a la
API. El

36
00:02:11,137 --> 00:02:14,857
servidor responde con una acción aprobada y
acredita 10 puntos a

37
00:02:14,897 --> 00:02:18,857
Ana. También aumenta 10 puntos en su clan
institucional y en el clan

38
00:02:18,897 --> 00:02:22,577
privado que tiene activo. El registro guarda el
valor de los puntos y el factor

39
00:02:22,617 --> 00:02:26,537
ambiental correspondientes a ese momento. No
depende de que el navegador invente el

40
00:02:26,577 --> 00:02:30,517
saldo. Además, al compartir públicamente la
acción, se genera una

41
00:02:30,557 --> 00:02:34,137
publicación en el feed. Luego repetimos
exactamente la

42
00:02:34,177 --> 00:02:38,057
solicitud usando la misma clave de idempotencia.
La base conserva un

43
00:02:38,097 --> 00:02:41,937
solo registro y no duplica los puntos, pero el
servidor devuelve un error

44
00:02:42,257 --> 00:02:46,097
500. Eso sigue siendo un fallo. Un reintento
normal debe tener

45
00:02:46,157 --> 00:02:50,117
una respuesta controlada que el cliente pueda
interpretar. Las propuestas de

46
00:02:50,157 --> 00:02:53,757
límite diario e idempotencia siguen fuera de
esta versión y deben

47
00:02:53,797 --> 00:02:55,377
reconciliarse antes de integrarlas

48
00:02:56,278 --> 00:02:59,858
La limpieza requiere fotografía. Para comprobar
el flujo del servidor,

49
00:02:59,977 --> 00:03:03,578
enviamos una referencia sintética de archivo,
claramente identificada

50
00:03:03,638 --> 00:03:07,338
como prueba. No estamos demostrando una carga
real al almacenamiento.

51
00:03:08,038 --> 00:03:11,178
La acción queda pendiente de auditoría y todavía
no acredita puntos.

52
00:03:11,898 --> 00:03:15,878
Ana intenta aprobarla y recibe un 403. Ese
permiso está

53
00:03:15,918 --> 00:03:19,698
reservado al administrador. En cambio, la
pantalla de auditoría de Laura

54
00:03:19,838 --> 00:03:23,718
no puede cargar los pendientes porque solicita
una lista que el backend responde

55
00:03:23,758 --> 00:03:27,578
con 405. La operación sí funciona usando la ruta
correcta de

56
00:03:27,618 --> 00:03:31,378
auditoría por API. Laura aprueba y el saldo pasa
de diez a

57
00:03:31,418 --> 00:03:34,898
treinta. Después la rechaza con un motivo. El
saldo vuelve a diez,

58
00:03:35,278 --> 00:03:39,098
ambos clanes revierten los veinte puntos y la
misión de limpieza vuelve de completada

59
00:03:39,158 --> 00:03:43,078
a pendiente. El servidor funciona en este
recorrido secuencial. La bandeja

60
00:03:43,098 --> 00:03:45,658
administrativa necesita resolver su contrato con
la API.

61
00:03:46,488 --> 00:03:50,288
En campañas tenemos dos ejemplos sintéticos. Ana
ya participa

62
00:03:50,348 --> 00:03:54,028
en Semana Sustentable, que está activa. Su
registro aprobado de

63
00:03:54,068 --> 00:03:57,748
bicicleta incrementó la misión a una de dos
acciones. El progreso

64
00:03:57,788 --> 00:04:01,328
consultado en la API es 50% %. También tenemos

65
00:04:01,628 --> 00:04:05,448
Reto del termo en promoción con inicio futuro.
Abrimos su detalle

66
00:04:05,488 --> 00:04:09,128
desde la interfaz y usamos Unirme. La nueva
participación queda

67
00:04:09,168 --> 00:04:13,148
guardada. Pasamos de una a dos participaciones
en la base. Al volver al

68
00:04:13,208 --> 00:04:17,168
inicio, la campaña aparece entre las campañas de
Ana. Esto sí es una interacción

69
00:04:17,208 --> 00:04:21,208
integrada entre pantalla, servidor y
persistencia. Las fases tienen

70
00:04:21,248 --> 00:04:25,128
significado. Una campaña en promoción permite
inscribirse antes del

71
00:04:25,168 --> 00:04:28,648
comienzo. Una campaña activa registra el avance
de sus misiones.

72
00:04:29,228 --> 00:04:32,548
Para seguir probando, podemos usar estos mismos
casos como regresión después de

73
00:04:32,568 --> 00:04:36,468
integrar nuevos cambios, verificando tanto la
inscripción como el progreso derivado de

74
00:04:36,508 --> 00:04:37,348
acciones aprobadas.

75
00:04:38,215 --> 00:04:41,875
La clasificación global consulta datos reales.
Antes de cambiar la

76
00:04:41,915 --> 00:04:45,615
privacidad del perfil, Ana aparece primero con
diez puntos. Los

77
00:04:45,695 --> 00:04:49,635
otros usuarios conservan cero. La clasificación
por equipo, sin embargo,

78
00:04:50,075 --> 00:04:53,915
llama a una ruta de ranking de clanes que
todavía no está disponible. El

79
00:04:53,954 --> 00:04:57,715
resultado observado es cuatrocientos cuatro y la
interfaz muestra su estado de error.

80
00:04:58,375 --> 00:05:02,335
No debemos presentar esa pestaña como funcional.
Después comprobamos el

81
00:05:02,375 --> 00:05:06,115
perfil por API. Ana puede editar su biografía y
cambiar su visibilidad a

82
00:05:06,155 --> 00:05:10,115
privada. La respuesta conserva sus puntos
totales, el saldo disponible

83
00:05:10,174 --> 00:05:14,115
y el impacto de las acciones aprobadas. El
factor de la limpieza rechazada ya

84
00:05:14,155 --> 00:05:17,795
no cuenta en ese impacto. Estas pruebas nos dan
una base para completar la

85
00:05:17,835 --> 00:05:21,555
experiencia de perfil y extender la
clasificación sin confundir una

86
00:05:21,595 --> 00:05:24,875
operación disponible en el servidor con una
pantalla que ya esté integrada.

87
00:05:25,573 --> 00:05:29,153
El feed muestra publicaciones que llegan del
backend, incluida la acción

88
00:05:29,193 --> 00:05:33,053
compartida y una publicación sintética de Diego.
Probamos crear

89
00:05:33,113 --> 00:05:37,033
otra publicación como Ana y editarla mediante la
API. Ambos cambios

90
00:05:37,073 --> 00:05:40,833
se guardan. Después, Diego intenta modificar esa
publicación

91
00:05:40,893 --> 00:05:44,513
ajena y el servidor responde con 403. Esa

92
00:05:44,553 --> 00:05:48,493
protección está funcionando en el caso probado.
Al regresar a la pantalla

93
00:05:48,513 --> 00:05:52,433
de Ana, su publicación se ve, pero no aparecen
los controles que debería

94
00:05:52,473 --> 00:05:56,413
tener como autora. La versión del frontend usa
un identificador

95
00:05:56,493 --> 00:06:00,093
fijo para decidir quién es propietario y ese
identificador no

96
00:06:00,133 --> 00:06:03,873
corresponde a nuestra sesión. Así, la
autorización del servidor y

97
00:06:03,933 --> 00:06:07,313
la identificación del usuario en la pantalla
tienen estados distintos.

98
00:06:08,093 --> 00:06:11,893
El próximo trabajo aquí es usar la identidad de
la sesión y conservar los

99
00:06:11,933 --> 00:06:15,833
permisos del backend, seguido de una prueba de
edición, eliminación y

100
00:06:15,893 --> 00:06:17,513
recarga con dos cuentas diferentes.

101
00:06:18,503 --> 00:06:22,063
La primera acción de Ana alcanza el umbral
sintético de 10 puntos para la

102
00:06:22,102 --> 00:06:26,043
insignia Primer paso. Verificamos que exista una
insignia ganada en la

103
00:06:26,083 --> 00:06:29,763
base y que se crea su notificación. El rechazo
de la limpieza

104
00:06:29,843 --> 00:06:33,643
también genera una notificación propia. La API
de notificaciones

105
00:06:33,683 --> 00:06:37,503
devuelve estos eventos reales. La pantalla
actual, en cambio, presenta

106
00:06:37,543 --> 00:06:41,443
mensajes de ejemplo y no hace solicitudes a esa
API. Aunque permita

107
00:06:41,483 --> 00:06:45,463
marcar esos ejemplos como leídos, eso no
verifica una actualización persistida en

108
00:06:45,523 --> 00:06:49,363
el servidor. Hay otro punto pendiente de
integración. El perfil

109
00:06:49,403 --> 00:06:53,043
devuelve una lista vacía de insignias como
placeholder, incluso cuando la

110
00:06:53,103 --> 00:06:57,083
relación de insignia ganada existe. Son piezas
que ya tenemos en el backend

111
00:06:57,143 --> 00:07:00,703
y que conviene conectar de manera consistente.
Después podremos probar

112
00:07:00,743 --> 00:07:04,683
lectura, contadores, recarga y por separado el
comportamiento

113
00:07:04,723 --> 00:07:07,043
en tiempo real que todavía depende de cambios
sin integrar

114
00:07:07,865 --> 00:07:11,665
También revisamos las operaciones que hoy se
pueden demostrar directamente por

115
00:07:11,725 --> 00:07:15,565
API. Ana ya lidera un clan privado. Cuando
intenta crear otro,

116
00:07:15,765 --> 00:07:18,945
recibe el rechazo esperado por la regla de un
solo liderazgo.

117
00:07:19,525 --> 00:07:23,405
Diego sí es elegible y crea un clan temporal.
Ana intenta

118
00:07:23,445 --> 00:07:27,405
eliminar ese clan ajeno y recibe un 403. Diego,
como

119
00:07:27,445 --> 00:07:31,425
propietario, puede disolverlo. El servidor
devuelve 204 y conserva

120
00:07:31,485 --> 00:07:35,485
la fila con su marca de borrado lógico. Esto
evita confundir eliminar

121
00:07:35,525 --> 00:07:39,485
de la lista con borrar físicamente el historial.
Por último, probamos una

122
00:07:39,525 --> 00:07:43,165
modificación administrativa del catálogo. La API
responde

123
00:07:43,425 --> 00:07:47,245
200, pero el nombre solicitado no cambia. Una
respuesta exitosa

124
00:07:47,305 --> 00:07:51,065
sin persistencia no es un resultado aprobado. Ya
existe trabajo

125
00:07:51,105 --> 00:07:54,825
local sobre ese problema. Conviene terminar su
integración y repetir este

126
00:07:54,865 --> 00:07:57,765
caso antes de considerar completo el
mantenimiento del catálogo.

127
00:07:58,715 --> 00:08:02,295
El trabajo de base de datos se coordinó con el
otro agente para evitar

128
00:08:02,315 --> 00:08:05,675
duplicarlo. Su ensayo independiente aplicó
veintiún

129
00:08:05,715 --> 00:08:09,195
migraciones pendientes sobre un conjunto
representativo de datos

130
00:08:09,255 --> 00:08:12,395
sintéticos, pasando de treinta y ocho a
cincuenta y nueve.

131
00:08:12,995 --> 00:08:16,635
Comparó los datos existentes antes y después,
incluidos

132
00:08:16,735 --> 00:08:20,435
saldos e historial congelado. También provocó el
fallo de una

133
00:08:20,475 --> 00:08:24,435
emisión duplicada y comprobó que la migración se
podía reintentar después de

134
00:08:24,495 --> 00:08:28,395
retirar ese duplicado deliberado. El hub enlaza
ese informe y

135
00:08:28,435 --> 00:08:32,055
distingue su versión de código de la versión
usada en este video. Nuestro

136
00:08:32,095 --> 00:08:36,035
entorno local también arrancó con sus
migraciones aplicadas. Ninguno

137
00:08:36,075 --> 00:08:39,895
de estos resultados prueba que los entornos
compartidos ya estén actualizados.

138
00:08:40,355 --> 00:08:44,335
Aquí no aplicamos Terraform ni modificamos Neon
y no presentamos

139
00:08:44,395 --> 00:08:48,375
un despliegue de nube como validado. El
siguiente paso operativo requiere

140
00:08:48,435 --> 00:08:51,715
revisar el grafo final y comprobar el entorno
real autorizado

141
00:08:52,532 --> 00:08:56,272
El paquete final deja 31 comprobaciones, 21
aprobadas,

142
00:08:56,612 --> 00:09:00,372
ocho fallidas, una integración todavía no
implementada y una

143
00:09:00,392 --> 00:09:04,312
comprobación de nube sin ejecutar. Estas cifras
describen la cobertura

144
00:09:04,372 --> 00:09:08,052
de este recorrido, no un porcentaje de calidad
de todo el proyecto.

145
00:09:08,572 --> 00:09:12,212
El hub permite filtrar resultados y abrir cada
captura, clip y

146
00:09:12,272 --> 00:09:15,932
respuesta guardada. Para avanzar, propongo
primero recuperar la

147
00:09:15,972 --> 00:09:19,952
compilación del front end, después conectar el
registro y la auditoría con

148
00:09:19,992 --> 00:09:23,712
sus rutas reales. En paralelo, hay que
reconciliar las propuestas de

149
00:09:23,752 --> 00:09:27,332
idempotencia y límite diario, terminar la
identidad del feed y

150
00:09:27,392 --> 00:09:31,172
conectar las notificaciones persistidas. El
ranking de clanes y las

151
00:09:31,212 --> 00:09:35,052
insignias del perfil quedan como integraciones
pendientes claramente localizadas.

152
00:09:35,632 --> 00:09:39,152
Cada corrección puede repetir el mismo caso y
comparar su resultado.

153
00:09:39,792 --> 00:09:43,792
Así llegamos a clase con una demostración
honesta del avance y con evidencia

154
00:09:43,832 --> 00:09:47,832
que también sirve para trabajar, revisar cambios
y comprobar que las mejoras

155
00:09:47,932 --> 00:09:49,172
realmente quedan guardadas.