Gramática superficial mínima del Lenguaje SV — v0.2

Sucesora normativa de v0.1 para admisibilidad, `resolve` y coherencia de `Frame`

Autor: Juan Antonio Lloret Egea
ORCID: 0000-0002-6634-3351
ISSN: 2695-6411
Licencia: CC BY-NC-ND 4.0
Fecha: 23 de agosto de 2026
Estado: Especificación técnica pública — v0.2

1. Estatuto y relación con v0.1

La versión 0.2 conserva íntegramente la gramática v0.1 salvo en las producciones y restricciones que este documento sustituye de forma expresa.

Por tanto:

Gramática v0.2
= Gramática v0.1
+ correcciones de este documento

Las construcciones no mencionadas aquí mantienen su sintaxis y su estatuto anteriores. La versión 0.1 se conserva como antecedente histórico y no se reescribe retrospectivamente.

La v0.2 baja a la IR canónica v0.3.

2. Objetivos de la revisión

Esta versión corrige tres fronteras observables de la etapa frontal:

separa los estados de admisibilidad técnica del valor semántico Tri.U;
obliga a que resolve identifique una ocurrencia constituida de U mediante estado y posición;
conserva la sintaxis de Frame, pero somete sus colecciones derivadas a las reglas de cierre estructural y causal de IR v0.3.

No introduce un cuarto valor ternario ni un cuarto impacto semántico independiente.

3. Admisibilidad técnica

3.1. Estados cerrados

La producción v0.1:

{Ok, Degraded, Failed, U}

queda sustituida por el conjunto cerrado:

{Ok, Degraded, NotAdmitted}

El orden superficial de los tres identificadores no tiene significado semántico; el conjunto debe contener exactamente una vez cada estado.

Producción normativa:

admissibility_state        ::= "Ok" | "Degraded" | "NotAdmitted" ;

admissibility_decl         ::= "admissibility_spec" identifier "{"
                               "parameter_id" ":" nat ";"
                               "states" ":" "{" admissibility_state ","
                                                admissibility_state ","
                                                admissibility_state "}" ";"
                               "rule" ":" identifier ";"
                               "}" ;

Reglas de bienformación:

parameter_id > 0;
states contiene exactamente Ok, Degraded y NotAdmitted;
rule no puede estar vacío.

El incumplimiento se diagnostica como:

E110 — InvalidAdmissibilitySpec

3.2. Separación respecto de `Tri`

Failed deja de formar parte de AdmissibilitySpec. El fallo de captura continúa representado por el símbolo técnico Bottom de CaptureSpec.

No existen coerciones automáticas:

Bottom       ↛ Tri
NotAdmitted  ↛ Tri
fallo técnico ↛ Tri.U

Una observación admitida puede producir legítimamente Tri.U únicamente a través de un Ternarizer cuya partición partition_u la clasifique en la región semántica correspondiente.

4. Objetivo explícito de `resolve`

4.1. `ResolutionTarget`

Se introduce una forma superficial cerrada para identificar el objeto revisado:

resolution_target          ::= "(" identifier "," nat ")" ;

Su significado es:

ResolutionTarget = (EvaluableStateRef, position)

La posición es uno-basada.

4.2. Nueva producción de `resolve`

La producción v0.1 que aceptaba el literal abstracto U queda sustituida por:

resolve_cmd                ::= "let" identifier "=" "resolve" "("
                               resolution_target ","
                               "with" ":" identifier ","
                               "context" ":" identifier ","
                               "mechanism" ":" identifier
                               ")" ";" ;

Ejemplo:

let RR1 = resolve((S1, 3),
                  with: RS1,
                  context: ContextoClinico,
                  mechanism: RevisionExperto);

Reglas de bienformación:

el estado referenciado debe ser un CellState o CoupledState evaluable;
la posición debe existir;
el valor efectivo de la posición debe ser U;
with debe referir un ResSpec;
por defecto, la instancia (context, mechanism) debe coincidir exactamente con (ResSpec.context, ResSpec.mechanism).

El incumplimiento de estas condiciones se diagnostica como:

E305 — UnsafeUResolution

resolve representa revisión de una U constituida. La mera ejecución de la revisión no confiere por sí sola una clausura positiva de esa U.

5. Proyección de resultados de `resolve`

La forma general de proyección no cambia:

projection_cmd             ::= "let" identifier "=" identifier "." identifier ";" ;

Para un ResolutionRecord v0.3 se reconocen los campos:

target
previous
reviewed_to
resolved_to
context_ref
mechanism_ref

Ejemplo válido:

let valor_resuelto = RR1.resolved_to;

La existencia del campo resolved_to no significa que el programa pueda fabricar una clausura positiva.

6. `Frame`: sintaxis conservada, bienformación reforzada

La producción superficial de Frame se conserva:

frame_decl                 ::= "frame" identifier "{"
                               "index" ":" nat ";"
                               "architecture" ":" identifier ";"
                               "cell_states" ":" list<identifier> ";"
                               "eval_results" ":" list<identifier> ";"
                               "gate_results" ":" list<identifier> ";"
                               "supervision" ":" list<identifier> ";"
                               "criticalities" ":" list<identifier> ";"
                               "}" ;

La IR v0.3 exige, sin imponer exhaustividad:

architecture referencia un CompositionGraph;
existe como máximo un CoupledState por nodo de esa arquitectura;
dos nodos distintos pueden compartir el mismo CellSpec mediante CoupledSpec distintos;
cada evaluación incluida evalúa un estado del propio Frame;
no hay dos evaluaciones materiales de la misma fuente dentro del mismo Frame;
cada compuerta incluida depende sólo de evaluaciones incluidas;
cada supervisión incluida conserva su meta-evaluación y objetivo dentro del mismo cierre;
un SystemTarget de supervisión debe coincidir con Frame.architecture;
mientras no exista productor superficial constituido de CriticalityResult, criticalities = [].

Las violaciones de este cierre se diagnostican como:

E308 — FrameClosureViolation

7. Versionado observable

La etapa frontal v0.2 debe emitir en la cabecera canónica:

{
  "grammar_version": "0.2",
  "ir_version": "0.3",
  "serializer_version": "0.1.0"
}

8. Elementos que no cambian

Esta versión no introduce:

nuevos literales de Tri;
max o min en la superficie;
declaración superficial completa de ConflictOperator;
primitivas de tiempo, reloj o UTC;
deployment_profile como construcción del Lenguaje;
TCB, raíz de confianza o atestación como tipos de IR;
productor superficial de CriticalityResult;
habilitación de PendingU.

La deuda de ConflictOperator en régimen General permanece visible y no queda resuelta por E308 ni por ninguna de las tres correcciones anteriores.

9. Compatibilidad

Un programa v0.1 que utilice:

states: {Ok, Degraded, Failed, U}

resolve(U, ...)

no es conforme con la gramática v0.2.

Las demás construcciones v0.1 permanecen compatibles mientras satisfagan los juicios de bienformación de IR v0.3.

10. Dictamen técnico

La gramática v0.2 mantiene la superficie austera del Lenguaje SV y corrige las fronteras necesarias para impedir que un fallo técnico se convierta en semántica ternaria, que una revisión opere sobre un U abstracto sin identidad y que un Frame pueda declarar resultados ajenos a su propio cierre estructural o causal. El perfil léxico complementario de la sección 11 cierra además las primitivas heredadas letter y digit sin modificar la semántica.

11. Perfil léxico complementario

Las primitivas letter y digit heredadas de la Gramática v0.1 se interpretan conforme a ADENDA_NORMATIVA_PERFIL_LEXICO_GRAMATICA_SVP_0_2_2026_08_27.md. La adenda cierra el repertorio de identificadores y naturales sin modificar Tri, la IR 0.3 ni las palabras reservadas.

12. Perfiles fuente

Los perfiles fuente SVP-ES y SVP-EN se rigen por ESPECIFICACION_NORMATIVA_PERFILES_FUENTE_SVP_ES_EN_v1_2026_08_29.md.

El perfil fuente es una capa de representación anterior a la aplicación de la gramática canónica. Resuelve exclusivamente las formas constitutivas declaradas por el perfil hacia una misma identidad canónica. No crea una segunda gramática, una segunda IR ni una segunda semántica, y no debe confundirse con el perfil léxico complementario de la sección 11.

Por tanto, grammar_version = 0.2 identifica la gramática canónica común aplicada después de la resolución del perfil fuente explícito.

13. Reconciliación de cierres internos heredados

La forma vigente de las producciones heredadas connector_decl y table_decl sustituye únicamente el cierre interno de mapping y table conservado en el texto histórico v0.1. El bloque interno termina en } sin un punto y coma adicional antes de la llave de cierre de la declaración:

connector_decl             ::= "connector" identifier "{"
                               "source_codomain" ":" identifier ";"
                               "target_position" ":" nat ";"
                               "mapping" ":" "{"
                                   { identifier "->" tri_literal ";" }
                               "}"
                               "}" ;

table_decl                 ::= "admissibility_table" identifier "{"
                               "input_codomains" ":" list<identifier> ";"
                               "output_codomain" ":" identifier ";"
                               "table" ":" "{"
                                   { tuple_literal "->" identifier ";" }
                               "}"
                               "}" ;

Esta reconciliación fija normativamente la forma ya adoptada por el corpus canónico y por la realización Rust. No amplía el lenguaje, no modifica la semántica de Connector o AdmissibilityTable y no cambia los números de versión de Gramática, IR o serializador. La redacción v0.1 se conserva sin modificación como antecedente histórico.

14. Recepción de la multiplicidad y el orden de campos opcionales · RETP-087

Las producciones heredadas de v0.1 §§5.4–5.5 admiten cada campo entre corchetes cero o una vez, en el orden de la producción. SemanticRelation admite table seguido de constraints; Pattern, arity seguido de constraints. La omisión de cualquiera permite declarar el otro. TransitionData.metadata y entry.transition también son opcionales singulares, en sus posiciones declaradas. Estas reglas afectan a los campos, no a la multiplicidad de los elementos de sus listas.

Repetir un campo, aunque repita el mismo valor o comience con una lista vacía, no es una forma de actualización: se rechaza durante el análisis, antes de perder una ocurrencia o emitir IR. La inversión de los dos campos de §5.4 también se rechaza; no se reordena la fuente. Los perfiles ES/EN comparten la producción después de resolver sus formas constitutivas.

Esta recepción corrige DFL-010 en las dos rutinas de análisis Rust que sobrescribían campos. No crea sintaxis ni cambia las versiones. La radiografía N0 §18 identifica diagnóstico, pruebas y límites; el rechazo efectivo es Frontend(UnexpectedToken(...)). Rectificación RETP-088: la atribución previa a E001 era incorrecta; E001 significa InvalidTriValue. La obligación de estos campos se identifica por esta §14, sin crear un código diagnóstico.

15. Declaración de Ternarizer y límite de ejecución · K1-T / RETP-088

Se conserva ternarizer_decl de v0.1 §5.2 y su descenso declarativo. Sus identificadores no definen conjuntos ni una función ejecutable. Las operaciones de v0.1 §5.7, con las correcciones de esta v0.2, no contienen una llamada al ternarizador. Ni el nombre de la declaración ni el de su mapping autorizan código anfitrión. Las formas inventadas ternarize(...)/ternarizar(...) no son primitivas ni palabras constitutivas nuevas.

La IR 0.3 §2.4 delimita la ruta productiva no habilitada y las obligaciones previas a su eventual incorporación. No se modifica la gramática, las tablas ES/EN ni las versiones.

GRAMATICA SUPERFICIAL MINIMA SV v0 2.md