SCAFFOLD 0.2: decisión de aceptación¶
| Campo | Registro |
|---|---|
| Fecha | 16-oct-2026; hora de aprobación no registrada. |
| Responsable | José Adrián Ruiz-Carmona, responsable metodológico de SCAFFOLD; cuenta pública kasailabs en Codeberg, según el registro de autoridad de 0.1. |
| Decisión y procedencia | Aprobación expresa del responsable en la sesión de revisión de las cinco propuestas. Este registro conserva una síntesis; no publica la conversación privada. |
| Edición | SCAFFOLD 0.2 — accepted. |
| Alcance aceptado | R-033 a R-037: impacto e invalidación de evidencia, correspondencia ejecución/infraestructura/código, migración compatible de datos, límites estructurales y conexiones remotas de ingeniería. |
| Base | Los 31 requisitos de SCAFFOLD 0.1 se incorporan por referencia sin modificar sus archivos o huellas. Total 0.2: 36 requisitos. |
| Texto de referencia | Requisitos adicionales; español normativo. Los IDs provisionales PROP-033 a PROP-037 corresponden respectivamente a R-033 a R-037. |
| Formalización | La redacción aprobada se expresa en fichas con actor, condición, obligación, evidencia, límite y riesgo residual; las responsabilidades y excepciones conservan la edición base. No incorpora nuevos umbrales ni herramientas obligatorias. |
| Integridad | reference/scaffold-accepted-0.2-sha256.json fija las huellas del texto español y de esta decisión, los IDs incluidos y la referencia íntegra a 0.1. Es evidencia de integridad, no de identidad criptográfica del aprobador. |
| Límites de aprobación | No acepta perfiles de ingeniería o jurisdicción, axiomas nuevos, traducciones como revisadas, implementaciones, certificaciones ni una enmienda de ASILO/MILPA. R-017 sigue pendiente y excluido. |
| Publicación | Commit, push, tags y despliegue del portal no forman parte de esta aprobación metodológica. |
Transición¶
Un proyecto declara si aplica 0.1 o 0.2; no se infiere por carpetas ni por instalar un SDK. La adopción de 0.2 evalúa los cinco requisitos según sus condiciones. Resultados históricos bajo 0.1 conservan su edición; cambiar una entrada invalida su uso como evidencia vigente sin borrar el resultado histórico. Las dos ediciones conservan sus registros separados.
Qué queda por comprobar¶
La aceptación no demuestra controles en funcionamiento. La implementación necesita mapear cada requisito a su comprobación y conservar resultados reales. Prioridades identificadas:
- Refactor: evidencia de comportamiento antes/después y casos de caracterización pertinentes, vinculados al elemento y a revisiones concretas; menor complejidad no prueba equivalencia.
- Calidad operativa: escenarios, entorno, carga y mediciones para objetivos no funcionales; los umbrales pertenecen al proyecto o perfil, no son universales.
- Acceso remoto: pruebas de autorización, revocación, destino e identidad del servidor, datos enviados al modelo y recuperación ante resultados inciertos, en un entorno autorizado.
Son pendientes de implementación y evaluación, no tres requisitos adicionales aceptados. No se
afirma revisión independiente ni pruebas de proveedores, acceso remoto o migraciones reales.
Las traducciones informativas mantienen review_status: pending hasta revisión competente.