Preparar la verificación de artefactos

Esta guía aplica SCAFFOLD 0.1. No obliga a adoptar una herramienta, serialización, arquitectura, historia de usuario o diagrama concretos. El perfil de ingeniería propone compromisos optativos; sus contratos ejecutables y aceptación siguen pendientes.

Empieza con un alcance comprobable

Declara carta, levantamiento, elemento de trabajo y criterios de aceptación. Una biblioteca sin UI puede justificar que las comprobaciones de pantallas no aplican; una aplicación web selecciona flujos, estados y entornos pertinentes. Los formatos equivalentes son admisibles si conservan los campos y relaciones de los requisitos. SCAFFOLD 0.1 tiene 31 requisitos aceptados; R-017 continúa como enmienda pendiente.

Artefacto o evidencia	Base existente	Comprobación sugerida y límite
Carta y levantamiento	R-019, R-020	Objetivo, exclusiones, responsables, efectos críticos y fuentes; existir no prueba que estén aceptados.
Historia, función o iniciativa	R-021 a R-024	ID, objetivo, criterios, estado, dependencias, padre y aceptación; una historia es un formato opcional.
Lote, zonas, cuadrilla y traspaso	R-001 a R-005, R-009, R-016, R-030, R-031	Dueños, turnos, límites, inmutabilidad y dependencias sin ciclos; una declaración no impide una escritura externa.
Arquitectura, contrato y código	R-006, R-007, R-018	Versiones correspondientes, dependencias permitidas y sustitución de adaptadores; no impone un patrón universal.
Documentación y diagramas	R-006, R-010, R-023	Enlaces, fuentes editables, compilación y correspondencia; renderizar no acredita corrección arquitectónica.
UI cuando corresponda	R-010, R-021, R-023	Flujos, estados, resoluciones, accesibilidad y revisión visual declarados; una captura o prueba automática no prueba usabilidad o accesibilidad completa.
Git y revisión	R-003, R-008, R-025, R-026	Elemento/lote/cambio/versión en ambos sentidos y protección consultada o regla local; una convención de nombres no demuestra protección.
Integración y entrega	R-010, R-011, R-027 a R-029	Resultado ligado a revisión, artefacto construido, misma huella promovida, configuración aparte y reversión; CI verde no acepta un efecto crítico.
Evaluación y aprendizaje	R-024, R-032	Fuente de indicadores, incidentes y medidas antes/después; simulación no es evaluación real de un modelo.

Los IDs remiten a los requisitos, con sus condiciones y excepciones. El contenido regional necesario en ejecución no se excluye por ser «contexto»: entrega regional.

Cuatro observaciones distintas

1. Forma: campos, tipos, versiones y límites.
2. Coherencia: referencias, dependencias, estados y revisiones correspondientes.
3. Ejecución: evidencia identificada del artefacto, entorno, herramienta y resultado reales.
4. Decisión: quién aceptó qué objeto, con qué alcance y autoridad comprobada cuando corresponda.

Un registro estructuralmente válido puede mentir. Evidencia ausente o una herramienta no disponible se registra como no evaluada, no como éxito. «No aplica» identifica condición y razón; no sustituye una comprobación fallida. Una casilla «revisado por humano» no autentica a una persona. Un resultado técnico no cierra por sí solo un elemento (R-022, R-023).

Fuente de verdad, trazabilidad e impacto de cambios

No existe un único documento que sea fuente de verdad para todo el proyecto. Cada afirmación debe tener una autoridad identificable: el registro de requisitos para necesidades, el contrato para interfaces, el código para comportamiento ejecutable y el registro de decisiones para las decisiones aprobadas. Un README o diagrama puede ser una vista derivada si declara su fuente y forma de regenerarse. Copiar la misma decisión en varios archivos sin propietario crea fuentes competidoras.

La taxonomía para declarar forma de aplicación, estructura, repositorio, despliegue y perfiles regionales está en el perfil de arquitectura de software. El grafo referencia sus fuentes canónicas por ID; no duplica su contenido.

El proyecto mantiene un grafo de artefactos con IDs estables, rutas, tipo, revisión o huella, propietario, condición de aplicación y relaciones tipadas. Como mínimo, el perfil de proyecto declara qué relaciones son necesarias para cada tipo de trabajo. Una cadena sugerida es:

requisito → elemento de trabajo/historia/caso de uso → criterios verificables → contrato y decisión arquitectónica → componentes/código → pruebas/evaluaciones → documentación/diagramas → entrega/operación.

Una relación expresa dependencia o cobertura declarada; por sí sola no prueba que el artefacto satisfaga el requisito. Toda afirmación de cobertura debe llevar evidencia comprobable y una revisión humana cuando el proyecto la requiera. Un grafo acíclico facilita el análisis de impacto; las relaciones de referencia o agrupación que admitan ciclos deben declararse como tales y no participar en el cálculo de dependencias.

Al cambiar un artefacto, el repositorio identifica el nodo modificado, calcula los dependientes transitivos según relaciones declaradas, y marca como pendientes de revisión las evidencias que dependían de la revisión anterior. Un archivo generado se vuelve a generar desde su fuente; no se edita manualmente para silenciar una divergencia. Un artefacto escrito a mano requiere revisión de contenido: una huella o un render correcto no determinan si el significado sigue vigente. Comprobaciones incompletas, referencias ausentes o fuentes en conflicto se informan como tales; no se resuelven por «último cambio gana» ni se regeneran decisiones aceptadas.

El registro puede vivir en YAML, JSON, una base de datos o un sistema de trabajo siempre que conserve IDs, revisiones, relaciones, procedencia y exportación verificable. El repositorio debe mantener un modo de solo lectura para CI que informe nodos afectados y fuentes inválidas sin instalar extensiones ni ejecutar instrucciones encontradas en artefactos. La CI puede bloquear una integración según el perfil declarado; no convierte su resultado en aceptación humana.

Para asistentes de IA, cada tarea recibe los requisitos y contratos pertinentes con IDs y revisiones exactas, las zonas de escritura autorizadas y criterios positivos y negativos. Toda afirmación factual que pase a un artefacto enlaza su evidencia. El asistente propone cambios en una zona limitada; el linter detecta impacto técnico y deriva pendiente, pero no decide significado, autoridad ni aceptación. La persona responsable resuelve conflictos y acepta el resultado.

Cuadrilla base sugerida

El perfil puede formar cuadrillas según riesgos y cambios, no activar todos los roles en todo lote. Una configuración mínima para una función de software es coordinación/producto, arquitectura, implementación y QA. Seguridad participa desde el diseño cuando hay datos, permisos, red, modelos o efectos sensibles. UI/UX se incorpora si existen flujos de usuario. Documentación/DevEx y entrega se incorporan cuando el cambio altera contratos de uso, construcción, CI o publicación. En un proyecto pequeño una persona puede cubrir varias responsabilidades; quien implementa no acredita por sí mismo su revisión independiente ni acepta por producto o entrega.

Cada lote declara un escritor por archivo, revisores, interfaces de traspaso y evidencia. Sólo se paralelizan zonas sin dependencias de escritura; cambios cruzados requieren lote coordinado y una integración serializada. El número de agentes no sustituye responsabilidad humana.

Skills, plugins y MCP

Una skill distribuye instrucciones y procedimiento; un plugin empaqueta funciones instalables para un producto anfitrión; MCP normaliza el protocolo con que un cliente accede a herramientas o recursos. Son capas distintas y sus nombres no acreditan confianza. El cliente anfitrión conserva identidad, autorización por acción, allowlist, límites, procedencia, registro y revocación. El contenido de un repositorio no instala skills/plugins ni habilita servidores MCP automáticamente.

SCAFFOLD-R-006 · R-018 · R-022 · R-023

Implementación agnóstica y segura

El núcleo de comprobación puede recibir artefactos normalizados y devolver hallazgos sin red, Git, navegador, modelos ni escrituras. Adaptadores optativos aportan evidencia de esas herramientas bajo permisos explícitos. Leer un documento no ejecuta sus comandos ni instala complementos. Una integración de CI/CD conserva entradas, configuración y huellas; el proveedor puede cambiar sin cambiar el significado de la comprobación.

Prueba una biblioteca y una aplicación web ficticias, con casos válidos, inconsistentes y con pruebas o decisiones ausentes. Cambiar una revisión invalida la evidencia que dependía de ella. Los detalles de API, configuración y distribución corresponden a la implementación. La metodología no prescribe un producto ni una herramienta de agentes. El generador de plantillas de un producto tampoco demuestra que implemente el ciclo completo de SCAFFOLD.

Volver a SCAFFOLD · Perfil de ingeniería

La edición SCAFFOLD 0.2 añade R-033 a R-037: son 36 requisitos contando la base 0.1. La guía no sustituye esas fichas ni demuestra controles implementados.