Matriz de pruebas del núcleo (TEST-01)¶

La matriz de M1 es ejecutable y no depende de credenciales, motores externos ni datos reales. Su fuente de escenarios es escenarios/manifest.json; el ejecutor es backend/tests/test_core_matrix.py.

Cobertura de reglas¶

Regla/caso	Camino positivo	Camino negativo	Limitación/evidencia	Frontera
TYPE_MISMATCH	tipo incompatible en edad	nombre ya es string	capability field_types ausente	0/50/80 %
FIELD_MISSING	obligatoriedad sobre edad	nombre siempre presente	evidencia incompleta	0/50/80 %
FIELD_NULL	obligatoriedad sobre edad con nulls	campo sin null	evidencia incompleta	0/50/80 %
FIELD_REMOVAL_IMPACT / CRITICAL_DELETION	eliminar nombre	eliminar campo inexistente	evidencia incompleta	80 %
FIELD_RENAME_IMPACT	renombrar nombre	renombrar campo inexistente	evidencia incompleta	50/80 %
NESTING_SHAPE_CHANGE	mover edad a ruta anidada	ruta inexistente	Cassandra: NESTING_UNSUPPORTED	50/80 %
INDEX_UNSUPPORTED	propuesta de índice	adapter con capability	adapter sin capability	limitación visible
VALIDATION_UNSUPPORTED	propuesta de validación	adapter con capability	adapter sin capability	limitación visible
CONSTRAINT_UNSUPPORTED	endurecer restricción	operación sin evidencia de cambio	capability ausente	limitación visible
NULLABILITY_CHANGE	requerir no-null	campo completo sin null	evidencia incompleta	0/50/80 %
ARRAY_SHAPE_CHANGE	tags mixto	colección uniforme	capability de tipos ausente	50/80 %
HIGH_IMPACT	severidad en 50/79 %	0 %	evidencia incompleta	50/79 %
CRITICAL_DELETION	borrado al 80 % o más	borrado sin presencia	capability/evidencia ausente	80 %
INCOMPLETE_EVIDENCE	snapshot parcial	snapshot completo	limitación obligatoria	métricas nulas
READ_ONLY_GUARD	propuesta compatible sin incompatibilidad	—	no ejecuta escritura	0 %

Las siete capabilities (field_types, requiredness, nesting, indexes, validations, constraints, engine_specific) también tienen casos parametrizados que verifican regla explícita, affected_count: null e impact_percentage: null cuando falta soporte. ANALYSIS-01 agrega test_analysis_rules.py: valida las 15 reglas analíticas y los cuatro hallazgos estables de capability, categoría/severidad/motores, HIGH_IMPACT, contexto de motor y que rules_applied sea exactamente la secuencia de hallazgos activados.

ANALYSIS-02 agrega test_analysis_evidence.py: exactitud con denominador único y porcentaje, dataset vacío sin porcentaje fabricado, muestra al límite con métricas globales nulas y timeout con duración/limitación visibles. test_mongodb_inspection.py y test_couchdb.py confirman que los adaptadores publiquen evidence_scope, observation_limit y inspection_duration_ms sin secretos.

Cobertura del manifest¶

La matriz parametriza las 50 entradas del manifest, exige IDs únicos, los tres motores, versión 1.0 y al menos diez escenarios críticos. Los escenarios críticos deben producir riesgo ALTO o CRÍTICO; cada ejecución conserva engine, solo las rules_applied activadas y hallazgos para que la salida sea trazable. La ejecución de conectores live y el gate end-to-end permanecen fuera de TEST-01.

Gate integrado E2E-02¶

scripts/run_e2e_scenarios.py consolida los tres runners de motor sin cambiar el contrato del núcleo. backend/tests/test_e2e_scenarios.py cubre el camino correcto de 50 escenarios/14 críticos y el error cuando un crítico pierde su riesgo alto o crítico. El gate conserva reglas, riesgo y evidencia en JSON y Markdown versionados, y CI ejecuta --check para rechazar resultados obsoletos.

Release candidate E2E-03¶

scripts/run_e2e_release.py consume el smoke Docker aislado y verifica que el análisis local del fixture queda bajo dos segundos y no cambia el hash de la colección sintética. El timeout live se controla contra un puerto local sin servicio y debe conservar evidencia incompleta y una limitación explícita. backend/tests/test_e2e_release.py cubre el camino correcto, evidencia faltante y el límite de dos segundos; los artefactos no incluyen el hash, URIs, credenciales ni documentos.

Cobertura específica de MONGO-04¶

scripts/run_mongodb_scenarios.py filtra las 17 entradas MongoDB, conserva el fixture-first del MVP y escribe resultados deterministas en escenarios/resultados/mongodb-scenarios.json. backend/tests/test_mongodb_scenarios.py verifica que las 15 operaciones de ChangeOperation tengan caso, que los escenarios mongo-01, mongo-03, mongo-04, mongo-05 y mongo-10 sean ALTO o CRÍTICO, y que cross-01 fuerce evidencia incompleta, métricas nulas y REQUIERE REVISIÓN. Cada finding debe conservar rule_id, evidence y recommendation.