Por qué los sistemas generados deberían explicarse a sí mismos

@lautarogartner_ |

Por qué el software generado debería mostrar su estructura, contratos, capacidades y hechos del runtime relevantes para la seguridad.

El software generado tiene un problema de confianza. No porque generar software sea malo: es útil, ahorra tiempo, elimina repeticiones y permite que un framework produzca resultados consistentes. El problema aparece después. Se ejecuta un build, aparece una carpeta y se espera que el desarrollador confíe en que el resultado es correcto, seguro y comprensible. Es demasiada confianza.

Un sistema generado debería explicarse a sí mismo.

Debería decir qué produjo, qué tipos de archivos existen, qué capacidades tiene, qué build generó el resultado y si sus contratos son válidos. Esto ayuda a la experiencia de desarrollo, pero también a la seguridad.

La seguridad empieza por saber qué existe. Si un runtime no puede enumerar sus propios artefactos, tenés que descubrirlos manualmente. Si no puede decir qué capacidades tiene, tenés que inferir el comportamiento a partir del código y las convenciones. Si no puede informar si su manifiesto es válido, no sabés si el sistema que estás inspeccionando coincide con el que el framework cree haber generado. Esa incertidumbre se convierte en riesgo operativo.

Paideia intenta reducir ese riesgo con archivos pequeños y explícitos.

`system.json` describe el contrato del sistema generado. `runtime.json` describe la identidad del runtime: versión del framework, identificador del build, inventario de artefactos, capacidades declaradas y metadatos del build. `context.json` les da a los agentes un mapa compacto del sitio. `llms.txt` explica por dónde deberían empezar. El comando `doctor` valida que el runtime generado sea internamente consistente.

Esto importa para la seguridad porque es difícil revisar un comportamiento oculto. Un inventario sencillo de artefactos permite comprobar si el resultado contiene sólo los archivos esperados. Un identificador determinista del build permite ver si el contenido cambió entre builds. Las declaraciones de capacidades indican qué afirma poder hacer el runtime: servir un sitio estático, exponer contexto para agentes, validar manifiestos e inspeccionar su identidad. Las comprobaciones de `doctor` pueden detectar contratos rotos antes de publicar. Nada de esto reemplaza una revisión de seguridad, pero le da un punto de partida concreto.

Lo importante es que estos archivos son simples. No son un nuevo sistema de permisos, una dependencia de la nube ni un motor complejo de políticas. Son archivos generados que una persona puede leer, un script puede comprobar y un agente puede recibir. Eso alcanza para que el sistema sea más fácil de inspeccionar.

Los desarrolladores ya hacemos este trabajo de manera informal. Revisamos carpetas, leemos la salida del build, abrimos archivos generados, nos preguntamos si el runtime sirve más de lo que debería y si un cambio vino del contenido o de las herramientas. Paideia incorpora algunas de esas preguntas como parte central del sistema.

El cambio es pequeño, pero modifica el punto de partida. En vez de pedirles a los desarrolladores que reconstruyan el sistema generado, el sistema les da un mapa. En vez de ocultar el comportamiento detrás de la confianza en el framework, el runtime declara sus capacidades. En vez de tratar el resultado generado como un efecto secundario, el framework lo trata como algo que debe describirse y verificarse.

Esto también ayuda a los agentes. Un agente que trabaja en una base de código no debería tener que adivinar qué archivos importan, inventar capacidades a partir de nombres de carpetas ni resumir todo un sitio desde cero si ya existe un archivo compacto de contexto. Las mismas superficies explícitas que ayudan a revisar la seguridad también ayudan a que las herramientas automatizadas actúen con más cuidado.

La idea básica es esa: que el sistema generado sea lo suficientemente legible para que personas y agentes puedan inspeccionarlo antes de confiar en él.

El software legible no es sólo código bien formateado. Es software cuya estructura puede descubrirse, cuyo resultado puede comprobarse y cuyo comportamiento se declara con claridad.

Los sistemas generados deberían explicarse a sí mismos porque entenderlos es parte de usarlos de manera segura.