tests/ — Baterías y vectores de comprobación del Lenguaje SV

Estado vigente · RETP-088: conformidad directa de SV por run_conformance.py --rust-bin rust/target/debug/sv-native, CLI/SEC.0 con ese mismo argumento y paridad nativa/WASI/navegador en CI. Corpus 100 = 14 válidos + 86 inválidos; se conservan los 14 esperados. Los códigos catalogados y los rechazos textuales efectivos se distinguen en la adenda de oráculos. El compilador Python está retirado; sus pruebas citadas más abajo son antecedentes históricos. El banco de campos opcionales, de 64 testigos, y la radiografía §18 fijan el alcance nuevo; se conservan los bancos Domain/Horizon/BridgeSet.

K1-T añade 40 testigos —20 declaraciones/literales conservados y 20 rechazos— en nativo, WASI y navegador, usando el transporte existente. Ejecución: python tests/k1_ternarizer_cases.py --native-probe rust/target/debug/examples/assembly_probe --output-dir artifacts/k1-t. La aceptación de nombres de particiones no prueba una partición; las llamadas no constituidas, proyección de Ternarizer y coerciones técnicas se rechazan. El corpus permanece 100/100. N0 §19 recoge además la rectificación de trece atribuciones erróneas a E001.

La descripción fechada de agosto que sigue es un antecedente histórico, no el contrato de ejecución vigente.

Fecha de resincronización: 22 de agosto de 2026
Autor: Juan Antonio Lloret Egea
ORCID: 0000-0002-6634-3351
Institución: ITVIA — IA eñ™
ISSN: 2695-6411
Licencia: CC BY-NC-ND 4.0

1. Objeto

Esta carpeta contiene dos ámbitos que deben mantenerse diferenciados:

1. la evidencia ejecutable de la etapa frontal de referencia del Lenguaje SV, cuya secuencia es .svp → análisis sintáctico → validación → descenso a IR v0.2 → JSON normalizado;
2. el catálogo de vectores adversariales SEC.0 independiente de la implementación, destinado a fijar condiciones de ataque, evidencia de alcance y resultados contractuales esperados sin anticipar una realización soberana en Python.

Para cada caso válido de la etapa frontal, tests/run_conformance.py exige que la salida normalizada coincida con su archivo .expected.json. Para cada caso inválido, el mismo ejecutor exige que el procesamiento termine con el código diagnóstico exacto declarado en EXPECTED_INVALID_CODES.

Los vectores SEC.0 se mantienen separados en tests/sec0/. No modifican gramática, IR v0.2, validador ni catálogo diagnóstico y no constituyen por sí mismos una implementación material de los contratos.

2. Ejecución

python tests/run_conformance.py
python tests/run_cli_smoke.py
python tests/run_sec0_smoke.py
python tests/run_e006_characterization.py

Los nombres históricos de dos ejecutores contienen smoke; se conservan como identificadores de archivo. tests/run_sec0_smoke.py corresponde a la línea previa de resistencia del compilador y sus tres casos no deben interpretarse como cobertura de los contratos SEC.0-A/D/M/X/T.

El catálogo adversarial SEC.0 se documenta en tests/sec0/README.md, tests/sec0/VECTORES_ADVERSARIALES_SEC0_V1.md y tests/sec0/MATRIZ_CORRESPONDENCIA_ALCANCE_SEC0_V1.md.

El corte N0-01 añade un único caso negativo de conformidad para la unicidad de Codomain. El corpus de ese corte pasa a 80 casos —12 válidos y 68 inválidos— sin regenerar ni modificar los doce oráculos JSON válidos.

3. Estado acreditado de la etapa frontal

Sobre el estado 3d48c422915b0e0bed65ba2e7ce8b807d7a94c33, una verificación independiente en modo de solo lectura acreditó:

• conformidad: 58/58 — 10 casos válidos y 48 inválidos;
• pruebas rápidas de la interfaz de línea de órdenes: 3/3;
• SEC-0 histórico de resistencia del compilador: 3/3;
• caracterización de E006: 4/4.

Los cuatro ejecutores finalizaron con código de retorno 0 y el árbol de trabajo permaneció sin modificaciones antes y después de la ejecución.

Estos resultados son históricos y están ligados al estado indicado. No se transfieren automáticamente a commits posteriores.

4. Vectores contractuales SEC.0

tests/sec0/VECTORES_ADVERSARIALES_SEC0_V1.md conserva escenarios derivados de los contratos SEC.0 cerrados el 21 de agosto de 2026 mediante una forma independiente de la implementación.

Cada vector fija, como mínimo:

precondición
alteración o fallo ejercido
evidencia mínima de alcance sobre el objetivo
resultado contractual esperado

La existencia de un vector en el catálogo no constituye cobertura. La matriz tests/sec0/MATRIZ_CORRESPONDENCIA_ALCANCE_SEC0_V1.md relaciona propiedad, vector y condición mínima de alcance causal, y mantiene NO_PROBADO mientras no exista una ejecución falsable sobre el SUT exacto con alcance acreditado, oráculo admisible y veredicto derivado.

El catálogo incluye escenarios relativos a autoridad y constitución, fallo cerrado, continuidad y persistencia, consumo y recursos, raíces de confianza, TCB(G), atestación, mediación, falsabilidad, aplicabilidad, evidencia y transferencia entre perfiles. Incluye expresamente V-A-13: una nueva identidad local de proceso, contenedor, réplica, fork o reinicio no habilita una segunda T-0 sobre una continuidad autoritativa, AStore o PDep ya habitados.

Las antiguas materializaciones contractuales en Python se conservan en el historial del repositorio, pero no forman parte del árbol vigente. Su retirada evita atribuir a una maqueta local el estatuto de backend, entorno de ejecución o mecanismo material de seguridad.

Los vectores podrán convertirse en pruebas ejecutables cuando exista un SUT identificable y pueda conservarse la traza exigida por SEC.0-T:

TestRun
SUT
TestCase
Targets
ThreatModel
InitialState
InjectedFaults
ReachedFaults
Oracle
Observer
Expected
Observed
Verdict
Artifacts

ReachedFaults no puede reducirse a un registro emitido por el mismo componente bajo la misma clase de fallo cuando ese fallo pueda falsear también el registro. La evidencia de una vía concreta sólo se transfiere a otra cuando se acredita que ambas comparten la misma dependencia causal relevante; de lo contrario cada vía requiere alcance propio.

Los controles positivos y negativos de una misma afirmación deben corresponder a la misma identidad relevante de SUT, garantía y perfil material. En un positivo, Observed debe corresponder al cambio, emisión o consecuencia material del objeto o recurso protegido por G; un permiso, indicador interno, no-op, ausencia de rechazo o registro de éxito no bastan.

Añadir persistencia, recuperación, administración, comunicaciones, una nueva dependencia material u otra capacidad causalmente relevante puede cambiar las clases aplicables aunque el binario permanezca idéntico. La evidencia anterior no se transfiere automáticamente a la identidad resultante.

Las propiedades que dependan de infraestructura externa al proceso deberán ejercerse finalmente contra el sistema completo.

5. Casos válidos de conformidad SVP → IR

6. Casos inválidos

La batería incluye además casos léxicos negativos para guion bajo inicial, palabras reservadas en posición de identificador, marcas combinantes, alfabetos externos al perfil, letras latinas no enumeradas y dígitos no ASCII. Todos ellos deben rechazarse antes de constituir una IR válida.

La relación completa de casos inválidos y códigos esperados se mantiene en EXPECTED_INVALID_CODES, dentro de tests/run_conformance.py. Esa tabla es la referencia ejecutable para la correspondencia caso → diagnóstico.

Entre las comprobaciones recientes figuran:

• codomain_miembro_duplicado.svp → E004;
• admissibility_table_output_fuera_codominio.svp → E011;
• supervise_meta_no_evalresult.svp → E212;
• supervise_coupled_wrong_role.svp → E211;
• transition_event_fuera_horizon.svp → E307;
• transition_induced_parameters_vacios.svp → E406;
• projection_source_no_resultado.svp → E213;
• projection_campo_inexistente.svp → E214;
• projection_undeclared_source.svp → E006;
• resolve_missing_context.svp → E206;
• resolve_missing_mechanism.svp → E207;
• graph_conflicts_fuera_de_v0_1.svp → E001;
• graph_simple_concurrencia_mismo_puente.svp → E114;
• supervise_celltarget_tipo_incorrecto.svp → E006;
• supervise_composedtarget_tipo_incorrecto.svp → E006;
• supervise_systemtarget_tipo_incorrecto.svp → E006;
• gate_numero_entradas_incompatible_con_tabla.svp → E215;
• gate_codominio_posicional_incompatible_con_tabla.svp → E215.

La cobertura de un código mediante un caso explícito no implica por sí sola la cobertura exhaustiva de todo el juicio de la IR relacionado.

7. Caracterización de E006

tests/run_e006_characterization.py comprueba de forma separada cuatro situaciones que actualmente emiten E006:

• una referencia inexistente;
• CellTarget con referencia existente de tipo incompatible;
• ComposedTarget con referencia existente de tipo incompatible;
• SystemTarget con referencia existente de tipo incompatible.

La caracterización obtuvo 4/4 sobre el estado histórico indicado y no modifica el código diagnóstico, su nombre, su mensaje ni el validador. La diferencia entre ambos supuestos permanece documentada como deuda de precisión diagnóstica.

8. Alcance de E215

E215 comprueba la correspondencia entre la secuencia de EvalResult recibida por gate y AdmissibilityTable.input_codomains:

• igual número de entradas;
• igual codominio nominal en cada posición.

La comprobación posicional distingue codominios diferentes aunque contengan el mismo conjunto de valores. También se verificó de forma adicional la ruta de una evaluación procedente de CoupledState.

E215 no ejecuta la tabla ni calcula GateResult.output.

9. Cobertura observable y límites

Los 48 casos inválidos del estado acreditado cubren explícitamente 37 de los 47 códigos del catálogo efectivo. Los diez códigos restantes se encuentran clasificados en COBERTURA_OBSERVABLE_FFL_C_2026_08_20.md según su alcanzabilidad real, la existencia de rutas diagnósticas alternativas o la preservación estructural de la obligación.

La evidencia de la etapa frontal se interpreta distinguiendo:

1. caso persistido;
2. emisión observable;
3. propiedad estructural.

La batería SVP → IR comprueba conformidad de la etapa frontal y su descenso a IR. Los vectores SEC.0 fijan, de forma separada, ataques y criterios contractuales para realizaciones futuras. Ninguno de estos dos ámbitos constituye por sí solo una certificación de ejecución material completa.

FFL-A, FFL-B, FFL-C y FFL-E están cerrados. FFL-D permanece pendiente hasta decisión expresa.

Lenguaje de computación del Sistema Vectorial SV.
Juan Antonio Lloret Egea | ORCID 0000-0002-6634-3351 | CC BY-NC-ND 4.0 | ISSN 2695-6411

10. Oráculos reparados · 06/09/2026

El acta de reparación de oráculos
fija el alcance vigente y actualiza las menciones históricas a JSON normalizado:
Gramática 0.2, IR 0.3, comparación de pares ordenados sin pérdida de miembros ni
precisión numérica, e identidad literal donde se declara. Los doce archivos
.expected.json y los ochenta programas de conformidad se conservan.

python -m unittest discover -s tests -p 'test_oracle_support.py' -v
python tests/run_oracle_sensitivity.py --rust-bin rust/target/debug/sv-native --output-dir artifacts/oracle-sensitivity

La segunda orden exige un binario construido desde el corte examinado. Produce
las cuatro entradas, las salidas y errores originales y un informe con comandos,
retornos y huellas. Un control conforme y tres divergencias detectadas acreditan
la sensibilidad del comprobador. No amplían el corpus conforme ni cierran las
divergencias. Una corrección posterior exige revisar explícitamente este banco.

11. Cierre relacional N0-02 · 06/09/2026

La decisión J-K1 y el acta de cierre limitado añaden cuatro negativos E115 (vacía, clave ausente, ajena y repetida) y un positivo de orden independiente y textos compartidos. El corpus vigente es 85 = 13 válidos + 72 inválidos, Gramática 0.2 / IR 0.3. Los doce esperados anteriores conservan su identidad; el nuevo esperado se declara desde los campos normativos y la huella de la fuente, sin generarlo desde la salida del compilador.

python -m unittest discover -s tests -p 'test_output_semantics_totality.py' -v
cargo test --manifest-path rust/Cargo.toml -p sv_core --test output_semantics_totality

Las cinco pruebas Python verifican la relación y la conservación del AST; las seis Rust ejercen además ES/EN y ensamblaje con referencias cruzadas. Las subdivisiones de cada prueba no se suman como casos de conformidad.

run_oracle_sensitivity.py pasa al esquema sv-oracle-sensitivity-v2: conserva el control y las dos sondas CRLF, exige E115 para semantics_duplicate enlazada y añade semantics_unbound_duplicate como testigo residual de N0-03. Resultado: un control, un rechazo N0-02 y tres divergencias abiertas detectadas. Las sondas siguen separadas de los 85 programas de conformidad; no se acredita cierre global de homónimos ni reparación de DFL-008.

12. Unicidad y estabilidad de la proyección N0-03 · 06/09/2026

El acta N0-03 y J-J0 añaden una comprobación complementaria de unicidad a todas las semánticas. El corpus vigente pasa a 88 = 14 válidos + 74 inválidos: se añade la semántica no enlazada repetida (E115), un control negativo del rechazo previo de Connector.mapping (E007) y un positivo de mapas independientes, claves compartidas entre objetos, mapa vacío y texto con LF, tabulación, barra inversa y Unicode. El nuevo esperado se declara desde el esquema; los trece anteriores permanecen intactos.

assert_json_roundtrip comprueba lectura, escritura y nueva lectura del valor JSON conservando pares, orden, tipos y tokens numéricos. No es un serializador de IR. Se integra en assert_success y en la conformidad directa; R0-7, WASI y la preparación del manifiesto de navegador reciben la comprobación sin incorporar bibliotecas al núcleo. El navegador compara después los bytes exactos. Tres pruebas nuevas del observador verifican ámbitos locales, escapes homónimos y 5000 dígitos sin estrechamiento a un entero de máquina ni coma flotante: 19 pruebas del observador en total.

python -m unittest discover -s tests -p 'test_json_projection.py' -v
cargo test --manifest-path rust/Cargo.toml -p sv_core --test json_projection

Tres pruebas Python contrastan, además, la conservación de miembros desde AST antes de perderlos en un mapa. Cinco pruebas Rust cubren ES/EN, mapas independientes, rechazo sin celda, ensamblaje y la guarda previa de Connector. La etapa frontal vigente no interpreta escapes dentro de cadenas SVP: el positivo contiene LF y tabulación reales; el serializador JSON los escapa conforme a su contrato existente.

El banco de sensibilidad pasa a sv-oracle-sensitivity-v3, conservando exactamente las cinco entradas de v2. Exige un control, dos rechazos E115 (N0-02/N0-03) y dos divergencias CRLF aún abiertas en DFL-008. No suma las sondas a la conformidad y no adapta automáticamente esperados a un nuevo resultado.

13. Referencia de arquitectura N0-04 · 07/09/2026

El acta N0-04 documenta J-H0, diagnóstico, recepción y límites. El corpus vigente es 91 = 14 positivos + 77 negativos. Las nuevas entradas aíslan arquitectura ausente, tipo incorrecto y dos grafos reales distintos para Agent.

transition_data_events.svp conservaba Arch1 sin declarar. Se añaden explícitamente tres declaraciones al final y se modifica su esperado desde el esquema: los cinco objetos anteriores se mantienen; se añaden los tres nuevos y se actualiza la huella. Los otros trece esperados permanecen intactos. Las versiones históricas y sus huellas están enlazadas en el acta; no se regeneran esperados desde el compilador.

Cuatro pruebas Python (python -m unittest discover -s tests -p 'test_horizon_architecture.py' -v) y cinco Rust (cargo test --manifest-path rust/Cargo.toml -p sv_core --test horizon_architecture) ejercen referencias, Agent y conservación. Rust incluye ES/EN y ensamblaje mixto; el corpus común 14/77 llega a WASI y navegador por los flujos existentes. La multiplicidad de Horizon.events se conserva sin decidir su estatuto. Los negativos anteriores conservan su primer rechazo aunque puedan contener otras infracciones; esa precedencia no acredita referencias válidas. Sensibilidad v3 y sus cinco fuentes permanecen intactas.