Estado: accepted · 16-oct-2026. La decisión humana
acepta cinco requisitos nuevos, R-033 a R-037. SCAFFOLD 0.2 comprende 36 requisitos: los
31 de SCAFFOLD 0.1, incorporados por referencia sin cambiar sus textos,
y los cinco de esta página. R-017 sigue fuera de ambas ediciones; ASILO 0.1 y MILPA 0.1 no cambian.
El español es normativo; las traducciones son informativas y su revisión humana está pendiente.
Requisitos de ingeniería agnósticos para proyectos de software que declaren SCAFFOLD 0.2. No requieren múltiples agentes ni IA en el producto final.
Procedencia y autoridad
Cinco propuestas editoriales aceptadas por el responsable metodológico identificado en la decisión. reference/scaffold-accepted-0.2-sha256.json registra alcance, fuente y huellas.
Lenguaje
DEBE, NO DEBE, DEBERÍA y PUEDE conservan el significado adoptado por SCAFFOLD 0.1 en sus campos comunes; esta edición no modifica el documento de lenguaje normativo ASILO/MILPA.
Excepción
El responsable humano registra razón, alcance, duración, riesgos, recuperación y fecha de revisión, según la edición base. La excepción de ingeniería no suspende permisos, secretos ni revisión de efectos críticos de ASILO.
Aplicación
Cada ficha declara su condición. «No aplica» identifica condición y razón; evidencia ausente o comprobación fallida no se convierten en «no aplica».
Evolución
Cambiar obligaciones, excepciones o alcance requiere nueva decisión humana y edición identificada. La aceptación del método no acredita una implementación ni revisión independiente.
Un artefacto cambia y siguen contándose como vigentes pruebas o decisiones basadas en la revisión anterior.
Alcance y condición
Artefactos con dependencias relevantes para un cambio del proyecto: requisitos, criterios, contratos, diagramas, componentes, configuración, migraciones y evidencia.
Actor responsable
Responsable técnico del análisis; responsable de producto para la aceptación del elemento afectado.
Formulación verificable
Cada artefacto con dependencias relevantes DEBE declarar identificador estable, revisión o huella, autoridad, tipo de relación y condición de aplicación. Ante un cambio, el proyecto DEBE identificar los dependientes afectados y marcar obsoleta la evidencia cuya entrada cambió. La revisión actual del elemento NO DEBE presentarse como terminada hasta regenerar o revisar esa evidencia y obtener la aceptación exigida por R-022 y R-023. Una vista de tablero NO DEBE mantener una fuente independiente del estado del trabajo.
Evidencia esperada
Referencias versionadas, relaciones declaradas, informe de impacto, evidencia invalidada y su sustitución o revisión. El historial anterior se conserva como historial, no como evidencia de la revisión actual.
Límite de comprobación
Una relación expresa dependencia declarada, no cobertura semántica probada. Relaciones desconocidas se informan como no evaluadas; una huella no decide significado.
Riesgo residual
Un grafo incompleto puede omitir afectados; evidencias coherentes pueden compartir un error.
Base
Amplía R-006; aplica autoridad, procedencia y contradicciones visibles de MILPA-R-001, R-007 y R-008.
Código, configuración de ejecución e infraestructura sostienen supuestos incompatibles aunque pasen las pruebas unitarias.
Alcance y condición
Proyectos con despliegue y dependencias de ejecución que afecten su operación.
Actor responsable
Responsables técnico y de entrega.
Formulación verificable
El proyecto DEBE declarar las dependencias de ejecución pertinentes: configuración requerida y opcional, referencias a secretos sin sus valores, puertos y destinos de red, recursos y límites, comprobaciones de salud, dependencias de runtime y propiedades operativas necesarias. DEBE vincularlas con código y manifiestos de despliegue, identificando revisiones y entorno. Las comprobaciones de integración declaradas DEBEN considerar la correspondencia entre esos artefactos según su alcance.
Evidencia esperada
Declaraciones y referencias de configuración, código y despliegue; resultados de comprobaciones de variables, referencias, enlaces y límites pertinentes, con herramienta, revisión y entorno.
Límite de comprobación
Los campos y valores dependen del servicio y entorno; no se impone tecnología ni lista universal. Un servicio sin despliegue registra por qué no aplica.
Riesgo residual
La correspondencia declarada puede no representar la configuración efectiva; un análisis estático puede omitir valores dinámicos.
Base
Concreta R-006, R-010 y R-027 a R-028. Permisos, datos y secretos conservan ASILO-R-004 y R-006.
Versiones concurrentes de código, jobs, eventos y datos dejan de ser compatibles durante despliegue o reversión.
Alcance y condición
Cambios sobre datos persistentes o sus esquemas.
Actor responsable
Responsables técnico, de datos y de entrega; el proyecto identifica quién ocupa cada responsabilidad.
Formulación verificable
El cambio DEBE declarar compatibilidad hacia atrás y hacia adelante con versiones que pueden coexistir, efectos sobre datos, estrategia de migración, verificación, recuperación y condiciones de retiro de estructuras antiguas. Si no puede aplicarse de forma atómica y compatible, DEBE definir una secuencia de trabajo dependiente y NO DEBE retirar la estructura anterior antes de cumplir las condiciones observables de retiro. Una migración irreversible DEBE tener estrategia explícita de recuperación y aceptación humana del riesgo.
Evidencia esperada
Versiones coexistentes y matriz de compatibilidad, secuencia de trabajo, comprobaciones de migración y datos, evidencia de las condiciones de retiro y recuperación o reversión.
Límite de comprobación
Expand-contract es una opción. No se imponen motor, tamaño de lote, tiempo de estabilidad ni promesa universal de ausencia de downtime.
Riesgo residual
Retener una columna antigua no basta para revertir si dejó de recibir escrituras; restaurar datos puede perder cambios posteriores. Los bloqueos y la carga reales pueden diferir de las pruebas.
Base
Concreta R-010, R-016 y R-028; conserva revisión de efectos críticos y límites de datos de ASILO.
La implementación viola límites de dominio, módulos, dependencias o flujos aunque los contratos de API coincidan.
Alcance y condición
El proyecto declara módulos, capas o límites de confianza.
Actor responsable
Responsable técnico.
Formulación verificable
El proyecto DEBE identificar propietarios, dependencias permitidas, interfaces públicas y relaciones prohibidas de los límites declarados. DEBE seleccionar comprobaciones apropiadas al lenguaje y arquitectura para detectar dependencias no permitidas, acoplamiento entre repositorios y divergencia de diagramas relevantes. Cuando una relación no pueda comprobarse automáticamente, DEBE declarar la limitación y la evidencia de revisión.
Evidencia esperada
Mapa de límites y reglas; configuración y resultados de comprobaciones, incluidos casos que rechazan una dependencia prohibida; contratos y diagramas afectados.
Límite de comprobación
AST, reglas de importación y pruebas de arquitectura son opciones. No exige DDD, arquitectura hexagonal, microservicios ni una nomenclatura universal.
Riesgo residual
Análisis estático y diagramas pueden omitir dependencias dinámicas o efectos temporales; respetar límites no prueba corrección interna.
Base
Concreta R-006 y R-007; conserva el modelo de capas de ASILO-R-002 y vínculos de MILPA-R-007.
Una IA desde local hereda credenciales o permisos remotos; las zonas del repositorio no contienen efectos en servidores y una interfaz local puede enviar contexto a un modelo externo.
Alcance y condición
Una tarea de ingeniería asistida por IA conecta con un servidor, incluido uno de inferencia, o produce efectos remotos.
Actor responsable
Responsable técnico declara destinos y alcance; responsable del entorno autoriza el acceso; la persona autorizada decide efectos críticos conforme a ASILO-R-005.
Formulación verificable
La conexión DEBE vincularse al elemento de trabajo y declarar origen, destino, propósito, entorno, protocolo e identidad esperada. DEBE distinguir el destino de la herramienta del servidor del modelo. DEBE verificar la identidad del servidor mediante el protocolo; ante discrepancia, DEBE detenerse para revisión, sin desactivar la verificación ni aceptar una identidad nueva en silencio. DEBE declarar identidad de sesión, capacidades, recursos/rutas, vigencia, revocación y límites; NO DEBE heredar automáticamente el acceso del humano ni ampliar alcance por petición del modelo. DEBE declarar datos autorizados de entrada/salida, tratar respuestas remotas como no confiables y mantener credenciales fuera del contexto y registros del modelo. DEBE comprobar autorización vigente en la frontera real antes de cada acción; un efecto crítico conserva aprobación del destino y objeto concretos. Cambiar destino, acción o alcance DEBE implicar revisión de autorización. DEBE registrar tarea, revisión de contexto, entorno/destino, identidad, operación, decisión, fecha y evidencia con clasificación y retención pertinentes. Ante resultado incierto por desconexión, DEBE reconciliar el estado antes de reintentar.
Evidencia esperada
Configuración versionada sin credenciales; pruebas de destino no autorizado, identidad cambiada, sesión revocada/caducada, escritura con permiso de lectura, respuesta maliciosa, ausencia de secretos y reintento de efecto incierto. Distingue simulación de control probado en un entorno remoto autorizado.
Límite de comprobación
VPN, túnel o conexión autorizada no conceden otros destinos, port forwarding, elevación ni comandos arbitrarios. Un hook Git no controla acciones ya ejecutadas. No exige revisión humana para toda conexión ni un proxy concreto.
Riesgo residual
Un efecto permitido puede causar daño; una respuesta aparentemente inocua puede contener instrucciones maliciosas. Un manifiesto no demuestra contención efectiva.
Base
Concreta R-001, R-004, R-010 y R-027; aplica ASILO-R-001, R-003 a R-007 según sus condiciones, sin modificarlos.
Un proyecto declara la edición que adopta. Adoptar 0.2 requiere evaluar las cinco fichas según
sus condiciones; no convierte resultados históricos bajo 0.1 en incumplimientos retroactivos.
Las responsabilidades humanas existentes pueden acumularse en una persona según la edición base.
Horcón, SCAFFOLD Core u otra implementación pueden proporcionar comprobaciones y adaptadores.
La aceptación no afirma que existan. El registro de decisión
identifica los pendientes de implementación y evaluación.