🚧 Lo que NO hace
Objetivo principal: conocer los bordes antes de poner la plataforma delante de un grupo. Esta es la página que hay que leer entera antes de instalar nada en el servidor de un centro.
Todo lo que sigue está medido o leído en el código, no supuesto. La propia plataforma lo anuncia en el aviso naranja de todas sus pantallas.
Los cuatro límites están declarados y no se aplican
El despliegue no arranca sin que los cuatro límites de recursos estén escritos. Pero esas cifras no acotan nada:
GET /salud
{
"estado": "en marcha",
"limites": { "memoria": 536870912, "tiempo_de_computo": 30,
"procesos_simultaneos": 64, "espacio_ocupado": 2147483648 },
"advertencia": "Sin autenticación y sin aplicar los límites: ensayo, no producción."
}
El motivo es arquitectónico, no un olvido: los modelos no corren en contenedores separados, sino como procesos hermanos dentro del mismo contenedor que el plano de control. Comparten sistema de ficheros, espacio de procesos y cupo de memoria. No hay frontera donde poner un techo.
Conectarlos exige colgar cada modelo de su propio contenedor, que es la decisión aplazada
DEF-8, hoy sin ningún camino acreditado.
Un modelo descontrolado no encuentra aquí ningún freno.
No hay denegación de red por modelo
El contenedor tiene salida a internet abierta, y el código del alumnado corre dentro de él.
El recorrido de extremo a extremo sí se ejercita con la red retirada, pero eso es el ensayo, no el despliegue.
La puerta del alumnado no existe
Cómo llega la carpeta de un alumno a la plataforma no está decidido. Es DEF-9, y no
tiene candidatos evaluados.
Lo que se instala es un directorio vigilado: plomería de ensayo. Hoy la entrega es a mano.
Quién puede hacer qué
Aquí conviene ser preciso, porque hay dos superficies con reglas distintas.
La pantalla no pide credencial. A un navegador no se le pide un secreto. Lo que la protege es que el puerto solo se publica en la propia máquina y que se rechaza cualquier petición de escritura que no venga de la propia pantalla.
La API JSON sí la pide, en la cabecera X-Captia-Credencial.
Y ahora lo importante:
No distingue quién la presenta. No hay cuentas, ni permisos, ni rastro de quién hizo qué más allá del nombre que cada cual teclee en el campo «quién retira» — que es texto libre y nadie comprueba.
En la práctica: quien alcance la pantalla puede retirar el modelo de cualquiera. La propia pantalla lo dice en su pie.
Lo que la plataforma no sabe de sí misma
No mide el espacio que ocupa cada modelo. La columna «Ocuparía liberar» del inventario sale vacía siempre. No es un cero —un cero significaría que no ocupa nada—: es que nadie lo mide.
No detecta que una página del manual se ha quedado atrás. Ninguna comprobación automática puede comparar una frase con el comportamiento de un producto.
No avisa si un modelo deja de responder. El inventario dice sirviendo porque así se registró, no porque se acabe de comprobar. Para saber si responde, hay que invocarlo.
Resumen para quien decide si esto se instala
| Pregunta | Respuesta hoy |
|---|---|
| ¿Puede un modelo agotar la memoria del servidor? | Sí. No hay techo aplicado |
| ¿Puede un modelo salir a internet? | Sí. No hay denegación de red |
| ¿Puede alguien retirar el modelo de otro? | Sí, si alcanza la pantalla |
| ¿Queda rastro de quién retiró? | Sí, pero es texto libre sin comprobar |
| ¿Sobrevive el inventario a un reinicio del servidor? | Sí. Pero el contenedor no vuelve solo: hay que volver a desplegar |
| ¿Se borra el identificador del alumno al retirar? | En el inventario sí; en el árbol de trabajo del servidor, no |
Esto es un ensayo. Sirve para enseñar el recorrido completo con un grupo, en un servidor donde
un consumo descontrolado no tenga consecuencias. No para dejarlo conviviendo sin vigilancia
con los servicios de producción del edificio, que es exactamente el escenario para el que
está pensado a largo plazo. Ese salto depende de DEF-8.