Edición aceptada — 13-oct-2026; completada el 14-oct-2026. Están vigentes 31 requisitos:
SCAFFOLD-R-001 a SCAFFOLD-R-016 y SCAFFOLD-R-018 a SCAFFOLD-R-032.
Decisión humana de aceptación.
El texto en español es normativo.
Estos campos aplican a cada ficha aceptada de esta página. El significado de DEBE,
NO DEBE, DEBERÍA y PUEDE sigue el vocabulario normativo,
adoptado por SCAFFOLD 0.1 sin modificar ASILO ni MILPA.
Campo
Valor
Estado y edición
accepted · SCAFFOLD 0.1 · R-001 a R-016 y R-018 desde el 13-oct-2026; R-019 a R-032 desde el 14-oct-2026.
Clase
Requisito de ingeniería agnóstico respecto a tecnologías. R-019 a R-032 cubren además la gestión del proyecto de software y son agnósticos respecto a herramientas de seguimiento y servicios de alojamiento de código.
Alcance general
Personas y asistentes que construyen software en repositorios que declaran SCAFFOLD 0.1. R-019 a R-032 se aplican además a la planificación, integración y entrega de ese software, por decisión del owner del 14-oct-2026.
Excepción
El responsable humano registra razón, alcance, duración, riesgos, reversión y fecha de revisión. R-012 y R-013 definen procedimientos particulares; no eximen ASILO/MILPA. Apartarse de un DEBERÍA exige razón registrada y aceptación del riesgo.
Procedencia
Corpus editorial propio de SCAFFOLD, consolidado en la edición 0.1 por la decisión humana registrada. El campo Base conserva la relación con ASILO 0.1 y MILPA 0.1, sin constituir enmienda a ellos.
Evidencia de aceptación
Decisión humana y registro separado reference/scaffold-accepted-0.1-sha256.json en el repositorio del método.
Decisiones futuras
Las revisiones requieren nueva edición identificada y decisión humana; la enmienda R-017 queda fuera de esta edición.
Cada ficha añade problema, alcance y condición de aplicación, actor humano responsable,
formulación verificable, evidencia esperada, riesgo residual y base. El proyecto identifica
a las personas que ocupan esos roles. La ficha se lee junto con estos campos comunes.
Los roles son responsabilidades, no puestos. Una misma persona PUEDE ocupar varios; en un
proyecto de una persona, los ocupa todos. Un agente no ocupa ninguno.
Rol
Responde de
Responsable de producto
Objetivo, carta de proyecto, orden de la lista de trabajo y aceptación de lo terminado.
Responsable de coordinación
Zonas, cadencia, cuadrillas, asignación y revisión periódica.
Responsable técnico
Arquitectura, contratos, modelo de ramas, dependencias y levantamiento técnico.
Responsable de entrega
Entornos, promoción de artefactos, despliegue, reversión y versiones.
Responsable de lote
Un lote concreto: zonas, asistentes, traspasos y resultado.
Responsable de cuadrilla
Una cuadrilla de personas, de agentes o mixta, y la supervisión de sus agentes.
Las fichas R-001 a R-018 nombran a su actor por la tarea («persona responsable de…»). El
proyecto indica qué rol ocupa cada una; si no lo indica, responde el responsable de coordinación.
Una ruta NO DEBE tener más de un dueño de escritura declarado. Una ruta compartida DEBE declararse como tal, con la regla de turno que el proyecto fije.
Evidencia esperada
Mapa de zonas, dueño o turno compartido y rutas del cambio.
Riesgo residual
La herramienta puede ignorar el mapa.
Base
Cita: zonas restringidas en el manifiesto (MILPA-R-004). Añade: dueño por ruta y turno.
Arranque con referencias inexistentes o contexto excesivo.
Alcance y condición de aplicación
Se prepara el contexto inicial de una tarea con asistentes.
Actor responsable
Responsable del contexto de la tarea.
Formulación verificable
El repositorio DEBERÍA declarar un contexto de arranque: la lista corta de artefactos vigentes que un asistente lee primero. Lo citado DEBE existir. Cada tarea sigue sujeta a su propio presupuesto de contexto, con clasificación máxima de datos y caducidad.
Evidencia esperada
Lista de entrada, existencia de referencias y presupuesto de esa tarea.
Riesgo residual
Un artefacto vigente puede contener información incorrecta.
Base
Relacionado: presupuesto de contexto por tarea, que no se reutiliza entre tareas (ASILO-R-003). Añade: catálogo de entrada que cada presupuesto puede incluir.
Pérdida o alteración del trabajo al cambiar de asistente.
Alcance y condición de aplicación
Se cambia de asistente dentro de un lote.
Actor responsable
Persona responsable del lote, con emisor y receptor identificados.
Formulación verificable
Al cambiar de asistente dentro de un lote, quien entrega DEBE dejar una nota de traspaso con los campos de la guía y un estado. Una nota tomada NO DEBE editarse; si el objetivo cambia, se cancela con motivo y se abre otra. El cambio de herramienta no concede permisos ni continuidad.
Evidencia esperada
Nota con campos completos, estados, historial y huella al tomarla.
Riesgo residual
Una nota completa puede describir mal el estado real.
Base
Sin base aceptada: la guía de contexto describe el traspaso como técnica explicativa, no como estándar. Añade: obligación, estado, toma por quien recibe y no edición tras tomarla.
Contrato, mapa de arquitectura y código DEBEN declarar la versión con que se corresponden, y el repositorio DEBERÍA poder comprobar que un cambio de uno no deja a otro desactualizado sin aviso.
Evidencia esperada
Versiones correspondientes y resultado de comprobación, o razón de apartarse del DEBERÍA.
Riesgo residual
Artefactos sincronizados pueden compartir el mismo error.
Base
Relacionado: vínculos entre proyectos con contrato y versión (MILPA-R-007); la regla de dependencias DEBERÍA comprobarse de forma automática cuando el perfil lo permita (ASILO-R-002). Añade: sincronía interna de un repositorio, con la misma fuerza que ASILO-R-002 para la comprobación (DEBERÍA).
Trabajo sin objetivo, límites ni cierre verificable.
Alcance y condición de aplicación
Trabajo con asistentes en el repositorio.
Actor responsable
Persona responsable del lote.
Formulación verificable
El trabajo DEBE organizarse en lotes de tipo función, corrección, reestructuración o investigación, con objetivo, persona responsable, zonas, asistentes, intervalo, estado y resultado. El costo se registra como dato o como «desconocido», nunca como estimación disfrazada.
Evidencia esperada
Registro con tipo, objetivo, responsable, zonas, asistentes, intervalo, estado, resultado y costo o desconocido.
Riesgo residual
Un registro completo no demuestra calidad del trabajo.
Base
Relacionado: separación de hechos e hipótesis en informes que se usan para decidir (MILPA-R-002); límites de costo, acciones y tiempo por ejecución automatizada (ASILO-R-007), que un lote no sustituye. Añade: unidad organizativa, registro de costo y cierre.
Integración sin comprobaciones o efecto crítico sin decisión humana.
Alcance y condición de aplicación
Antes de integrar un lote o producir un efecto catalogado como crítico.
Actor responsable
Persona responsable de la integración y del efecto crítico.
Formulación verificable
Antes de integrar un lote, DEBEN ejecutarse las comprobaciones que el repositorio declare. Un asistente NO DEBE integrar ni desplegar por sí mismo lo que el catálogo de efectos críticos del proyecto incluya; lo demás sigue las comprobaciones declaradas.
Evidencia esperada
Resultados de comprobaciones y confirmación informada para el efecto crítico.
Riesgo residual
Las comprobaciones y la revisión humana pueden omitir errores.
Base
Relacionado: ASILO-R-005 exige un catálogo explícito de efectos críticos, cuyo mínimo incluye publicar o enviar a terceros; desplegar puede entrar ahí. Añade: comprobaciones por integración y la integración o el despliegue como candidatos explícitos a ese catálogo. La decisión humana se limita a lo catalogado, porque ASILO-R-005 advierte que pedir aprobación para todo lleva a aprobar sin leer.
Configuración de ingeniería publicada dentro del producto.
Alcance y condición de aplicación
Se construye un artefacto para desplegar.
Actor responsable
Persona responsable de construcción y publicación.
Formulación verificable
La configuración exclusiva de la capa de ingeniería (zonas, notas, lotes, configuración de los asistentes de programación) DEBE quedar fuera del artefacto que se despliega, comprobado sobre el artefacto construido.
Evidencia esperada
Inventario y comprobación sobre el artefacto construido que acrediten la exclusión.
Riesgo residual
El inventario puede omitir archivos o datos incrustados.
Base
Sin base aceptada. ASILO-R-002 pide declarar capas y su regla de dependencia, no excluir archivos. Añade: exclusión comprobada.
Exploración que elude controles o se vuelve trabajo canónico sin cierre.
Alcance y condición de aplicación
El proyecto decide habilitar un modo de exploración.
Actor responsable
Persona que autoriza la exploración y su salida.
Formulación verificable
Un proyecto PUEDE declarar un modo de exploración aislado. Antes de iniciarlo DEBE identificar las comprobaciones de zona, sincronía y lotes que permite suspender, su alcance y duración y la persona responsable. Siguen vigentes los demás requisitos SCAFFOLD, los requisitos ASILO/MILPA, los permisos, los límites de datos y la revisión de efectos críticos. Todo resultado DEBE descartarse o entrar en un lote formal con las comprobaciones aplicables antes de integrarse.
Evidencia esperada
Declaración previa de controles suspendibles, límites y salida registrada como descarte o lote formal.
Riesgo residual
El aislamiento de la exploración puede fallar.
Base
Relacionado: lugar separado para material temporal no canónico (MILPA-R-006) y vínculos exploratorios marcados y sin publicación (excepción de MILPA-R-007). Añade: modo formal y su salida.
Se usa una vía de urgencia para omitir comprobaciones de ingeniería.
Actor responsable
Persona responsable de activar la vía y de la revisión posterior.
Formulación verificable
Una vía de urgencia para omitir comprobaciones de ingeniería DEBE definirse de antemano, dejar registro al usarse y terminar en revisión posterior. No exonera la revisión que exige ASILO-R-005, previa o posterior según la excepción de emergencia de esa ficha.
Evidencia esperada
Procedimiento previo, registro de uso y revisión posterior, con la decisión ASILO-R-005 que corresponda.
Riesgo residual
La revisión posterior no deshace todos los efectos.
Base
Cita: emergencia definida de antemano (ASILO-R-005). Añade: el procedimiento para la capa de ingeniería.
Escritura entre repositorios sin alcance ni contrato.
Alcance y condición de aplicación
Una raíz coordina varios repositorios.
Actor responsable
Persona responsable de la coordinación entre repositorios.
Formulación verificable
La raíz de un proyecto compuesto DEBE declarar qué repositorios coordina y por qué contrato se comunican. Desde la raíz NO DEBE escribirse en un repositorio hijo salvo mediante un lote abierto en ese hijo.
Evidencia esperada
Manifiesto de hijos, contratos y lotes abiertos en los hijos afectados.
Riesgo residual
Los manifiestos pueden no reflejar la estructura real.
Base
Cita: nodo padre en el manifiesto, herencia fuera de 0.1 (MILPA-R-004); alcance no más amplio que el de quien invoca (ASILO-R-004). Añade: dirección del trabajo entre niveles.
Contexto de raíz que absorbe código sin un lote del hijo.
Alcance y condición de aplicación
Se prepara una tarea en una raíz compuesta.
Actor responsable
Persona responsable del contexto de la raíz.
Formulación verificable
Desde la raíz, el contexto DEBE limitarse a manifiestos, contratos, mapas y notas de los hijos; su código entra en un lote del hijo. Cada tarea de la raíz sigue sujeta a su propio presupuesto de contexto.
Evidencia esperada
Presupuesto y lista de fuentes de la raíz; lote del hijo para acceso a su código.
Riesgo residual
Un manifiesto o nota puede exponer información no prevista.
Base
Cita: fuentes permitidas por tarea (ASILO-R-003). Añade: regla por defecto para el nivel que coordina.
Se construye sin objetivo, alcance ni responsables acordados; cada persona o asistente infiere el propósito por su cuenta.
Alcance y condición de aplicación
Todo proyecto que declare SCAFFOLD, al arrancar desde cero o al adoptar el método sobre trabajo existente.
Actor responsable
Responsable de producto.
Formulación verificable
Antes de abrir el primer lote de tipo función, el proyecto DEBE tener una carta de proyecto con objetivo, problema que resuelve, alcance y exclusiones, personas responsables de producto, coordinación, técnica y entrega, catálogo de efectos críticos, restricciones de datos y criterio de éxito observable. La carta DEBE llevar versión y fecha; cambiarla DEBE quedar registrado como decisión del responsable de producto.
Evidencia esperada
Carta con versión, responsables nombrados, catálogo de efectos críticos e historial de cambios.
Riesgo residual
Una carta completa puede describir un objetivo equivocado.
Base
Cita: owner humano y alcance en el manifiesto (MILPA-R-004); catálogo de efectos críticos (ASILO-R-005). Añade: la carta como punto de partida del trabajo planificado.
Se adopta el método sobre un sistema existente sin saber qué hay: se planifica sobre supuestos y se reabren decisiones ya tomadas.
Alcance y condición de aplicación
Se adopta SCAFFOLD sobre un repositorio, producto o proyecto que ya tiene código, usuarios o compromisos.
Actor responsable
Responsable técnico.
Formulación verificable
Al adoptar SCAFFOLD sobre trabajo existente, el proyecto DEBE registrar un levantamiento con: inventario de repositorios y entornos, comprobaciones existentes y su último resultado, versiones en uso, dueños conocidos, deuda y riesgos conocidos, y trabajo en curso. Cada dato DEBE marcarse como hecho con fuente o como hipótesis. El trabajo en curso DEBE convertirse en elementos de trabajo o descartarse con motivo.
Evidencia esperada
Levantamiento fechado, con hechos e hipótesis separados, y elementos de trabajo creados desde él.
Riesgo residual
Lo que nadie recuerda no aparece en el levantamiento.
Base
Cita: hechos, inferencias e hipótesis separados (MILPA-R-002). Añade: el levantamiento como entrada desde cualquier punto del proyecto.
Trabajo que nadie pidió, sin criterio para saber cuándo está terminado, ni forma de encontrar por qué se hizo.
Alcance y condición de aplicación
Todo trabajo planificado del proyecto.
Actor responsable
Responsable de producto.
Formulación verificable
El trabajo planificado DEBE registrarse como elementos de trabajo con identificador estable, tipo, objetivo, criterios de aceptación verificables, persona responsable, estado, dependencias y elemento padre o ninguno. Un lote de tipo función o corrección DEBE citar al menos un elemento de trabajo; un lote de investigación o reestructuración PUEDE abrirse sin él si declara su motivo. Un identificador NO DEBE reutilizarse.
Evidencia esperada
Lista de trabajo con elementos completos y lotes enlazados a ellos.
Riesgo residual
Criterios de aceptación bien escritos pueden pedir lo equivocado.
Base
Relacionado: lotes de trabajo (SCAFFOLD-R-009); dependencias entre lotes (SCAFFOLD-R-016). Añade: el elemento de trabajo como unidad planificada, distinta del lote que la ejecuta.
Un asistente, una herramienta o quien llega primero decide qué se construye y en qué orden.
Alcance y condición de aplicación
Se ordena, acepta o descarta trabajo planificado.
Actor responsable
Responsable de producto.
Formulación verificable
El orden de la lista de trabajo, la aceptación de un elemento terminado y su descarte DEBEN decidirlos personas con ese rol declarado. Un asistente PUEDE proponer elementos, criterios y orden; NO DEBE reordenar, aceptar ni descartar sin que quede registrada la decisión de una persona.
Evidencia esperada
Historial de orden y de aceptación con la persona que decidió.
Riesgo residual
Una persona puede aceptar sin revisar.
Base
Relacionado: revisión humana de efectos críticos (ASILO-R-005). Añade: la prioridad y la aceptación del trabajo como decisiones humanas.
Se empieza trabajo que no está claro y se declara terminado trabajo que no lo está.
Alcance y condición de aplicación
Un elemento de trabajo entra en curso o se marca terminado.
Actor responsable
Responsable de coordinación para la condición de listo y la definición de terminado; la aceptación sigue SCAFFOLD-R-022.
Formulación verificable
El proyecto DEBE declarar una condición de listo para empezar y una definición de terminado, con versión. Un elemento NO DEBE marcarse terminado sin que sus criterios de aceptación y la definición de terminado se hayan comprobado y sin la aceptación de una persona. La definición de terminado DEBE incluir las comprobaciones de integración del repositorio (SCAFFOLD-R-010).
Evidencia esperada
Definiciones con versión y, por elemento terminado, comprobaciones ejecutadas y persona que aceptó.
Riesgo residual
Una definición de terminado débil deja pasar trabajo incompleto.
Base
Sin base aceptada en ASILO/MILPA. Añade: condición de listo y definición de terminado.
Se abre más trabajo del que se termina, el equipo no se sincroniza y los mismos problemas se repiten.
Alcance y condición de aplicación
Todo proyecto con trabajo en curso.
Actor responsable
Responsable de coordinación.
Formulación verificable
El proyecto DEBE declarar su cadencia: ciclos de duración fija o flujo continuo. En flujo continuo DEBE declarar un límite de trabajo en curso por estado o por persona y cuadrilla. Con cualquier cadencia, el proyecto DEBE declarar la periodicidad de una revisión del trabajo terminado y de una mejora del proceso, y hacerlas con fecha, participantes y acuerdos registrados; cada acuerdo DEBERÍA convertirse en elemento de trabajo.
Evidencia esperada
Cadencia declarada, límites de trabajo en curso cuando apliquen y actas de revisión y mejora.
Riesgo residual
Las reuniones pueden hacerse sin cambiar nada.
Base
Sin base aceptada en ASILO/MILPA. Añade: cadencia, límite de trabajo en curso y revisión periódica.
No se sabe qué cambio implementa qué trabajo, ni qué trabajo incluye una versión.
Alcance y condición de aplicación
Toda rama de trabajo, cambio confirmado, solicitud de integración y versión.
Actor responsable
Responsable técnico.
Formulación verificable
Cada rama de trabajo y cada solicitud de integración DEBEN citar el identificador del elemento de trabajo o del lote que implementan. Cada cambio confirmado DEBE cumplir SCAFFOLD-R-003 en un campo legible por máquina. Desde una versión DEBE poder obtenerse la lista de elementos de trabajo que incluye, y desde un elemento, sus cambios.
Evidencia esperada
Convención de nombres declarada, referencias en ramas, cambios y solicitudes, y una consulta que liste elementos por versión.
Riesgo residual
Una referencia puede apuntar al elemento equivocado.
Base
Cita: atribución de cambios (SCAFFOLD-R-003). Relacionado: procedencia (MILPA-R-001). Añade: trazabilidad en ambos sentidos entre trabajo, cambios y versiones.
Cambios que llegan a la rama principal sin revisión ni comprobaciones, o ramas que viven tanto que integrarlas es otro proyecto.
Alcance y condición de aplicación
Repositorios con control de versiones donde trabajan personas o asistentes.
Actor responsable
Responsable técnico.
Formulación verificable
El repositorio DEBE declarar su modelo de ramas: rama principal, tipos de rama, quién integra y con qué comprobaciones. La rama principal DEBE estar protegida: un asistente NO DEBE escribir en ella sin solicitud de integración revisada por una persona. Una rama de trabajo DEBERÍA pertenecer a un solo lote y tener una vida máxima declarada. Dos asistentes NO DEBEN escribir a la vez en la misma rama salvo turno declarado.
Evidencia esperada
Modelo de ramas declarado; protección configurada en el servicio de alojamiento o, sin servicio, regla declarada y comprobación del historial de la rama principal; edad de ramas abiertas.
Riesgo residual
La protección puede desactivarse o tener excepciones olvidadas.
Base
Cita: zonas de escritura y turno (SCAFFOLD-R-001); comprobaciones antes de integrar (SCAFFOLD-R-010). Añade: modelo de ramas y protección de la rama principal. La revisión de una solicitud de integración es revisión de código; no es la confirmación de efectos críticos de ASILO-R-005, que sigue reservada a lo catalogado.
Entornos sin propósito declarado: datos reales en pruebas, secretos compartidos entre entornos, despliegues por quien tenga acceso.
Alcance y condición de aplicación
Todo entorno donde se ejecuta el software: local, integración, pruebas, preproducción, producción u otros.
Actor responsable
Responsable de entrega.
Formulación verificable
El proyecto DEBE declarar sus entornos con propósito, valor máximo de clasificación de datos admitido, origen de sus secretos, quién puede desplegar en él y comprobaciones de entrada. La clasificación usa una escala con nombre y valores definidos (MILPA-R-003). Un entorno que use secretos DEBE tener secretos propios, no compartidos con otro entorno. Un entorno que no sea de producción NO DEBE recibir datos reales por encima de su valor declarado salvo excepción registrada. Desplegar en producción DEBE figurar en el catálogo de efectos críticos.
Evidencia esperada
Declaración de entornos y registro de despliegues con persona y comprobaciones.
Riesgo residual
Una copia de datos puede salir de su entorno por una vía no declarada.
Base
Cita: datos sensibles y secretos (ASILO-R-006); efectos críticos (ASILO-R-005). Añade: entornos declarados y despliegue a producción como efecto crítico; SCAFFOLD-R-010 ya preveía que el catálogo incluyera despliegues.
Lo que llega a producción no es lo que se probó, y no hay forma conocida de volver atrás.
Alcance y condición de aplicación
Se promueve un artefacto entre entornos o se despliega.
Actor responsable
Responsable de entrega.
Formulación verificable
El artefacto que se promueve entre entornos DEBE ser el mismo que pasó las comprobaciones, identificado por su huella criptográfica, y NO DEBE reconstruirse por entorno; la configuración por entorno se inyecta aparte. Antes de desplegar en producción DEBE existir un plan de reversión. Al desplegar DEBE registrarse versión, huella, entorno, persona que autorizó y resultado. Si una vía de urgencia (SCAFFOLD-R-013) despliega un artefacto distinto del comprobado, DEBE registrar su huella y lo omitido, y el despliegue entra en la revisión posterior.
Evidencia esperada
Huella del artefacto en cada promoción, plan de reversión y registro de despliegue.
Riesgo residual
Una reversión puede no deshacer cambios de datos.
Base
Relacionado: exclusión de la capa de ingeniería del artefacto (SCAFFOLD-R-011). Añade: identidad del artefacto entre entornos y reversión.
Versiones sin significado declarado ni registro de qué cambió y quién la autorizó.
Alcance y condición de aplicación
Se publica o despliega una versión del software.
Actor responsable
Responsable de entrega.
Formulación verificable
El proyecto DEBE declarar su esquema de versiones y qué cambio exige subir cada componente. Cada versión publicada DEBE tener etiqueta inmutable en el control de versiones, notas de versión obtenidas de sus elementos de trabajo y de los lotes sin elemento que incluya, cambios incompatibles señalados y la persona que la autorizó. Publicar a terceros sigue el catálogo de efectos críticos (ASILO-R-005). Una etiqueta publicada NO DEBE moverse a otro cambio.
Evidencia esperada
Esquema declarado, etiquetas, notas de versión y autorización.
Riesgo residual
Un cambio incompatible puede pasar sin señalarse.
Base
Relacionado: vínculos con contrato y versión (MILPA-R-007); sincronía de versiones (SCAFFOLD-R-006). Añade: esquema y registro de versiones.
Nadie responde por un grupo de agentes, o un equipo humano no sabe qué puede hacer cada asistente.
Alcance y condición de aplicación
El proyecto trabaja con cuadrillas: equipos de personas, de agentes o mixtos.
Actor responsable
Responsable de coordinación.
Formulación verificable
Cada cuadrilla DEBE declarar su persona responsable, integrantes, zonas de escritura y tipos de trabajo que acepta. Cada agente de una cuadrilla DEBE tener perfil de agente con alcance, límites por ejecución (ASILO-R-007) y persona que lo supervisa; ese perfil no es el perfil del proyecto de MILPA-R-006. Una cuadrilla formada sólo por agentes NO DEBE aceptar trabajo, ordenar la lista de trabajo, aprobar su propio resultado ni autorizar un despliegue.
Evidencia esperada
Ficha de cada cuadrilla con responsable, integrantes, perfiles y zonas.
Riesgo residual
La supervisión declarada puede no ejercerse.
Base
Cita: identidad y alcance de cada agente (ASILO-R-004); presupuestos (ASILO-R-007). Añade: la cuadrilla como unidad de asignación con responsable humano.
Se asigna trabajo sin saber quién lo hará ni si cabe en la capacidad disponible; la capacidad de los agentes se confunde con la de las personas.
Alcance y condición de aplicación
Se asigna un elemento de trabajo o un lote.
Actor responsable
Responsable de coordinación.
Formulación verificable
Cada elemento en curso DEBE tener una persona responsable aunque lo ejecute un agente. La planificación DEBE distinguir la capacidad de las personas, medida en tiempo disponible, de la de los agentes, limitada por presupuesto y por la revisión humana que requieren sus resultados. Una estimación DEBE registrarse como estimación, separada del dato medido.
Evidencia esperada
Asignaciones con responsable, capacidad declarada por tipo y estimaciones separadas de datos.
Riesgo residual
La revisión humana puede volverse el cuello de botella sin que se mida.
Base
Relacionado: costo como dato o «desconocido» (SCAFFOLD-R-009); hechos e hipótesis (MILPA-R-002). Añade: asignación y capacidad diferenciada.
Se afirma que el proceso mejora sin medirlo, y los incidentes se olvidan sin cambiar nada.
Alcance y condición de aplicación
Proyectos que entregan software a un entorno de producción o lo publican.
Actor responsable
Responsable de coordinación, con el responsable de entrega para los incidentes.
Formulación verificable
El proyecto DEBE declarar qué indicadores de entrega mide, cómo los obtiene y con qué periodicidad. Todo incidente de producción y toda reversión DEBEN tener una revisión posterior con hechos, causas probables como hipótesis y acciones; cada acción DEBE convertirse en elemento de trabajo. Una afirmación de mejora NO DEBE hacerse sin medición antes y después.
Evidencia esperada
Indicadores con fuente, revisiones de incidentes y elementos de trabajo creados desde ellas.
Riesgo residual
Un indicador puede mejorarse sin que mejore el resultado.
Base
Cita: hechos, inferencias e hipótesis (MILPA-R-002). Relacionado: evaluación de fallos de IA (ASILO-R-008). Añade: medición de la entrega y revisión de incidentes.
Propuesta de enmienda a MILPA-R-007, que hoy exige declarar cada vínculo en ambos extremos. Se decidió proponerla el 13 de octubre de 2026; no está aceptada. Si se aceptara: un vínculo con un sistema que no declara su extremo DEBE marcarse como externo, con el contrato ajeno usado y su versión o fecha de captura, y una nota de traspaso NO DEBE tener por receptor a un externo. Mientras no se acepte, rige MILPA-R-007 con sus excepciones vigentes.
Contradice MILPA-R-007 tal como está (su única excepción son los vínculos exploratorios). Relacionado: lo externo es no confiable (ASILO-R-001).
El campo Base distingue Cita, Relacionado y Sin base aceptada en ASILO/MILPA.
«Sin base aceptada» significa que el requisito es nuevo en SCAFFOLD, no que carezca de
aceptación en SCAFFOLD 0.1. Su aceptación propia no traslada requisitos a otro método.
R-017 conserva su estado de enmienda propuesta a MILPA y requiere una decisión separada.
SCAFFOLD-R-005 usa este formato abierto de campos, independiente de productos y aceptado
en SCAFFOLD 0.1. La guía explicativa de contexto aporta el significado de los apartados citados.
No se exige una serialización, extensión de archivo ni producto de software particular:
Campo
Contenido
Identificador
Único dentro del repositorio.
Emisor y receptor
Quién entrega y quién recibe.
Estado de la nota
abierta, tomada, bloqueada_por, cerrada o cancelada. Es un esquema propio; no se convierte en el estado de un requisito, de un vínculo ni de un lote.
Bloqueada por
Identificador de otra nota, o ninguna.
Origen
Nota de la que procede si fue devuelta, o ninguno.
Caducidad
Fecha, o no declarada. Informa; no cambia el estado por sí sola.
Objetivo, referencias y revisiones, límites vigentes
Los apartados de la guía de contexto.
Resultados; hechos, inferencias e hipótesis; decisiones; siguiente acción
Los apartados de la guía de contexto.
Historial de estado
Fecha, estado, quién y motivo de cada cambio.
Huella al tomarla
Resumen criptográfico del contenido leído por quien la tomó.
Cerrar una nota dice que su trabajo terminó; no aprueba ni acepta su contenido.
Como el de la nota de traspaso, estos formatos son listas de campos, sin serialización ni
producto obligatorios. Un gestor de tareas, un archivo en el repositorio o una hoja de cálculo
pueden cumplirlos. La página de plantillas los muestra con un ejemplo ficticio.
Formato
Requisito
Campos mínimos
Carta de proyecto
R-019
Versión y fecha; objetivo; problema; alcance y exclusiones; responsables de producto, coordinación, técnica y entrega; catálogo de efectos críticos; restricciones de datos; criterio de éxito observable; historial de cambios.
Levantamiento
R-020
Fecha; repositorios y entornos; comprobaciones y último resultado; versiones en uso; dueños; deuda y riesgos; trabajo en curso y su destino; cada dato como hecho con fuente o hipótesis.
Elemento de trabajo
R-021
Identificador; tipo (iniciativa, función, corrección, reestructuración, investigación u otro declarado); objetivo; criterios de aceptación; responsable; estado; padre; dependencias; lotes, ramas, cambios y versión que lo implementan.
Estado del elemento
R-021, R-023
propuesto, listo, en_curso, en_revisión, terminado o descartado. Es un esquema propio: no es el estado de un lote, de una nota ni de un requisito.
Solicitud de integración
R-025, R-026
Elemento o lote; rama; persona responsable; asistentes que intervinieron; comprobaciones y resultado; revisor humano; efectos críticos que toca o ninguno.
Registro de despliegue
R-027, R-028
Versión; huella del artefacto; entorno; persona que autorizó; comprobaciones; plan de reversión; resultado y hora.
Nota de versión
R-029
Versión y etiqueta; elementos incluidos; cambios incompatibles; persona que autorizó; fecha.
Ficha de cuadrilla
R-030
Nombre; responsable; integrantes personas y agentes; perfil, alcance, presupuesto y supervisor de cada agente; zonas; tipos de trabajo que acepta.
Cerrar, terminar o desplegar registra un hecho; no aprueba por sí solo la calidad del resultado.
Declarar zonas no impide que una herramienta escriba fuera de ellas; una nota puede mentir; un
contrato sincronizado puede ser incorrecto; un registro de lotes completo puede documentar trabajo
malo; una persona puede integrar sin leer. Una lista de trabajo ordenada puede ordenar mal; una
definición de terminado puede ser débil; un indicador puede mejorar sin que mejore el producto. SCAFFOLD ordena y hace visible; no elimina colisiones,
errores ni alucinaciones.