Caso de estudio principal / Diseño de gobernanza
AEDF v1.0.0 — De marco de gobernanza a base de producción
Conectar intención de ingeniería, cambio controlado, validación, evidencia, autoridad humana e historial de publicación sin prescribir la arquitectura técnica del adoptante.
Un marco de entrega se convirtió en base de producción al superar arquitecturas distintas de la suya.
Las decisiones de publicación deben seguir la evidencia, no la ceremonia.
AEDF comenzó como un experimento de gobernanza de ingeniería: una forma de evitar que requisitos, arquitectura, implementación, automatización, validación, evidencia, seguridad, aprobación humana e historial de publicación se convirtieran en registros desconectados.
La versión 1.0.0 marca el punto en que ese experimento se convirtió en la base estable de gobernanza de producción para los proyectos de ingeniería de Avantlord donde aplica. El fundamento está deliberadamente acotado: una calificación exitosa en dos arquitecturas de adopción materialmente distintas, seguida de la validación de la versión estable en ambas.
I — El problema de ingeniería
El trabajo de ingeniería rara vez falla porque falte un solo artefacto. Falla cuando los artefactos dejan de coincidir. Los requisitos pueden alejarse de la arquitectura; la implementación puede rebasar su orden de trabajo; la automatización puede informar éxito sin validar la fuente prevista; la evidencia puede perder su procedencia; las restricciones de seguridad pueden desaparecer entre diseño y publicación; y un cambio técnicamente correcto puede carecer todavía de aceptación humana.
AEDF trata esas relaciones como un solo ciclo controlado, no como un conjunto de documentos adyacentes:
- 01IntenciónDefinir el resultado y la autoridad.
- 02Orden de trabajoAcotar alcance, riesgo y aceptación.
- 03Cambio controladoImplementar desde la verdad del repositorio.
- 04ValidaciónProbar los contratos del marco y del adoptante.
- 05EvidenciaConservar resultados reproducibles.
- 06RevisiónMantener explícitas las puertas técnicas y de producto.
- 07PublicaciónEntregar solo bajo autoridad registrada.
La secuencia no es papeleo alrededor de la ingeniería. Cada transición responde una pregunta distinta: qué está autorizado, qué cambió, qué se probó, qué respalda la evidencia, quién lo aceptó y qué estado exacto se publicó.
II — Gobernanza como infraestructura ejecutable
AEDF aporta el contrato compartido de gobernanza: roles de autoridad, clases de riesgo, puertas del ciclo, expectativas para órdenes de trabajo, requisitos de evidencia, manejo de excepciones y semántica de validación. Un adoptante aporta la realidad específica del repositorio: arquitectura, alcance de fuente controlado, política del proyecto, comandos de construcción y pruebas, modelo de ejecución y mecanismo de publicación.
- AEDF
- Define cómo un cambio de ingeniería se vuelve revisable, validado, autorizado y trazable.
- Adoptante
- Define qué es el producto, qué fuente está controlada, cómo se construye y qué significa que funcione correctamente.
Esta separación es la frontera de portabilidad. AEDF no prescribe Astro, Python, TypeScript, empaquetado de escritorio, API, alojamiento estático ni un entorno de ejecución de agentes. Exige que el adoptante declare esos hechos y luego evalúa la entrega contra ese contrato declarado.
El alcance de fuente se convirtió en un asunto de candidato de publicación
La calificación inicial expuso que “la fuente del repositorio” era demasiado ambigua para un validador reutilizable. Productos distintos ubican sus entradas de ejecución en raíces diferentes, y examinar muy poco o un directorio inferido podía producir evidencia sobre la superficie equivocada.
Por ello, el contrato estable hace explícitas las raíces de fuente controladas. La validación falla cuando una raíz requerida falta, es inválida, se superpone de forma no permitida o sale del adoptante mediante recorrido de rutas. Los controles de todo el repositorio—como los archivos de gobernanza y las comprobaciones de espacios en el rango de cambios—siguen abarcando el repositorio completo y no desaparecen porque la fuente de aplicación esté acotada.
Esta es una frontera de validación, no una afirmación de que las comprobaciones de raíces sustituyan una revisión completa de seguridad o un programa de detección de secretos.
III — Entrega estable del marco
El modelo estable de entrega es nativo de GitHub. Cada adoptante fija una referencia inmutable de versión de AEDF e invoca la validación propiedad del marco en esa versión protegida. El marco en ejecución puede identificar así su propia procedencia mientras valida la política del repositorio adoptante y sus raíces de fuente declaradas.
Contrato de entrega
- Sin bifurcar el validador
- Sin checkout del marco en ejecución
- Privilegio mínimo
El adoptante no mantiene una bifurcación específica del validador, no realiza un segundo checkout privado del marco durante la validación ni conserva una credencial de larga duración entre repositorios. El flujo solo necesita los permisos requeridos para leer el repositorio adoptante y ejecutar la ruta de validación fijada. Esto reduce la superficie de credenciales y cadena de suministro sin fingir que una referencia inmutable resuelve por sí sola todo aspecto de procedencia.
IV — Dos adoptantes calificados
La evidencia de publicación provino de sistemas cuya arquitectura, cadena de herramientas y necesidades de entrega son materialmente distintas.
- Sitio web de Avantlord
- Un sitio Astro, static-first, orientado a contenido y consciente de localización, con colecciones tipadas, validación de construcción web y entrega mediante Cloudflare Workers Static Assets.
- ProjectOS
- Un producto local-first en Python y TypeScript con fronteras de aplicación y API, paquete de escritorio para Windows, ejecutable PyInstaller y construcción de instalador, además de una arquitectura evolutiva de ejecución mediante agentes.
Un adoptante enfatizó grafos de contenido, superficies lingüísticas pareadas, metadatos, rutas estáticas y empaquetado web. El otro enfatizó fronteras de aplicación, estado local, implementación entre lenguajes, empaquetado ejecutable, construcción de instaladores y orquestación de agentes bajo control humano. Ambos conservaron su propia arquitectura mientras cumplieron la misma semántica del marco.
AEDF v1.0.0 demostró portabilidad en dos arquitecturas de ingeniería materialmente distintas sin requerir bifurcaciones del marco, validadores específicos por repositorio ni atajos semánticos.
Eso es evidencia de portabilidad acotada, no de compatibilidad universal. Un nuevo adoptante puede revelar una nueva suposición y exigir que el marco evolucione mediante el mismo proceso controlado.
V — Las decisiones de publicación siguen la evidencia
RC4 corrigió la procedencia del marco y luego superó la calificación en ambos adoptantes. La pregunta de preparación no era si existía otro número de candidato disponible, sino si quedaba un defecto material sin resolver o una afirmación de publicación sin probar.
- RC4Calificación
El sitio web y ProjectOS cumplieron la misma semántica propiedad del marco en arquitecturas distintas.
- RevisiónPreparación para publicar
La evidencia y los límites restantes se evaluaron de forma explícita.
- 1.0Versión estable
El candidato calificado se promovió sin una ceremonia RC5 carente de evidencia.
- UsoValidación del consumidor
Ambos adoptantes validaron la referencia estable inmutable y migraron hacia ella.
La secuencia fue: calificación RC4 → dos adoptantes exitosos → revisión de preparación → v1.0.0 → validación estable de consumidores → transición de los adoptantes. RC5 no se creó porque no hacía falta otro cambio de candidato para establecer la afirmación aprobada de publicación.
Las decisiones de publicación deben seguir la evidencia, no la ceremonia.
VI — Base de gobernanza en producción
AEDF v1.0.0 es ahora la base de gobernanza de producción para los proyectos de ingeniería de Avantlord donde aplica. Estandariza el contrato de entrega mientras deja la arquitectura técnica en manos de cada adoptante.
- Entrega por órdenes de trabajo
- El trabajo consecuente empieza con intención, alcance, riesgo y aceptación acotados.
- Autoridad explícita
- Revisión arquitectónica, aceptación de producto, integración y publicación siguen siendo decisiones distintas.
- Política del repositorio
- Cada adoptante registra sus obligaciones de arquitectura, validación y ejecución.
- Validación de alcance
- Las raíces controladas son explícitas, validadas y resistentes a recorridos fuera del adoptante.
- Procedencia inmutable
- Los adoptantes vinculan la validación con una referencia estable y protegida del marco.
- Entrega respaldada por evidencia
- Pruebas, construcción, empaquetado y resultados posteriores a la integración permanecen conectados con el estado publicado.
- Manejo de excepciones
- Las desviaciones requieren autoridad visible, no debilitamiento silencioso.
- Puertas humanas de publicación
- La automatización informa la aprobación; no la presupone.
Dirección futura acotada
Las etiquetas firmadas, las atestaciones de publicación y una aplicación más fuerte de comprobaciones requeridas donde las capacidades de la plataforma lo permitan son rutas razonables de robustecimiento. Son oportunidades adicionales, no evidencia de que el contrato estable actual esté incompleto para su alcance aprobado.
- 01Intención humanaResultado, prioridad y aceptación
- 02AEDF v1.0.0Contrato de autoridad, ciclo, evidencia y publicación
- 03Política del adoptanteArquitectura, alcance, pruebas y ejecución
- 04Entrega controladaCambio revisado y evidencia inmutable
- 05ProducciónEl estado exacto autorizado del adoptante
AEDF pasó de experimento de gobernanza a base de producción porque sus límites fueron desafiados, corregidos y validados en sistemas materialmente distintos.
El resultado no es un marco que sea dueño de toda arquitectura. Es un contrato estable para mover la intención de ingeniería hacia una entrega controlada y respaldada por evidencia, manteniendo explícitas la autoridad humana y la verdad específica de cada adoptante.