En un proyecto de framework hay un umbral silencioso en el que cambia la pregunta. Al principio, la pregunta es: ¿esto es real?
No es una pregunta cínica. Es la correcta. Un framework puede tener buenas ideas, una filosofía clara y algunos ejemplos que funcionan y aun así no ser real del modo en que el software necesita serlo. Puede ser un repositorio con potencial, un ensayo con archivos de código adjuntos o una pila de experimentos organizados de una manera prometedora. Pero hasta que alguien pueda empezar de cero y crear un sistema que funcione, el proyecto sigue viviendo principalmente dentro de su propio repositorio.
Paideia cruzó una pequeña versión de ese umbral cuando aprendió a inicializar un proyecto.
El comando es modesto:
paideia init my-siteNo parece espectacular. Crea una carpeta, escribe algunos archivos, le da al proyecto una definición de sitio, agrega un primer artículo y prepara scripts para compilar, iniciar, ejecutar `doctor`, inspeccionar y crear artículos. Después, el proyecto generado puede instalar dependencias, compilarse, ejecutar un servidor de producción, exponer artefactos del runtime e inspeccionar su propio resultado. Es una función pequeña, pero también un cambio de categoría.
Antes de `init`, Paideia era un repositorio de framework interesante. Podías clonarlo, leerlo, compilar el sitio incluido, inspeccionar los artefactos y entender la estructura del experimento. Servía, pero mantenía al usuario dentro de la casa del framework. La primera experiencia seguía siendo «entrá en este repositorio y mirá». Después de `init`, puede pasar a ser «hacé algo propio». Eso importa más que la cantidad de código involucrada.
Las herramientas de software son en parte objetos técnicos y en parte objetos psicológicos. Una herramienta necesita capacidades y un punto de entrada que ayude al usuario a orientarse. En pocos pasos tiene que decir: acá estás, esto existe, así lo cambiás, así lo comprobás y así lo ejecutás. El flujo de `init` es el comienzo de esa promesa.
Un proyecto generado por Paideia es pequeño a propósito. Tiene una página de inicio, una página de presentación, un artículo, un contrato del sitio y un README. Se compila en archivos comunes dentro de `dist`. Junto a esas páginas genera `runtime.json`, `system.json`, `context.json` y `llms.txt`. No son decorativos: son la parte del sistema que explica qué se generó, qué capacidades existen, cuál es la identidad del runtime y cómo una persona o un agente puede inspeccionar el resultado.
La distinción importante es ésta: Paideia busca generar sistemas que puedan sostenerse por sí mismos, no clones con la marca Paideia.
El proyecto generado debería sentirse como el proyecto del usuario, no como una copia de las partes internas del framework. El nombre del paquete debería ser claro. El README debería explicar el flujo de trabajo local. El título, autor, descripción y URL del sitio deberían ser valores de ejemplo fáciles de reconocer y editar. Los scripts deberían ser mínimos y predecibles. Los artefactos del runtime deberían pertenecer al sistema generado.
El framework puede seguir siendo visible. Debería serlo: «Generado con Paideia Framework» es una frase honesta. Pero el centro tiene que desplazarse hacia lo que está haciendo el usuario. Por eso importa pulir esta experiencia.
Después de que funciona un comando `init`, es tentador saltar a funciones más grandes: bases de datos, autenticación, paneles de administración, plugins, formularios, despliegues e integraciones. Todas son interesantes. También son peligrosas si llegan demasiado temprano. Un framework puede volverse impresionante antes de volverse confiable. Puede acumular superficies antes de que la primera se sienta bien. Paideia necesita la disciplina inversa: el recorrido pequeño debería ser excelente antes de que exista el grande.
¿Puede una persona que no conoce el proyecto crear uno en pocos minutos? ¿Puede encontrar dónde viven los artículos, compilar el sitio, ejecutar `doctor` e inspeccionar el runtime? ¿Puede abrir `dist` y entender los artefactos? ¿Puede cambiar el título sin leer el código del framework? ¿Puede un agente orientarse con `context.json` y `llms.txt` sin adivinar?
No son preguntas vistosas. Son la base. La superficie de verificación empieza a reflejarlo. Hay tests para `init`, la estructura del proyecto inicial, los artículos generados, el runtime del sitio, su identidad, los contratos y diagnósticos del manifiesto, la instalación y `doctor`. También hay un recorrido directo de comprobación para proyectos generados: instalar, compilar, inspeccionar, iniciar y consultar el endpoint de salud.
Así empieza la confianza: cuando la herramienta puede crear repetidamente algo pequeño, comprensible y verificable. No alcanza con afirmar que está lista para producción o mostrar una gran hoja de ruta. Esto también aclara en qué se está convirtiendo Paideia.
Al principio, el proyecto hablaba de software pensado para la IA, identidad del runtime y sistemas generados que se explican a sí mismos. Esas ideas siguen importando, pero el centro práctico se vuelve más preciso: sistemas pequeños y comprensibles.
La frase es menos llamativa, y eso está bien. Es más concreta y le da al proyecto una prueba. Si Paideia agrega una función, ¿ayuda a crear un sistema pequeño que se pueda entender? Si genera un artefacto, ¿facilita inspeccionarlo? Si agrega un comando, ¿reduce la confusión? Si genera un proyecto, ¿se siente propio del usuario?
El flujo de `init` no termina ese trabajo. Es la primera puerta real.
La siguiente prueba útil es otro sistema: algo que no sea este blog. Un portal de documentación, un sitio de notas, un registro de cambios, un CRM pequeño o un control de inventario. El blog validó la publicación. Una segunda aplicación permitirá comprobar si la arquitectura admite otra estructura sin volverse imprecisa.
Paideia está entrando en esa etapa. La mejor pregunta ya no es «¿esto es real?» ni todavía «¿cuánto puede hacer?». Es «¿qué tan preciso puede seguir siendo el alcance mientras se vuelve útil?».
Es una pregunta más saludable. Le pide al proyecto que crezca sin inflarse, que cada función justifique su lugar y que el centro siga siendo lo suficientemente pequeño para inspeccionarlo.
Paideia debería volverse útil del mismo modo en que deberían comportarse sus sistemas generados: con claridad, intención y suficiente conocimiento de sí mismos para poder usarlos con cuidado.