Origen de la ampliación SCAFFOLD 0.2¶
Estado: histórico — contenido aceptado el 16-oct-2026. Los identificadores PROP-033 a PROP-037 son el antecedente de R-033 a R-037. La formulación normativa vigente está en los requisitos 0.2, según la decisión humana. El texto siguiente conserva las razones de las propuestas; no es una segunda fuente normativa.
La base ya cubre carta y levantamiento (R-019, R-020), planificación y aceptación humana (R-021 a R-024), trazabilidad y ramas (R-025, R-026), integración y entrega (R-010, R-027 a R-029), cuadrillas (R-030, R-031) y operación (R-032). Las propuestas siguientes se limitan a las relaciones verificables que aún quedan débiles o implícitas. No prescriben Jira, Git, Mermaid, un proveedor, una arquitectura concreta ni un ejecutor de pruebas.
Secuencia de análisis de impacto¶
El cambio identifica primero el artefacto y su revisión. El análisis recorre las relaciones declaradas hacia contratos y límites de módulos, configuración y topología, migraciones y pruebas. La evidencia dependiente de una revisión anterior queda pendiente hasta repetirse o revisarse. Si la relación no se conoce, el resultado es «no evaluado», no «sin impacto». Sólo después se aplican las comprobaciones y aceptación requeridas antes de promover el artefacto.
Propuestas candidatas¶
SCAFFOLD-PROP-033 — Impacto e invalidación de evidencia¶
Problema. Un requisito, historia, contrato, diagrama, configuración, migración o componente puede cambiar mientras pruebas o aprobaciones siguen apareciendo como vigentes aunque se hayan ejecutado sobre una revisión anterior.
Propuesta. Cada artefacto con dependencias relevantes declara un identificador estable, revisión o digest, autoridad, tipo de relación y condición de aplicación. Ante un cambio, el proyecto identifica los descendientes afectados y marca como obsoleta la evidencia cuya entrada cambió. El elemento afectado no se presenta como terminado hasta regenerar o revisar esa evidencia. Las vistas de tablero pueden mostrar ese estado, pero no mantienen una copia independiente de la fuente de trabajo.
Comprobación posible. Cambiar una historia en un caso ficticio identifica sus criterios, contrato, pruebas y componentes dependientes; la ejecución antigua deja de contar como evidencia vigente. Las relaciones desconocidas se muestran como no evaluadas, no como sin impacto.
Relación existente. Extiende la sincronía débil de R-006 y concreta el impacto que ya describe la guía de verificación de artefactos. Se apoya en la autoridad, procedencia y contradicciones visibles de MILPA-R-001, R-007 y R-008; no redefine esas reglas.
SCAFFOLD-PROP-034 — Contrato de ejecución y correspondencia infraestructura-código¶
Problema. La interfaz puede ser correcta y las pruebas unitarias pasar mientras el servicio lee variables no declaradas, asume una conexión no permitida o excede recursos, timeouts o límites que el entorno real no proporciona.
Propuesta. Cuando un proyecto tenga despliegue, declara las dependencias de ejecución que afectan su operación: configuración requerida y opcional, referencias a secretos (nunca sus valores), puertos y destinos de red, recursos y límites pertinentes, health checks, dependencias de runtime y propiedades operativas necesarias. Vincula dichas declaraciones con el código y los manifiestos de despliegue. Los valores específicos dependen del servicio y del entorno; no se impone una lista universal ni una herramienta de infraestructura.
Comprobación posible. El análisis detecta variables consumidas pero no declaradas, referencias a secretos ausentes, enlaces de red no descritos y contradicciones entre límites declarados y configuración de aplicación/despliegue. La evidencia identifica versiones y entorno; no afirma que el despliegue vaya a funcionar en cualquier entorno.
Relación existente. Concreta R-006, R-010 y R-027 a R-028. ASILO-R-004 y R-006 siguen gobernando permisos, datos y secretos; esta propuesta no duplica su política de seguridad.
SCAFFOLD-PROP-035 — Compatibilidad y migraciones de datos¶
Problema. Código de versiones simultáneas, jobs, consumidores de eventos y esquema persistente pueden dejar de ser compatibles durante despliegues graduales o reversiones, aunque cada cambio aislado compile.
Propuesta. Un cambio persistente declara compatibilidad hacia atrás y hacia adelante con las versiones que pueden coexistir, efectos sobre datos, estrategia de migración, verificación, recuperación y condiciones para retirar estructuras antiguas. Para cambios que no puedan aplicarse de forma atómica y compatible, el proyecto define una secuencia de trabajo dependiente (por ejemplo, expansión, transición, cambio de lectura y contracción) y no elimina la versión anterior hasta cumplir las condiciones observables de retiro. Una migración irreversible requiere una estrategia explícita de recuperación y aceptación del riesgo.
Comprobación posible. Pruebas de migración sobre una base efímera con datos representativos; pruebas de compatibilidad entre versiones concurrentes; revisión de operaciones de DDL según el motor elegido; verificación de rollback o recuperación. Ningún umbral de downtime, tamaño de lote ni ventana de estabilidad es universal.
Relación existente. Concreta criterios de R-010 y R-028. El perfil de arquitectura ya declara propiedad, migración, recuperación y datos; esta propuesta llevaría su vínculo al ciclo de trabajo y a la evidencia de integración.
SCAFFOLD-PROP-036 — Límites estructurales verificables¶
Problema. Los contratos de API pueden estar sincronizados mientras se violan límites internos de dominio, módulos, dependencias o flujos de datos. Los nombres de arquitectura por sí solos no impiden esos acoplamientos.
Propuesta. Cuando el proyecto declara módulos, capas o límites de confianza, identifica sus propietarios, dependencias permitidas, interfaces públicas y relaciones prohibidas. Selecciona comprobaciones apropiadas al lenguaje y arquitectura para detectar dependencias no permitidas, acoplamiento entre repositorios y divergencia de los diagramas relevantes. Si una relación no se puede comprobar automáticamente, se declara la limitación y la evidencia de revisión.
Comprobación posible. Una prueba de arquitectura o análisis equivalente demuestra que una dependencia prohibida falla; un cambio de topología identifica contratos, diagramas y revisiones afectados. AST, reglas de importación o análisis estático son opciones de implementación, no mandatos del estándar.
Relación existente. Concreta R-006 y R-007 en el nivel de estructura interna. MILPA-R-007 continúa gobernando vínculos entre proyectos; no se propone modificar MILPA.
SCAFFOLD-PROP-037 — Conexiones y acciones remotas desde ingeniería local¶
Problema. Un asistente en una computadora local puede usar SSH, una API, un cliente de base de datos o un servidor MCP con las credenciales de quien lo inició. Las zonas del repositorio local no limitan por sí mismas lo que lee o modifica en el servidor. Además, usar una interfaz local no implica que el modelo procese los datos localmente.
Alcance y responsable. Aplica cuando una tarea de ingeniería asistida por IA conecta con un servidor, incluido uno de inferencia, o produce efectos remotos. El responsable técnico declara destinos y alcance; el responsable del entorno autoriza el acceso. La decisión sobre efectos críticos conserva ASILO-R-005. No exige aprobación humana para toda conexión.
Propuesta. El proyecto vincula la conexión con el elemento de trabajo y declara:
- Origen de la ejecución, destino, propósito y entorno (desarrollo, prueba o producción). Distingue el servidor sobre el que actúa la herramienta del servidor donde se ejecuta el modelo. Endpoint, protocolo, identidad esperada y política viven en configuración versionada; las credenciales no forman parte de esos artefactos.
- Verificación de identidad del servidor mediante el mecanismo del protocolo, por ejemplo clave de host SSH o certificado TLS. Una discrepancia se detiene para revisión; el agente no desactiva la verificación ni acepta una identidad nueva en silencio. VPN, túnel o acceso a una red no sustituyen autenticación ni autorización.
- Identidad de sesión, capacidades permitidas, recursos y rutas remotas, vigencia, revocación y límites. El acceso disponible en la computadora del humano no se hereda automáticamente. Una conexión autorizada no concede acceso a otros destinos, port forwarding, elevación de privilegios ni ejecución arbitraria de comandos.
- Datos autorizados para salir y entrar: código, archivos, prompts, logs, resultados y contexto recuperado. Las respuestas remotas se consideran no confiables. Las credenciales se utilizan mediante un mecanismo fuera del contexto del modelo; los registros omiten sus valores. Leer datos remotamente también puede exponerlos al proveedor del modelo y requiere evaluar esa ruta.
- Autorización vigente en el punto real de ejecución, antes de cada acción. La revisión de un commit o un hook local no controla una operación SSH, SQL o API que ya ocurrió. Un efecto crítico presenta su destino y objeto concretos a la persona autorizada; cambiar destino, acción o alcance requiere revisar la autorización, sin ampliar permisos por petición del modelo.
- Resultado y trazabilidad mínima: tarea, revisión del contexto, entorno/destino, identidad, operación, decisión, fecha y evidencia con la clasificación y retención pertinentes. Si una desconexión deja incierto un efecto, se reconcilia el estado antes de reintentarlo; no se supone que falló ni se repite ciegamente.
Ejemplo ficticio. Un lote permite consultar logs sanitizados de un servidor de prueba por SSH. La sesión no permite administrar producción ni modificar la base de datos. Si el asistente propone una migración, el proyecto revisa ese efecto, entorno y permisos antes de ejecutarla. Si los logs se analizan con un modelo externo, el envío se evalúa aparte de la lectura por SSH.
Comprobación posible. Probar destino no autorizado, identidad de servidor cambiada, sesión revocada o caducada, intento de escritura con acceso de lectura y resultado remoto con instrucciones maliciosas. Verificar que no se envían secretos al modelo ni se repite un efecto de resultado incierto. La evidencia distingue rechazo simulado y control probado contra un entorno remoto autorizado; no se afirma contención real por tener sólo un manifiesto.
Relación existente. Complementa R-001, R-004, R-010 y R-027 en ingeniería remota. Aplica ASILO-R-001, R-003, R-004, R-005, R-006 y R-007 con sus condiciones. MILPA conserva fuentes, autoridad y vínculos; ninguna de esas ediciones se modifica. Horcón u otro host puede proporcionar adaptadores y mediación; documentar esta propuesta no demuestra que ese control esté implementado.
Límites de alcance y asignación entre metodologías¶
- SCAFFOLD gobierna el ciclo de vida de desarrollo de software asistido por IA: desde la carta y el trabajo planificado hasta arquitectura, código, integración, entrega y aprendizaje. No requiere multiagentes: una persona y un asistente pueden aplicarlo. Tampoco requiere que el producto final contenga IA.
- ASILO aporta los controles de confianza, permisos, datos, efectos críticos, presupuestos y evaluación de fallos de IA. Las propuestas 034, 035 y 037 usan esos controles cuando sus condiciones aplican; no crean una seguridad paralela dentro de SCAFFOLD.
- MILPA mantiene autoridad, procedencia, perfiles, fuentes y vínculos entre proyectos. Sus requisitos actuales cubren el registro de artefactos y contradicciones; no se identifica aquí una enmienda necesaria a MILPA 0.1.
- Horcón puede implementar lectores, analizadores, conectores, vistas y compuertas. Un dashboard es una proyección del estado autorizado, no una autoridad adicional. Una integración externa sólo recibe los datos permitidos por el perfil de ASILO.
- Investigación, publicación, documentación no asociada a software y creación artística pueden usar Horcón/MILPA/ASILO y sus propias extensiones; no se convierten por ello en alcance de SCAFFOLD.
Resultado de la revisión¶
Las cinco propuestas se aceptaron como ampliación SCAFFOLD 0.2. Condiciones, responsables, evidencia, excepciones y riesgo residual se formalizan en sus fichas. ASILO/MILPA, R-017 y los perfiles conservan su estado.